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

Статья подготовлена для корпоративного портала.

Бизнес-правила являются причиной существования 

программной системы. Они составляют основу функционирования. 

Они порождают код, который делает или экономит деньги. 

Они — наши семейные реликвии. 

-- Роберт Мартин

В прошлых статьях мы обсудили, кто такой архитектор и какую пользу он приносит компании. Сегодня предлагаю поговорить, а какие архитекторы бывают.

Родоначальником формализации архитектуры корпоративных информационных систем можно считать Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture», в которых и было описано то, что получило название модель Захмана.

Данная модель, несмотря на сложный вид, продвигает достаточно простую концепцию. Для разных людей при описании разных частей системы (под системой здесь понимается все предприятие) необходимо использовать разные модели, главное, чтобы они согласовывались между собой. Сам Захман пояснял это на примере строительства загородного дома. Архитектор садится с заказчиком и высокоуровнево обсуждает, что должно быть на участке и в доме. Результатом такой работы является концептуальный план, который в процессе работы архитектора превратиться в план водоснабжения для сантехников, архитектурный план для строителей, план электропроводки для электриков. И задача архитектора следить, чтобы все эти планы были между собой согласованы (чтобы не получилось, что водоснабжение придет в спальню, вместо санузла). 

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

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

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

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

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

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

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