Хочу рассказать, почему растущие бизнес-требования к 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 лет, когда ИИ возьмёт на себя проектирование изменений в ИТ-ландшафте, превратив архитекторов разного уровня из проектировщиков систем в проектировщиков интеллектуальных архитектурных агентов?
Жду вас в комментариях.
