Бизнес-слой (Business Layer) в ArchiMate описывает организационную структуру, функции, процессы и сервисы, которые предприятие предоставляет клиентам и партнёрам. Он отвечает на «Кто?», «Что?» и «Как?» на уровне деятельности, не вдаваясь в техническую реализацию. Если мотивационный слой (06.03.01 Мотивационный слой) объясняет почему мы действуем, бизнес-слой показывает, какую работу выполняем и какие услуги оказываем — и служит мостом к прикладным системам (06.03.03 Прикладной и технологический слои). Для системного аналитика владение этим слоем означает способность моделировать деятельность организации на уровне, понятном бизнесу, и достаточно строгом для автоматизации (03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)). ArchiMate 3.x (в тексте — 3.1) — один из слоёв языка; мотивация, прикладной и технологический слои, а также сквозные связи — в 06.03.01 Мотивационный слой, 06.03.03 Прикладной и технологический слои и 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

1. Суть темы

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

Realization и Value. Realization в бизнес-слое означает: процесс, функция или взаимодействие реализует бизнес-сервис. Связь с ценностью (Value) и результатом (Outcome) из мотивационного слоя идёт через Association, Influence или Serving — не через Realization; бизнес-сервис не «реализует» Value (06.03.01 Мотивационный слой). Это правило — каноническое для всей статьи; ниже — только отсылки к нему.

Граница с контекстом системы. Внешние акторы (клиенты, партнёры) часто моделируются как Business Actor снаружи организации (03.01.02 Моделирование контекста системы (Context Diagram)). Внутренние исполнители — через Business Role с назначением (Assignment) на процесс или взаимодействие. Внешний актор обычно не получает Assignment на внутренние процессы: он использует сервис или интерфейс через Serving.

Граница со scope. Границы решения можно очертить набором бизнес-сервисов и процессов, входящих в релиз: то, что за пределами выбранных сервисов, — вне скоупа (02.01.04 Определение границ решения (Scope Modelling)). ArchiMate здесь даёт язык фиксации, а не методику scope-workshop.

Граница с BPMN, UML и C4. ArchiMate — верхнеуровневый скелет; детальные регламенты процессов — в BPMN (03.04.01 BPMN 2.0 - введение и основы, 06.02.01 Потоки, шлюзы, события), отдельные сценарии с акторами — в UML Use Case (03.02.01 Диаграмма прецедентов (Use Case Diagram), 04.03 Use Case vs User Story — выбор подхода), контекст системы в C4 — в 06.03.05 C4-модель. На одной диаграмме держите один уровень абстракции: если нужны шлюзы, таймеры, SLA по шагам или исполнимость в Camunda — выносите в BPMN (06.02.03 Типовые паттерны BPMN); в ArchiMate оставляйте ключевые шаги и объекты. Критерий «достаточно одной view» — в §3.

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

Элементы бизнес-слоя группируются в активные (субъекты), поведенческие (действия), пассивные (объекты), а также сервисные и продуктовые.

2.1. Активные структурные элементы

ЭлементРольПримеры
Business ActorФизическое лицо, организация или подразделение, способное действовать; внутренний или внешний«Банк», «Клиент», «Отдел кредитования»
Business RoleНабор обязанностей и полномочий, назначаемый акторам«Менеджер по продажам», «Андеррайтер»
Business CollaborationСовокупность ролей, совместно выполняющих работу«Команда по работе с претензиями»

Actor vs Role. Актор — кто (персона или единица); роль — какую функцию исполняет. Один актор может нести несколько ролей; одну роль могут исполнять несколько акторов. Business Actor/Role согласуют с акторами прецедентов в UML (03.02.01 Диаграмма прецедентов (Use Case Diagram)).

Collaboration vs Assignment. Assignment связывает конкретную роль с процессом, функцией, взаимодействием или интерфейсом («роль X выполняет процесс Y» или «роль X обслуживает канал Z»). Collaboration — именованная группа ролей без указания, кто именно что делает внутри; типично для организационной viewpoint. Пример: роли «Юрист», «Менеджер», «Поддержка» объединены в Collaboration «Работа с претензиями»; на диаграмме процесса каждая роль назначена на свой шаг через Assignment.

2.2. Поведенческие элементы

ЭлементРольКогда выбирать
Business ProcessУпорядоченная последовательность действий, преобразующая входы в выходы; может быть привязана к одной или нескольким ролям по шагамПоток работ с чётким началом и концом; кандидат на BPMN-детализацию
Business FunctionНабор действий, сгруппированных по компетенции или ресурсу; стабильнее процессаОрганизационная декомпозиция («Управление персоналом»), функциональная карта
Business InteractionКоллективное поведение — обмен между несколькими ролями без внутренней декомпозиции«Переговоры о контракте» — когда нельзя свести к одному исполнителю и не нужен пошаговый регламент
Business EventСобытие в бизнес-среде, запускающее или влияющее на поведение«Поступление заказа от клиента»

Process vs Interaction. Процесс описывает поток работ и обычно назначается ролям по шагам; interaction — единое коллективное действие без последовательности внутри. Контрпример «согласование лимита»: если есть два шага («менеджер готовит предложение» → «руководитель утверждает») с разными ролями — моделируйте Process с двумя Assignment; Interaction — когда на воркшопе достаточно зафиксировать «менеджер и руководитель согласуют лимит» без разбиения на шаги и без выноса в BPMN.

Function vs Process. Функция — «что умеет организация» (стабильная capability); процесс — «как это делается сейчас» (может меняться при смене канала). На одной диаграмме не смешивайте иерархию функций и детальный процесс.

2.3. Пассивные структурные элементы

ЭлементРольПримеры
Business ObjectЗначимая сущность предметной области«Кредитная заявка», «Счёт-фактура»
RepresentationКонкретная форма объекта (PDF, web-форма, бумажный бланк)«Заявка в PDF», «Web-форма заявки»
ContractФормализованное соглашение между сторонами«SLA по техподдержке», «Кредитный договор»

Object vs Representation. Один бизнес-объект «Кредитная заявка» может иметь несколько представлений. На диаграмме процесса Access идёт к Business Object; Representation связывают Association с объектом. Типовой вопрос аналитика: «одна заявка — три канала подачи» — один объект, несколько Representation, процесс читает/пишет объект (модификатор Access), а канал — через Interface или Serving.

Contract в процессах. Контракт связывают с продуктом (Aggregation) и сторонами через Association (кто с кем договорился); исполнение условий — через процессы, которые реализуют сервисы продукта. Access к Contract на бизнес-диаграмме обычно не нужен: детали обязательств — в продуктовой viewpoint или в спецификации, не в потоке «заявка → решение».

2.4. Сервисные и продуктовые элементы

ЭлементРольПримеры
Business ServiceЯвно определённая функциональность «снаружи»: вход–выход без раскрытия внутренней реализации«Выдача потребительского кредита», «Обработка претензий»
Business InterfaceТочка доступа к сервису«Личный кабинет», «Телефон горячей линии»
ProductПакет сервисов, контрактов и связанных элементов для клиента«Кредитная карта Gold», «Пакет Премиум-обслуживание»

Service vs Interface. Сервис — что предоставляется; интерфейс — как к нему обращаются. Клиент использует (Serving) сервис и/или интерфейс; процесс реализует сервис. Связь «интерфейс ↔ сервис» задают Association или трассировкой «Actor → Interface, Process → Realization → Service»; Serving между Interface и Service не ставят — Serving означает «кто кому предоставляет функциональность», и это всегда сервис или интерфейс → актор/роль.

Product, Contract, Service. Продукт обычно агрегирует сервисы и контракты (SLA, условия). Объекты появляются через процессы, которые эти сервисы реализуют, а не напрямую в составе продукта.

2.5. Отношения в бизнес-слое

ОтношениеНаправление / смыслПримечание
AssignmentАктивная структура → поведение или интерфейсActor → Role; Role → Process, Function или Interaction; Role → Interface (кто обслуживает канал)
RealizationПоведение → сервисProcess / Function / Interaction реализует Business Service
AccessПоведение → пассивная структураProcess / Function / Interaction читает, пишет или читает-писывает Business Object; модификаторы: read, write, read-write
FlowПередача между поведенческими элементамиПоток «Заявка» между двумя процессами, когда важен перенос объекта или результата
TriggeringСобытие → поведениеBusiness Event запускает Process или Interaction
ServingСервис или интерфейс → активная структураСервис или интерфейс обслуживает роль или внешнего актора
Aggregation / CompositionСоставProduct агрегирует Service и Contract; Function состоит из Process

Access — типичная ошибка: связывать роль с объектом напрямую. Роль участвует через Assignment к процессу; Access идёт от процесса (или функции, interaction) к объекту. Иначе смешиваются ролевая модель (10.01.11 Шаблон ролевой модели) и модель манипуляции данными (03.03.01 ER-диаграммы (сущность-связь)).

Event, Triggering, Flow — когда что выбирать.

  • Triggering — «что запускает работу»: событие «Поступила заявка» → Triggering → Process «Обработать заявку». На ArchiMate-view достаточно одной связи; детали стартового события — в BPMN (06.02.01 Потоки, шлюзы, события).
  • Flow — «что передаётся между уже существующими процессами»: Process «Принять заявку» → Flow «Заявка» → Process «Принять решение». Если процесс один и объект меняется через Access — Flow не нужен.
  • Access без Flow — один процесс читает и пишет объекты на месте; промежуточная передача между ролями внутри одного процесса — Assignment, не Flow.

Не перегружайте диаграмму всеми связями — выбирайте Viewpoint (06.03.04 Взаимосвязи и точки зрения (Viewpoints)). Для «использования сервисов» достаточно Actor, Service, Interface и Serving; для «процесс + данные» — Role, Process, Object, Access и при необходимости Event + Triggering.

2.6. Пример модели бизнес-слоя

Минимальный набор для трассировки «сервис — процесс — объект» (не полная палитра слоя: Function, Collaboration, Event, Interaction здесь опущены намеренно). Упрощённая модель кредитования в банке.

graph TD
    subgraph Внешний_актор [Внешний актор]
        Клиент[Actor: Клиент]
    end
    subgraph Банк [Банк]
        Роль_Менеджер[Role: Менеджер по работе с клиентами]
        Процесс_Обработка[Process: Обработать кредитную заявку]
        Сервис_Кредитование[Service: Выдача потребительского кредита]
        Интерфейс_ЛК[Interface: Личный кабинет]
        Объект_Заявка[Object: Кредитная заявка]
        Представление_Форма[Representation: Web-форма заявки]
        Объект_Решение[Object: Кредитное решение]
        Контракт_SLA[Contract: SLA по срокам рассмотрения]
        Продукт[Product: Кредит Быстрый]
    end

    Клиент -->|Serving| Сервис_Кредитование
    Клиент -->|Serving| Интерфейс_ЛК
    Интерфейс_ЛК ---|Association| Сервис_Кредитование
    Интерфейс_ЛК -->|Assignment| Роль_Менеджер
    Процесс_Обработка -->|Realization| Сервис_Кредитование
    Роль_Менеджер -->|Assignment| Процесс_Обработка
    Процесс_Обработка -->|Access read| Объект_Заявка
    Процесс_Обработка -->|Access write| Объект_Решение
    Представление_Форма --- Объект_Заявка
    Продукт -->|Aggregation| Сервис_Кредитование
    Продукт -->|Aggregation| Контракт_SLA

    style Клиент fill:#d0e0ff,stroke:#333
    style Роль_Менеджер fill:#ffe6cc,stroke:#333
    style Процесс_Обработка fill:#d5e8d4,stroke:#333
    style Сервис_Кредитование fill:#f8cecc,stroke:#333,stroke-dasharray: 5 5
    style Интерфейс_ЛК fill:#f8cecc,stroke:#333
    style Объект_Заявка fill:#fff2cc,stroke:#333
    style Объект_Решение fill:#fff2cc,stroke:#333
    style Представление_Форма fill:#fff2cc,stroke:#333
    style Продукт fill:#e1d5e7,stroke:#333
    style Контракт_SLA fill:#e1d5e7,stroke:#333

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

2.7. Типичные точки зрения (Viewpoints)

Для работы аналитика чаще всего достаточно двух viewpoints бизнес-слоя:

Продуктовая архитектура (Product, Contract, Service) — третья, когда обсуждаете состав предложения для клиента. Полный перечень viewpoints, правила отсечения элементов и cross-layer view — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

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

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

  1. Начинайте с сервисов — зафиксируйте, какие услуги видит клиент; затем декомпозируйте в процессы через Realization. Это согласуется с границами scope по сервисам (02.01.04 Определение границ решения (Scope Modelling)).
  2. Разделяйте функции и процессы — функции для capability-карт; процессы — для потоков работ и трассировки к BPMN.
  3. Моделируйте объекты и Access — каждый создаваемый или изменяемый объект ведёт к требованиям к данным (03.03.01 ER-диаграммы (сущность-связь)) и в словарь (10.01.14 Шаблон глоссария и словаря данных).
  4. Трассируйте сверху вниз — Requirement (motivation) → Business Service → Process → Business Object → Application Service (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки); cross-layer Realization — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints).
  5. Различайте внешнего актора и внутреннюю роль — клиент использует Serving/Interface; менеджер получает Assignment на процесс или интерфейс.
  6. Выбирайте глубину детализации — одной ArchiMate-view достаточно, пока на воркшопе обсуждают что делает организация, какие объекты и какие сервисы видит клиент. Заводите BPMN (03.04.01 BPMN 2.0 - введение и основы, 10.01.08 Шаблон сквозной фичи (BPMN-процесс)) или Use Case, когда появляются шлюзы и ветвления, SLA или таймеры по шагам, исполнимость (Camunda, 06.02.04 Работа с Camunda) или нужна пошаговая регламентация для разработки. ArchiMate остаётся каркасом; BPMN-шаблон — детализацией того же процесса.
  7. Стройте диаграммы под аудиторию — для бизнеса: продукты, сервисы, интерфейсы; для SA: процессы, объекты, связи с прикладным слоем (06.03.03 Прикладной и технологический слои).
  8. Документируйте в артефактах — модель питает Vision, BRD, SRS (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)); акторы и роли согласуют с картой стейкхолдеров (02.01.03 Анализ заинтересованных сторон (Stakeholder Map)).

Связь с другими слоями и нотациями:

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

  • Access от роли к объекту — Access только от поведения к Business Object; роль подключается через Assignment.
  • Realization «сервис → Value» — см. §1; типичная инверсия направления Realization (стрелка «от сервиса», а не «от процесса к сервису»).
  • Serving между Interface и Service — Serving только «сервис/интерфейс → актор/роль»; связь канала с сервисом — Association или трассировка через Process → Realization → Service.
  • Interface без Assignment — неясно, кто обслуживает канал; при handoff в прикладной слой нужна роль на интерфейсе.
  • Смешивать Process и Interaction — дублировать одно и то же и в BPMN, и как interaction без причины; контрпример — §2.2.
  • Смешивать уровни абстракции — см. §1; функциональная карта и пошаговый процесс на одной view.
  • Назначать внешнего актора на внутренний процесс — клиент использует сервис, не выполняет процесс банка.
  • Путать Business Object и Representation — один объект, несколько форм; Access — к объекту.
  • Triggering и Flow «на всякий случай» — см. §2.5; лишние связи без события или передачи между процессами засоряют view.
  • Перегружать диаграмму — без выбора Viewpoint; правила — 06.03.04 Взаимосвязи и точки зрения (Viewpoints).
  • Обещать полную трассировку только бизнес-диаграммой — связь до application layer и ER — через соседние слои и артефакты трассировки.
  • Дублировать scope- и stakeholder-методики — здесь только модельные элементы; elicitation — в ветке 02.x.

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

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

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

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

Инструменты