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

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС. За последние годы я видел десятки моделей архитектуры — своих и чужих. И знаете, какая беда встречается чаще всего? Не кривой синтаксис и не «неправильная» стрелочка. Модель есть, она красивая, висит в Confluence — а на неё никто не смотрит, когда принимает решение.

В апреле 2026 The Open Group выпустила ArchiMate 4.0, и это, как ни странно, хороший повод пересобрать привычку моделирования с нуля. Потому что сейчас в новой версии новички — вообще все, опытные архитекторы в том числе.

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

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

Почему вообще стоит перечитать привычки: что случилось в 4.0

Если коротко: язык похудел. The Open Group сократила число концептов примерно на 30% — с шестидесяти с лишним типов элементов до сорока. Сделано это по большей части через чистку метамодели: раньше вы были обязаны раскладывать процессы по трём разным слоям (бизнес‑процесс, процесс приложения, технологический процесс), даже когда по сути это был один и тот же процесс. Теперь в большинстве практических случаев не нужно выбирать специализированную разновидность процесса под конкретный слой — достаточно смоделировать процесс.

Что поменялось на практике, если перечислить только то, что реально трогаешь руками при сборке модели:

• Термин «слой» (layer) заменён на более гибкий «домен» (domain), а сама структура языка теперь изображается не привычной матрицей «слои × аспекты», а «ArchiMate Hexagonion», где Motivation вынесен в центр.

• Появилась множественность на связях. Теперь связь может нести кратность — 1..*, 0..1, 1-to‑many — чтобы выразить ограничения уровня экземпляров прямо в модели. Раньше «один клиент может иметь много счетов» приходилось описывать в тексте рядом со схемой.

• Убрали часть избыточных элементов и связей. Например, Composition больше не входит в базовый набор отношений языка — для группировки теперь используют Aggregation или специальный элемент Grouping. Связь никуда не «пропала», но в обновлённой метамодели применяется иначе.

• Звучит академично, но переводится в одну вещь: модель стало проще собирать и, что важнее, проще читать тому, кто не архитектор. А именно на читаемости обычно всё и рушится.

Один нюанс, о котором честно предупрежу, потому что это боль многих на июнь 2026. Самый популярный бесплатный инструмент — Archi — на момент написания официальной поддержки 4.0 ещё не даёт (её, к слову, ведёт председатель ArchiMate Forum, который контрибьютит в Archi с 2013 года, — так что вопрос времени).

Из коммерческих Visual Paradigm заявил себя первым вендором с полной поддержкой ArchiMate 4. Поэтому дальше структуру модели я показываю схемами, а нотацию 4.0 объясняю словами — так вы соберёте ту же логику в любом инструменте. Мой совет новичкам: не ждать «идеального» тулинга, а начать в том, что под рукой, держа в голове новую метамодель.

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

Шаг 0. Договоримся об исходных условиях

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

Что мы моделируем: интернет‑магазин среднего размера. Клиент заходит на сайт, оформляет заказ, платит картой, получает уведомление, склад собирает и отгружает. Ничего экзотического — именно поэтому пример узнаваемый.

Наши вводные и ограничения:

1. Инструмент: Archi (бесплатный, кросс‑платформенный). Метамодель держим в голове по 4.0, даже если палитра инструмента пока по 3.2.

2. Аудитория модели: продакт, тимлид разработки, DevOps. Не международное жюри архитекторов — это определяет уровень детализации.

3. Уровень детализации: обзорный. Строим карту, а не чертёж каждого болта.

4. Что НЕ моделируем: платёжный шлюз изнутри, устройство CDN, схему БД по таблицам. Это живёт в других, более детальных представлениях.

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

Дальше я опираюсь на разбор консультантов NILUS — это не часть стандарта The Open Group, а экспертные рекомендации, но сформулированы точно. Хорошая архитектура целенаправленна, а не исчерпывающа — достаточно смоделировать релевантные слои так, чтобы поддержать реальное решение, дорожную карту или обсуждение рисков. Остальное — визуальный шум.

Шаг 1. Начинаем с бизнес‑домена: что происходит и для кого

Первое правило, которое я усвоил на своих ошибках: для первой модели удобно идти сверху вниз, от бизнеса к технологиям.

Оговорюсь — это не единственный путь: опытные команды начинают и с карты способностей, и с портфеля приложений, и с event storming. Но когда садишься за модель впервые, движение сверху вниз даёт самую понятную траекторию. Разработчику хочется сразу рисовать сервисы и базы — привычная зона комфорта. Но если начать снизу, получите красивую схему инфраструктуры, из которой непонятно, зачем она вообще нужна бизнесу.

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

Для нашего магазина:

• Активные структуры (кто действует): Клиент, Оператор склада. В терминах ArchiMate это Business Actor.

• Поведение (что делают): «Оформить заказ», «Оплатить», «Собрать и отгрузить». Это бизнес‑процессы.

• Пассивные структуры (над чем работают): Заказ, Платёж. Это Business Object.

Здесь же проявляется первое новшество 4.0, которое реально упрощает жизнь. Раньше, если один и тот же процесс затрагивал человека, приложение и инфраструктуру, приходилось плодить дубли поведения на каждом слое.

Теперь Role больше не ограничен исключительно бизнес‑доменом и может использоваться шире — в том числе применяться к активным структурам за пределами бизнес‑слоя. То есть «Обработчик заказа» как роль можно осмысленно закрепить и за живым оператором, и за сервисом‑автоматом. Для e‑commerce, где половину действий делает человек, а половину — система, это удобно.

Введём эту первую часть визуально. На схеме ниже (рис. 2) — только бизнес‑домен: актёры, их процессы и объекты, с которыми они работают. Никакой технической начинки, она появится позже.

Сразу важная оговорка на все диаграммы в статье: для иллюстраций я использую Mermaid, а не настоящую нотацию ArchiMate. ArchiMate — строгий визуальный язык со своими значками и типами связей; здесь прямоугольники и стрелки условны.

Тип связи я подписываю прямо на стрелке (serving, realization, access), а поток между процессами (‑→) — это просто последовательность, а не конкретное отношение ArchiMate. Так логику можно прочитать без установленного инструмента; в реальном Archi те же элементы собираются штатной палитрой.

Как проверить, что шаг сделан верно: пройдитесь по каждому процессу и спросите — у него есть тот, кто его запускает (актёр), и то, что он производит (объект)? Если у процесса нет актёра, вы описываете не бизнес, а какую‑то абстракцию. Если процесс не создаёт и не меняет ни одного объекта — скорее всего, он лишний на этом уровне.

Главная мысль этого шага: если вы не можете назвать актёра, процесс и объект простыми словами, значит, вы ещё не поняли задачу — и рисовать техническую часть рано. Бизнес‑домен — это проверка на то, что вы вообще понимаете, что за систему описываете.

Шаг 2. Спускаемся в домен приложений: чем это автоматизируется

Теперь, когда понятно ЧТО и ДЛЯ КОГО, спускаемся на уровень приложений. Здесь мы отвечаем на вопрос: какие системы реализуют бизнес‑поведение.

Для магазина это будет примерно так:

1. Application Component (компоненты‑системы): Витрина (Storefront), Сервис заказов (Order Service), Сервис оплаты (Payment Service), Сервис уведомлений (Notification Service).

2. Application Service (что система отдаёт наружу): «Приём заказа», «Проведение платежа», «Отправка уведомления». Это то, чем компонент служит бизнес‑процессу.

Ключевая связка ArchiMate, которую надо понять один раз и навсегда: бизнес‑процесс не «содержит» приложение и не «запускает» его напрямую. Приложение предоставляет сервис (Application Service), сервис обслуживает — в терминах ArchiMate это связь Serving — бизнес‑процесс, а сам сервис реализуется компонентом через Realization. Для простоты я опускаю здесь Application Interface (точку доступа, через которую публикуется сервис): на обзорном уровне он только загромоздит схему. Звучит как занудство, но именно эта дисциплина отделяет читаемую модель от каши.

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

Дальше там же есть золотое: используйте самую конкретную связь из возможных; Association — самая слабая связь, и злоупотребление ей — красный флаг недисциплинированного моделирования. Я бы предпочёл увидеть модель с десятью точными связями, чем с полусотней безликих стрелочек «просто чтобы соединить».

Ещё момент про направление, на котором спотыкаются все новички. Serving идёт от поставщика к потребителю, Realization — от реализующего к абстракции, Access — от активного элемента к пассивному. Перепутать направление — семантически как сказать «база данных работает на приложении» вместо «приложение работает на базе». Я сам, когда начинал, рисовал стрелки «как красивее легло». А потом на ревью выяснялось, что модель читается ровно наоборот.

Добавим домен приложений к нашей схеме и покажем, как он стыкуется с бизнесом (рис. 3).

Как проверить, что шаг сделан верно: возьмите любой бизнес‑процесс с рис. 2 и проследите цепочку вниз — есть ли сервис, который его обслуживает, и компонент, который этот сервис реализует?

Если у процесса нет обслуживающего сервиса, значит, в системе нет ничего, что его поддерживает (либо вы забыли компонент, либо процесс вообще ручной). Обратная проверка: нет ли компонента, который ничего не обслуживает, — такой «висит в воздухе» и, возможно, лишний.

Главная мысль: между «что делает бизнес» и «какой компонент это делает» всегда стоит сервис. Компонент реализует сервис, сервис обслуживает процесс. Держите этот бутерброд в голове — и половина вопросов «а как соединить вот это с этим» отпадёт сама.

Шаг 3. Технологический домен и та самая новая множественность

Опускаемся на последний уровень — технологический. Здесь живёт то, на чём всё крутится: узлы (Node) и системный софт (System Software). Для простоты не выделяю отдельно Device (физическое или виртуальное железо): на обзорном уровне облачный кластер удобнее показать одним узлом, в детальной инфраструктурной модели Device моделируют явно.

Для нашего магазина, без фанатизма:

Node: облачный кластер приложений, сервер БД.

System Software: собственно СУБД (пусть будет PostgreSQL), брокер сообщений.

И вот здесь развернём во всю ширь второе большое новшество 4.0 — кратности на связях, потому что e‑commerce — это идеальная витрина для него. В реальном интернет‑магазине один клиент оформляет много заказов. Один заказ содержит много позиций. Один платёж относится ровно к одному заказу. Раньше всё это жило в комментариях сбоку. Теперь это выражается прямо в модели: например, кратность 1..* от Клиента к Заказу.

Мне как‑то попалась мысль, что кратности сближают ArchiMate с UML по точности — и это правда, но с двумя оговорками.

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

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

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

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

Табл. 1. Мини‑шпаргалка по связям для сборки модели

Как проверить, что шаг сделан верно: для каждого компонента приложения из шага 2 спросите — на каком узле он развёрнут и с каким системным софтом работает? Если компонент ни к чему не привязан на технологическом уровне, вы не сможете ответить на вопрос «а где это вообще запущено». И отдельно по кратностям: на каждую проставленную кратность должна найтись фраза бизнес‑смысла («один платёж — один заказ»). Не можете такую фразу придумать — убирайте кратность, это украшательство.

Главная мысль шага: технологический домен — не место, чтобы показать, какой у вас крутой стек. Это место, чтобы показать, на чём держатся сервисы из шага 2 и где узкие места. А новые кратности используйте точечно, как скальпель, а не как малярную кисть.

Шаг 4. Собираем сквозное представление и проверяем читаемость

Теперь самое интересное — собрать три домена в одно связное представление (view) и посмотреть, читается ли оно. И вот тут вступает главный принцип, который я ставлю выше всех остальных. Формулировка NILUS бьёт точно: самый важный best practice — это дисциплина представлений: каждое представление отвечает на один вопрос для одной аудитории. Дальше — проверка, которую я советую сделать привычкой: прежде чем рисовать диаграмму, произнесите вслух: «это представление отвечает на вопрос X для стейкхолдера Y». Не можете закончить фразу — не рисуйте представление.

Наше сквозное представление отвечает на вопрос «как заказ клиента проходит через системы и инфраструктуру» для тимлида и продакта. Всё, что не помогает ответить на этот вопрос, с диаграммы убираем.

Пара практических приёмов оформления, которые превращают схему из «понятной автору» в «понятную всем».

• Первое — расставляйте элементы по потоку: если есть логический поток (бизнес запускает приложение, приложение обращается к инфраструктуре), располагайте элементы слева направо или сверху вниз по этому потоку — единый паттерн раскладки снижает когнитивную нагрузку.

• Второе, и это правило я бы выделил жирным для смешанной аудитории: добавляйте легенду; архитекторы читают ArchiMate нативно, стейкхолдеры — нет, и три строки легенды решают, поймут представление или проигнорируют.

Как проверить, что шаг сделан верно: покажите схему человеку, который её не рисовал (продакту, соседу‑разработчику), и попросите пересказать, что на ней происходит. Понял без ваших комментариев — представление читаемо. Начал переспрашивать «а это что» — значит, либо элементов слишком много, либо не хватает легенды и подписей.

Главная мысль: сквозное представление ценно не тем, что показывает «всё сразу», а тем, что позволяет проследить одну ниточку — путь заказа — через все уровни и увидеть, где он рвётся. Это и есть архитектурный рентген, ради которого всё затевалось.

Шаг 5. Проверяем модель: чек‑лист качества

Модель нарисована. Но «нарисована» не значит «готова». В коде мы гоняем тесты — в моделировании тоже есть свои проверки, и хорошие команды их не пропускают. Приведу метрики качества, которые кажутся мне самыми практичными (их удобно считать даже скриптом):

• Валидность связей — цель около 98%. Это доля связей, соответствующих метамодели ArchiMate; инструменты вроде Archi и Sparx EA умеют проверять это прямо при создании, так что невалидных связей должно быть почти ноль.

• Свежесть модели — цель порядка 75%. Доля элементов в активных доменах, изменённых за последние 180 дней; то, что не трогали больше полугода, скорее всего, разошлось с реальностью.

• Элементы‑сироты — цель «нулевой рост». Это элементы, которые есть в репозитории, но не появляются ни на одной диаграмме; они копятся от удалённых диаграмм и брошенных экспериментов и засоряют поиск.

В Archi, кстати, для таких проверок есть скриптовый движок jArchi — можно прогнать модель программно и выгрузить дашборд качества. Небольшой пример на jArchi (JavaScript), который просто считает, сколько элементов не имеют описания — банальная, но частая болячка:

// jArchi (JavaScript) — считаем элементы без документации
var total = 0, documented = 0;
$("element").each(function (e) {
    total++;
    if (e.documentation && e.documentation.trim().length > 0) {
        documented++;
    }
});
console.log("Всего элементов: " + total);
console.log("С описанием: " + documented +
    " (" + (documented / total * 100).toFixed(1) + "%)");

Мой личный чек‑лист перед тем, как показать модель команде, короче формальных метрик, но по нему я прохожусь всегда:

• Могу ли я объяснить каждую связь одной фразой на русском? Если где‑то мнусь — связь под снос или переделку.

• Есть ли на диаграмме хоть одна стрелка Association, которую можно заменить на конкретную (Serving, Realization, Access)? Если да — заменяю.

• Отвечает ли представление ровно на один вопрос? Если поймал себя на «ну тут и про это, и про то» — режу на два.

• Поймёт ли продакт без меня рядом? Нет — добавляю легенду и подписи.

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

Где этот способ не сработает

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

• Во‑первых, если нужна глубокая детализация одного куска — точная модель данных или процесс с ветвлениями и обработкой ошибок — ArchiMate для этого не лучший инструмент. Как отмечают сами практики, ArchiMate хорошо дополняется другими нотациями: бизнес‑процесс можно связать с BPMN‑диаграммой его деталей, а компонент приложения — с UML‑моделями внутреннего устройства. Не пытайтесь одним языком закрыть всё.

• Во‑вторых, если ваша команда никогда не жила с моделями, красивая схема сама по себе ничего не изменит. Тут я держу в голове очень отрезвляющую мысль, которую стоит повесить над столом каждого, кто рисует архитектуру: если артефакт архитектуры не влияет на финансирование, дорожную карту, стандарты или решения по разработке — это просто настенная живопись. Могу себе представить, как обидно потратить неделю на модель, которую положат в вики и забудут. Поэтому первый вопрос всегда: какое решение эта модель помогает принять? Нет ответа — не начинайте.

• В‑третьих, про сам переход на 4.0. Соблазн «всё старое на выброс» велик, но The Open Group сознательно закладывала обратную совместимость: версия развивает язык с сильной совместимостью на уровне пользователя, позволяя перейти с прежних версий плавно, сохранив ключевые концепты. Если у вас уже есть модели на 3.2 — не переписывайте их в панике. Начните новые проекты по‑новому, а старые мигрируйте, когда тулинг догонит и когда в этом будет практический смысл.

Итог

Мы прошли путь от пустого холста до сквозной модели магазина: бизнес‑домен — приложения — технологии — сборка представления — проверка качества. По дороге пощупали два главных новшества ArchiMate 4.0 — доменную структуру вместо жёстких слоёв и кратности на связях. И, надеюсь, увидели: самое важное в моделировании — не знание всех сорока элементов, а дисциплина. Одна модель — один вопрос, одна связь — одно понятное объяснение.

Если заберёте из статьи одну вещь, пусть это будет фраза‑проверка перед каждой диаграммой: «на какой вопрос и для кого она отвечает». С ней даже первая модель на незнакомой версии языка выйдет осмысленной, а не станет очередными красивыми обоями.

---

Я специально показывал ArchiMate не как набор правил из спецификации, а как рабочий инструмент: с пустого холста, с ошибками, проверками и вопросом «а кому вообще нужна эта схема?». Продолжить разбор можно на бесплатных уроках OTUS — их проводят преподаватели‑практики, а во время эфира можно задавать вопросы.

• 8 июля в 20:00 — «Новшества языка ArchiMate 4.0». Записаться

• 15 июля в 20:00 — «Архитектура предприятия: детализация бизнес-аспектов через ArchiMate 3.2». Записаться

• 21 июля в 20:00 — «Данные в TOGAF. Где скрыты? Разбираемся в деталях». Записаться

Больше открытых уроков июля смотрите в дайджесте.