Хочу рассказать, почему растущие бизнес-требования к Time-to-Market, персонализации, 0 FTE in RUN заставили нас пойти на радикальный шаг — разработку собственной платформы управления архитектурой EA Tool. Это не история про замену одного софта на другой, а рассказ о том, как мы создаём «цифровую нервную систему» банка и как переход от изолированного рисования диаграмм (набивших оскомину «квадратиков со стрелками») к управлению цифровым двойником снова меняет нашу профессию.
Привет, Хабр! Я Дмитрий Клецких — главный архитектор и лидер архитектурного сообщества в банке, и Сергей Назаров — лидер продукта EA Tool. Наша основная цель — сделать так, чтобы архитектура перестала быть «башней из слоновой кости» и помогала бизнесу реализовывать цели стратегии, а командам — быстро, безопасно, предсказуемо и самостоятельно развивать сложный ИТ-ландшафт.
Некоторое время назад я рассказывал про наше видение трансформации архитектурной функции в банке в связи с AI-изменениями, а сейчас хочется сказать несколько слов про инструменты управления корпоративной архитектурой.
Десятилетиями для нас, как и для многих на рынке, стандартом де-факто оставались такие вендорские решения, как Alfabet, iServer, Sparx EA и др. Это мощные, «классические» инструменты метамоделирования ИТ-ландшафта с широкой встроенной функциональностью, включающей аналитику текущего и целевого состояния ИТ-ландшафта, в которых годами работали сотни наших спецов. Но сейчас стало очевидно, что созданные десятки лет назад, такие инструменты имеют встроенные ограничения и начинают откровенно тормозить ИИ-революцию.
Предпосылки: почему мы отказались от старого подхода
Sparx EA был хорош, но работал скорее как персональная рабочая станция, а не как единая среда для коллаборации архитекторов и команд. Сложные модели репозитория, вечная и ни разу не решённая полностью проблема с актуальностью данных, ручное поддержание связей между архитектурными артефактами, которые создаются на данных из репозитория — всё это сильно замедляет и делает непрозрачными процессы управления корпоративной архитектурой. К примеру, повсеместной стала ситуация, когда обычный draw.io становился единственным союзником в отрисовке «простой» архитектурной схемы для обсуждения изменений с командами и руководителями разного уровня.
Нам требовалась новая философия: единый источник истины, автоматизация рутины и смещение фокуса с проектирования картинок на управление жизненным циклом ИТ-активов. Сложность в том, что на российском рынке нет поставщиков ПО, которые бы предоставляли «архитектурные репозитории будущего», ориентированные на наши представления о работе корпоративного архитектора в новом ИИ-мире: сейчас российский рынок сконцентрирован на рутинной замене устаревших инструментов типа Sparx, Alfabet или ARIS.
Что мы хотим сделать «простыми словами»?
Модель, в которой ИИ будет готовить черновики архитектурных решений на основе данных репозитория, а архитектор — «оцифровывать» наши знания, правильно писать промпты и валидировать полученные от ИИ ответы. В первую очередь мы ориентируемся на архитектурные решения уровня Стратегии.
Но обо всём по порядку…
EA Tool изначально задумывался как платформа вокруг единого репозитория архитектурных объектов. Силами одной укомплектованной agile-команды мы строим его как автозаполняемый digital twin нашего ИТ-ландшафта, где каждый объект — это «живая» сущность со своей историей и связями. Более того, ключевыми пользователями нашего EA Tool являются даже не архитекторы, а автономные agile-команды.
От Green Path к Spec-Driven Development
Понятно, что переход на использование «формализованного» EA Tool повышает качество проработки архитектурных решений, но истинная ценность цифровизации архитектурных знаний раскрывается при интеграции EA Tool с производственным процессом.
Согласованная в EA Tool модель — бизнес-способности , бизнес-функции, потоки данных, API, компоненты — больше не пылится в цифровых репозиториях. Она становится триггером для запуска CI/CD пайплайнов. Это открывает дорогу к концепции «Green Path» — стандартизированному пути доставки ценности. Передавая спецификации напрямую в разработку по процессу SDLC, мы закладываем фундамент для методологии Spec-Driven Development (SDD).
А интеграция с профильными инструментами вроде SpecKit позволит в перспективе продуктовым командам на лету генерировать заглушки, схемы баз данных и базовый код прямо из архитектурных моделей. Архитектурные артефакты превращаются в исполняемый артефакт.
Но ещё важнее — интеграция EA Tool с инструментами производственного процесса. Проще говоря, речь о связке с сервисами поверх GitHub, которые используют данные из YAML-спецификаций, разрабатываемых командами сервисов. Получается картина, когда архитектор проектирует change сверху вниз, от стратегии до уровня solution, а реальные данные о сервисах продуктов подтягиваются из Git для валидации фактического ИТ-ландшафта относительно архитектурного решения, которое было принято на берегу.
Как изменился процесс работы и Architectural Governance
Раньше процесс выглядел так: архитектор по запросу (команды или проектного офиса, не важно) рисует диаграмму, а затем вручную вбивает информацию о новых системах и связях в репозиторий. В то же время в более развитых системах управления архитектурой диаграммы на лету генерировались на основе данных из репозиториев. Это приводило к расхождениям, репозиторий отставал от реальности, а анализ влияния очередного изменения требовал героических усилий. Скажу больше, если инструмент не был встроен в производственный процесс, то данные в репозитории никогда не были актуальными.
Понятно, что на старте использования EA Tool, скорость подготовки архитектурных решений просела. От команды и архитекторов потребовалась дисциплина: строго придерживаться нотаций, заполнять все обязательные метаданные и пр. Мы в полной мере прочувствовали закон «мусор на входе — мусор на выходе». Допустил халтуру на диаграмме — автоматизация бережно зафиксирует её в репозитории.
Ответственность за качество сместилась на самую раннюю стадию — этап проектирования. Зато когда комьюнити приняло эти правила игры, скорость превысила прежние показатели: рутина на финальных этапах исчезла полностью. Теперь логика другая: после согласования архитектурного решения регистрация ИС (потоков данных и пр.) в репозитории происходит автоматически. Информационные системы сразу привязываются к бизнес-способностям. Вся эта структура в EA Tool напрямую мапится на нашу референсную модель, построенную на базе собственного архитектурного фреймворка. Благодаря этому, мы говорим с бизнесом на одном языке и чётко видим, какие конкретно ИТ-активы поддерживают ту или иную ценность для клиента. Архитектура перестаёт быть сухой схемой и становится оцифрованным бизнес-активом. Мы просто повторяем то, что в теории должно было быть сделано 5-7 лет назад. Очевидно, что прорыва в новый ИИ-мир здесь случиться не может.
Вектор развития: от AI-ассистента к Agentic RAG
Следующий шаг — внедрение технологий ИИ, о котором я говорил в начале статьи. Не для того, чтобы заменить архитекторов, а чтобы адекватно соответствовать вызовам нового мира. Цитируя Уильяма Гибсона, автора книги «Машина различий»: «Будущее уже здесь. Просто оно неравномерно распределено».
На первом этапе мы фокусируемся на контекстном поиске (NLP + векторный поиск) и RAG-системах. Любой участник команды сможет прийти в репозиторий и узнать, к примеру, какие системы отвечают за процессинг карт и используют устаревшую СУБД. Это критически снизит порог входа в архитектурны знания банка.
Но по мере зрелости платформы роль ИИ-ассистента выйдет за рамки умного поиска. Следующий логичный этап — внедрение паттернов Agentic RAG. В этой парадигме автономные ИИ-агенты смогут не просто доставать знания из базы, но и проактивно взаимодействовать с ИТ-ландшафтом: самостоятельно валидировать проектные решения на соответствие политикам безопасности, находить дублирующиеся бизнес-функции и предлагать оптимальные интеграционные маршруты, опираясь на исторический опыт банка.
Что в итоге
EA Tool — это пример смены философии всей архитектурной функции. От изолированного моделирования мы перешли к управлению жизненным циклом ИТ-активов в едином цифровом пространстве.
А как вы оцениваете подобные изменения в индустрии? Готовы ли вы делегировать рутину инструментам, оставив себе пространство для аналитики и стратегии? И самое интересное: как, на ваш взгляд, изменится профиль Enterprise-архитектора через 3-5 лет, когда ИИ возьмёт на себя проектирование изменений в ИТ-ландшафте, превратив архитекторов разного уровня из проектировщиков систем в проектировщиков интеллектуальных архитектурных агентов?
Жду вас в комментариях.
Комментарии (6)
itGuevara
06.04.2026 10:01Есть ли DSL-язык для описания архитектуры (текстовый и для человека) и онтология, метаМодель, но более проработанная, чем в TOGAF \ ArchiMate? При наличии такого DSL и с ИИ было бы удобнее разговаривать.
Как ваш EA Tool связан с 072 формой, которую сдаете в ЦБ? В ней же основная архитектура «до винтика» прописана, включая привязку к бизнес-процессам, звенья ИС, источник \ получатель данных между ИС и т.п.
сейчас российский рынок сконцентрирован на рутинной замене устаревших инструментов типа Sparx, Alfabet или ARIS.
Чем же они устаревшие? Желательно списочек устаревшего.
В сторону семантики смотрели (не совсем ЕА, но принцип такой-же, а нотацию \ онтологию можно любую добавить)?
Информационные системы сразу привязываются к бизнес-способностям. Вся эта структура в EA
Не понял к чему была ссылка https://www.opengroup.org/togaf/series-guides
Вообще ссылки на opengroup.org лучше не давать - к многим материалам не пускают без регистрации (и регистрация там тоже не простая). Лучше ссылки на копию \ зеркало с материалами.
Вся эта структура в EA Tool напрямую мапится на нашу референсную модель, построенную на базе собственного архитектурного фреймворка. Благодаря этому, мы говорим с бизнесом на одном языке и чётко видим, какие конкретно ИТ-активы поддерживают ту или иную ценность для клиента. Архитектура перестаёт быть сухой схемой и становится оцифрованным бизнес-активом.
Не верится. Есть, что показать? Прикажите ИИ хотя бы сформировать и выгрузить онтологию вашего EA Tool в OWL и положите на github (она не будет содержать ваших данных по системам, только МетаМодель).
Теги: github
Где ссылка на github вашего "волшебного" EA Tool? Вообще, к какому прототипу наиболее близок ваш EA Tool?
Неужели без ИИ \ RAG не собрать хороший EA Tool? Кстати тут обзор EA.
ent_architect Автор
06.04.2026 10:01itGuevara4 часа назад, спасибо, что потратили время и прочитали :) спасибо за вопросы !
Ответы ниже:
Есть ли DSL-язык для описания архитектуры (текстовый и для человека) и онтология, метаМодель, но более проработанная, чем в TOGAF \ ArchiMate? При наличии такого DSL и с ИИ было бы удобнее разговаривать.
В качестве DSL сейчас используем YAML-описание связей ИТ-компонентов (и их API) с шагами бизнес-процессов, но это отдельный проект, ориентированный больше на бизнес-мониторинг и создание контекста для ИИ. В самом же EA Tool присутствует ИИ-ассистент, использующий RAG, на основе данных микросервисов, образующий репозиторий (данные , конечно, кладет в векторную базу и далее по референсной схеме).
Метамодель (онтология) конечно же есть, в ней сейчас более 30 сущностей, охватывающих в основном бизнес-архитектуру, архитектуру данных и прикладную ИТ-архитектуру.
Как ваш EA Tool связан с 072 формой, которую сдаете в ЦБ? В ней же основная архитектура «до винтика» прописана, включая привязку к бизнес-процессам, звенья ИС, источник \ получатель данных между ИС и т.п.
Мы воспринимаем форму 072 просто как еще один viewpoint/отчет на основе репозитория (я бы не сказал, что в ней вся архитектура "до винтика"). Данные для этого нашей метамоделью предусмотрены. Ну и скажу, что архитектура - все это пирог слоистый и описать, как выглядит сбор любой формы, например, 072, можно по разному: можно для уровня Правления, можно для мидл-уровня, можно "до винтиков" для команд - для этого нужны разные объекты репозитория.
сейчас российский рынок сконцентрирован на рутинной замене устаревших инструментов типа Sparx, Alfabet или ARIS.
Чем же они устаревшие? Желательно списочек устаревшего.
Если коротко, они устарели прежде всего морально, т.к. изначально строились под EAM фреймворки типа TOGAF, которые по мне так не отвечают современным требованиям (отдельная занятная дискуссия для исследователей TOGAF: а был ли когда-то вообще смысл в этих фреймворках для организаций, если убрать плюсы сертификации для личного брендинга ?). А теперь к ним спешно прикручивают сбоку ИИ (опять таки в рекламных целях, без особенного понимания, как будет выглядеть сама профессия архитектора в связи с появлнием ИИ). Вообще перечислять здесь слишком долго (монолит опять таки со всеми вытекающими; морока в событийку с инструментами производственного процесса или инструментами динамической инфраструктуры; не ясно, как встраивать в корпоративные стандарты разработки пользовательских сервисов, сохраняя единый клиентский путь; как Architecture as a Code прикручивать к условному alfabet мне тоже не очевидно; если мы везде про API-first культуру, то как работать с "вшитыми" API из "коробок" тоже вопросы и пр.). Думаю, что стоит посвятить этой теме отдельную статью.
В сторону семантики смотрели (не совсем ЕА, но принцип такой-же, а нотацию \ онтологию можно любую добавить)?
Смотрим и очень активно, т.к. понимаем, что для AI-driven предприятия нужно стоить не просто цифровой двойник, а именно семантический !
Информационные системы сразу привязываются к бизнес-способностям. Вся эта структура в EA
Не понял к чему была ссылка https://www.opengroup.org/togaf/series-guides
Вообще ссылки на opengroup.org лучше не давать - к многим материалам не пускают без регистрации (и регистрация там тоже не простая). Лучше ссылки на копию \ зеркало с материалами.
Понимаю. Вообще на тему бизнес-способностей правильнее было дать ссылку на BizBOK, но он платный, поэтому ограничились TOGAF. Ссылка дана в общеобразовательном смысле. На наш взгляд техника Capability based planning для многих крупных корпораций остается чем-то "инновационным" и не заслуженно забытым :(
Вся эта структура в EA Tool напрямую мапится на нашу референсную модель, построенную на базе собственного архитектурного фреймворка. Благодаря этому, мы говорим с бизнесом на одном языке и чётко видим, какие конкретно ИТ-активы поддерживают ту или иную ценность для клиента. Архитектура перестаёт быть сухой схемой и становится оцифрованным бизнес-активом.
Не верится. Есть, что показать? Прикажите ИИ хотя бы сформировать и выгрузить онтологию вашего EA Tool в OWL и положите на github (она не будет содержать ваших данных по системам, только МетаМодель).
У нас есть Value Stream Maps для ключевых потоков ценности (VS), на которых отображается связь стадий VS с бизнес-способностями и далее бизнес-функциями, ИТ-системами и бизнес-данными. По сути это ключевая модель для общения с теми, кто за доходную часть бюджета отвечает :) Представление метамодели в виде OWL у нас есть, возможно опубликуем когда-нибудь после обсуждения с нашей ИБ и compliance.
Где ссылка на github вашего "волшебного" EA Tool? Вообще, к какому прототипу наиболее близок ваш EA Tool?
Наружу пока не выкладывали и честно говоря не планировали. Насчет прототипа сложно определенно сказать, поскольку EA Tool «затачивается» под наши процессы, но в целом наверное можно сказать, что это model-first EAM инструмент.
Неужели без ИИ \ RAG не собрать хороший EA Tool? Кстати тут обзор EA.
Спасибо за ссылку. У нас есть собственный опыт изучения и эксплуатации (в организациях, в которых работали ранее) некоторых из EAM-платформ, таких как Alfabet, Sparx, Bizzdesign, iServer, ADOIT. Я уверен, что дело не в тулах, а в целевом architecture governance. Он уже меняется , тулы просто будут следом меняться.
Спасибо !
itGuevara
06.04.2026 10:01Наружу пока не выкладывали и честно говоря не планировали. Насчет прототипа сложно определенно сказать, поскольку EA Tool «затачивается» под наши процессы, но в целом наверное можно сказать, что это model-first EAM инструмент.
Какие примеры model-first EAM инструментов? И в чем у них сходства \ различия с EA Tool?
Вообще подобные статьи вызывают двоякое мнение. В них прослеживается "Какую крутую штуку мы сделали, но не покажем и даже подробно не расскажем".
Сделали "хорошую" онтологию, так положите на github (чего онтологию то жалеть?), тогда было бы понятно насколько она действительно хороша. Или МетаМодель сделали бы круче TOGAF \ ArchiMate - они плохие, но лучше пока нет. Если начнете на github собирать проект, то наверняка и помощники подойдут.Когда каждый "собственный велосипед" городит за "высокой корпоративной стеной" (читай "в потемках") - так себе занятие. Не лучше open source \ crowdsourcing? Бред в "конкурентное преимущество" надеюсь не верите.
ADOxx, Archi (что еще из open source?). Только видимо лучше за основу брать https://enterprise-architecture.org с его ontology-driven enterprise model и к нему визуализацию добавить, лучше редактор \ конструктор метаМодели (чтобы нотации добавлять). Отечественных open source - практически нет ("русские корни" - не в счёт), а в BPM\EA сегменте видимо единственный Runa WFE (BPMN-engine). Как по мне: если it-ВУЗ не имеет собственного open source, то ректора менять нужно.
Фраза "EA Tool «затачивается» под наши процессы" - означает, что в вашем банке банковские процессы не как в других банках?
KorotenkoP
06.04.2026 10:01Как всегда - одни лозунги.
Как вы собираетесь делать цифровой двойник без дерева метрик, без единого каталога данных и единой метамодели, включая не только бизнес способности, но и метамодель данных от глоссария до айайтема.
У вас ни слова про концептуальную модель данных, создание которой стоит колоссальный усилий, а у вас её нет.
За сложностью описания обычно скрывают воздушные замки без прочного фундамента.
vasyaya_23
Означает ли это, что у вас в репозитории учитываются только объекты ИТ-архитектуры? А что с объектами бизнес-архитектуры и архитектуры данных, такими как value streams, бизнес-сущности и т.д.?
Еще вопрос - можете поделиться метамоделью вашего репозитория?