Содержание курса

• Понятие «Архитектура»

• Бизнес-архитектура

• Информационная архитектура

• Архитектура прикладных решений. Область разработки прикладных систем

• Архитектура прикладных решений. Портфель прикладных систем

• Техническая Архитектура

• Подходы к построению Архитектуры

• Графический язык моделирования ArchiMate

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

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

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

ArchiMate в оригинале Architecture-Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес-процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

Важно понимать, что ArchiMate:

• Это НЕ методология (в отличие от TOGAF, который говорит «что делать»)

• Это НЕ инструмент (вроде Sparx EA, Archi или iServer)

• Это язык, который предоставляет единый набор понятий и обозначений (нотацию), чтобы все участники (бизнес-архитекторы, ИТ-архитекторы, разработчики, руководство) могли понимать друг друга.

7.1. Ядро языка

В основу идеи ArchiMate положены Слои (Layers), Аспекты (Aspects) и Отношения (Relationships).

7.1.1. Слои Архитектуры  

ArchiMate организует модель предприятия в три основных слоя, которые позволяют разграничить ответственность и фокус:

1) Слой деятельности (Business Layer): Описывает бизнес-процессы, услуги, функции, роли и организационные единицы. Это то, что делает компания и как она это делает.

Тезисы:

• Люди за информацией видят те объекты окружающего мира, которые эта информация изображает.

• У людей есть цели, полномочия и ответственность.

• Целенаправленная деятельность есть только на этом уровне.

2) Слой приложений (Application Layer): Описывает программные компоненты, которые поддерживают бизнес-слой. Это приложения и их взаимодействие.

Тезисы:

• Из одних данных программы делают другие данные, отличающиеся как форматом, так и содержанием.

• Никто никому ничего не обещает и не даёт поручений, не преследует никаких целей.

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

3) Технологический слой (Technology Layer): Описывает мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Инфраструктура: оборудование, системы, сети и сервисы, необходимые для работы приложений.

Тезисы:

• На уровне оборудования тоже есть программы, но они уже другого рода — тут уже никто не знает, что означают эти данные в реальном мире.

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

Эти слои связаны между собой отношениями «реализации» (realization) и «обслуживания» (serving).

Например:

• Технологический сервис «Хостинг БД» реализует Службу данных «API клиента».

• Приложение «CRM‑система» обслуживает Бизнес‑процесс «Оформление заказа».

7.1.2.  Аспекты (Aspects) слоя  

В ArchiMate каждый основной слой (Бизнес, Приложения, Технология) внутренне структурирован по трем одинаковым аспектам (или перспективам). Это позволяет единообразно описывать статическую структуру, динамическое поведение и информационную модель в любом контексте.

Внутри каждого слоя объекты делятся по следующим аспектам:

1. Активная структура (Active Structure): Элементы этого аспекта представляют собой субъектов — сущности, которые способны выполнять работу, проявлять поведение, принимать решения. Это "игроки на поле". Показывает кто/что выполняет поведение? (Роли, компоненты, системы).

2. Пассивная структура (Passive Structure): Элементы этого аспекта представляют собой объекты — сущности, над которыми совершаются действия, или которые несут информацию. Они пассивны по своей природе. (Данные, объекты, документы).

3. Поведение (Behavior): Элементы этого аспекта описывают динамичное поведение — процессы, функции, услуги, события. Это "работа", которую выполняют активные структуры. Показывает, что делают эти субъекты? (Процессы, функции, сервисы).

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

Классическая схема взаимодействия внутри одного слоя:

© Активная Структура → Поведение (отношение Assignment)

Активный элемент назначен на выполнение поведения. Пример: Business Role «Кассир» назначен (assigned to) на Business Process «Оформить заказ».

© Поведение → Пассивная Структура (отношение Access)

Поведение обращается к пассивному элементу (чтение, запись, изменение). Пример: Business Process «Оформить заказ» получает доступ (accesses) к Business Object «Заказ».

© Активная Структура → Пассивная Структура (отношение Association)

Активный элемент каким-то образом связан с пассивным (например, владеет им). Пример: Application Component «CRM‑система» ассоциирован (associated with) Data Object «Клиент».

Взаимодействие элементов можно представить так:

Где, Сервис — это единица функциональности системы предоставленная наружу системы, а Интерфейс — это точка доступа, где сервис становится доступным окружению.

7.1.2. Отношения (Relationships)  

Спецификация строго определяет, какие типы связей возможны между элементами. Основные:

1. Композиция (Composition) ▸: Сильное владение («часть не может существовать без целого»).

2. Агрегация (Aggregation) ◂: Слабое владение («часть может существовать отдельно от целого»).

3. Назначение (Assignment) ──⨀: Назначение роли исполнителю (например, Business Actor назначен на Business Role).

4. Реализация (Realization) ──➤: Один элемент реализует другой (например, Application Service реализует Business Service).

5. Обслуживание (Serving) ──☷: Один элемент предоставляет услугу другому.

6. Доступ (Access) ---> Отношение элементов поведения к бизнес-объектам или объектам данных. Процесс, функция, взаимодействие, служба или событие «делает что‑то» с объектом.

7. Ассоциация (Association) ──: Универсальная связь, когда другие отношения не подходят.

8. Специализация (Specialization) ──▷: Отношение «является разновидностью» (наследование).

9. Запуск (Triggering) ──➤

10. Использование (Used by) ──> Отношение моделирует использование сервисов процессами, функционалами или взаимодействиями, а также доступ к интерфейсам ролями, компонентами или в рамках совместной бизнес- деятельности.

7.2. Спецификация ArchiMate

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

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

Также для описания реальных сущностей и явлений часто используют расширение — «Мотивация» (Motivation Extension). Оно отвечает на вопросы: «ПОЧЕМУ?» и «ЗАЧЕМ?» существует та или иная архитектура.

Как видно из рисунка в ArchiMate существует устоявшаяся, широко принятая практика (de-facto стандарт), которая использует цвет для визуального разделения слоев и улучшения читаемости диаграмм. 

Итак, начнем рассматривать непосредственно элементы модели с уровня мотивации.

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

Это не просто список желаний, а формальная модель, которая отвечает на критически важные вопросы «Почему?» (Why?), «С какой целью?» (What for?) и «В каких рамках?» (Within what boundaries?) до того, как будут спроектированы процессы, приложения или инфраструктура. Это «архитектура для архитектуры».

7.2.1.  Элементы уровня мотивация (Motivation Elements) 

Это расширение позволяет моделировать контекст и обоснование для архитектуры. Оно связывает мир архитектурных решений (компоненты, процессы, сервисы) с миром стратегии, требований и конструкций.

Проще говоря, оно помогает ответить на вопросы:

• Почему мы начинаем этот проект?

• Какие бизнес-цели мы преследуем?

• Какие внешние или внутренние силы на нас давят?

• Какие требования мы должны удовлетворить?

• Как мы поймем, что достигли успеха?

1)  Цель (Goal) — конечное состояние, которое стремится достичь заинтересованное лицо.

Вопрос: «Какого общего состояния мы хотим достичь?»

Примеры: Повысить удовлетворенность клиентов; Стать лидером рынка,

2) Результат (Outcome) — конкретный, измеримый и наблюдаемый результат, который является следствием достижения некоторых целей. Часто бывает более тактическим и измеримым, чем цель.

Вопрос: «Какой конкретный, измеримый результат мы ожидаем?»

3) Заинтересованная сторона (Stakeholder) — Ролевое имя отдельного лица, группы лиц или организации (или их классов), которая представляет интересы этих лиц, связанные с результатами архитектурного процесса

Вопрос: «Для кого мы это делаем? Кого это затрагивает?»

Примеры: Правительство, Акционеры, Клиенты, Сотрудники, Партнеры.

4) Драйвер (Driver) — Внутренняя или внешняя сила, которая создает необходимость изменения в предприятии. Это «двигатель» или «спусковой крючок» для трансформации.

Вопрос: «Что заставляет нас меняться?»

Примеры: Изменение законодательства о персональных данных, Рост конкуренции, Необходимость цифровой трансформации, Новые технологические возможности.

5) Оценка (Assessment) — Заключение или вывод о влиянии драйвера на заинтересованные стороны. Это формализованное понимание ситуации, основанное на анализе.

Вопрос: «Как мы оцениваем воздействие этого драйвера?»

Примеры: Риск штрафов за несоответствие GDPR оценивается как высокий, Текущая ИТ‑инфраструктура не обеспечивает требуемую производительность, Устаревший интерфейс снижает лояльность клиентов.

Магия расширения «Мотивация» — в его связях. Оно создает логические цепочки обоснования:

Моделирование причинно‑следственной цепочки

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

© Драйвер (Driver) → Оценка (Assessment) → Цель (Goal) → Требование (Requirement).

Пример: Рост конкуренции (Драйвер) приводит к выводу «Наша доля рынка снижается» (Оценка). Это формирует Цель «Увеличить лояльность клиентов», которая воплощается в Требование «Внедрить программу лояльности в мобильном приложении».

Формализация «мягких» понятий

Уровень переводит абстрактные стратегические концепции в конкретные элементы модели, которыми можно управлять:

© Ценности (Value) и Смыслы (Meaning) становятся объектами, которые можно связать с услугами или процессами, которые их создают.

© Принципы (Principles) и Ограничения (Constraints) из разрозненных документов превращаются в явные правила, влияющие на дизайн архитектуры.

Создание «золотой нити» для отслеживания

Главная практическая ценность — это возможность прослеживаемости (traceability). Любое требование к программному компоненту или изменение бизнес‑процесса можно напрямую связать с исходной целью, драйвером и заинтересованной стороной. Это отвечает на вопросы:

«Зачем мы тратим бюджет на этот проект?»

«Какое требование мы нарушим, если откажемся от этого модуля?»

«На чьи интересы повлияет это изменение?»

Управление влиянием заинтересованных сторон (Stakeholders)

Уровень мотивации делает интересы и влияние различных сторон (Stakeholders) явными и центральными для архитектуры. Модель показывает, чьи интересы движут изменениями и чьи требования должны быть удовлетворены.

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

 Например, модель может выглядеть так:

Теперь детально разберем элементы уровня деятельности (Business Layer).

Элементы уровня деятельности (Business Layer) ArchiMate описывают организационную структуру, ключевые активы, процессы и их взаимодействие — то, что организация делает для реализации целей, определённых на уровне мотивации.

Этот слой является центральным связующим звеном между стратегией («зачем») и реализацией в ИТ («как»).

7.2.2. Элементы уровня деятельности  

Уровень деятельности (Business Layer) описывает организационную структуру, бизнес-процессы, услуги, функции и потоки информации, которые реализуют основную цель предприятия.

Его представление дает ответ на вопрос: «ЧТО делает организация для создания ценности?» и фокусируется на:

• Структуре: Кто и какие роли выполняет?

• Поведении: Какие процессы и функции осуществляются?

• Информации: Какими объектами (данными, продуктами, документами) оперирует?

Активная Структура (Active Structure) — «Кто/Что выполняет работу?»

Эти элементы представляют собой структурные сущности, которые могут выполнять поведение, принимать решения или нести ответственность.

1) Бизнес‑актор (Business Actor). Организационная единица (внешняя по отношению к моделируемому предприятию) или роль/человек, которые выполняют определенное поведение.

Примеры: «Клиент», «Поставщик», «Партнер», «Регулирующий орган».

2) Бизнес‑роль (Business Role). Роль, выполняемая Бизнес‑актором внутри предприятия. Определяет ответственность за выполнение конкретного поведения.

Примеры: «Кассир», «Менеджер по продажам», «Бухгалтер».

3) Бизнес‑коллаборация (Business Collaboration). Временная группировка двух или более Бизнес‑ролей, Бизнес‑акторов или других коллабораций, которые работают вместе для выполнения коллективного поведения.

Примеры: «Команда быстрого реагирования», «Совместное предприятие 'Альфа'», «Рабочая группа по внедрению CRM».

4) Бизнес‑интерфейс (Business Interface). Точка доступа, через которой Бизнес‑сервис, предоставляемый Бизнес‑ролью или Актором, становится доступным для окружения.

Примеры: «Служба поддержки клиентов» (как точка контакта), «Окно приема документов», «Веб‑сайт для партнеров».

Поведение (Behavior) — «Какая работа выполняется?»

Эти элементы описывают функциональность или динамические аспекты бизнеса.

5) Бизнес‑процесс (Business Process). Последовательность действий, направленных на достижение измеримого результата, имеющая ценность для предприятия. Обычно поток управления четко определен.

Примеры: «Оформление заказа», «Обработка возврата», «Найм сотрудника».

6) Бизнес‑функция (Business Function). Совокупность поведения, основанная на выбранных компетенциях предприятия, обычно управляемая на постоянной основе. Менее зависима от потока, чем процесс.

Примеры: «Маркетинг», «Финансовое планирование», «Управление персоналом», «Производство».

7) Бизнес‑взаимодействие (Business Interaction). Единица коллективного поведения, выполняемая в контексте Бизнес‑коллаборации. Моделирует взаимодействие между ролями.

Примеры: «Согласование условий договора» (между менеджером и юристом), «Проведение собеседования».

8) Бизнес‑событие (Business Event). Нечто происходящее (внутри или вне предприятия), что требует ответной реакции.

Примеры: «Поступление заказа от клиента», «Истечение срока действия лицензии», «Получение платежа».

9) Бизнес‑услуга (Business Service). Явно определенная услуга, которую предприятие предоставляет своему окружению. Она представляет ценность для клиентов и скрывает внутреннюю реализацию.

Примеры: «Онлайн‑проверка кредитоспособности», «Услуга доставки», «Круглосуточная техподдержка».

Пассивная Структура (Passive Structure) — «Над чем выполняется работа?»

Эти элементы представляют собой объекты, над которыми совершаются действия поведения.

10) Бизнес‑объект (Business Object). Пассивный информационный элемент, имеющий релевантность для бизнеса, которым манипулируют Поведенческие элементы.

Примеры: «Заказ», «Клиент», «Накладная», «Договор».

11) Договор (Contract). Формальное или неформальное соглашение, которое определяет права и обязанности сторон. Часто является специализацией Бизнес‑объекта.

Примеры: «Соглашение об уровне услуг (SLA)», «Публичная оферта», «Трудовой договор».

12) Концепция расположения (Location) ‑используется для моделирования распределения структурных элементов, таких как хозяйствующие субъекты, используемые компоненты и устройства. 

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

13) Представление (Representation) — рабочий продукт. Имя существительное. Связанные наборы сервисов, сопровождаемых контрактом/набором соглашений, который предполагается как единое целое потребителям (внешним и внутренним). Например, сообщения или документы, являющиеся полезными носителями информации, связанными с бизнес‑объектом.

Рассмотрим простой пример, чтобы показать, как эти элементы работают вместе:

© Бизнес-роль «Кассир» (Активная структура) ──⨀ назначена (assigned to) на Бизнес-процесс «Оформить заказ» (Поведение).

© Бизнес-процесс «Оформить заказ» (Поведение) --- > получает доступ (accesses) к Бизнес-объекту «Заказ» (Пассивная структура) для его создания и изменения.

© Бизнес-процесс «Оформить заказ» (Поведение) ──➤ вызывает (triggers) Бизнес-событие «Заказ подтвержден» (Поведение).

Для бизнес-слоя можно выделить следующие ключевые принципы использования:

• Связь с мотивацией: Каждый бизнес-процесс или услуга должен в идеале реализовывать (realizes) одну или несколько Целей (Goal) с уровня мотивации.

• От поведения к структуре: Бизнес-роли назначаются (assigned) на Бизнес-процессы/Функции, которые, в свою очередь, используют (use) или создают (realize) Бизнес-объекты.

• Абстракция через услуги: Бизнес-услуги позволяют скрыть сложность внутренних процессов (процесс «Как?») от потребителя, предоставляя ему лишь результат («Что?»). Это ключ к созданию гибких и слабосвязанных архитектур.

• Фокус на взаимодействии: Элементы Взаимодействие (Interaction) и Коллаборация (Collaboration) критически важны для моделирования кросс-функционального сотрудничества, которое доминирует в современных организациях.

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

В следующей части мы продолжим рассмотрение слоев спецификации ArchiMate.