Заинтересованные стороны в ArchiMate 4.0: кто они и зачем нужны

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

Схема иллюстрирует заинтересованную сторону (Stakeholder) в ArchiMate 4.0 и её связь с целью (Goal). Руководитель компании заинтересован в сокращении расходов, поэтому его ожидания отражаются в архитектурной модели в виде цели. Стрелка здесь служит условным обозначением связи для наглядности, а не точным обозначением типа отношения ArchiMate.

В этой статье разберём, как в ArchiMate 4.0 описываются Заинтересованные стороны, чем они отличаются от Драйверов, Интересов и проблем и других понятий, как находить их в реальных проектах и связывать с архитектурными решениями. Материал построен от простого к сложному: сначала определим участников, затем рассмотрим их роли, интересы, конфликты и способы отображения в архитектурной документации.

Что такое заинтересованные стороны в ArchiMate 4.0

В ArchiMate 4.0 Заинтересованные стороны — это понятие, с помощью которого фиксируют участников, имеющих интерес к архитектуре или способных повлиять на её развитие. Речь идёт не только о физических лицах. За такой ролью может стоять совет директоров, государственный орган, подразделение компании, клиентская группа, поставщик или профессиональное сообщество.

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

В практической работе Заинтересованная сторона отвечает на вопрос: кто воспринимает изменения как значимые? Например, при переходе банка на новую платформу руководитель ИТ будет беспокоиться о надёжности и стоимости эксплуатации, финансовый директор — о бюджете, оператор — об удобстве интерфейса, а регулятор — о соблюдении обязательных требований.

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

Критерий	Что означает	Пример
Влияние	Способность менять решения, сроки или ресурсы	Совет директоров утверждает бюджет
Зависимость	Насколько участник зависит от результата архитектурных изменений	Операторы зависят от доступности рабочего места
Интерес	Что именно участник хочет получить или сохранить	Сократить время обработки заявки
Ответственность	За какие последствия участник отвечает	Директор по информационной безопасности отвечает за риски
Полномочия	Право принимать, согласовывать или блокировать решения	Регулятор может потребовать доработку

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

Практический пример 1

Ситуация: компания внедряет единую систему управления заказами.

Заинтересованные стороны:
- коммерческий директор — хочет видеть продажи в одном месте;
- руководитель склада — хочет точные остатки;
- оператор — хочет меньше ручного ввода;
- клиент — хочет получать актуальный статус заказа;
- аудитор — хочет видеть историю изменений.

Вывод: одна система имеет минимум пять разных ожиданий.
Если учесть только коммерческого директора, проект может быть удобным для отчётности,
но неудобным для склада и клиентов.

Зачем нужны заинтересованные стороны

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

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

Работа с участниками помогает сделать несколько важных вещей:

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

Особенно важно учитывать их при подготовке Представлений и выборе Точек зрения. Руководителю нужна краткая картина затрат, рисков и эффектов. Архитектору — зависимости между системами и технологиями. Пользователю — изменения в рабочем сценарии. Один огромный чертёж для всех обычно похож на универсальный инструмент, который одинаково неудобен для любой задачи.

Если участника не учесть	Возможное последствие	Как предотвратить
Пользователь	Сотрудники обходят новую систему	Провести интервью и пилотирование
Финансовый руководитель	Не хватает бюджета на эксплуатацию	Показать полную стоимость владения
Служба безопасности	Проект не проходит проверку	Подключить специалистов до выбора решения
Клиент	Изменение ухудшает пользовательский опыт	Проверить сценарии клиента и метрики качества
Регулятор	Нарушены обязательные требования	Зафиксировать нормативные ограничения заранее

Ещё одна задача — управление ожиданиями. Участники часто используют одни и те же слова в разном смысле. Для директора «надёжность» может означать отсутствие простоев, для инженера — резервирование компонентов, а для аудитора — доказуемое выполнение процедур. Архитектурное обсуждение должно переводить такие общие слова в проверяемые критерии.

Практический пример 2

Неудачная формулировка:
"Система должна быть удобной и надёжной."

Рабочая формулировка:
- оператор оформляет заявку не более чем за 3 минуты;
- сервис доступен 99,9% рабочего времени;
- восстановление после сбоя занимает не более 30 минут;
- каждое изменение заказа сохраняется в журнале.

Результат: ожидания разных участников превращаются в проверяемые условия.

Какие бывают заинтересованные стороны

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

Группа	Типичные интересы	Основной вопрос
Руководители и владельцы бизнеса	Результат, прибыль, риски, сроки	Зачем компании эти изменения?
Сотрудники и пользователи систем	Удобство, понятность, скорость	Как изменится моя ежедневная работа?
ИТ-специалисты и архитекторы	Совместимость, поддержка, безопасность	Как реализовать и сопровождать решение?
Клиенты и партнёры	Качество сервиса, прозрачность, доступность	Что изменится для внешнего участника?
Регуляторы и аудиторы	Соответствие законам и стандартам	Можно ли доказать выполнение требований?

Руководители и владельцы бизнеса

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

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

Практический пример 3

Вопрос владельца бизнеса:
"Почему мы должны менять старую систему?"

Слабый ответ:
"Потому что текущая платформа устарела."

Сильный ответ:
"Из-за ограничений текущей платформы запуск нового продукта занимает 8 недель.
Целевая архитектура сокращает этот срок до 2 недель и снижает зависимость
от ручных операций. Стоимость перехода — такая-то, основной риск — такой-то."

Сотрудники и пользователи систем

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

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

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

Что выяснить у пользователя	Почему это важно
Какие действия выполняются чаще всего	Они определяют удобство основного сценария
Где возникают задержки	Именно там часто находится резерв эффективности
Какие данные вводятся повторно	Повторный ввод повышает ошибки и стоимость работы
Какие исключения встречаются	Исключения могут быть важнее «идеального» процесса
Что сотрудники делают вне системы	Это показывает скрытые обходные пути

ИТ-специалисты и архитекторы

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

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

Практический пример 4

Конфликт ожиданий:

Бизнес: "Запустить сервис через месяц."
Эксплуатация: "Нужны резервное копирование и мониторинг."
Безопасность: "Нужны многофакторная аутентификация и журналирование."
Архитектор: "Нужно проверить интеграции."

Решение:
1. выделить обязательный минимум для первого запуска;
2. зафиксировать отложенные функции;
3. назначить владельцев рисков;
4. определить дату пересмотра временных решений.

Клиенты, партнёры и регуляторы

Внешние участники часто не видны на внутренних совещаниях, но именно они могут определить границы допустимого. Клиент оценивает скорость и качество сервиса, партнёр — стабильность обмена данными, регулятор — соответствие требованиям. В цифровых экосистемах таких участников становится особенно много.

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

Внешняя сторона	Что её интересует	Архитектурный аспект
Клиент	Доступность и понятность сервиса	Каналы взаимодействия и качество услуг
Поставщик	Стабильность интеграции	Форматы данных и правила обмена
Регулятор	Соблюдение обязательных норм	Контроль, хранение и трассируемость данных
Аудитор	Доказательства выполнения процедур	Журналы, отчёты и ответственность
Партнёр по экосистеме	Предсказуемость совместной работы	Соглашения, интерфейсы и уровни сервиса

Как определить заинтересованные стороны

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

Искать нужно не только тех, кто громче всех говорит, но и тех, кто понесёт последствия молча. Самые заметные участники не всегда являются самыми важными.

Практический процесс можно разделить на несколько шагов:

1. определить границы инициативы и ожидаемый результат;
2. составить предварительный список подразделений и внешних участников;
3. проверить, кто принимает решения, кто выполняет работу и кто несёт риски;
4. провести интервью, наблюдения и анализ документов;
5. сгруппировать участников по общим интересам;
6. сопоставить интересы с требованиями и архитектурными решениями;
7. проверить список на пропуски и конфликтующие ожидания.

Метод	Когда применять	Что можно узнать	Ограничение
Интервью	Для ключевых участников	Мотивы, опасения, ожидания	Зависит от откровенности собеседника
Наблюдение	Для изучения реальной работы	Скрытые операции и обходные пути	Занимает время
Анализ документов	В регулируемых процессах	Формальные обязанности и ограничения	Документы могут устареть
Семинар	Для согласования нескольких групп	Конфликты и общие цели	Громкие участники могут доминировать
Опрос	Для большой аудитории	Массовые тенденции	Мало контекста и деталей

Определение участников и их ролей

Начинать лучше с границ инициативы. Нельзя качественно определить участников, пока непонятно, что именно меняется: отдельный экран, бизнес-процесс, информационная платформа или вся операционная модель компании. Чем шире границы, тем больше уровней влияния придётся рассматривать.

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

Практический пример 5

Инициатива: перевод закупок в электронный формат.

Решает: директор по снабжению.
Финансирует: финансовый директор.
Использует: специалисты по закупкам.
Согласует: юридическая служба.
Поддерживает: ИТ-служба.
Контролирует: внутренний аудит.
Затрагивается косвенно: поставщики.

Проверка полноты:
если не включить поставщиков, электронный процесс окажется рассчитан
только на внутреннюю сторону и может не заработать на практике.

Выявление интересов и ожиданий

После составления списка нужно понять, чего каждый участник хочет, чего опасается и по каким признакам оценит успех. Полезно задавать открытые вопросы: «Что должно измениться?», «Что нельзя потерять?», «Какой риск для вас неприемлем?», «Что будет доказательством результата?».

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

Высказывание	Возможный смысл	Что уточнить
«Нужна гибкость»	Частые изменения требований	Какие изменения и с какой частотой?
«Нужна прозрачность»	Не хватает статусов и ответственности	Кто и какие данные должен видеть?
«Нужно снизить риски»	Есть опасения по сбоям, безопасности или срокам	Какой риск наиболее критичен?
«Система должна быть быстрой»	Долгий отклик мешает работе	Для каких операций и при какой нагрузке?
«Нельзя зависеть от поставщика»	Есть опасение блокировки или роста расходов	Какие компоненты должны быть заменяемыми?

Связь с архитектурными решениями

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

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

Практический пример 6

Участник: руководитель клиентского сервиса.
Интерес: сократить время ответа клиенту.
Требование: оператор должен видеть историю обращения и заказа.
Решение: объединить данные службы поддержки и системы заказов.
Результат: оператор отвечает без переключения между четырьмя приложениями.
Метрика: среднее время ответа уменьшается с 15 до 7 минут.

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

Примеры из практики

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

Внедрение корпоративной информационной системы

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

Единая система не устраняет противоречия автоматически: она часто делает их видимыми и обязательными для согласования.

Владельцу бизнеса нужна управляемость, финансовому блоку — единые цифры, производству — точные планы, складу — актуальные остатки, а ИТ-службе — контролируемая интеграция и понятная поддержка. Если внедрение строится только вокруг настройки программных функций, организационные конфликты просто переместятся внутрь новой системы.

Участник	Интерес	Риск	Решение
Генеральный директор	Единая управленческая картина	Отчёты остаются несопоставимыми	Общие правила показателей
Финансовый директор	Контроль затрат	Расходы видны слишком поздно	Связь плановых и фактических данных
Начальник производства	Реалистичный план	Срывы из-за неверных остатков	Синхронизация запасов и заказов
Сотрудник склада	Простые операции	Ошибки при ручном вводе	Штрихкодирование и понятные сценарии
ИТ-служба	Стабильная эксплуатация	Сложная поддержка	Стандартизированные интеграции и мониторинг

Практический пример 7

До проекта:
- остатки ведутся в трёх системах;
- план производства уточняется по телефону;
- отчёт формируется пять рабочих дней.

После согласования интересов:
- определён единый источник данных о запасах;
- зафиксирован владелец каждого справочника;
- отчёт строится автоматически;
- ручные корректировки регистрируются и проверяются.

Автоматизация бизнес-процесса

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

При обследовании важно выяснить не только нормативный маршрут, но и исключения: срочную заявку, отсутствие руководителя, изменение суммы, возврат документа на доработку. Если автоматизировать только идеальный сценарий, сотрудники продолжат использовать электронную почту и таблицы для нестандартных случаев.

Этап процесса	Участник	Типичная проблема	Архитектурная мера
Создание заявки	Сотрудник	Непонятно, какие поля обязательны	Подсказки и проверка данных
Согласование	Руководитель	Заявки теряются в почте	Единый маршрут и уведомления
Проверка	Финансовая служба	Нет информации о бюджете	Связь с финансовыми лимитами
Исполнение	Сервисное подразделение	Невозможно оценить очередь	Статусы и контроль сроков
Анализ	Руководитель процесса	Нет статистики	Отчёты по срокам и причинам возврата

Практический пример 8

Процесс согласования закупки.

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

Изменение:
- заявка создаётся в одном интерфейсе;
- система сама определяет маршрут;
- каждый участник видит срок своего действия;
- возврат фиксируется с указанием причины;
- руководитель получает отчёт о задержках.

Модернизация ИТ-инфраструктуры

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

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

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

Параметр	Что спрашивает бизнес	Что проектирует ИТ
Доступность	Как часто возможен простой?	Резервирование и устранение единых точек отказа
Восстановление	Когда работа будет возобновлена?	Резервные копии и сценарии восстановления
Производительность	Сохранится ли скорость при росте нагрузки?	Масштабирование и тестирование
Безопасность	Как защищены важные данные?	Контроль доступа, шифрование и мониторинг
Стоимость	Сколько будет стоить владение?	Модель потребления ресурсов и оптимизация

Практический пример 9

Сервис: интернет-магазин.

Бизнес-ограничение:
простой более 20 минут приводит к существенным потерям продаж.

Архитектурное решение:
- резервирование критичных компонентов;
- автоматическое переключение;
- мониторинг ключевых показателей;
- регулярная проверка восстановления.

Проверка:
раз в квартал проводится имитация отказа,
а результат рассматривается владельцем бизнеса и ИТ-службой.

Разработка целевой архитектуры компании

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

В таком проекте число участников обычно велико. Руководство определяет стратегические приоритеты, бизнес-подразделения формулируют потребности, ИТ оценивает реализуемость, безопасность задаёт ограничения, финансы проверяют доступность инвестиций. Архитектору важно не смешать все голоса в одну усреднённую позицию, а показать различия и точки согласия.

Уровень планирования	Главный вопрос	Участники
Стратегический	Куда должна двигаться компания?	Собственники и высшее руководство
Тактический	Какие способности нужно развить?	Руководители направлений и владельцы продуктов
Операционный	Как изменить ежедневную работу?	Менеджеры процессов и сотрудники
Технологический	На каких решениях это построить?	Архитекторы и ИТ-специалисты
Контрольный	Как подтвердить достижение результата?	Финансы, аудит, безопасность и регуляторы

Практический пример 10

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

Связь с интересами:
- руководство — новый источник выручки;
- клиент — оформление без посещения офиса;
- операционный блок — меньше ручной обработки;
- ИТ — единая платформа интеграции;
- безопасность — защита персональных данных.

Очередность:
1. определить клиентские сценарии;
2. выбрать приоритетную услугу;
3. подготовить интеграции;
4. провести пилот;
5. измерить результат и расширить решение.

Похожие понятия

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

Понятие	На какой вопрос отвечает	Чем отличается
Заинтересованная сторона	Кто заинтересован или влияет?	Описывает участника
Интересы и проблемы	Что для него важно или вызывает обеспокоенность?	Описывает содержание интереса
Драйвер	Что побуждает к изменениям?	Описывает причину или воздействующий фактор
Точка зрения	Какой способ анализа нужен?	Задаёт правила отбора и показа информации
Представление	Как конкретно показана архитектура?	Является результатом отображения
Модель	Что и как описывается в целом?	Содержит структурированное описание

Интересы и проблемы (Concerns)

Интересы и проблемы описывают то, что важно для Заинтересованной стороны: цель, опасение, вопрос, требование к результату или область риска. Если участник отвечает на вопрос «кто?», то это понятие отвечает на вопрос «что именно его волнует?».

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

Участник	Интересы и проблемы	Возможный показатель
Клиент	Быстрое получение услуги	Время прохождения заявки
Руководитель	Контроль затрат	Отклонение от бюджета
Оператор	Меньше ручной работы	Количество действий на операцию
Безопасность	Контроль доступа	Число нарушений и исключений

Точка зрения (Viewpoint)

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

Для владельца бизнеса подходит одна Точка зрения, для инженера инфраструктуры — другая. Это не означает, что существуют две разные архитектуры. Меняется способ подачи информации, а не сама описываемая реальность.

Одна архитектура может иметь много точек зрения, потому что разным участникам нужны разные ответы на разные вопросы.

Представление (View)

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

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

Драйвер (Driver)

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

Различие между Драйвером и Интересами и проблемами особенно важно. Изменение закона является Драйвером, а необходимость обеспечить хранение данных в установленном формате — конкретной проблемой или интересом участника. Один Драйвер может породить несколько интересов у разных сторон.

Драйвер	Кого затрагивает	Какие изменения может вызвать
Новое регулирование	Юристов, ИТ, руководство	Изменение процессов и хранения данных
Рост конкуренции	Продажи, маркетинг, клиентов	Ускорение вывода новых услуг
Рост аварий	ИТ и владельцев бизнеса	Резервирование и мониторинг
Слияние компаний	Все подразделения	Интеграцию систем и унификацию процессов

Модель (Model)

Модель — это структурированное описание архитектуры, в котором элементы, свойства и связи организованы по определённым правилам. Она может охватывать стратегию, бизнес, приложения, технологии, реализацию изменений и другие области.

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

Уровень описания	Что может содержать	Для кого полезен
Стратегический	Цели, возможности, направления развития	Руководство
Бизнесовый	Процессы, роли, продукты, услуги	Владельцы бизнеса
Прикладной	Приложения, интерфейсы, данные	Архитекторы и владельцы систем
Технологический	Инфраструктура, сети, платформы	Инженеры и эксплуатация
Изменения	Проекты, этапы, результаты, переходы	Офис трансформации и руководство

Связь между понятиями можно представить как последовательность: Драйвер создаёт давление на организацию, Заинтересованная сторона формулирует значимый для неё вопрос, этот вопрос выражается через Интересы и проблемы, затем рассматривается в нужной Точке зрения и показывается в конкретном Представлении, входящем в общую Модель.

Итоговый мини-пример

Драйвер: новое требование законодательства.
Заинтересованная сторона: руководитель службы безопасности.
Интерес: доказуемый контроль доступа к данным.
Архитектурное решение: централизованное управление правами.
Точка зрения: безопасность и соответствие требованиям.
Представление: схема ролей, систем и журналов доступа.
Модель: общее описание архитектуры компании.

Хорошая работа с Заинтересованными сторонами не сводится к тому, чтобы добавить несколько фигур на диаграмму. Её цель — сделать архитектуру объяснимой: показать, кто влияет на изменения, какие интересы нужно учитывать, почему выбран конкретный путь и каким образом будет проверен результат. Тогда ArchiMate 4.0 становится не декоративным языком для красивых схем, а рабочим инструментом согласования бизнеса, людей и технологий.

Перед завершением проекта полезно проверить несколько вопросов:

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

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