Архитектура предприятия и архитектура решений

Нередко при разборе вопросов управления архитектурой предприятия (enterprise architecture management) возникает путаница между способами деления этой огромной, сложной области на части. Что нужно и для анализа, и для определения критичных взаимосвязей и для определения необходимых ролей. Грэхем Беррисфорд даёт в довольно компактной заметке объясняет, как, по его мнению, это деление сделано в TOGAF. В том числе автор обозначает более чёткую границу между архитектурой предприятия (enterprise architecture) и архитектурой решения (solution architecture).

Домены (architecture domains)

Сначала, про то, что в TOGAF называется доменами. Это распространённое деление BDAT:

1. Бизнес-архитектура (B – business) – это бизнес-роли и процессы, которые создают цифровые данные для предоставления необходимых услуг и продуктов для достижения целей
2. Архитектура данных (D – data) — это информация, создаваемая и используемая в ходе выполнения бизнес-ролей и процессов.
3. Архитектура приложений (A -applications) — это приложения, используемые в ходе выполнения бизнес-ролей и процессов, а также способы их интеграции.
4. Инфраструктура или технологическая архитектура (T – technology)— это клиентские устройства, веб-серверы, ерверы приложений и данных, базы данных, промежуточное программное обеспечение, операционные системы, сети, коммутаторы, брандмауэры

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

1. С бизнес-процессами и ролями в них
2. Данными, создаваемыми и используемыми в п.1
3. Приложениями, необходимыми для сбора, анализа и предоставления п.2
4. Технология/инфраструктуры, необходимых для того, чтобы обеспечить работу п.3

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

Уровни архитектуры (architecture levels)

В описании уровней автор добавляет к скупому описанию стандарта TOGAF о том, что это уровни деления (гранулярности) следующее, можно сказать лирическое, уточнение.

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

Архитекторы предприятия (enterprise architects) рассматривают общую картину, принимая высокоуровневый, широкий, стратегический взгляд, возможно охватывающий более одной организации, на системы бизнес-деятельности и ИТ, от которых они зависят. Архитектура предприятия — это все, что вы можете задокументировать с помощью:

• Иерархия бизнес-функций или способностей (capabilities {прим.пер. – в некоторых умных книжках называемых «практиками»})
• Модели сквозных бизнес-процессов или потоков создания ценности
• Портфель приложений
• Другая документация, например словарь данных

с отображением связей между ними.

Архитекторы решений (solution architects) работают над подмножеством архитектуры предприятия и на более низком уровне проектирования, чем может быть реализовано на уровне всей организации. Архитектура решения может быть описана в общем виде так:

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

Детальное проектирование или архитектура программного обеспечения могут разрабатывать заданную архитектуру решения, дополняя структуру компонентов и API приложения, решать вопросы детального проектирования схем данных, сообщений и обмена сообщениями между приложениями.
Эти три уровня пересекаются. В терминах модели С4 (Context – контекст, Containers – контейнеры, Components – компоненты, Code – код) их можно выделить следующим образом:

• Архитектура предприятия — уровень контекста приложения
• Архитектура решения — уровень контейнера/компонента приложения
• Архитектура программного обеспечения – уровень компонента/класса приложения.

Если свести всё вместе, то получается в общем виде что–то типа:

Разумеется, разные компании по-разному организуют работу с архитектурой. В некоторых архитектор может работать в более чем одном домене и на более чем одном уровне. У некоторых есть дополнительные архитектурные роли. Например, специалисты архитектуры безопасности – это нередко отдельная команда, которая вовлекается во многих областях.
Но обычно архитекторы уровня предприятия специализируются на конкретных доменах BDAT, тогда как от архитекторов решений ожидается достаточное знание во всех четырёх доменах.

Архитекторы предприятия осуществляют надзор за портфелями приложений и технологий компании. Они направляют и управляют изменениями в этих портфелях, стремясь интегрировать системы в масштабах всего предприятия, стандартизировать процессы, описание данных и технологии. Их работа может быть относительно стратегической (как правило, от 2 до 10 лет). Они создают относительно абстрактные модели и дорожные карты.

Целью архитекторов предприятия является определение дорожных карт для бизнес-процессов, приложений и платформенных технологий предприятия. Задача состоит в том, чтобы координировать эти дорожные карты доменов.

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

Архитекторы решений обычно связаны с конкретным проектом, в рамках которого разрабатывается или изменяется одно или несколько приложений и/или способ взаимодействия приложений. Они могут стремиться предоставить решение для одного направления бизнеса, использовать узкие определения процессов и данных, а также технологии. Их работа носит относительно тактический характер (как правило, от 6 месяцев до 2 лет). Они создают относительно конкретные модели и пути миграции.
Тактические решения, необходимые направлениям бизнеса, могут пересекаться с дорожными картами на уровне предприятия. Задача состоит в том, чтобы скоординировать эти два уровня.

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

• Архитекторы предприятия, фокус которых «наверх», на стратегии/консультировании.
• Архитекторы (специалисты) доменов, которые обеспечивают проверку и руководство на базе принципов и стандартов в своей области или бизнес-сегменте.
• Архитекторы решений, которые сосредоточены на поставке сквозных, комплексных решений.
• Архитекторы программного обеспечения, которые сосредоточены на структуре программного обеспечения и используемых шаблонах проектирования».

Дополнительно в этой же заметке, ссылаясь на стандарт SFIA (Skills Framework for the Information Age – система навыков и компетенций для цифрового мира), Грэхем Беррисфорд приводит варианты профилей компетенция для различных ролей, которые могут потребоваться в вышеописанных областях.

Оригинал заметки (англ.) здесь.