Для комплексного моделирования архитектуры предприятия когда-то был создан язык ArchiMate. Его концепции не были придуманы с нуля, а базировались на существовавших к тому времени подходах, методологиях, фрейморках и других языках моделирования (см., например, ¹). Основной целью был именно комплексный подход к моделированию предприятия: общая нотация для всех организационных ролей — владельцев, системных архитекторов, аналитиков, управленцев, программистов, инженеров и всех остальных. Модель предприятия должна была выражаться через архитектурные описания, оформленные как формализованные структурированные документы с явно выраженными сущностями и связями между ними.

Предполагалось, что через ArchiMate можно выразить архитектуру любого предприятия, однако максимальная эффективность предполагалась для компаний, использующих для функционирования современные информационные технологии. Ориентирами при создании служили UML, BPMN, Zachman Framework, TOGAF — все они уже активно использовались бизнесом и каждый из них отражал определённый аспект моделирования. Также активно изучался опыт реальных организаций, чтобы язык не был чисто академическим исследованием, а был максимально прикладным.

Формальная спецификация² ArchiMate довольно компактная, однако для понимания требует тщательного изучения (как и почти любая спецификация). Авторы сознательно ограничили набор используемых информационных элементов и не стремятся к его увеличению в каждой новой версии, поэтому процесс моделирования существующей организации на ArchiMate может оказаться особенно сложным, так как придётся для каждого объекта деятельности подбирать подходящий информационный элемент для его описания.

Графическая нотация ArchiMate в многом позаимствована из существующих языков моделирования, однако семантика некоторых элементов может отличаться от знакомой по другим инструментам. Визуальное представление ArchiMate документа не является главным, это не просто набор рисунков из разноцветных блоков и стрелочек, модель языка предполагает жёсткие и чётко формализованные связи, некоторые из которых могут отсутствовать на конкретной графической диаграмме, но присутствовать в файле документа с полным описанием модели. Из-за ограниченности набора информационных элементов нужно тщательно выбирать, что именно необходимо использовать для представления реального бизнес-объекта или процесса. В мета-модели³ ArchiMate предполагается, что архитектурное описание не нужно видеть «целиком», вместо этого для конкретных заинтересованных сторон создаются представления (views), которые неформально можно представить как диаграммы, доносящие информацию для конкретной точки зрения (viewpoint) определённой заинтересованной стороны. Например, для точки зрения директоров будет своя диаграмма, проецирующая большую общую модель на интересы именно директоров. Аналогично для программистов, инженеров сопровождения и других бизнес-ролей организации.

Также при дизайне языка явным образом учитывались аспекты использования создаваемых моделей: они должны быть читабельными и эффективно доносить заложенную информацию даже до тех, кто не является экспертом в ArchiMate. И для этого необходима очень высокая квалификация архитекторов — тех людей, кто формализует и записывает архитектурные описания. Чтобы поддерживать целостность модели, необходимо для моделирования использовать соответствующее программное обеспечение, которое способно создавать и поддерживать все информационные элементы и связи из спецификации языка. Фактически эталонной реализацией является проект Archi, он бесплатный и с открытым исходным кодом. Поддержка ArchiMate в той или иной степени реализована во множестве других продуктов, однако часто она ограничена только визуальным аспектом (как, например, в draw.io).

⚜︎ ⚜︎ ⚜︎

В спецификации ArchiMate помимо мета-модели языка (которая описывает набор элементов и связей) также предлагается свой фреймворк (framework), то есть конкретный метод использования элементов для описания архитектуры. В рамках фреймворка версий ArchiMate с самого начала⁴ предлагался иерархичный способ организации элементов в модели через слои (layers):

• на верхнем (внешнем) слое элементы деятельности / бизнеса (business layer), через которые описывается поведение и представление организации в её окружении;
• далее слой приложений (appplication layer), то есть как реализуются элементы слоя бизнеса через программное обеспечение;
• и в конце технологический слой, то есть как реализуются элементы слоя приложений технологически / физически.

Иллюстрация из спецификации ArchiMate 3.2, © The Open Group

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

Иллюстрация из спецификации ArchiMate 3.2, © The Open Group

На каждом слое были элементы двух типов: элементы структуры (structure elements), описывающие сущности (объекты и субъекты), и элементы поведения (behavior elements), описывающие взаимодействие с элементами структуры. Например, функция (function) или сервис (service) были свои на каждом из базовых слоёв — бизнеса, приложений и технологическом.

⚜︎ ⚜︎ ⚜︎

Такая жёсткая иерархия со слоями вызывала много проблем и претензий, при моделировании реальных организаций возникали сложности с идентификацией элементов модели, было непонятно, какой где использовать и почему. Реальные цельные сущности приходилось искусственно разделять на элементы соответствующих слоёв, а итоговая ArchiMate-модель концептуально сильно отличалась от фактической ментальной модели. Аналогично с элементами поведения — их привязка к трём слоям не соответствует фактической архитектуре, где поведенческие сущности часто по факту «размазаны» между формальными слоями.

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

⚜︎ ⚜︎ ⚜︎

По всей видимости, претензий накопилось столько, что разработчики ArchiMate их приняли к сведению, обработали и представили по-настоящему революционную редакцию стандарта, опубликованную пока в виде предварительного снапшота ArchiMate Next⁵, который со временем станет четвёртой версией. Очевидно, что до финальной версии пока далеко и в процессе обсуждений многое может поменяться, но общий вектор развития очевиден — ослаблять формализм и снижать требования к строгости. Ниже короткий обзор изменений из первого снапшота.

Самое главное — революционное — изменение, которое полностью меняет привычный подход к моделированию из прошлых версий — это отказ от слоёв. Их больше нет в модели, вместо них области⁶ (domain) без линейной иерархии, но с множеством точек взаимного пересечения, и это отражено в новых иллюстративных описаниях, оформленных в виде шестиугольника (“ArchiMate Hexagonion”):

ArchiMate Core Framework, Иллюстрация из спецификации ArchiMate Next Snapshot 1, © The Open Group

ArchiMate Full Framework, Иллюстрация из спецификации ArchiMate Next Snapshot 1, © The Open Group

Названия областей преобразованы из названий слоёв прошлой версии спецификации, а также добавлена новая Общая область (Common Domain), в которую перенесены элементы поведения, также Role, Collaboration и Path. Во всех остальных областях (кроме Strategy Domain) элементов поведения больше нет. Отдельно отмечу перенос элемента Role из слоя бизнеса в общую область, теперь элементы активной структуры из любой области можно назначать на роль.

Удалена связь композиции (composition relationship), это одно из самых обсуждаемых и спорных изменений. Удаление самой сильной структурной связи фактически убирает из модели возможность указания монопольного владения и принадлежности.

Удалены элементы поведения Business Interaction, Application Interaction, Technology Interaction, им не нашлось места в общей области и я с этим соглашусь, так как семантически было не очень понятно, зачем они изначально были выделены в отдельные элементы, если фактически они повторяют семантику процесса или функции, которыми и предлагается заменять.

Удалён элемент Constraint из слоя мотивации, вместо него предлагается использовать Requirement из области мотивации. Это тоже спорное, хотя и понятное изменение — разница между элементами неочевидна, вызывала споры и вопросы.

Из слоя бизнеса удалён элемент Контракт (Contract), вместо него предлагается использовать Бизнес-объект (Business object) с соответствующей специализацией. Это изменение я в целом поддерживаю, не было какой-то прямо острой необходимости выделять из всех бизнес-объектов именно контракт.

Также из слоя бизнеса удалён элемент Носитель информации (Representation), вместо него предлагается использовать (в зависимости от контекста) Объект данных (Data object) из области приложений, Артефакт (Artifact) или Материал (Material) из технологической области. Насколько я понял, он был удалён за ненадобностью, поскольку его роль уже играл объект данных (и транзитивно через него артефакт или материал).

Из слоя имплементации и миграции удалён элемент Расхождение (Gap), вместо него предлагается использовать Оценку (Assessment) из области мотивации или Поставляемый результат (Deliverable) из области имплементации и миграции. Тут без комментариев.

⚜︎ ⚜︎ ⚜︎

Вот пример, как изменения повлияли на ключевую диаграмму, иллюстрирующую взаимодействие между элементами Core Framework Layers / Core Framework Domains. Как было в версии 3.2:

Иллюстрация из спецификации ArchiMate 3.2, © The Open Group

И как стало в грядущем стандарте:

ArchiMate Core Framework, Иллюстрация из спецификации ArchiMate Next Snapshot 1, © The Open Group

⚜︎ ⚜︎ ⚜︎

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

Примечания¶