Мотивационный слой (Motivation Layer) ArchiMate отвечает на вопросы «зачем» и «почему» изменения нужны организации: он фиксирует драйверы, цели, требования и интересы заинтересованных сторон до перехода к процессам и системам. Для системного аналитика это верхняя часть трассировки — от стратегического контекста до формулировок, которые попадут в Vision, BRD или спецификацию. ArchiMate 3.x (в тексте — 3.1) — один из слоёв языка моделирования архитектуры предприятия; бизнес-, прикладной и технологический слои, а также сквозные связи между слоями — в 06.03.02 Бизнес-слой, 06.03.03 Прикладной и технологический слои и 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

1. Суть темы

Мотивационный слой не описывает, как работает организация или ИС, — он фиксирует причины изменений и критерии успеха. Элементы слоя связывают внешние и внутренние факторы (драйверы) с целями, результатами и требованиями; отсюда начинается обоснование проектных решений.

Типовая логика модели — не «стейкхолдер порождает драйвер», а цепочка Driver → Assessment → Goal → Outcome / Requirement. Заинтересованная сторона (Stakeholder) участвует через назначение (Assignment) или ассоциацию (Association) с драйвером, оценкой, целью или требованием: она задаёт перспективу, но не заменяет драйвер как фактор изменений.

На границе мотивационного слоя модель обрывается на Requirement и Outcome. Связи Realization и Serving вниз — к бизнес-процессам, сервисам, компонентам приложений — относятся к другим слоям ArchiMate и описаны в 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

Stakeholder в мотивационном слое — тот, у кого есть интерес к архитектуре и её результатам. Business Actor из бизнес-слоя — роль, которая выполняет работу; одного человека можно моделировать и как Stakeholder, и как Actor, но это разные элементы с разной семантикой (подробнее — 06.03.02 Бизнес-слой).

Мотивация vs контекст системы. Диаграмма контекста (03.01.02 Моделирование контекста системы (Context Diagram)) отвечает на «что входит в систему и кто снаружи»; мотивационный слой — на «зачем меняем организацию или ИС». Оба артефакта живут «сверху» спецификации: контекст задаёт границу решения, motivation — обоснование изменений внутри этой границы. На одном проекте их часто рисуют рядом, но не смешивают элементы.

2. Ключевые понятия

2.1. Элементы мотивационного слоя

ЭлементРольПримеры
StakeholderЧеловек, группа или организация с интересом к результатам«Регулятор», «Конечный пользователь», «CFO»
DriverВнешний или внутренний фактор, мотивирующий к изменениям«Изменение законодательства», «Рост конкуренции»
AssessmentОценка драйвера с точки зрения конкретной заинтересованной стороны«Доля рынка упала на 5%», «SLA нарушается в 30% случаев»
GoalЖелаемое состояние; формулируется позитивно, может быть качественной«Повысить качество клиентского сервиса», «Обеспечить соответствие GDPR»
OutcomeНаблюдаемый, измеримый эффект достижения цели«NPS вырос на 15 пунктов», «Время обработки заказа ≤ 5 мин»
RequirementПотребность или обязательство, которое должно быть удовлетворено решением; не только «функция системы»«Единая точка входа для обращений клиентов», «Отчётность по регуляторным формам»
ConstraintФактор, сужающий пространство решений«Бюджет ≤ 500 тыс.», «Срок — 6 месяцев»
PrincipleУстойчивое правило принятия архитектурных решений«Данные — актив компании», «Повторное использование вместо дублирования»
ValueПолезность для заинтересованной стороны«Снижение операционных затрат», «Упрощение аудита»
MeaningСмысл термина или информации для стейкхолдера«“Клиент” включает дистрибьюторов»

Goal и Outcome. Цель описывает намерение; измеримость и KPI чаще выражаются через Outcome и связываются с практиками из 02.01.02 Цели, KPI и критерии успеха (SMART, GQM) — без требования, что каждая Goal обязана быть SMART.

Requirement: бизнес vs система. В мотивационном слое требование может фиксировать организационную или регуляторную потребность до появления ИС. Классификация БТ, ФТ и НФТ — в 02.03.01 Классификация требований (БТ, ФТ, НФТ); привязка к приложениям начинается ниже мотивационного слоя.

Value и Meaning — когда выносить отдельно. Value фиксирует полезность для конкретного стейкхолдера, а не измеримый результат: «упрощение аудита» для CFO — Value, «NPS +15» — Outcome. Не дублируйте Goal: Value связывайте Association со Stakeholder и при необходимости Influence с Goal, если ценность явно подталкивает к ней. Meaning нужен, когда один термин трактуется по-разному: «“Клиент” включает дистрибьюторов» для отдела продаж vs «только физлица с договором» для комплаенса. Связывайте Meaning Association с Stakeholder; содержание переносите в глоссарий (10.01.14 Шаблон глоссария и словаря данных), а в модели оставляйте якорь «чей смысл зафиксирован».

Principle, Requirement, Constraint — одна ситуация:

СитуацияPrincipleRequirementConstraint
Миграция в облако«Cloud-first для новых сервисов»«Данные клиентов хранятся в сертифицированном ЦОД»«Только провайдеры из реестра ФСТЭК»

2.2. Отношения внутри мотивационного слоя

ОтношениеОбозначениеТипичное применение
InfluenceПунктирная стрелка (+/−)Driver → Assessment, Assessment → Goal, Principle → Goal / Requirement, Constraint → Requirement
RealizationПунктир + пустой треугольник на стороне «реализующего»Requirement → Goal, Outcome → Goal
AssignmentСплошная линия с маркером на стороне StakeholderStakeholder → Assessment, Stakeholder → Goal
CompositionЛиния с закрашенным ромбом на стороне целогоGoal → подцели; Requirement → составные требования
AggregationЛиния с пустым ромбомСлабая группировка целей или требований
AssociationСплошная линияStakeholder ↔ Value, Stakeholder ↔ Meaning; связь, когда другой тип не подходит

Influence и знак «+/−». В ArchiMate это qualifier влияния, а не арифметика KPI: «+» — усиливает или поддерживает, «−» — ослабляет или противоречит. На диаграмме знак обязателен, если направление влияния неочевидно; рисовать Influence без знака — типичная ошибка. Это не «зависимость задач» из MS Project: связь описывает мотивационное давление, а не порядок работ.

Realization в этой заметке — только внутри motivation: Requirement и Outcome реализуют Goal. Принцип направляет цель или требование через Influence, а не «реализует» её. Компоненты бизнес-, прикладного и технологического слоёв реализуют требования уже за пределами мотивационного слоя (06.03.02 Бизнес-слой, 06.03.04 Взаимосвязи и точки зрения (Viewpoints)).

Assignment vs Association для Stakeholder. Assignment — ответственность или перспектива оценки/цели: «CFO владеет этой Assessment», «директор отвечает за Goal». Association — интерес без формального владения: связь со Value или Meaning, осведомлённость о Driver. Если стейкхолдер оценивает ситуацию или отвечает за цель — Assignment; если только заинтересован в выгоде или трактовке термина — Association.

Assessment: обычно создаётся аналитиком или архитектором на основе данных elicitation; один Driver может иметь несколько Assessment — по одной на перспективу каждой ключевой Stakeholder.

Декомпозиция Goal (Composition): останавливайтесь, когда подцель однозначно порождает требования или входит в скоуп релиза; глубже 3–4 уровней на одной диаграмме редко нужно.

Противоречащие цели: моделируйте разные Goal для разных Stakeholder и связывайте их Influence с «+»/«−»; явно показывайте, какой Driver или Assessment тянет цели в противоположные стороны. При выборе, что войдёт в релиз, опирайтесь на 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

2.3. Пример мотивационной модели

Сценарий: рост ожиданий клиентов к скорости ответа и измеримое падение лояльности. Типы связей соответствуют таблице выше; Driver — фактор среды, Assessment — симптом с цифрой.

graph TD
    D[Driver: Рост ожиданий клиентов к скорости ответа]
    A[Assessment: 30% клиентов уходят из-за ожидания]
    G[Goal: Сократить среднее время обработки запроса]
    O[Outcome: NPS +15 пунктов]
    R[Requirement: Единый канал обращений 24/7]
    P[Principle: Мгновенная обратная связь]
    C[Constraint: Бюджет ≤ 50 тыс.]
    V[Value: Снижение оттока на 10%]
    M[Meaning: Клиент — физлицо с активным договором]
    S1[Stakeholder: Клиенты]
    S2[Stakeholder: Генеральный директор]

    D -.->|Influence +| A
    A -.->|Influence +| G
    R -.->|Realization| G
    O -.->|Realization| G
    P -.->|Influence +| G
    C -.->|Influence -| R
    S1 ---|Assignment| A
    S2 ---|Assignment| G
    S1 ---|Association| V
    S1 ---|Association| M

    style D fill:#ffe6cc,stroke:#333
    style A fill:#fff2cc,stroke:#333
    style G fill:#d5e8d4,stroke:#333
    style O fill:#dae8fc,stroke:#333
    style R fill:#f8cecc,stroke:#333
    style P fill:#e1d5e7,stroke:#333
    style C fill:#f5f5f5,stroke:#333
    style V fill:#d4f0d4,stroke:#333
    style M fill:#f0f0f0,stroke:#333
    style S1 fill:#b3d9ff,stroke:#333
    style S2 fill:#b3d9ff,stroke:#333

Mermaid не воспроизводит канонические фигуры ArchiMate; в инструментах с поддержкой нотации (07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io)) используйте штатные символы и типы связей из палитры.

3. Как применяется в работе аналитика

Мотивационный слой решает задачи нотации, не подменяя техники BA:

Детали выявления стейкхолдеров, интервью и приоритизации — в 02.01.03 Анализ заинтересованных сторон (Stakeholder Map) и 02.02.01 Интервьюирование и анкетирование; здесь — только как зафиксировать результат в ArchiMate.

Когда полный слой не окупается. На малом продукте или коротком релизе достаточно пары Goal и Requirement в BRD, epic map или Confluence без отдельной motivation-диаграммы. ArchiMate здесь — нотация для согласования и трассировки, а не обязательный артефакт каждого спринта.

4. Типовые ошибки и ограничения

  • Строить главную цепочку от Stakeholder к Driver — драйвер описывает фактор среды; стейкхолдер назначается на оценку или цель, а не «порождает» конкуренцию или закон.
  • Смешивать Realization и Influence — Principle и Constraint почти всегда Influence; Realization в motivation — у Requirement и Outcome относительно Goal.
  • Рисовать Influence без знака «+/−» — теряется семантика поддержки и противоречия; это не «стрелка зависимости» из плана проекта.
  • Требовать SMART у каждой Goal — измеримость выносите в Outcome; KPI и критерии успеха — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
  • Сужать Requirement до «система должна» — теряются бизнес-требования и регуляторные обязательства без привязки к ИС.
  • Рисовать Requirement → Constraint как иерархию — ограничение влияет на требование или цель, направление и тип связи важны для трассировки.
  • Путать Stakeholder и Business Actor — мотивация vs исполнение; см. 06.03.02 Бизнес-слой.
  • Оставлять «висячие» Value и Meaning — элемент без Stakeholder и без связи с глоссарием не несёт смысла; Meaning дублируйте в 10.01.14 Шаблон глоссария и словаря данных.
  • Обещать сквозную трассировку только мотивационной диаграммой — до процесса, сервиса или компонента связи идут через другие слои (06.03.04 Взаимосвязи и точки зрения (Viewpoints)).
  • Перегружать одну диаграмму — Motivation Viewpoint обычно включает подмножество элементов; что класть на одну view и как дробить модель — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints).
  • Формально валидные, но бедные цепочки — в нотации допустимы Driver → Goal без Assessment (например, внешний регуляторный драйвер с очевидной трактовкой) и Requirement без Realization к Goal. Для системного аналитика такие фрагменты ослабляют трассировку: помечайте «orphan» Requirement и по возможности доводите до Goal или Outcome.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • The Open Group. ArchiMate 3.1 Specification — глава Motivation Layer. Вход на сайт стандарта: https://www.opengroup.org/archimate
  • Онлайн-версия спецификации 3.1 (может требовать подписку Open Group): https://pubs.opengroup.org/architecture/archimate31-doc/
  • Marc Lankhorst et al. ArchiMate 3.0.1: A Pocket Guide — краткий справочник по элементам и отношениям (версия pocket guide может отставать от 3.1; элементы motivation согласованы).
  • Gerben Wierda. Mastering ArchiMate Edition III — практические примеры мотивационных моделей.

Инструменты