Нередко при разборе вопросов управления архитектурой предприятия (enterprise architecture management) возникает путаница между способами деления этой огромной, сложной области на части. Что нужно и для анализа, и для определения критичных взаимосвязей и для определения необходимых ролей. Грэхем Беррисфорд даёт в довольно компактной заметке объясняет, как, по его мнению, это деление сделано в TOGAF. В том числе автор обозначает более чёткую границу между архитектурой предприятия (enterprise architecture) и архитектурой решения (solution architecture).
Сначала, про то, что в TOGAF называется доменами. Это распространённое деление BDAT:
Это области архитектуры, в каждой из которых решаются свои, специфичные вопросы. Решаются, разумеется, таким образом, чтобы складывалась целостная, непротиворечивая картина всего предприятия. Действительно, в большинстве архитектурных проектов необходимо разобраться с:
Помимо этих доменов, есть области (тоже домены), решая вопросы в которых, мы будем вынуждены работать во всех четырёх вышеперечисленных доменах. Например: руководство, безопасность, действующие силы и т.п. Последние как бы пересекают четыре домена из списка выше.
В описании уровней автор добавляет к скупому описанию стандарта TOGAF о том, что это уровни деления (гранулярности) следующее, можно сказать лирическое, уточнение.
Архитектура, которую мы можем осмысленно обсуждать, это то, что мы можем видеть, наблюдая реальность непосредственно или глядя на конкретное ее представление. Невозможно непосредственно наблюдать больше, чем крошечный фрагмент бизнеса. Аспекты BDAT предприятия могут быть представлены на разных уровнях абстрагирования от деталей бизнес-операций в реальности.
Архитекторы предприятия (enterprise architects) рассматривают общую картину, принимая высокоуровневый, широкий, стратегический взгляд, возможно охватывающий более одной организации, на системы бизнес-деятельности и ИТ, от которых они зависят. Архитектура предприятия — это все, что вы можете задокументировать с помощью:
с отображением связей между ними.
Архитекторы решений (solution architects) работают над подмножеством архитектуры предприятия и на более низком уровне проектирования, чем может быть реализовано на уровне всей организации. Архитектура решения может быть описана в общем виде так:
Детальное проектирование или архитектура программного обеспечения могут разрабатывать заданную архитектуру решения, дополняя структуру компонентов и API приложения, решать вопросы детального проектирования схем данных, сообщений и обмена сообщениями между приложениями.
Эти три уровня пересекаются. В терминах модели С4 (Context – контекст, Containers – контейнеры, Components – компоненты, Code – код) их можно выделить следующим образом:
Если свести всё вместе, то получается в общем виде что–то типа:
Разумеется, разные компании по-разному организуют работу с архитектурой. В некоторых архитектор может работать в более чем одном домене и на более чем одном уровне. У некоторых есть дополнительные архитектурные роли. Например, специалисты архитектуры безопасности – это нередко отдельная команда, которая вовлекается во многих областях.
Но обычно архитекторы уровня предприятия специализируются на конкретных доменах BDAT, тогда как от архитекторов решений ожидается достаточное знание во всех четырёх доменах.
Архитекторы предприятия осуществляют надзор за портфелями приложений и технологий компании. Они направляют и управляют изменениями в этих портфелях, стремясь интегрировать системы в масштабах всего предприятия, стандартизировать процессы, описание данных и технологии. Их работа может быть относительно стратегической (как правило, от 2 до 10 лет). Они создают относительно абстрактные модели и дорожные карты.
Целью архитекторов предприятия является определение дорожных карт для бизнес-процессов, приложений и платформенных технологий предприятия. Задача состоит в том, чтобы координировать эти дорожные карты доменов.
Чтобы охватить домены BDAT, команда архитекторов предприятия может включать в себя специалистов по соответствующим архитектурным доменам. В отличие от них, архитекторы решений должны знать достаточно обо всех предметных областях, чтобы гарантировать, что решение будет работать в целом.
Архитекторы решений обычно связаны с конкретным проектом, в рамках которого разрабатывается или изменяется одно или несколько приложений и/или способ взаимодействия приложений. Они могут стремиться предоставить решение для одного направления бизнеса, использовать узкие определения процессов и данных, а также технологии. Их работа носит относительно тактический характер (как правило, от 6 месяцев до 2 лет). Они создают относительно конкретные модели и пути миграции.
Тактические решения, необходимые направлениям бизнеса, могут пересекаться с дорожными картами на уровне предприятия. Задача состоит в том, чтобы скоординировать эти два уровня.
На крупном и разнородном предприятии может существовать уровень между корпоративными архитекторами и архитекторами решений. Директор по архитектуре сказал мне, что: «Чтобы дать полный охват бизнеса, у нас есть:
Дополнительно в этой же заметке, ссылаясь на стандарт SFIA (Skills Framework for the Information Age – система навыков и компетенций для цифрового мира), Грэхем Беррисфорд приводит варианты профилей компетенция для различных ролей, которые могут потребоваться в вышеописанных областях.
Оригинал заметки (англ.) здесь.
