Моделирование архитектуры предприятия. Обзор языка ArchiMate

Проект создания ArchiMate

Язык ArchiMate был разработан в Нидерландах в рамках исследовательского проекта, возглавляемого Telematica Instituut1, в сотрудничестве с рядом организаций и университетов. Финансирование осуществлялось голландским правительством, банком ABN AMRO, пенсионным фондом Stichting Pensioenfonds ABP и Centrum voor Wiskunde en Informatica2. После завершения проекта язык ArchiMate был опробован и использован в таможенной и налоговой администрации Нидерландов, ABN AMRO и ABP Pension Fund [2, 3].

В 2008 году право собственности и дальнейшего развития ArchiMate было передано одной из ведущих организаций по разработке открытых и независимых от поставщиков ИТ-стандартов - консорциуму The Open Group, активно развивающего стандарт архитектуры предприятия TOGAF [9]3. В феврале 2009 года в качестве технического стандарта была опубликована первая версия языка The ArchiMate 1.0 Specification. В 2012 году вышла вторая версия The ArchiMate 2.0 Specification, а также была введена сертификационная программа, которая включает сертификацию специалистов, аккредитацию обучающих курсов и сертификацию программных средств, поддерживающих стандарт языка ArchiMate. Сейчас действует модификация второй версии стандарта The ArchiMate 2.1 Specification, опубликованная в 2013 году [4]. О ней и пойдет речь в статье4.

Исходные положения при создании языка

Созданию языка ArchiMate предшествовала большая информационно-аналитическая работа, в ходе которой был проведен анализ сложившейся практики разработки архитектуры предприятия и определены потребности заинтересованных сторон в проектировании, коммуникациях и представлении, реализации и управлении изменениями архитектуры предприятия [5].

В конечном итоге в ходе всестороннего анализа целей и требований удалось сформулировать исходные положения, которых разработчики придерживались при создании языка, и основные свойства, которыми должен обладать язык описания архитектуры общего назначения [4, 5]:

• сервисная ориентированность языка - понятие «сервис» удобно и наглядно для представления взаимодействий внутри системы5 или между системами. К тому же, сервисы уже используются в разных предметных областях и понятны различным заинтересованным сторонам;
• послойное строение языка - заимствование из архитектурных фреймворков точки зрения на предприятие как на систему различных систем, образующих слои (уровни) представления предприятия;
• связность языка - введение в состав языка набора четко определенных отношений, которые устанавливают связи и зависимости как внутри предметных областей, так и между ними;
• компактность языка - ограничение набора понятий языка таким образом, чтобы, оставаясь простым и доступным, язык был достаточным для моделирования 80 % архитектурных задач;
• язык уровня предприятия - акцент на более крупный уровень детализации, чем в языках, используемых для моделирования на более низких уровнях (например, UML - для моделирования приложений, BPMN - моделирование бизнес-процессов);
• совместимость языка - совместимость понятий языка с понятиями языков на других уровнях моделирования, например, понятия проектного управления должны без затруднений выражаться более общими понятиями архитектурного языка;
• прагматичность - максимальное использование понятий и конструкций из других языков там, где это возможно;
• расширяемость языка - определение механизмов и средств расширения понятий, входящих в ядро языка, для отражения специфики исследуемых предметных областей;
• независимость языка от конкретных архитектурных фреймворков и методологий.

Базовые понятия языка - элементы и отношения

К базовым понятиям языка относятся понятия «элемент» и «отношение» [4, 5]. Именно на основе элементов и отношений строятся описания (создаются модели) предприятия или его отдельных частей. Элементы - это «кирпичики» различного содержания, формы и предназначения, а отношения - различного рода соединения, связывающие элементы.

Элементы. Элементы в языке различаются по трем признакам, или аспектам (рис. 1) [4]:

Рис. 1. Метамодель - основные понятия языка.

• структурный/поведенческий;
• внешний/внутренний взгляд на систему;
• индивидуальный/коллективный.

Первый аспект разделяет элементы языка на три типа: активный структурный элемент, пассивный структурный элемент и элемент поведения.

1. Активный структурный элемент (active structure element) определяется как некая сущность, которая способна выполнять определенные действия. Это могут быть бизнес-исполнители, компоненты приложений или устройства, которые реально исполняют те или иные действия.
2. Пассивный структурный элемент (passive structure element) определяется как некоторый объект, на котором выполняются действия. Обычно это информационные объекты или объекты данных, также они могут быть использованы для представления физических объектов, над которыми выполняются те или иные действия.
3. Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.

Элементами поведения являются процессы, функционалы (функции), сервисы и события. Они назначаются активным структурным элементам, чтобы показать, кто или что производит те или иные действия. Следует отметить, что разделение элементов по аспекту «структурный/поведенческий» похоже на структуру человеческих языков, в которых в состав предложений входят существительное-подлежащее (в ArchiMate - активный структурный элемент, то есть субъект поведения), глагол-сказуемое (элемент поведения, то есть выполнение поведения) и существительное-дополнение (пассивный структурный элемент, то есть объект, на котором выполняется поведение).

Пример 1. Использование элементов «бизнес-исполнитель», «бизнес-роль», «бизнес-процесс» и «бизнес-сервис»6.

В модели показана страховая компания, которая представляется как бизнес-исполнитель. В ее состав входят два отдела - отдел страхования багажа и отдел страхования поездок (рис. 2). Отделу страхования поездок назначена бизнес-роль по продаже соответствующих страховок - «Продавец страховок на поездки». В этой роли отдел страхования поездок выполняет бизнес-процесс по выписыванию страхового полиса - «Выписать страховку на поездку». Данный бизнес-процесс реализует бизнес-сервис страхования поездок, который предоставляется потребителю.

Рис. 2. Пример использования элементов «бизнес-исполнитель», «бизнес-роль», «бизнес-процесс» и «бизнес-сервис».

Второй аспект различает внешний и внутренний взгляды на систему, и на этой основе вводятся понятия «сервис» и «интерфейс» (рис. 1.).

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

Сервисы являются основными связующими звеньями между различными слоями. Например, приложение обеспечивает сервисы для слоя бизнес-процессов и, в свою очередь, использует сервисы инфраструктурного слоя. Исходя из этого, различают внутренние и внешние сервисы. Внутренние сервисы - это сервисы, доступные внутри данного слоя; внешние сервисы - это сервисы слоя, доступные извне данного слоя. В таблице 1 суммируется разделение элементов на структурные/поведенческие и на внешние/внутренние, которое играет центральную роль в языке [9].

Таблица 1. Распределение элементов языка по аспектам структурный/поведенческий и внешний/внутренний.

Пример 2. Использование элементов «функционал приложений», «сервис приложений» и «интерфейс приложений».

В модели показано, что сервис приложений «Сервис обработки транзакций» реализуется функционалом приложений «Учет» и доступен другим компонентам через интерфейс приложений «API обработки транзакций» (рис. 3). Функционал приложений «Учет» выполняется компонентом приложений «Компонент учета». Сервис приложений «Обработка транзакций» используется функционалом приложений «Биллинг», который выполняется компонентом приложений «Компонент биллинга». Функционал приложений «Биллинг» предлагает сервис приложений «Сервис создания накладной», который может быть использован для поддержки бизнес-процессов. Данный сервис доступен через интерфейс приложений «Экран биллинга».

Рис. 3. Использование элементов «функционал приложений», «сервис приложений» и «интерфейс приложений».

Пример 3. Продукт, состоящий из нескольких бизнес-сервисов.

В модели показан продукт «Телебанкинг», предлагаемый клиентам (рис. 4). Открытие счета и поддержка приложений (например, helpdesk и т. п.) осуществляется соответствующими бизнес-сервисами, которые реализуются бизнес-исполнителем «Клиентский отдел». Как часть продукта потребитель может также использовать банковский сервис, который предлагает такие сервисы приложений, как электронный денежный перевод и предоставление статуса счета. Сервисы приложений реализуются компонентом приложений «Телебанкинг».

Рис. 4. Продукт, состоящий из нескольких бизнес-сервисов.

Третий аспект учитывает то, что определенное действие (поведение) может выполняться одним структурным элементом и коллективом, то есть совместно несколькими структурными элементами (например коллективом сотрудников). Соответственно выделяют активный структурный элемент «совместная бизнес-деятельность» и элемент поведения членов этого коллектива - «взаимодействие».

1. Совместная деятельность (collaboration) определяется как группировка (или объединение) - возможно, временная - двух или более структурных элементов для выполнения некоторого совместного поведения.
2. Взаимодействие (interaction) определяется как единица поведения, выполняемая в рамках совместной деятельности двух или более структурных элементов.

Пример 4. Использование элемента «совместная бизнес-деятельность».

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

Рис. 5. Использование элемента «совместная бизнес-деятельность».

Отношения. Отношения в языке - это различного рода соединения, связывающие элементы и определяющие свойства этих соединений (например, физические/логические, между структурными элементами и элементами поведения). Отношения в языке разделяются на три группы: структурные, динамические и другие.

• Структурные отношения - это отношения, которые моделируют структурные зависимости между элементами одного или разных типов.
• Динамические отношения - это отношения, которые используют для моделирования зависимостей между элементами поведения (действиями).
• В группу «другие» относят отношения, которые не входят в первые две группы. Многие из отношений были заимствованы из существующих стандартов: например, композиция (composition), объединение (aggregation), ассоциация (association) и специализация (specialization) взяты из UML 2.0, а запуск (triggering) используется во многих языках моделирования бизнес-процессов.

Полный перечень элементов и отношений, образующих ядро языка ArchiMate, представлен соответственно в приложениях 2 и 3 в конце статьи. Эти типы элементов и отношений поддерживают моделирование архитектур на фазах B (Бизнес-архитектура)), C (Архитектура информационных систем) и D (Технологическая архитектура) метода разработки архитектуры TOGAF.

Слои языка

Обычно архитектурные описания делают для различных областей, или так называемых «слоев» организации. Эти области называют слоями в том смысле, что более нижние слои обеспечивают функциональность более высоким. В этом контексте для описания предприятия в языке определяются три основных слоя: бизнес-слой, слой приложений и технологический слой [4]. Они хорошо соотносятся с фазами TOGAF и с соответствующими архитектурами - B (Бизнес-архитектура), C (Архитектура информационных систем) и D (Технологическая архитектура). В каждом слое используется общая концепция элементов языка (с их аспектами) и отношений. Это позволяет выделить в слоях несколько доменов, описывающих различные предметные области в рамках слоя. Соотношение слоев, элементов и отношений языка и архитектурных доменов показано на рисунке 6 [6, 7].

Рис. 6. Соотношение слоев и аспектов языка и архитектурных доменов.

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

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

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

Взаимосвязи между слоями формируются отношениями «использование» и «реализация»:

• отношение типа «использование» показывает, как более высокий слой использует сервисы более низкого слоя;
• отношение типа «реализация» показывает, как элементы более низких слоев могут реализовывать сопоставимые элементы более высоких слоев.

Например, элемент «объект данных» в слое приложений может реализовывать элемент «бизнес-объект» в бизнес-слое. А элемент «артефакт» в технологическом слое может реализовывать элемент «объект данных» или элемент «компонент приложений» в слое приложений.

Пример 5. Многослойное представление архитектуры предприятия.

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

Рис. 7. Многослойное представление архитектуры предприятия.

Механизмы расширения языка

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

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

• через добавление дополнительных атрибутов к существующим понятиям (механизм профилирования);
• через определение новых понятий на основе уже существующих (механизм специализации).

Начиная с версии 2.0 в язык включены два расширения его ядра: расширение, связанное с мотивационными факторами, и расширение, связанное с реализацией и переходом.

Первое расширение необходимо для поддержки фаз A (Видение архитектуры) и H (Управление изменениями архитектуры) метода разработки архитектуры TOGAF, а также предварительной фазы и фазы управления требованиями. Для этого ядро языка было расширено элементами и отношениями, связанными с мотивационными факторами: «заинтересованная сторона», «драйвер», «требования» и т. д. Перечень элементов и отношений, связанных с мотивационными факторами, дан в приложении 4.

Второе расширение предназначено для поддержки фаз E (Возможности и решения), F (Планирование перехода) и G (Руководство реализацией) метода разработки архитектуры TOGAF. Для этого ядро языка было расширено элементами и отношениями, связанными с реализацией и переходом: «пакет работ», «поставляемый результат», «разрыв» и т. д. Перечень элементов и отношений, связанных с реализацией и переходом, приводится в приложении 5.

Способы представления

Полная модель архитектуры предприятия достаточно сложна и объемна. Более того, заинтересованные стороны часто самостоятельно определяют требуемые им представления общей архитектуры предприятия. Для этого язык вводит понятие «представление» (view) архитектуры и обеспечивает гибкий подход к работе с архитектурными представлениями.

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

Представления задаются способами представления (точками зрения, viewpoints), которые используются для показа определенных аспектов архитектуры по отдельности или в связке.

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

Можно сказать, что представление - это то, что мы видим, а способ представления - это точка зрения, с которой мы смотрим [4]. Способ представления позволяет фокусировать внимание на определенных аспектах архитектуры, которые определяются интересами заинтересованных сторон. Именно они в конечном итоге определяют, какие элементы и отношения будут включены в представление.

Способы представления классифицируются в языке по двум измерениям: по назначению и по содержанию. В свою очередь каждое из измерений разбивается соответственно на 3 типа и 3 уровня:

• по назначению - для проектирования, для принятия решений, для информирования;
• по содержанию - детальный уровень, уровень согласованности и обзорный уровень.

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

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

TOGAF и ArchiMate

TOGAFи ArchiMate являются стандартами The Open Group, которые непосредственно относятся к разработке архитектуры предприятия. С одной стороны, у TOGAF и ArchiMate имеются свои спецификации, и они могут использоваться по отдельности, независимо друг от друга, или вместе с другими стандартами. С другой стороны, существуют значительные преимущества при совместном использовании TOGAF и ArchiMate.

Основная цель языка в контексте методологии TOGAF - представление архитектурных моделей. ArchiMate дополняет TOGAF, обеспечивая необходимый набор понятий и обозначений. Язык позволяет создавать как отдельные модели, в том числе соответствующие представлениям TOGAF, так и модели, объединяющие различные домены архитектуры. С включением двух расширений язык полностью покрывает все фазы метода разработки архитектуры TOGAF (таблица 2).

Таблица 2. Использование понятий языка на различных фазах метода разработки архитектуры TOGAF.

В рамках консорциума The Open Group продолжаются работы по развитию ArchiMate, сближению его спецификации со спецификацией TOGAF. В частности, рассматривается разработка новых расширений языка, которые будут включать понятия для моделирования бизнес-политик и процессов принятия решений [6].

Литература

1. Q084 ArchiMate Forum. Information Sheets. The ArchiMate Forum of The Open Group. The Open Group, July 2014

2. Telematica Instituut. Annual Report, 2005.

3. Sethuraj Nair. ArchiMate: Its Time Has Come?

4. ArchiMate 2.1 Specification, Open Group Standard, December 2013.

5. M. Lankhorst et al, Enterprise Architecture at Work – Modelling, Communication and Analysis, Second Edition, Springer, 2009.

6. H. Jonkers, D. Quartel, H. Franken, ArchiMate for Integrated Modelling Throughout the Architecture Development and Implementation Cycle, Uporabna Informatika, 2012.

7. H. Jonkers, E. Proper, M. Turner, TOGAF and ArchiMate: A Future Together. A Vision for Convergence & CoExistence, The Open Group, November 2009.

8. TOGAF Version 9.1, The Open Group.

9. G. Berrisford, M. Lankhorst, Using ArchiMate with an Architecture Method. A conversation, 2009.

1 В 2009 году название организации было изменено на Novay.

2 Проект продолжался с июля 2002 года по декабрь 2004 года. Стоимость и трудоемкость проекта составили соответственно около 4 млн евро и 35 человеко-лет.

3 Information Management писал об этом стандарте в статьях «The Open Group Architecture Framework (TOGAF) Часть 1. Структура, ключевые понятия, модель и инструменты развития архитектуры, информационный контент» (Information Management № 4 2013) и «Часть 2. Континуум предприятия, ссылочные модели и управление развитием архитектуры» (Information Management № 5 2013).

4 Автором статьи выполнен перевод данной версии стандарта на русский язык.

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

6 Приведенные примеры взяты из спецификации языка [4].

Источник: vk.cc

Комментарии: