Следите за нашими новостями на Facebook! Всегда что-нибудь интересное ;)
Будьте в курсе!
Подпишитесь на нашу рассылку, и мы будем присылать вам интересные статьи, анонсы и новости.
Алексей Лосев
Директор по разработке

  • Кандидат физико-математических наук.
  • Microsoft MVP (Most Valuable Professional), Visual Studio and Development Technologies.
  • 18+ лет личного стажа разработчика ПО на платформе .NET.
  • 10+ лет управления командами разработки различного масштаба.
  • 8+ лет преподавания разработки ПО в МГТУ им. Баумана.
  • Выстраивание процессов разработки ПО по Agile (Scrum) и внедрение управления проектами по PMBOK.
  • Управление разработкой банковского ПО в части ITSM информационной безопасности, внутренней автоматизации.Лучшие практики ITSM (ITIL).

Архитектор, а какой ты?

Бизнес-правила являются причиной существования программной системы. Они составляют основу функционирования. Они порождают код, который делает или экономит деньги. Они — наши семейные реликвии.

© Роберт Мартин
Which the?
Software Architector
Togaf
Модель Закман
В прошлых статьях мы обсудили, кто такой архитектор и какую пользу он приносит компании. Сегодня предлагаю поговорить, а какие архитекторы бывают.

Родоначальником формализации архитектуры корпоративных информационных систем можно считать Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture», в которых и было описано то, что получило название модель Захмана.
Взаимосвязь архитектурных артефактов по модели Togaf
модель архитектуры программных решений Закмана
Данная модель, несмотря на сложный вид, продвигает достаточно простую концепцию. Для разных людей при описании разных частей системы (под системой здесь понимается все предприятие) необходимо использовать разные модели, главное, чтобы они согласовывались между собой. Сам Захман пояснял это на примере строительства загородного дома. Архитектор садится с заказчиком и высокоуровнево обсуждает, что должно быть на участке и в доме. Результатом такой работы является концептуальный план, который в процессе работы архитектора превратиться в план водоснабжения для сантехников, архитектурный план для строителей, план электропроводки для электриков. И задача архитектора следить, чтобы все эти планы были между собой согласованы (чтобы не получилось, что водоснабжение придет в спальню, вместо санузла).

Существенным минусом при описании корпоративной архитектуры в модели Захмана является то, что она ориентирована на ситуацию конца восьмидесятых - начала девяностых прошлого века. На тот момент у компаний была одна-две информационные системы и сложности были в основном в их разработке. У современных компаний, особенно крупных, которые и испытывают потребность в архитектурных артефактах, основная проблема не в развитии отдельной информационной системы (хотя и с этим есть сложности), а в том, как не потонуть в том зоопарке систем, который исторически сложился и требует все более сложных и сложных интеграций.

Переходя на более высокий уровень, Togaf предлагает из всех столбцов оставить только 4 домена: бизнес деятельность, данные, приложения и технологии. При этом, ничто не мешает думать про корпоративную архитектуру в тех же уровнях детализации: от контекстного, через концептуальный и логический, к физическому и непосредственной реализации. В этом случае получится следующая модель:

модель архитектуры программных решений Togaf
На этой модели уже будет удобно обсудить, кто и за что отвечает. Большинство архитекторов находятся на трех верхних уровнях, и различаются названием доменом с которым работают. На двух последних уровнях чаще говорят уже про исполнителей:
Классическая модель разработки архитектуры программных решений, присущая большинству компаний
До такого разделения на зоны ответственности, может, не с выделением всех ролей, большинство компаний доходит достаточно быстро, но, как мы обсуждали в прошлой статье, максимальной пользы от разрозненных архитектур получить, как правило, не удается. Для этого должны появиться интегрирующие роли: архитектор решений и тот самый корпоративный архитектор.
Корпоративный архитектор и архитектор решений
Архитектор решений отвечает за результаты работы архитекторов, привлекаемых в рамках конкретного решения (отдельной информационной системы), причем, его должно интересовать все: от бизнес-процессов, в поддержке которых участвует решение, до того, как это решение развернуто. Понятно, что все это ему нужно не в тех деталях как, например, архитектору инфраструктуры, да и не по всей компании. Но то, что касается его решения – нужно.

Корпоративный архитектор отвечает больше за согласованность высокоуровневых вещей между доменами. Он не знает всех деталей реализации конкретного решения, но как это решение вписывается в общую картину и взаимодействует с другими системами — это его зона ответственности.

На этом цикл концептуальных статей про архитектуру можно заканчивать и переходить к самому интересному - к деталям.