Представьте город без карты. Дома построены, улицы проложены, люди живут своей жизнью — но никто не знает, как всё это связано между собой. Каждый архитектор чертит по-своему: у одного — квадраты, у другого — кружки, а у третьего — загадочные стрелки, ведущие в никуда. Когда решения принимаются «на глаз», последствия не заставят себя ждать. В результате, ценные находки теряются в ворохе несогласованных схем. Именно так выглядит ИТ-ландшафт без продуманной системы архитектурных артефактов. Сегодня я расскажу, как мы в МТС наводим в этом хаосе порядок, почему выбрали путь EAoaP — и что сделали, чтобы эта красивая теория прижилась в реальной, живой экосистеме из сотен продуктов.
Привет, Хабр! Меня зовут Наиль Миннахметов и я — корпоративный архитектор в МТС. В прошлом –– разработчик, аналитик и консультант в телекоме, финтехе, eCom, ритейле, логистике, фарме и FMCG. Занимался много чем, но всегда это было связано с IT. Я помогал разным бизнесам расти, становиться надёжнее или зарабатывать больше.
Этот материал написан по мотивам моего доклада на конференции Highload++. Поговорим про выбор модели управления артефактами, разберём, что такое архитектурные артефакты, какие они бывают, для чего нужны, как их организовывать. Затронем особенности модели EAoaP и обсудим, что это за пять непонятных букв и в чём их специфика. Научимся имплементировать модель и жить в ней.
Выбор модели управления артефактами и что мы выбрали в МТС
Перед тем, как говорить об организации артефактов, надо понять, для чего это делать.
Зачем организовывать артефакты архитектуры?
Классические вопросы, которые помогают решить, стоит ли работать с архитектурными артефактами или оставить их как есть:
Проблема синхронизации контекстов. Решения создаются без понимания причин, а выбор часто определяется бюджетными ограничениями, а не логикой.
Зоопарк форматов и инструментов — «я художник, я так вижу». Разные схемы оформлены в несопоставимых стилях — жёлтые квадратики с зелёными кружочками. Это усложняет понимание и сравнение, особенно в масштабах экосистемы МТС с 600+ продуктами. От такого обычно больно.
Проблема влияния и последствий. В связанной экосистеме изменения в одном продукте могут нарушить работу других, если заранее не оценить их воздействие. Или связь продуктов в экосистеме несёт дополнительную ценность. Разрываем связь — уничтожаем ценность. Хочется, чтобы такое происходило как можно реже.
Отношения со стейкхолдерами. Учитываются не все заинтересованные стороны, из-за чего решения могут не соответствовать ожиданиям части участников. Ваня согласен, а про Машу и Васю — забыли.
Проблема велосипедов, которые не хотелось бы придумывать снова. Важно помочь всем продуктам, разработчикам и архитекторам каждый раз не делать одно и то же.
С пользой разобрались: как организовать?
Проблемы характерны для компаний и команд любого масштаба, а в крупных встречаются особенно часто.
Страшные слова: Zachman Framework, TOGAF, FEAF.
Это фреймворки энтерпрайз-архитектуры (архитектуры предприятия) — крупные стандарты с историей около 50-ти лет, описывающие, как сосуществовать в больших структурах. В нашем случае, синхронизировать работу бизнеса и IT. Несмотря на популярность и активное продвижение консультантами, у них есть ряд проблем.
В упрощённом виде все эти фреймворки сводятся к плану перехода из текущего состояния в целевое с горизонтом в лет пять. На практике это часто заканчивается провалами, о которых потом рассказывают интереснейшие доклады на фейл-митапах. Тем не менее, фреймворки распространены, на них ссылаются и часто указывают в требованиях вакансий.
Есть фреймворки уровнем ниже, описывающие solution-архитектуру: Rozanski & Woods, C4 Model, Kruchten 4+1.
Модель C4 известна многим и ориентирована не на предприятия и бизнес, а на продукты и их системы — как они устроены и работают. Модель хорошо подходит для визуализации, получила широкое распространение, но не охватывает бизнес-аспекты, фокусируясь только на решениях.
Мы изучили все варианты и договорились не брать ни один из них, а выбрать другой подход:
EAoaP (Enterprise Architecture on a Page)
EAoaP — молодой фреймворк, созданный как критика классических подходов вроде TOGAF. Он отмечает, что часть этих стандартов устарела, сами они чрезмерно сложны, содержат огромное количество (около 2-х млн) артефактов и разнородных методов, что делает их применение на практике затруднительным.
Святослав Котусев, независимый исследователь и автор EAoaP, предложил, на основе анализа крупных энтерпрайз-компаний, описывать архитектуру предприятия через 6 основных блоков и 24 артефакта.
24 или 2 млн артефактов? Как говорится, почувствуйте разницу.
Использовать все артефакты необязательно — достаточно выбрать нужные. По словам Святослава, всю энтерпрайз-архитектуру, которую часто продают за большие деньги, можно уместить на одной странице.
Одно из ключевых отличий фреймворка — отсутствие жёсткого разделения слоёв артефактов: они рассматриваются как микс бизнес- и IT-аспектов.
Если посмотреть на схему выше, то верхние три блока больше про бизнес, нижние три — скорее про IT. Но при этом они связаны. Об этом дальше и поговорим.
Что не так с EAoaP? Особенности модели, с которой мы работаем
Серебряных пуль не бывает: несмотря на привлекательный вид, у подхода есть недостатки:
Не имеет реальных внедрений. Я лично знаком со Святославом. Когда он выступал на МТС True Tech Hack и рассказывал про свою модель, ему задали вопрос, как модель показала себя на практике. Святослав ответил, что он исследователь, модель нарисовал, а вот реальных внедрений не видел. Её реально никто нигде не применял, это, скорее, академическая работа.
Не учитывает организационную структуру компании. Модель описывает артефакты «в вакууме» –– в отрыве от контекста, и не отражает наличие кластеров, трайбов, продуктов, отделов или других единиц.
Плоская модель. В ней отсутствует глубина и иерархия — артефакты представлены как отдельные элементы без уровней. В реальности же в энтерпрайзе они почти всегда многоуровневые, например: продукт, кластер, экосистема. Это стало для нас одним из ключевых препятствий.
Явно не даёт понимания разницы To Be и As Is: фреймворк фиксирует состояние в текущей точке, но не показывает, где мы находимся на пути к цели и куда движемся. Для сравнения и отслеживания прогресса требуется отдельно создавать модели As Is и To Be, что на практике сложно и малореализуемо.
EAoaP и реальность
В реальности иерархичность артефактов, структур, продуктов и самой организации делает модель неприменимой в исходном виде. В ней выделены четыре блока:
Visions — видение;
Outlines — по сути, бизнес-идеи;
Landscapes – ландшафт;
Designs —решения, к которым мы привыкли.
В средних и крупных энтерпрайзах каждый из этих блоков почти всегда имеет иерархическую структуру. А значит плоское представление модели для них не подходит. Аналогичные ограничения в определённой степени есть и у двух других блоков стандартов, но там проблема менее критична.
Что мы с этим сделали
Мы могли бы использовать TOGAF, который понятен и привычен, но отказались от этого варианта — он тоже нам не подходит. Вместо этого решили адаптировать модель EAoaP и проверить, что из этого получится. Поскольку она не учитывает иерархические артефакты, эту проблему нужно было решать. Прямое ручное поддержание иерархии, её связывание и сборка оказались бы слишком затратными и нецелесообразными.
Мы заполнили пробелы так:
Создали единые Inventory-системы — хранилища артефактов с автоматизацией процессов, упрощающей их ведение и использование.
Сделали артефакты машиночитаемыми. Чтобы системы работали синхронно, обменивались данными и связывались между собой, мы решили по возможности делать все архитектурные артефакты в машиночитаемом формате.
Начали отслеживать связи и формировать представления на единых витринах компании. Между артефактами разных блоков модели существуют связи. Например, бизнес-capability и архитектура, описывающая реализацию сервиса конкретного продукта, — это разные артефакты из разных Inventory, но их часто нужно связать. Мы решили реализовывать такие связи и представления на собственных витринах, где они будут объединяться.
As Is –– это данные, собранные с ландшафта. Отказались от создания и сравнения статичных схем — нарисовал, наложил одно на другое, посмотрел на свет. Это не работает. Мы отказались от классического подхода As Is и начали определять текущее состояние, собирая данные напрямую с ландшафта в реальном времени. Для этого использовали платформы, с которыми работают многие наши системы и продукты.
Детали по артефактам: что используем, от чего отказались и что переосмыслили
Стандарты
Библиотека шаблонов. Классические шаблоны проектирования — это проверенные решения для повторяющихся задач, когда известен как сам тип задачи, так и эффективный способ её реализации. Фреймворк предполагает наличие таких шаблонов, и в нашей практике они действительно используются. Мы создали библиотеку, в которой собраны готовые архитектурные варианты для разных кейсов. Это не сложная или уникальная разработка, а стандартный, понятный инструмент: достаточно открыть библиотеку, найти задачу по типу и выбрать из одного, двух или трёх предложенных архитектурных решений наиболее подходящее.
LDM –– отказались от стандартизации. Логические модели данных описывают структуру данных в базе без указания физического хранения, но с детализацией по параметрам, ключам, типам и другим характеристикам. В крупных организациях такие модели часто отстают от реальности: их забывают обновить или внести изменения, что в масштабах энтерпрайза или экосистемы превращается в серьёзную проблему. Мы приняли решение не организовывать и не стандартизировать логические модели данных. При этом для части продуктов — в основном дата-ориентированных — их использование остаётся необходимым, и мы это не запрещаем. Однако устанавливать единые требования и пытаться связывать эти модели между собой считаем излишним.
Playbooks/handbooks. Вместо классических общих гайдлайнов мы используем формат playbooks и handbooks — подробных руководств, описывающих архитектурные процессы и порядок действий в компании. Например, в handbook можно найти чёткий алгоритм для любой роли архитектора, независимо от уровня. Если нужно вывести дополнительный сервис, руководство подскажет, что необходимо сделать: внести данные в Inventory, настроить мониторинг и выполнить другие шаги. Такие материалы служат практичными и понятными инструкциями для выполнения задач.
Inventory технологий + жизненные циклы. Мы разработали собственную систему для хранения информации о технологиях, используемых в экосистеме, и отслеживания их жизненных циклов. Это централизованное хранилище, где фиксируются все используемые технологии, включая версии библиотек, поскольку проблемы нередко возникают именно из-за конкретной версии. Система автоматически отслеживает, какие технологии и версии допустимы, а какие — нет, с указанием причин. Процесс полностью автоматизирован, что упрощает контроль и поддержку актуальности данных.
Принципы –– иерархическая структура. В управлении архитектурой мы используем федеративный подход, при котором решения принимаются на местах, а не централизованно. Принципы играют ключевую роль и помогают командам самостоятельно выбирать оптимальные решения без ожидания указаний от корпоративного архитектора.
В нашей модели принципы устроены иерархически: на верхнем уровне — экосистемные бизнес-принципы; ниже — каскад из технологических принципов, вытекающих из бизнесовых.
Например, API-First — это краткий стейтмент, один из примерно десяти базовых, который в дальнейшем развернут в архитектурные принципы. Последние служат руководством для команд при принятии решений по конкретным задачам.
Considerations или договорённости на уровне стратегии
У Святослава этот элемент называется considerations, но по сути это договорённости или стратегический уровень, преимущественно бизнес-стратегия.
Принципы –– иерархическая структура + каскад технологических.
Inventory трендов + жизненный цикл. Тренды мы ведём в автоматизированной системе, которая поддерживает процесс trendwatching — отслеживание и анализ тенденций. Для каждого тренда фиксируется его жизненный цикл. Подобные решения широко применяются на рынке, но мы используем собственную систему. Это стандартный подход, адаптированный под наши задачи.
Inventory КМД (Концептуальная Модель Данных). Для работы с такими моделями мы выбрали иной подход, чем в случае с логическими. Их детализация ниже, поэтому поддержка требует меньше времени и ресурсов, но при этом их инвентаризация крайне важна. КМД позволяет понимать, какие дата-объекты существуют, кто с ними работает, кто является их владельцем и что с ними может происходить. Эта информация критична для экосистемы, особенно когда продукты взаимодействуют и кооперируются. Мы реализовали инвентаризацию КМД в виде системы с иерархическим хранением данных.
Стратегия — иерархия артефактов (Business-Tech-Arch). В нашей модели стратегия также имеет иерархическую структуру:
Бизнес-стратегия определяет, где мы хотим оказаться через определённый срок, например, через год.
Технологическая стратегия отвечает на вопрос, какие технологии потребуются для достижения этих целей.
Архитектурная стратегия формирует видение того, какие архитектурные решения могут поддержать выбранные технологии и цели.
Архитектурная стратегия не является жёстким предписанием, а скорее служит ориентиром и направлением, в которое стоит смотреть при планировании и разработке.
Policy (правила). В нашей практике таких правил нет, так как они относятся к централизованной модели управления. По словам Святослава, в западных компаниях такой подход распространён: управление строится на большом количестве формализованных правил, и чтобы отразить такую особенность, он включил этот элемент в модель. Мы же от него отказались, так как централизованное управление нам не подходит, хотя в других организациях такой подход может быть уместен.
Visions
Visions — набор артефактов, который описывает, что из себя представляет энтерпрайз, с которым мы работаем.
Inventory процессов. Описывает, как выглядят процессы. Обычно это репозитории, где фиксируются небольшие процессы, которые затем объединяются в крупные, включая сквозные (E2E), критичные и некритичные. Такая практика многим знакома и нередко вызывает сложности, однако мы научились с ней работать, хотя постепенно стараемся от неё отходить.
Inventory архитектур (ArchOps). Этот компонент описывает, как выглядят архитектуры. Мы объединили их в единую систему (inventory) — ArchOps, которая хранит, визуализирует и позволяет сравнивать архитектурные решения, а также отслеживать их жизненные циклы.
Система основана на подходе Architecture as a Code и работает с метаинформацией, из которой формируются визуальные представления. При этом сами изображения для нас не являются конечной целью, так как с ними нельзя напрямую работать — иначе пришлось бы решать проблемы, созданные самим процессом визуализации.
О системе ArchOps мы подробно рассказывали на True Tech Hack. Она активно используется и востребована, так как упрощает управление архитектурой в рамках нашей экосистемы.
Inventory Business Capability и потоки ценностей — это упрощённое представление того, в чём заключается уникальное предложение продукта, его ценность для клиента, а также причина, по которой клиент готов за него платить или пользоваться им бесплатно. Value Chains мы также храним в системе ArchOps.
Помимо этого, у нас есть отдельное Inventory Business Capability. С его помощью мы описываем экосистему, определяем, какие возможности у нас уже есть, каких нет и какие мы хотели бы развить. Это история про inventory упакованных capability.
Inventory PBC (Packaged Business Capabilities) — это технический уровень, представляющий собой своего рода маркетплейс сервисов. Здесь можно выбрать нужный сервис и получить готовый Kubernetes-контейнер, который можно задеплоить и связать с другими компонентами, используя его интерфейсы.
Этот слой напрямую связан с Inventory Business Capability, которое описывает возможности с бизнесовой стороны, обеспечивая связку между бизнес- и техническим представлением сервисов.
Роадмапы используются ситуативно. Мы отказались от роадмапов как стандарта, поскольку в нашем масштабе их применение оказалось неэффективным. В экосистеме с 600 продуктами и примерно 30 взаимосвязанными платформами крайне сложно синхронизировать планы. Попытки реализовать это через крупные диаграммы Ганта с множеством столбцов и связей показали неудовлетворительный результат. Такой подход не соответствует ни нашему масштабу, ни продуктовому формату работы.
В отдельных случаях роадмапы могут быть полезны, но как обязательный стандарт мы их не используем. Вместо этого мы перешли на подход синхронизации по целям. На определённый период, например квартал, мы формулируем ключевые цели для конкретного набора продуктов или платформ. При этом не определяется, каким образом эти цели будут достигнуты — команды самостоятельно выбирают путь реализации.
Такой формат полностью заменил необходимость в традиционных роадмапах и устранил связанные с ними проблемы синхронизации, которые ранее были одной из серьёзных сложностей.
Outlines
Бизнес-описания — при необходимости. В контексте модели Outline представляет собой бизнес-предложение, в котором на бизнесовом языке описываются желаемые сценарии, принципы работы и ожидаемые результаты. Такой формат актуален для проектного подхода, но в продуктовой разработке практической ценности почти не имеет.
По словам Святослава, в ряде компаний, где он изучал практики, модель до сих пор остаётся проектной, несмотря на распространение продуктового подхода.
В нашей работе этот формат используется только при необходимости. Если кому-то удобно представить информацию в таком виде, включая использование презентаций, — это допускается. Однако как обязательный стандарт мы бизнес-описания не внедряем.
Inventory СJs. Вместо описаний инициатив в формате кейсов мы решили всегда рассматривать этот аспект с точки зрения клиента. Для этого используется Inventory Customer Journey — инструмент, фиксирующий пути клиента: как он взаимодействует с приложением, экосистемой или выполняет определённые действия в наших продуктах.
Мы отслеживаем такие пути на разных уровнях детализации, но не используем формат, в котором они оформляются как описания инициатив с кейсами, так как этот подход нам не подходит.
Сравнение вариантов — ADR. Для фиксации выбора и принятых решений мы используем ADR (Architecture Decision Records). Этот формат применяется не только в данном блоке, но и при разработке дизайнов. ADR — это компактные артефакты, в которых указываются: текущий контекст; задача, которую требуется решить; рассмотренные варианты; причины выбора конкретного варианта из нескольких.
Таким образом, каждое решение документируется с чётким обоснованием: «Мы выбрали этот вариант, потому что…».
Designs
ADR — наше всё! Мы применяем ADR (Architecture Decision Records) в двух случаях: при принятии решений на более высоком, в том числе бизнесовом, уровне; при описании дизайнов конкретных решений и solution-дизайнов продуктов. Все ADR хранятся в inventory и интегрированы с системой ArchOps.
Inventory архитектур (ArchOps). Для описания архитектурных решений мы также используем ArchOps. В ней хранятся все архитектуры, которые мы разрабатываем. Система позволяет собирать их, устанавливать связи между ними и связывать с другими артефактами, обеспечивая целостное представление архитектурных данных. ArchOps применяется во многих процессах и является центральным инструментом нашей архитектурной практики.
Landscapes
IT Роадмапы — ситуативно. Вы поняли — не надо никаких роадмапов.
Inventory архитектур (ArchOps). Ландшафт строится путём агрегирования данных с нижних уровней. При визуализации мы часто применяем модель C4, в частности её контекстный уровень. Он описывает, какие продукты есть в системе, какие продукты связаны с ними, где находятся потребители, а где — источники данных, что откуда берётся и куда передаётся. Такой подход к связке продуктов позволяет получить целостное представление о состоянии ландшафта.
Inventory продуктов. Это system portfolio — реестр продуктов, аналогичный тем, что есть в большинстве крупных компаний. В нём можно найти продукт по коду, названию или другим параметрам и получить информацию о его назначении и имеющихся capabilities. В нашем случае этот inventory связан с Inventory Business Capability, что позволяет в одном месте видеть и продукт, и его функциональные возможности.
Результаты
20% артефактов фреймворка убрали;
20% артефактов изменили, причём основательно;
Оставшиеся 60% классно подходят, но только большинство из них иерархичны, почти для каждого нужны inventory, и это всё пришлось автоматизировать.
Неплохой результат, можно было сделать и хуже.
Как с этим жить, чтобы было хотя бы чуточку проще
После разработки и внедрения подхода возник вопрос — как эффективно работать с ним в условиях постоянных изменений. Мы действуем в реальном времени: кто-то реализует новые задачи, меняются бизнес-приоритеты, меняется ситуация в целом. Фреймворк учитывает этот фактор и предлагает модель, отражающую динамику и взаимное влияние артефактов, что помогает поддерживать актуальность данных и целостность архитектурной картины.
Мы изучили эту схему и разобрались в её логике. При внимательном рассмотрении видно, что взаимное влияние артефактов приводит к необходимости постоянной актуализации: любое изменение в одном элементе влечёт корректировки в других. Этот момент я обсуждал со Святославом — он работает над тем, чтобы решить эту проблему, и есть надежда, что ему удастся найти подходящее решение.
Наш подход
Мы пошли другим путем:
Все артефакты одного типа связываются автоматически в Inventory-системах. Автоматизация сборки иерархии осуществляется системами, без ручного вмешательства. Мы передаём в Inventory только данные с нижнего уровня — например, от отдельных продуктов. Далее система автоматически агрегирует их в более крупные сущности, такие как бизнес-домены, и затем объединяет всё в масштабах всей экосистемы.
Артефакты из разных блоков связываются через единые представления на основе метаинформации. Второй элемент — это представления, которые в текущем виде реализованы в формате графов. В будущем планируется использование и других форматов, но сейчас основной инструмент — графовые структуры.
Все представления объединяются в единой точке — EDT (Enterprise Digital Twin), которая отслеживает и связывает артефакты по их идентификаторам, обеспечивая целостное отображение архитектурной картины.
В EDT можно:
выбрать нужные артефакты и установить между ними связи;
убрать ненужные элементы, например capability, и посмотреть, какие системы с ними связаны;
отследить, какие сервисы реализуют эти capability;
выяснить, какие решения были с ними связаны.
Цели и Capabilities — основная точка синхронизации Бизнес-IT. Синхронизация работы бизнеса и IT — ключевой элемент продуктового подхода, который мы активно внедряем. Capabilities выполняют роль промежуточного звена между бизнесом и IT, помогая обеим сторонам говорить на схожем языке.
У бизнеса и IT формируются общие цели, что исключает ситуацию, когда IT может реализовывать что-то, не соответствующее потребностям бизнеса. При этом мы исходим из того, что бизнес чётко понимает, что ему нужно, а IT обязано реализовывать именно эти задачи.
Федеративный подход к управлению функцией архитектуры. При сложной структуре и большом количестве артефактов попытка централизованно навязывать решения и контролировать их выполнение обречена на неэффективность. Такой подход обычно приводит к громоздким отделам корпоративной архитектуры, где сотни сотрудников занимаются согласованием, а процессы затягиваются на недели.
Мы отказались от этого сценария и выбрали федеративную модель. Вместо жёсткого контроля мы предоставляем командам правила, рекомендации, примеры и кейсы. Они могут использовать их для упрощения своей работы, но при желании — действовать по-другому. Главное условие — достижение поставленных целей, независимо от выбранного пути.
Заключение: что мы получили в итоге
По итогу получили примерно такую картину:
Это визуализация описанной модели. В центре находится красный треугольник — EDT (Enterprise Digital Twin), объединяющий данные из всех Inventory-систем, ландшафта и технологических платформ. Эти данные формируют представления в виде графов, с которыми можно работать, а также в виде списков, которые мы внедрили недавно. Эти представления являются витринами для анализа.
Внизу находится блок в виде кружочка для прогнозирования, моделирования и поиска аномалий. На данный момент реализован только поиск аномалий; прогнозирование и моделирование планируется внедрить в будущем. Мы рассматриваем возможность использования LLM для автоматического моделирования сценариев и оценки изменений в ландшафте.
В результате все пользователи — сотрудники, системы и другие потребители данных — получают единую точку доступа, где все Inventory и артефакты (в нашем случае 19 из 24) объединены в целостную систему, из которой можно извлекать полезную информацию.
Итоги
EAoaP хорош в качестве основы организации архитектурной практики в продуктовых компаниях. Enterprise Architecture on a Page в целом работает неплохо. Мне кажется, он лучше TOGAF, но это моё личное мнение. В целом, подходит.
Выявленные минусы нивелируются машиночитаемым подходом к описанию артефактов. Возможно, есть другие решения, но нам это показалось самым разумным.
С едиными репозиториями артефактов уменьшаются трудозатраты на поддержание целостной картины. В этой истории ключевое — единые репозитории. Они помогают не погибнуть под всем этим в разрезе большого Энтерпрайза, каким мы являемся.
Если вам интересна тема архитектурных артефактов и вы хотите узнать больше о практических подходах к управлению сложными ИТ-экосистемами, приходите на конференцию Highload 2025 в Москве. Будут сильные эксперты из мира разработки, архитектуры и инфраструктуры, живые кейсы, общение и опыт из первых рук. Подпора в развитии ваших проектов и архитектурных практик.