ArchiMate — это язык моделирования архитектуры предприятия. Я часто о нём слышал, но никогда не пользовался. Он казался мне очень сложным с очень странной солянкой из разносортных объектов, с замороченным десктопным редактором. Изначально мы даже не рассматривали ArchiMate как первый кандидат на реализацию в нашем инструменте моделирования, а больше склонялись к моделям данных, C4, UML, BPMN. И добавили эту нотацию совершенно случайно. Но пока рисовали примеры моделей для статьи я просто обалдевал на сколько ArchiMate клёвый, какими гениями он придуман и зачем ИТ архитекторам могут быть нужны ещё какие‑то языки моделирования.

Мы попробовали описать разные аспекты нашего программного продукта в этой нотации от миссии и стратегической карты до сценария резервного копирования базы данных. В итоге у нас получилось что‑то среднее между небольшим руководством по ArchiMate и тупой неприкрытой саморекламой. Решайте сами полезно для вас это или нет. Статья получилась очень объёмная, смело пролистывайте не интересные разделы.

Модель нашего продукта в ArchiMate

Перед тем как что‑то моделировать я посмотрел несколько курсов по ArchiMate, но они были на столько пространными и абстрактными, что только добавили вопросов. Ещё попался такой прикольный перечень разных видов ArchiMate‑диаграмм и ещё немного примеров. Кстати у автора много других интересных статей, и на этом этапе я начал догадываться зачем всё это нужно. Но опять‑таки все эти примеры слишком абстрактные с объектами типа Goal 1, Goal 2, Goal 3, ...

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

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

Первая фишка ArchiMate в том, что он достаточно гибкий. В нём нет единственно правильного набора диаграмм на все случаи. У вас полная свобода что и как моделировать, поначалу это вводит в ступор, но потом проникаешься этой идеей.

Дальше я буду отмечать интересные на мой взгляд моменты таким образом.

Миссия, видение, цели и ценности

Мне очень нравится ArchiMate тем, что он позволяет описать все аспекты программного продукта от верхнеуровневых целей или стратегической карты до деталей реализации. Начнём с миссии, видения, целей и ценностей:

Миссия — это основная цель организации, смысл её существования, она определяется на старте и редко меняется.

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

Видение — это образ нашей организации и продукта в будущем.

В будущем хотелось бы создать инструмент моделирования, доступный для широкой аудитории пользователей, чтобы он не требовал сложного и долгого обучения, чтобы он мог использоваться для решения разных задач от построения генеалогического древа школьником (это вполне себе модель) до моделирования архитектуры предприятия или чего‑то более глобального.

Затем можно обозначить верхнеуровневые цели:

• Разработать сам инструмент моделирования

• Создать основные нотации моделирования (модели данных, C4, ArchiMate, ...) и дать пользователям возможность создавать свои

• Предоставить людям возможность создавать модели и делиться ими

• Создать сообщество пользователей и разработчиков

И ключевые ценности:

• Максимальная простота и доступность для пользователей. Мы совершенно точно не делаем Enterprise‑комбайн с тысячами кнопок и диалогов

• Но при этом полнота функциональности. Должен быть репозиторий моделей с управлением доступом, версионированием, API. Должны поддерживаться все сценарии, необходимые в инструменте моделирования: создание нотаций моделирования, создание моделей, поддержка разных форм представления моделей (диаграммы, таблицы, деревья, текст, ...), валидация и преобразование моделей, генерация артефактов из моделей (документы, код, ...). Словом draw.io, Figma или Miro мы тоже не делаем. А делаем что‑то среднее между Enterprise‑решением и простой рисовалкой диаграмм

• Открытость и соответствие стандартам. Чтобы для обмена моделями использовались международные стандарты, чтобы не было vendor lock‑in и можно было без особых проблем переключаться с одного инструмента моделирования на другой, что мы и сделали для Archi

• Минимализм реализации. На сколько это возможно мы стараемся не изобретать велосипед и не делать ничего лишнего. Во‑первых, потому что у нас не бесконечные ресурсы. Во‑вторых, чтобы инструмент легко встраивался в ландшафт информационных систем на предприятиях, у нас есть базовая функциональность, а всё остальное можно сделать через API

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

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

Если вы считаете все эти детали просто саморекламой, то дальше будет только хуже, вы сэкономите своё время, если сразу закроете статью. Но, с другой стороны, и я не вижу смысла писать очередное руководство в стиле «давайте нарисуем модель для интернет‑магазина или PetClinic, вот, один квадратик „микросервис для заказов“, вот второй квадратик „микросервис для корзины“, между ними стрелочка», лично мне всегда не хватает примеров ближе к реальности.

Стратегическая карта

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

Здесь перечислены уже более конкретные и измеримые цели, но при этом и более изменчивые.

Довольно часто цели разбивают на 4 перспективы: финансы, клиенты, внутренние бизнес‑процессы, обучение и развитие. Этот подход с несколькими перспективами описан в книге Р. Каплана и Д. Нортона «Сбалансированная система показателей. От стратегии к действию», по которой уже написано много статей. Но я не могу удержаться от того, чтобы не сделать свой очередной корявый пересказ. Смело пролистывайте этот раздел.

Финансы

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

Финансовые цели зависят от множества факторов, в том числе от стадии, на которой находится организация (или ваш проект):

• Рост. На этом этапе компания может не приносить никакой прибыли, идут активные инвестиции в развитие, в наращивание клиентской базы

• Устойчивое состояние. Всё ещё требуются инвестиции, но уже должна быть и прибыль

• Сбор «урожая». Здесь важен возврат инвестиций, сделанных на предыдущих этапах

Можно выделить три направления для достижения финансовых целей:

• Рост доходов и расширение структуры деятельности

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

  • Новое применение. Возможно, да. Я ни разу не видел, чтобы инструмент моделирования использовали, например, для выбора работы, для построения генеалогического древа или чего‑то подобного. Или тот же n8n — это вполне себе инструмент моделирования, но узкоспециализированный с одной нотацией под одну задачу. Или Swagger позволяет описать модель API и генерировать из неё разные вещи. Наверное нужно много лет заниматься разработкой инструментов моделирования, чтобы увидеть что‑то общее между n8n, Swagger и рисовалкой генеалогических деревьев, но, на мой взгляд, во всех этих случаях решаются очень похожие задачи: придумывается метамодель (для потоков данных, API, родственных отношений), выбирается подходящая нотация (диаграмма, текст, таблица), создаются редактор, инструменты для исполнения моделей, для их анализа или генерации чего‑нибудь. На мой взгляд, есть много таких областей, где можно было бы не изобретать велосипед, а взять готовый инструмент моделирования и адаптировать его под эту область. Это одна из наших целей — расширить область применения инструментов моделирования

  • Новые клиенты и рынки. Наверное, да. В основном инструменты моделирования используются крупными компаниями. Сложно представить, что школьник купит лицензию на Enterprise Architect за несколько сотен долларов и начнёт там рисовать модели, описывающие его предков. Или вряд ли руководитель проекта будет для своих обычных задач использовать инструмент моделирования вместо Excel или PowerPoint. Или при выборе квартиры, машины, работы человек вряд ли будет рисовать модели, использовать метод анализа иерархий. Но на мой взгляд все они — потенциальные пользователи нашего инструмента моделирования. Эта область выходит далеко за рамки моделирования корпоративной архитектуры или чего‑то подобного

  • Новые взаимоотношения. Здесь мне сложно что‑то сформулировать

  • Новая структура предложения товаров и услуг. И здесь сложно написать что‑то осмысленное

  • Новая ценовая стратегия. Наверное, да, у нас бесплатный продукт

• Сокращение издержек и увеличение производительности

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

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

  • Совершенствование системы каналов. Для нас сейчас наиболее актуальны каналы продаж. И если посмотреть объективно на наши предыдущие статьи на хабре, видно что они не очень заходят. Возможно есть смысл попробовать ещё какие‑то площадки, конференции, прямые контакты

  • Сокращение текущих расходов. На данном этапе у нас нет особых расходов, например, инфраструктурных или административных

• Использование активов и инвестиционная стратегия

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

  • Оптимизация использования активов. Пока особо нечего оптимизировать

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

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

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

Клиенты

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

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

• Сохранение клиентской базы. Это один показатель, влияющий на долю рынка

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

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

  • Характеристики товаров и услуг

    • Функциональность

    • Качество

    • Цена

    • Сроки

  • Имидж и репутация

  • Взаимоотношения с клиентами

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

  • Целевой сегмент и прибыльный — сохранить этих клиентов

  • Целевой сегмент и неприбыльный — устранить причины отсутствия прибыли

  • Нецелевой сегмент и прибыльный — контролировать ситуацию

  • Нецелевой сегмент и неприбыльный — отказаться от сотрудничества

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

• Крупные компании, которые моделируют ИТ архитектуру, бизнес‑процессы, риски и другие сложные вещи. На мой взгляд для таких компаний важно следующее:

  • Комплексное решение. Чтобы все модели были в одном месте и каждому подразделению не приходилось создавать что‑то своё. Типа архитекторы используют Archi, разработчики — Structurizr и PlantUML, процессники — Camunda, безопасники и админы — ещё что‑то, часть моделей хранится в Git, часть — в базе данных. Очевидно, что вместо всего этого зоопарка должно быть одно простое решение с репозиторием моделей, API, управлением доступом, версионированием, валидацией моделей

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

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

  • Соответствие стандартам. Каким бы клевым не был инструмент моделирования, скорее всего он не будет использоваться в компании вечно и понадобится переход на другой инструмент, или в компании до этого уже использовались другие продукты и понадобится переход с них, или понадобится прикрутить к инструменту моделирования что‑нибудь сбоку для генерации документов, анализа моделей и так далее, или понадобится обмениваться моделями с другими компаниями, у которых используются другие инструменты моделирования. Во всех этих случаях хорошо, если ваш инструмент моделирования поддерживает международные стандарты для обмена моделями, для хранения метамоделей. Мы опираемся на стандарты Object Management Group и ровно поэтому нам было так легко интегрироваться с Archi

• Небольшие компании, стартапы, отдельные разработчики, аналитики

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

• Предметные специалисты

  • Возможность поделиться своими знаниями. Чтобы далеко не ходить за примерами... я немного разобрался в ArchiMate, создал несколько моделей, описывающих ИТ продукт, поделился этими знаниями с вами, и возможно это упростит вам работу над вашими проектами, вам не придётся проделывать этот путь с нуля. Или другой пример, мне часто приходится формулировать требования к ПО, декомпозировать их, оценивать, и у меня в голове есть шаблон, по которому это можно легко и быстро делать, который я могу описать в виде метамодели. Или другая ситуация, есть множество вариантов решения задачи, один сложнее, другой дороже, третий вообще какой‑то непонятный и можно ходить кругами от одного варианта к другому, а можно по определенному алгоритму эти варианты быстро оценить и выбрать оптимальный. У многих специалистов в голове множество таких ментальных шаблонов, с помощью которых они разбираются в чём‑то или принимают решения. Мы стремимся сделать удобный и простой инструмент для таких людей, чтобы они могли поделиться своими шаблонами с другими

• Частные пользователи

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

• Разработчики инструментов моделирования

  • Встраиваемость и расширяемость. Есть много проектов типа n8n, Structurizr, DBML, LinkML, DocHub и так далее, где люди с нуля решают одни и те же задачи: создание репозитория моделей, создание диаграммных, табличных, текстовых редакторов моделей, валидация моделей, генерация разных вещей из моделей. Мы думаем, что все эти задачи можно решить один раз в нашем проекте, а дальше заниматься сугубо прикладными вещами: созданием нотаций для моделирования данных или архитектуры, реализацией каких‑то узкоспециализированных генераторов, созданием инструментов для обратного инжиниринга схем баз данных в модель и так далее. Нет смысла каждый раз думать как хранить модели, как сделать для них редактор. Это одна из наших целей, чтобы наш инструмент легко поддерживал такие сценарии

И ещё немного вещей, важных для всех категорий пользователей:

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

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

Таким образом, это и есть наш перечень целей с точки зрения клиентской перспективы.

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

Внутренние бизнес-процессы

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

Виды процессов:

• Инновационные процессы — изучение рынка, создание предложения новых товаров или услуг

• Операционные процессы — создание и доставка существующих товаров или услуг существующим клиентам

• Послепродажное обслуживание

Вы можете ставить цели по их улучшению.

Наши цели:

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

• Оптимизация процесса разработки. Если возможно использовать что‑то готовое или запилить микродвижок для типовых задач, то мы это делаем. Например, когда добавляли поддержку ArchiMate, то неделя ушла на саму нотацию и ещё неделя на общесистемные вещи типа импорта/экспорта моделей, которые переиспользуются для всех существующих и будущих нотаций

• Обеспечение качества кода. В противном случае мы просто утонем в разработке

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

Обучение и развитие

Можно сформулировать цели по следующим направлениям:

• Возможности работника

• Возможности информационных систем

• Мотивация, делегирование полномочий, соответствие личных целей корпоративным

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

• Написание статей по моделированию

• Создание обучающих курсов

• Развитие сообщества

И здесь я отмечу ещё одну фишку:

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

Категории пользователей и их задачи

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

В ArchiMate на разных уровнях используются разные цвета:

• Фиолетовый — уровень мотивации

• Жёлтый — бизнес‑уровень

• Синий — уровень приложения

• Зелёный — технологический уровень

• Розовый — уровень реализации и миграции

Это особенно удобно когда на одной диаграмме есть объекты с разных уровней.

У нашего приложения 4 категории пользователей, которые участвуют в соответствующих процессах:

• Методолог

  • Описание правил моделирования

• Аналитик

  • Формализация знаний в виде моделей

  • Проверка моделей на соответствие с правилам моделирования от методолога

  • Хранение моделей

  • Преобразование моделей. Например, преобразования между концептуальными, логическими и физическими моделями данных. В общем случае все эти модели создаются вручную разными людьми (бизнес‑аналитиками, системными аналитиками, разработчиками), но вообще вы можете определить правила по которым наследование сущностей или связи многие ко многим с концептуального уровня реализуются на физическом уровне и выполнять эти преобразования автоматически. Или, например, вы описываете процессы в нотации EPC, но для имитационного моделирования удобнее преобразовать эти модели в сети Петри, а для исполнения процессов придётся их преобразовать в BPMN модели

  • Формирование артефактов из моделей. Генерация документов, кода, SQL‑скриптов, XML‑схем и так далее

  • Обмен моделями

  • Анализ моделей

• Бизнес‑пользователь

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

  • Исполнение моделей. Например, исполнение бизнес‑процессов

• ИТ специалист

  • Встраивание процесса моделирования в другие процессы в организации

Третья фишка ArchiMate в том, что у него достаточно гибкая нотация. Вы можете описывать связи между объектами с помощью стрелочек на диаграмме, а можете вкладывать одни объекты в другие. С точки зрения модели это одно и то же, разница только в визуализации. К такой свободе поначалу даже сложно привыкнуть, это не BPMN, в котором акторы почти всегда изображаются дорожками. Здесь любой объект может быть дорожкой.

Бизнес-процессы

Теперь провалимся в услугу «Описание правил моделирования», она реализуется с помощью следующего бизнес‑процесса:

Здесь связь между пользователем и бизнес‑услугой уже показана стрелочкой, а не вложенностью. Это отношение обслуживания (serving).

Честно говоря, в ArchiMate не самый тривиальный вопрос какие типы связей в каком случае использовать. Я старался выбирать наиболее подходящие, глядя в примеры и спрашивая у ChatGPT, который постоянно выдумывал несуществующие виды связей. К слову, у нас реализованы правила соединения объектов как в Archi, вы сможете соединить объекты только допустимыми типами связей.

Между услугой и процессом отношение реализации (realization). Внутри процесса перечисляем его шаги. На диаграмме это не показывается, но между процессом и шагами отношение композиции (composition). Последовательность выполнения шагов задаётся с помощью отношения вызова (triggering).

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

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

Затем пользователь создаёт метамодель. Но с нашей точки зрения создание метамоделей ни чем не отличается от создания обычных моделей, поэтому у нас один технический сценарий «Создание модели». Таким образом в ArchiMate решена эта вечная проблема когда с одной стороны хочется абстрагироваться от технических деталей и описать бизнес‑процессы человеческим языком, а не в терминах CRUD (посмотреть список проектов, создать проект, открыть проект, удалить проект, ...), но с другой стороны, хочется и упорядочить сценарии, сгруппировать их по типам объектов (проект, модель, ...) по типам действий над объектами (создать, посмотреть, удалить, ...). В ArchiMate мы описываем и человеческие бизнес‑процессы (жёлтые блоки, это может быть зоной ответственности бизнес‑аналитика), и технические сценарии использования системы (синие блоки, это может быть зоной ответственности системного аналитика), плюс наглядно показываем связи между уровнями.

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

Модель предметной области

В предыдущем разделе мы начали описывать сущности из нашей предметной области, опишем здесь остальные сущности:

Модель очень простая:

• На верхнем уровне создаётся пространство моделирования. Оно может быть персональным или для организации

• Пространство моделирования содержит проекты

• На этих двух уровнях пользователям могут назначаться роли (администратор, редактор, гость)

• Проекты содержат модели

• У моделей могут быть представления разных типов: диаграмма, дерево, таблица, текст, форма свойств

• Структура моделей определяется метамоделью

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

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

• Грамматика DSL так же задаётся отдельно, если вам нужно редактировать модели в текстовом виде

Перечень сценариев использования приложения

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

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

Фактически это аналог Use Case диаграмм из UML, просто я не стал показывать акторов.

Не буду приводить все сценарии, в текущей версии их 65 штук. С этими моделями уже можно делать что‑то полезное, а не только получать эстетическое удовольствие, двигая разноцветные прямоугольники на диаграмме. Например, вы можете использовать их для оценки трудозатрат. У нас получилось 65 пользовательских сценариев. Чтобы описать каждый из них понадобится в среднем один день, значит чтобы описать все — 3 месяца.

Затем можно разбить сценарии на категории: простой, средний, сложный. Например, сценарий «Просмотр списка проектов» простой, на него понадобится 1 неделя: реализовать API, фронтенд, покрыть тестами, протестировать вручную и поправить баги. А сценарий «Редактирование модели в текстовом виде» — сложный, на него понадобится 1 месяц. Затем можно оценить сколько человеко‑лет понадобится на реализацию всего приложения.

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

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

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

• а) Легко сделать и очень важно — реализуем эти сценарии в первую очередь

• б) Легко сделать, но не особо важно — сомнительно, но окей, почему бы не сделать, если будет время

• в) Сложно сделать и очень важно — разбиваем на более простые вещи

• г) Сложно сделать и не особо важно — тут два варианта, либо ищем миллионы денег на реализацию и кому это нужно, либо не делаем никогда

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

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

Сценарии использования приложения

Теперь более детально опишем сценарий создания модели:

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

• Оценить на сколько полно и правильно реализована фича

• Написать автотесты

• Выполнить ручное тестирование

• Добавить пункт в программу и методику испытаний

• Выполнить трассировку требований

Одна картинка, а сколько профита!

Структура приложения

Опишем структуру приложения:

Приложение состоит из фронтенда и бэкенда. Они взаимодействуют друг с другом через API. Также есть API для Model Context Protocol клиентов. Управление учетными данными осуществляется внешней системой, например, Keycloak.

Диаграммы последовательности

Создадим для примера ещё какую‑нибудь техническую схему, например, схему аутентификации MCP клиентов в нашем приложении:

Получился аналог Sequence Diagram из UML. Честно говоря, нарисовать эту картинку было достаточно сложно, нужно существенно перерабатывать алгоритм расположения связей, но что‑то в итоге получилось.

Шестая фишка ArchiMate в том, что у него очень простая нотация (прямоугольники и связи), но этого достаточно, чтобы рисовать очень разные вещи, включая диаграммы последовательности. Для этого не понадобилось создавать отдельную нотацию как в UML.

Технологические сценарии

Наконец мы дошли до технологического уровня. Здесь у нас пока 3 сценария:

Опишем схему развёртывания приложения:

Схема резервного копирования:

Мы начали с моделей, описывающих нашу миссию по улучшению этого мира, а заканчиваем параметрами скрипта резервного копирования базы данных. Я максимально доволен! Что вообще нельзя описать в ArchiMate? Наверное много чего, например, макеты пользовательского интерфейса, но нам ничего не мешает добавить для этого дополнительную нотацию.

Я хотел нарисовать для статьи ещё несколько моделей, но тогда я никогда её не опубликую. Лучше попробуйте сами описать ваш программный продукт с помощью ArchiMate.

Как попробовать нарисовать свои модели или экспортировать их из Archi

Для этого вам нужно аутентифицироваться в приложении и создать проект.

Затем вы можете создать новую ArchiMate модель:

Либо импортировать модель из Archi (файл с расширением archimate):

Рабочая область выглядит следующим образом:

Слева навигатор по моделям. У него такая же структура как в Archi, потому что структура моделей у нас идентичная, оба инструмента основаны на стандартах Object Management Group и используют одну и ту же метамодель.

Справа форма свойств. Она пока минималистичная, там название и описание объекта, входящие и исходящие отношения, перечень диаграмм, на которых объект используется. У некоторых объектов свойства немного другие, например, у связей типа «Доступ» (access) можно выбрать вид доступа (чтение, запись, ...), при этом будет изменяться внешний связи на диаграмме как и в Archi. Мы пока не выносили на форму свойств пользовательские атрибуты или параметры внешнего вида (шрифт, цвета,...), со временем их тоже добавим.

По центру редактор диаграмм. Палитра для создания объектов у нас открывается по правому клику мышкой по диаграмме. Возможно это будет непривычно после Archi. Если в этом будет необходимость, то наверное в будущем добавим палитру справа. К слову у нас поддерживаются точки зрения (viewpoint), но пока они только фильтруют доступные объекты в палитре и не засеривают объекты на диаграмме.

Затем вы можете выгрузить модель и открыть её в Archi:

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

Зачем ещё один инструмент моделирования?

Зачем ИТ архитекторам нужны ещё какие‑то языки моделирования кроме ArchiMate — это открытый вопрос. Но зачем делать ещё один инструмент моделирования, если уже есть Archi, совершенно очевидно — незачем! Но тем не менее мы мотивировались следующими вещами:

• Веб‑интерфейс удобнее, не нужно ничего устанавливать, можно открывать модели хоть на телефоне. Плюс так проще сделать приятный UI. Например, для меня всегда было болью попасть мышкой на рамку фигуры толщиной в 1 пиксель, чтобы изменить её размер, а в нашем инструменте толстенная рамка с приятной анимацией, я смотрю на неё и мне хочется изменять размер фигур :)

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

• Можно редактировать одну диаграмму одновременно с другими пользователями

• Поддерживаются другие нотации, например, C4, модели данных, EPC, VAD, ваши собственные нотации

• Если сравнивать с веб‑рисовалками типа draw.io, то у нас модели хранятся в том же формате, что и в Archi. Вы можете взять модель из Archi, загрузить её к нам, отредактировать, выгрузить обратно. Или написать плагин для Archi, который делает всё это через API. На уровне объектов обеспечивается полная совместимость. С диаграммами немного сложнее, мы постарались их сделать максимально похожими, но, например, сейчас нет возможности изменять цвет фигур или рисовать произвольные диагональные связи

• Есть API для интеграции с другими системами

• Есть поддержка Model Context Protocol, чтобы ИИ мог отвечать на вопросы по вашим моделям, расскажу про это в следующей статье

• В перспективе можно реализовать что угодно, например, текстовый редактор для ArchiMate моделей

Заключение

В статье мы немного рассказали про наш инструмент моделирования.

И попытались сделать небольшое руководство по ArchiMate. В своих проектах вы можете попробовать следовать этому же шаблону, описав следующие вещи:

• Миссия, видение, цели и ценности — позволят вам, пользователям вашего продукта или инвесторам в целом понять что и зачем вы делаете

• Стратегическая карта — позволит понять чем вы отличаетесь от конкурентов и сконцентрироваться на своих сильных сторонах

• Категории пользователей и их задачи — эта модель даст уже более конкретное представление о том что пользователи будут делать с вашим приложением

• Бизнес‑процессы — позволят вам более детально разобраться что делают ваши пользователи и как вы можете автоматизировать их работу

• Модель предметной области — поможет вам найти общий язык с пользователями или заказчиками вашего программного продукта

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

• Сценарии использования приложения — помогут поставить задачу на разработку, затем оценить реализацию, покрыть её тестами, написать программу и методику испытаний, выполнить трассировку требований

• Структура приложения — поможет разобраться из каких модулей состоит ваше приложение, как они связаны между собой

• Диаграммы последовательности — помогут описать сложные сценарии взаимодействия внутри приложения или со смежными системами

• Технологические сценарии — упростят сопровождение системы

Надеюсь вы нашли для себя что‑то полезное.