Язык Archimate часто используется для описания слоя приложений, функциональности информационных систем и интеграционных сценариев между информационными системами. Но в этой статье я хочу рассказать о применении бизнес-слоя в Archimate, а именно, как описать бизнес‑процессы на языке Archimate.
Archimate — это язык моделирования архитектуры предприятия, который был разработан еще в 2004 году и теперь является открытым стандартом Open Group для описания архитектурных аспектов бизнеса, информационных систем и технологической инфраструктуры.
Многие скажут — зачем процессы описывать в Archimate, если есть привычная нотация BPMN? Однако, по моему мнению, для решения архитектурных задач нотация BPMN несколько избыточна, ведь в ней более 100 различных объектов, а в архитектурном репозитории нам нужно иметь бизнес‑процесс, описанный на верхнем уровне, без особых деталей, и лучше, если этот слой будет описан на том‑же языке и в том‑же хранилище, что и остальные слои архитектуры организации, то есть на языке Archimate.
На всякий случай, для тех, кто не знаком с понятием бизнес‑процесса: бизнес‑процесс — это повторяемая последовательность действий, направленная на достижение поставленной цели.
В начале своего трудового пути я долгое время моделировал процессы в немецком инструменте ARIS в нотации EPC (Event‑driven Process Chain). Нотация EPC ориентирована на события и функции, и визуализирует процессы, как цепочку событий и функций, выполняемых исполнителями и информационными системами.
Когда, изучая фрейворк TOGAF, описывающие подходы к управлению архитектурой предприятия, я увидел нотацию TOGAF Process flow diagram, которая может быть нарисована на языке Archimate, то понял, что это та‑же самая EPC, которую просто стали рисовать не сверху вниз, а слева направо. Моделируя процессы на языке Archimate можно получить простую модель процессов, описывающую основной поток процессов с применением всего пяти объектов.
Итак, несмотря на то, что в Archimate достаточно много объектов, но для описания процессов нам понадобятся лишь четыре объекта с бизнес‑слоя и один объект со слоя приложений:
Ориентация модели может быть либо вертикальная, либо горизонтальная — решайте сами, однако сейчас модно рисовать слева‑направо, ведь теперь мы не печатаем диаграммы, а смотрим их на экране, что удобнее в горизонтальном формате.
Многие зададут вопрос, а где же логические операторы, которые столь необходимы для визуализации развилок и циклов процесса. Два логических оператора есть и в языке Archimate, и при необходимости их можно применять, однако, несколько проектов в которых они применялась показали, что логические операторы сильно усложняют описание процессов, поэтому задумайтесь, нужны ли вам все эти развилки и циклы в процессе для решения архитектурных задач.
По мне, то для решения архитектурных задач достаточно последовательного перечня процессов с фиксацией стартовых и конечных событий, по которым мы определим/зафиксируем границы процессов.
Для каждого процесса нужно определить исполнителя, и лучше, что бы эта была бизнес‑роль, а не должность (Actor на языке Archimate), ведь должности меняются куда чаще, чем бизнес‑роли. Ну, и если вы решите показать информационные потоки в процессах, то входящие и исходящие документы (носитель информации на языке Archimate) можно тоже визуализировать на языке Archimate.
Чуть не забыл про связи. Для описания процессов нам нужны:
В части описания ИТ‑поддержки есть множество вариантов отобразить использование информационной системы в том или ином процессе, однако, по моему мнению, самым простым и универсальным методом является использование объекта сервис приложения языка Archimate, что позволяет на логическом уровне отвязать диаграмму процесса от слоя реализации ИТ, ведь на уровне приложений можно к ИТ‑сервису привязать Приложение, и менять его не меняя диаграмму процесса.
В качестве инструмента для создания диаграмм процессов проще всего применить инструмент Archi, который изначально создан для описания элементов и связей корпоративной архитектуры на языке Archimate. И хотя инструмент бесплатный, у него уже есть достаточно серьезное сообщество пользователей по всему миру и активно дорабатывается новый функционал.
В качестве еще одного варианта для описания процессов можно применить draw.io, в котором есть набор объектов для моделирования на языке Archimate, однако в этом инструменте нельзя обеспечить взаимосвязь между несколькими диаграммами в модели организации.
Вполне возможно, что многие из читателей сочтут данный подход излишне упрощенным, и тут главное понять, кто является потребителем результата. Данная диаграмма показывает все ключевые взаимосвязи между исполнителями, процессами, ИТ‑сервисами и документами (данными), что позволяет увидеть и анализировать зависимости между архитектурными объектами, и целевой функционал информационных систем.
Если мы хотим на диаграмме увидеть все варианты протекания процесса со всеми циклами и развилками, то это потребует добавления дополнительных объектов, правда, по моему мнению, потребителем диаграммы станет уже не корпоративный архитектор, а бизнес‑аналитик или процессный эксперт, задачи которых — анализ и оптимизация процессов.
Совмещение двух нотаций, например, «сверху» Archimate, а для детального описания процессов BPMN возможно, правда в бесплатных инструментах пока не видел такого функционала.
В следующей статье могу разобрать слой приложений, в рамках которого можно нарисовать диаграмму взаимодействия информационных систем, которую часто можно увидеть в руках у корпоративных архитекторов.
Если вы задумываетесь о системном подходе к управлению организацией, обратите внимание на курс «Архитектура корпорации. TOGAF 10». Чтобы познакомиться с форматом обучения и преподавателями курса, приходите на демо-уроки:
30 октября в 19:00 — Принимаем решения или как правильно выбрать информационную систему? Записаться
11 ноября в 19:00 — TOGAF Open Agile Architecture. Записаться
17 ноября в 19:00 — Archimate — инструмент описания корпоративной архитектуры. Записаться
А тем, кто настроен на серьезное системное обучение, рекомендуем рассмотреть Подписку — выбираете курсы под свои задачи, экономите на обучении, получаете профессиональный рост. Узнать подробнее
Комментарии (10)
ASenchenko
30.10.2025 07:53А можно уже повозражать ? :)
для решения архитектурных задач нотация BPMN несколько избыточна
BPMN для архитектурных задач не "избыточна", а "не применима" по сути. В ней нет нормальных системных объектов. Это всё-таки процессная нотация. И объектов в ней далеко не 100. Модификаторы расширенного BPMN - это именно модификаторы. Их кроме Репина с Белайчуком никто и использовать толком не умеет.
Archimate тем и хорош, что в него явным образом добавлены элементы системы.Связи Archimate для описания бизнес‑процессов.
И вот здесь и начинается основная засада Archimate, сравнимая с засадой UML.
Для того, чтобы корректно прочитать схему, нужно знать нотацию. То есть применяя Archimate, Вы должны быть на 100% уверены в том, что все, кто будет смотреть документацию, точно знают назначение стрелок. Ну или давать легенду под каждой схемой.Офтоп
Почему во всех статьях по Archimate за последнее время использованы одни и те же картинки? Все с одного курса вышли?
что позволяет на логическом уровне отвязать диаграмму процесса от слоя реализации ИТ
Андрей, я дважды прочитал этот абзац и реально не понял Вашей идеи. Вы предлагаете НЕ использовать Archimate, используя Archimate ? Ну так на BPM это можно сделать.
однако в этом инструменте нельзя обеспечить взаимосвязь между несколькими диаграммами в модели организации.
Зато редактор draw.io встроен в confluence :)))
по моему мнению, потребителем диаграммы станет уже не корпоративный архитектор, а бизнес‑аналитик или процессный эксперт
Ну так в том и плюс чтобы спеку могли одинаково прочитать все.
В этом смысле потрясающе хорош Sequence, его не нужно пояснять текстом. Его просто читают все, от пользователей до программистов.в рамках которого можно нарисовать
Ну и совсем уж душнилу включу напоследок.
Разработка архитектуры - инженерная дисциплина. Мы не "рисуем". Мы "чертим" :)))))
koptelovak Автор
30.10.2025 07:53Спасибо за комментарий! Обсуждение всегда полезно :)
BPMN для архитектурных задач не "избыточна", а "не применима" по сути.
Я остерегаюсь резких утверждений, есть примеры, когда в BPMN добавляют объекты с разных слоев корп.архитектуры, правда это в коммерческих инструментах
Для того, чтобы корректно прочитать схему, нужно знать нотацию.
Это проблема любой нотации
Вы предлагаете НЕ использовать Archimate, используя Archimate ?
Я предлагаю использовать ИТ-сервис, а не приложение, что бы при замене приложения не перепривязывать объект к модели
Зато редактор draw.io встроен в confluence :)))
У любого подхода есть преимущества и недостатки
В этом смысле потрясающе хорош Sequence, его не нужно пояснять текстом
Ну это на уровне ИТ, на уровне бизнеса не поймут
Разработка архитектуры - инженерная дисциплина. Мы не "рисуем". Мы "чертим" :)))))
Ну тут все зависит от контекста :)))
ASenchenko
30.10.2025 07:53Я предлагаю использовать ИТ-сервис, а не приложение, что бы при замене приложения не перепривязывать объект к модели
Всё, понял. Уходим в абстракцию "тип системы". Да, это хороший подход.
когда в BPMN добавляют объекты с разных слоев корп.архитектуры, правда это в коммерческих инструментах
Лично наблюдал 3 "версии" BPMN, вполне устоявшиеся на уровне достаточно крупной компании. Думаю, это одна из причин, по которой разработчики Archimate таки начали его делать. В BPMN прямо дико не хватает системных связок и кто как хочет, тот так и изворачивается чтобы их добавить.
Это проблема любой нотации
Не скажите.
EPC, C4, да тот же BPMN без модификаторов, граничных событий и кастомных изменений, читают свободно таки все. Я недавно жену, госслужащего, буквально за 20 минут научил BPM-ки читать и даже чертить простенькие в камунде. По работе понадобилось.В Archimate же значащий тип стрелки. Я его редко использую именно по этой причине. Так то он реально удобен.
И по Sequence - если там не только IT-сущности на схеме, но и бизнес-описание, то те ребята из бизнеса, с которыми я работаю, прекрасно всё читают.
koptelovak Автор
30.10.2025 07:53EPC, C4, да тот же BPMN без модификаторов, граничных событий и кастомных изменений, читают свободно таки все
Думаю, что и описание процесса в Archimate не сильно отличается от EPC, да и других нотаций. Если у Вас читают EPC, то точно прочитают и Archimate. Вопрос правильности стрелок нотации на диаграмме на уровне бизнеса не сильно важен...
ASenchenko
30.10.2025 07:53У нас чуть другой подход просто.
Аналитики и архитекторы работают только в confluence, так что связи моделей "как в ARIS" не критичны. Всё держится внутри одного документа или ссылками. Ну и выбор инструментов соответствующий - то, что можно редактировать в конфе (отсюда и draw.io)
Поэтому есть 2 типа схем. Базовая абстракция, "БТ" - схемы helicopter view, обычно в C4. Если не не хватает динамики, то добавляется BPM (здесь как раз просится Archimate)
А вот уже при переходе на "ФТ", на конкретные функций конкретных систем - Sequence, EPC или текстовый UC - по ситуации.
Archimate же пока не прижился. Очень редко используем.
itGuevara
30.10.2025 07:53Похоже возвращаетесь к своему же Рисуем EPC в Archi, но уже не «в вертикаль»
rankdir="TB", а в «горизонталь»rankdir="LR".Что VAD \ EPC \ процессный блок в Archimate – это про «одно и тож» показано в ВРМ. Смарт-инструменты «Таблица -> Схема» (на github см. демонстрацию), а
Рис. 1. Пример объектов в диаграмме описания бизнес‑процессов на языке Archimate.
- вылитый «VAD с событиями» (кстати, именно такой VAD иногда и используется, т.к. без пояснения веток событиями он читается тяжело).
Важно саму природу связей показать, например, Триггер в Archimate – полагаю, что это передача маркера \ фишки workflow. Сама идея сравнения EPC и ArchiMate – хорошая, а более комплексно табличка тут, но ошибки есть и глубже нужно, например, сравнивать предикаты \ отношения.
Совмещение двух нотаций, например, «сверху» Archimate, а для детального описания процессов BPMN возможно, правда в бесплатных инструментах пока не видел такого функционала.
Да, ключевая проблема – это отсутствие бесплатных и хороших инструментов моделирования с репозитарием объектов: или в Archi добавлять редактор МетаМодели и добавлять через него любые нотации или «лучше искать» \ делать самим (раз; два). Есть ADOxx, но там все перепутано.
А EPC - да, наиболее полно проработанная нотация и онтологию процесса (МетаМодель объекта "Процесс") нужно строить на ней, впрочем как и математизацию workflow.
010011011000101110101
eEPC, IDEF0, BPMN, UML - по сути все делают одно и то же, без разницы что использовать. Но кому-то показалось мало, придумали ещё и это. Ну ладно, пусть будет
koptelovak Автор
У Archimate "из коробки" согласованность между другими слоями корп.архитектуры, а так Вы правы - все это про описание деятельности в виде алгоритмов