Хочу совсем кратко рассказать об изменениях, которые случились в формате и содержании тренинга по архитектуре ИТ-решений и которые я впервые представлю уже в июне в курсе ITARC «Разработка и управление ИТ-архитектурой», организованном компанией IT Expert. Мы затронем два основных вида деятельности solution architect: выбор и защита варианта реализации ИТ-проекта и декомпозиция решения — определение набора изменений, необходимых для реализации проекта.
Теперь эти две части логически разделены. Т.е. сначала мы учимся структурировать тот массив информации, который нам любезно предоставили заказчики и бизнес-аналитики: описание продукта или услуги, бизнес- и функциональные требования, знания, касающиеся предметной области и все остальное. Основные инструменты этой деятельности – это варианты использования в стиле Алистера Коберна, функциональные и концептуальные карты (см. Функциональные карты и диаграммы вариантов использования). В общем все, что у нас есть в качестве входной информации должно преобразиться в простую и понятную картину, отвечающую на вопрос: «что хочет заказчик?», пару рисунков и несколько страниц в корпоративной wiki системе. Затем мы придумываем пару-тройку вариантов реализации и визуализируем их при помощи инструмента use case maps. Дальше начинается более сложное. Получившийся «технический рисунок» проекта необходимо снабдить коротким интересным рассказом – убедительной историей, объясняющей наш выбор. Эти техники мы берем из тренинга «Презентация ИТ-проекта», который я имел удовольствие провести для нескольких корпоративных заказчиков пару лет назад.
Работа архитектора ИТ-решений не заканчивается согласованием варианта реализации. Самая интересная часть работы – проектирование. И вот в этой части тренинга произошли довольно существенные изменения. Во-первых, дело в [микро]сервисах. Если архитектору раньше достаточно было сказать, что данный функционал реализуется в том или ином приложении, и работа его на этот была закончена, то теперь проектировать придется глубже. При разработке прикладной архитектуры мы неминуемо сталкиваемся с таким понятием, как bounded context и просто не можем обойти стороной Domain-Driven Design Эрика Эванса. В разделе про интеграционную архитектуру нам никуда не уйти от дискуссии REST vs. SOAP и разговора о микросервисах (см. и Докеры, контейнеры и прочие микросервисы. Как DevOps меняет жизненный цикл ПО ). А в блоке тренинга, касающегося технологической архитектуры появилась тема DevOps (см. Cloud-Native Application Architectures). Раньше инфраструктурное проектирование завершалось составлением списка оборудования и лицензионного ПО, которое следует закупить и установить и перечнем руководств администратору. Теперь ИТ-инфраструктура — это отдельный функциональный блок с описанием сценариев развертывания, сценариев аварийных и плановых работ, в общем всего того, что следовало бы автоматизировать.
Безусловно, два дня это совсем немного для обсуждения обозначенных тем. А еще надо успеть и про IT4IT рассказать и построения операционной модели ИТ коснуться. Представленный учебный курс – скорее введение в деятельность solution architect-а. Затронуть глубже одну из тем можно будете при проведении тренинга в трехдневном, корпоративном формате.
- Регистрация на тренинг на сайте IT Expert
- Запись вебинара: архитектура ИТ-решений (IT Expert 28 апреля 2016)