ArchiMate связывает элементы разных слоёв в одной модели, а точки зрения (Viewpoints) и виды (Views) показывают эту модель по-разному — каждому стейкхолдеру только то, что отвечает на его вопросы. Без viewpoints диаграмма превращается в кашу; без сквозных Realization и Serving между views теряется трассировка от цели до инфраструктуры. Здесь — механизм viewpoints, выбор стандартных шаблонов ArchiMate 3.1, межслойный «клей» и практика построения видов. Элементы внутри слоёв — в 06.03.01 Мотивационный слой, 06.03.02 Бизнес-слой и 06.03.03 Прикладной и технологический слои; виды бизнес-/системной/технической архитектуры в терминах ИС — в 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).
1. Суть темы
Стандарт ArchiMate и родственный ISO/IEC/IEEE 42010:2011 (см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)) разделяют четыре понятия:
- Заинтересованная сторона (Stakeholder) — лицо, группа или организация с интересом к архитектуре. У каждой стороны есть интересы (concerns) — вопросы, на которые архитектура должна ответить.
- Точка зрения (Viewpoint) — спецификация (шаблон): для кого, с какой целью и из каких элементов метамодели строится представление. Фиксирует аудиторию, concerns, разрешённые элементы и связи, правила построения.
- Вид (View) — конкретная диаграмма (или набор диаграмм), построенная по Viewpoint. Это экземпляр применения шаблона к вашей архитектуре.
Viewpoint — «рецепт», View — «блюдо». Одна точка зрения порождает множество видов для разных систем и проектов.
ArchiMate и ISO 42010 на практике. Четыре понятия совпадают по смыслу, но в типичном инструменте ArchiMate вы создаёте Viewpoint и View; concern чаще живёт в описании viewpoint или в сопроводительном тексте, а не как отдельный артефакт в репозитории. Не ждите полного «архитектурного описания по 42010» из одной диаграммы — зафиксируйте concerns явно в ADR, BRD или свойствах view.
Одна модель — много views. Элементы архитектуры хранятся один раз в репозитории; каждый view — проекция того же набора элементов по правилам viewpoint. Шаг «связать views» в алгоритме ниже — не рисование несвязанных картинок, а добавление Realization, Serving и других связей между уже существующими элементами модели. Тогда изменение компонента на Application Usage автоматически отражается на Layered view и в Deployment.
Другие рамки представлений — например, уровни C4 — описаны в 06.03.05 C4-модель.
graph TD
ЗС[Заинтересованная сторона] -->|имеет| Интересы[Интересы]
Интересы -->|удовлетворяются| ТЗ[Точка зрения]
ТЗ -->|определяет правила для| Вид[Вид]
Модель[Единая модель архитектуры] -->|элементы отбираются в| Вид
ТЗ -->|ссылается на| Мета[Метамодель ArchiMate]
Вид -->|показывает| ЗС
Вид -->|связан с другими views через| Связи[Realization / Serving / …]
Зачем это системному аналитику:
- Управление сложностью — показываете только релевантную часть архитектуры; viewpoints помогают «нарезать» scope для разных аудиторий — см. 02.01.04 Определение границ решения (Scope Modelling).
- Целевая коммуникация — руководителю нужны цели и сервисы, разработчику — компоненты и интерфейсы, инженеру инфраструктуры — узлы и развёртывание.
- Повторное использование — в приложении C спецификации ArchiMate 3.1 перечислено 25 примерных (example) viewpoints; эталон имён и состава элементов — глава 14 и Appendix C spec, а в вашем инструменте — встроенный каталог viewpoints.
- Проверяемость — инструменты с метамоделью ArchiMate (Archi, BiZZdesign, Sparx EA с профилем ArchiMate) фильтруют палитру по Viewpoint и могут запускать валидацию; это не «формальное доказательство», но помогает поймать запрещённые элементы.
2. Ключевые понятия
2.1. Слои и области: что выбирает viewpoint
Viewpoints не дублируют полную карту ArchiMate — они отбирают элементы из нужных областей метамодели. Для выбора шаблона достаточно ориентироваться на эти зоны (остальные элементы и нотация — в соседних заметках серии 06.03 и в spec):
| Область | Зачем в viewpoints | Типичные concerns |
|---|---|---|
| Motivation | Цели, требования, стейкхолдеры | Зачем меняемся, для кого |
| Strategy | Capability, Resource, Outcome, Value Stream | Какие способности и результаты нужны стратегии |
| Business / Application / Technology | Процессы, сервисы, компоненты, узлы | Как организация и ИС работают и связаны |
| Physical | Equipment, Facility, Distribution Network | Физическое окружение и его связь с IT |
| Implementation & Migration | Work Package, Plateau, Gap | План изменений, AS-IS / TO-BE |
| Сквозные (Layered и др.) | Элементы нескольких слоёв по правилам spec | End-to-end трассировка |
Strategy vs Motivation. Goal Realization Viewpoint (Motivation) отвечает на «зачем»: цели → требования. Outcome Realization Viewpoint (Strategy) — на «какой бизнес-результат обеспечивают capabilities и ресурсы». Capability Map показывает карту способностей; не подменяйте ею декомпозицию целей.
2.2. Классификация стандартных Viewpoints (ArchiMate 3.1, Appendix C)
Spec группирует 25 example viewpoints в четыре категории. Имена ниже — как в спецификации (на английском); это отправные шаблоны, которые организация может сужать или расширять.
| Категория (Appendix C) | Viewpoints (англ. имя в spec) | Основная аудитория |
|---|---|---|
| Basic | Organization, Application Structure, Information Structure, Technology, Layered, Physical, Product, Application Usage, Technology Usage, Business Process Cooperation, Application Cooperation, Service Realization, Implementation and Deployment | Архитекторы, аналитики, широкая аудитория |
| Motivation | Stakeholder, Goal Realization, Requirements Realization, Motivation | Бизнес-руководители, BA, архитекторы |
| Strategy | Strategy, Capability Map, Value Stream, Outcome Realization, Resource Map | Стратеги, enterprise-архитекторы |
| Implementation & Migration | Project, Migration, Implementation and Migration | PM, архитекторы трансформации |
Отдельной категории «Business» или «Application» в Appendix C нет: business-ориентированные viewpoints (Organization, Business Process Cooperation, Product, Service Realization) входят в Basic. Application Usage — прикладной viewpoint о том, как приложения поддерживают бизнес-процессы; не путайте его с business-layer элементами.
Полный перечень имён, разрешённых элементов и связей — Appendix C и глава 14; список viewpoints в инструменте = практический эталон при сверке с spec.
2.3. Примеры стандартных Viewpoints
Goal Realization Viewpoint (Motivation)
Фокус: декомпозиция целей в подцели, требования и ограничения.
Элементы: Goal, Requirement, Principle, Constraint.
Связи: Aggregation (Goal → подцели), Realization (Requirement → Goal), Influence (Principle → Goal / Requirement).
Аудитория: бизнес-руководители. Связь с 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
Outcome Realization Viewpoint (Strategy)
Фокус: как capabilities, value streams и ресурсы производят бизнес-результаты (Outcome).
Элементы: Capability, Outcome, Value Stream, Resource, Value, Meaning.
Когда выбирать: стратегическая сессия, карта способностей, вопрос «что организация должна уметь и получить», а не «какие KPI у цели». Для целей → требований — Goal Realization, не Outcome Realization.
Business Process Cooperation Viewpoint (Basic)
Фокус: взаимодействие процессов, ролей и объектов.
Элементы: Business Actor, Business Role, Business Process, Business Object, Business Event.
Связи: Assignment, Flow, Triggering.
Аудитория: бизнес-аналитики. Связь с 06.03.02 Бизнес-слой, 03.04.01 BPMN 2.0 - введение и основы.
Application Usage Viewpoint (Basic)
Фокус: как бизнес-процессы используют прикладные сервисы и компоненты.
Элементы: Business Process, Application Service, Application Component (и при необходимости Business Service).
Связи: Realization, Serving, Assignment.
Аудитория: системные аналитики. Связь с 06.03.03 Прикладной и технологический слои.
Physical Viewpoint (Basic)
Фокус: оборудование, сооружения, распределительные сети и их связь с IT-инфраструктурой.
Элементы: Equipment, Facility, Distribution Network, Device, Node, Location, Material.
Аудитория: инженеры площадок, промышленные и facility-проекты. Дополняет Technology и Implementation and Deployment, когда важна не только «логика» узлов, но и физическая среда.
Implementation and Deployment Viewpoint (Basic)
Фокус: как прикладные компоненты и артефакты размещены на технологической инфраструктуре.
Элементы: Application Component, Artifact, Node, System Software, Device.
Связи: Deployment, Realization.
Аудитория: инженеры инфраструктуры. Связь с 07.08 Контейнеризация и оркестрация (Docker, Kubernetes).
Migration Viewpoint (Implementation & Migration)
Фокус: переход между plateau (состояниями архитектуры), work packages и gaps.
Элементы: Plateau, Gap, Work Package, Deliverable.
Аудитория: менеджеры проектов, архитекторы трансформации.
2.4. Сквозные связи между слоями (межслойная трассировка)
Это второй столп статьи: views связаны через общие элементы и отношения в одной модели. Для трассировки между viewpoints важны не все ~12 типов связей метамодели, а сквозные:
| Связь | Смысл | Типичная цепочка | Направление стрелки |
|---|---|---|---|
| Realization | Более конкретный элемент критически создаёт или обеспечивает более абстрактный | Application Service → Business Service; Technology Service → Application Service; Requirement → Goal | От реализующего к реализуемому |
| Serving | Элемент предоставляет функциональность другому | Application Service → Business Process; Node → Application Component | От обслуживающего к обслуживаемому |
| Assignment | Поведение привязано к исполнителю; структура — к узлу | Business Role → Business Process; Application Component → Node | От назначаемого к носителю |
| Access | Активный элемент обращается к пассивному (данным) | Business Process → Business Object; Application Component → Data Object | От активного к пассивному |
| Flow | Передача информации или ценности между поведенческими элементами | Business Process → Business Process; Application Function → Application Function | По направлению потока |
Realization — частая ошибка: Goal декомпозируется через Aggregation; Requirement реализует Goal; Principle влияет через Influence — не Realization.
Serving — направление: стрелка от поставщика к потребителю. Application Service Serving Business Process — сервис приложения обслуживает процесс.
Flow vs Access между слоями: Business Object и Data Object связывают через Representation, Access или mapping в Layered View, а не прямым Flow между слоями.
Derived relationships инструмент вычисляет автоматически; на view достаточно явных Realization и Serving — derived не рисуют вручную.
Multi-layer views: сквозные представления — Layered Viewpoint (обзор слоёв) и Service Realization Viewpoint (как сервисы реализуются поведением). Произвольное смешивание слоёв без viewpoint — типичная ошибка.
Сквозная трассировка поддерживает 02.03.04 Трассировка требований (концепция) и при необходимости оформляется через 10.01.15 Шаблон матрицы трассировки.
2.5. Быстрый выбор: concern → viewpoint
| Concern стейкхолдера | Viewpoint |
|---|---|
| Зачем меняемся: цели → требования? | Goal Realization |
| Какой бизнес-результат дают capabilities? | Outcome Realization |
| Какие способности нужны организации? | Capability Map |
| Кто участвует в процессе и что передаётся? | Business Process Cooperation |
| Какие приложения поддерживают процесс? | Application Usage |
| Как сервис реализуется процессами и компонентами? | Service Realization |
| Где ПО размещено на инфраструктуре? | Implementation and Deployment |
| Как оборудование и площадки связаны с IT? | Physical |
| Как перейти от AS-IS к TO-BE? | Migration |
| Как сервис/решение проходит через все слои? | Layered |
3. Как применяется в работе аналитика
3.1. Алгоритм выбора и построения View
- Определить стейкхолдеров и concerns — см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).
- Сопоставить concern со стандартным Viewpoint — таблица в разделе 2.5 или каталог в инструменте.
- Создать View в репозитории ArchiMate — в Archi: свойства view → Viewpoint; палитра фильтруется автоматически. То же в Sparx EA и BiZZdesign с профилем ArchiMate — см. 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io). draw.io и аналоги без метамодели ArchiMate не enforce viewpoints: там шаблон задаёте вы сами (список allowed elements).
- При необходимости адаптировать Viewpoint — см. раздел 3.3; зафиксировать изменения.
- Построить и связать views в одной модели — те же элементы на разных диаграммах; Realization и Serving между views дают сквозную трассировку.
- Проверить покрытие concerns — каждый вопрос закрыт на своём view; view можно передать на ревью — см. 08.04 Рецензирование и инспекции (техники Фейгана).
Когда 25 viewpoints избыточны. Маленькая команда, один продукт, нет EA-репозитория и разнородных стейкхолдеров — часто хватает одного Layered view или 06.03.05 C4-модель для технической аудитории. ArchiMate viewpoints оправданы, когда: несколько аудиторий с разными concerns, нужна трассировка в общем репозитории, организация уже ведёт EA-модель. Критерий: сколько разных вопросов должна закрыть архитектура — не «сколько шаблонов в spec».
3.2. Viewpoints и артефакты документов
Views не заменяют 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), но дают им архитектурную основу:
| Документ | Типичные Viewpoints | Что попадает в текст |
|---|---|---|
| Vision & Scope | Stakeholder, Goal Realization | Цели, drivers, ключевые stakeholders |
| BRD | Business Process Cooperation, Product, Service Realization | Процессы, роли, бизнес-сервисы и их реализация |
| SRS / FRD | Application Usage, Application Structure | Компоненты, сервисы, интерфейсы |
| ADR | Layered или адаптированный view | Решение с опорой на элементы модели — 10.01.13 Шаблон архитектурного решения (ADR) |
3.3. Собственный (custom) Viewpoint
Если стандартный шаблон не закрывает concern, адаптируйте или создайте свой. Минимальная спецификация (можно оформить как ADR):
- Stakeholders — для кого view.
- Concerns — какие вопросы должен закрыть.
- Purpose — designing / deciding / informing (по spec).
- Allowed elements — явный список типов из метамодели.
- Allowed relationships — какие связи разрешены между ними.
- Rules — например: «на view только Business Process и Business Role; без Application Component» или «Technology-элементы только Node и Device, без Business Process».
Граница адаптации: вы сужаете или расширяете example viewpoint из spec, не меняя семантику элементов. Произвольный набор без документирования — риск для команды.
3.4. Пример сквозной трассировки: «Улучшение клиентского сервиса»
Сценарий из нескольких views одной модели (каждый — свой Viewpoint и аудитория):
- Goal Realization (Motivation): Goal «Сократить время ответа» ← Requirement «Единый канал обращений 24/7» (Realization); Principle «Мгновенная обратная связь» Influence → Goal.
- Business Process Cooperation: процесс обработки запроса; роли «Оператор» и «Автоматизированный обработчик» (Business Role); Business Object «Тикет».
- Application Usage: Requirement «Единый канал…» трассируется в Business Service «Приём обращений» → Application Service «Сервис обработки обращений» (Realization) → Application Component TicketSystem (Realization); процесс Serving от Application Service.
- Implementation and Deployment: TicketSystem Deployment → Node в кластере Kubernetes (07.08 Контейнеризация и оркестрация (Docker, Kubernetes)).
- Migration (I&M): Plateau «AS-IS: только операторы» → Plateau «TO-BE: чат-бот + оператор»; Work Package «Внедрение TicketSystem»; Gap «Нет единого канала».
Цепочка для 02.03.04 Трассировка требований (концепция): Requirement → Business/Application Service → Application Component → Node. Каждая диаграмма читается своей аудиторией; связи между views — продолжение той же модели, а не отдельные рисунки.
4. Типовые ошибки и ограничения
- Goal — Realization → Principle — неверная метамодель; Principle связывают Influence с Goal или Requirement.
- Serving «наоборот» — стрелка от потребителя к поставщику.
- Application Usage в BRD вместо Service Realization / Product — путаница «кто потребляет приложение» и «что такое бизнес-сервис / продукт».
- Outcome Realization вместо Goal Realization — смешение стратегических outcomes и проектных целей/требований.
- Flow вместо Access/Representation между Business Object и Data Object.
- Всё на одном view без Layered Viewpoint — перегруженная диаграмма; делите по concerns.
- Несколько несвязанных моделей вместо одной — views не трассируются; элементы дублируются.
- Чат-бот как Business Role vs Application Component — автоматизация на прикладном слое; в процессе — Business Role с Serving от Application Service.
- Physical только «в теории» — на промышленных проектах добавьте Physical Viewpoint, а не только Technology.
- Custom viewpoint без документации allowed elements — несовместимые диаграммы в одной команде.
- Ожидание полного справочника связей здесь — Composition, Triggering, Specialization и др. — в spec; здесь только сквозной «клей» для viewpoints.
Связи с другими разделами базы
- Серия ArchiMate (06.03) — 06.03.01 Мотивационный слой, 06.03.02 Бизнес-слой, 06.03.03 Прикладной и технологический слои — элементы внутри слоёв; здесь — viewpoints и межслойные связи.
- Виды архитектуры ИС — 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) — параллель business/system/technical views и ArchiMate viewpoints.
- Scope и стейкхолдеры — 02.01.04 Определение границ решения (Scope Modelling), 02.01.03 Анализ заинтересованных сторон (Stakeholder Map), 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
- Альтернатива представлениям — 06.03.05 C4-модель — когда полный набор ArchiMate viewpoints избыточен.
- Трассировка — 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки.
- Процессы — 03.04.01 BPMN 2.0 - введение и основы — детализация процессов рядом с Business Process Cooperation.
- Документирование и ревью — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 10.01.13 Шаблон архитектурного решения (ADR), 08.04 Рецензирование и инспекции (техники Фейгана).
- Стандарты — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) (ISO 42010).
- Инструменты и инфраструктура — 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io), 07.08 Контейнеризация и оркестрация (Docker, Kubernetes).
Источники и дополнительные материалы
Книги и стандарты
- The Open Group. ArchiMate 3.1 Specification — глава 14 (Viewpoints and Views); Appendix C (Example Viewpoints). Вход: https://www.opengroup.org/archimate
- ISO/IEC/IEEE 42010:2011 — Systems and software engineering — Architecture description: https://www.iso.org/standard/50508.html
- Marc Lankhorst et al. ArchiMate 3.0.1: A Pocket Guide — раздел по Viewpoints.
- Gerben Wierda. Mastering ArchiMate Edition III — стандартные Viewpoints и их применение.
- The Open Group. ArchiMate Cookbook — примеры Viewpoints (публикации на opengroup.org).
Инструменты
- Archi — редактор ArchiMate со встроенными standard viewpoints: https://www.archimatetool.com/
- Справка Archi по views и Viewpoint: https://www.archimatetool.com/help/