Уровни зрелости архитектуры банка. От Дискет до ИИ

Кому будет интересна эта статья?

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

Об авторах

Свиридов Александр – Архитектор в ОТП банке, до этого работал в Сбере, ВТБ, Газпроме, более 15 лет в IT. 

Толстихин Сергей – Архитектор в Рольф. До этого – главный архитектор в ОТП банке, так-же работал архитектором в Райфайзен банке и Сбербанке.

Введение

Когда мы с Сергеем обсуждали мою предыдущую статью(Как устроен финтех изнутри ^[1]), всплыл вопрос: а как вообще понять, насколько банк зрел в плане архитектуры? У Сергея возникла идея привязать этапы развития архитектуры банка в целом именно к развитию интеграционного слоя. Именно он показывает, способен ли банк быстро и надёжно передавать данные между своими частями или всё держится на честном слове и ручной работе. Так родилась идея этой статьи.

Зрелость интеграционного слоя – это самый точный и измеримый показатель зрелости всей архитектуры банка. Без налаженных связей между системами даже самый современный core-банкинг превращается в изолированный остров.

В этой статье мы проследим, как менялась архитектура банков с конца девяностых до наших дней, и разложим этот путь на шесть уровней – от полного отсутствия интеграций до кое-каких набросков будущего, где рулит искусственный интеллект ^[2].

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

Уровень 0: Досистемная эра. «Где карту открывали, туда и идите»

конец 1990 и начало 2000 гг.

В конце 1990-х банковская автоматизация только набирала обороты. Внутри отдельного филиала уже могли работать электронные проводки и простенькая АБС(решения на Clarion (DiasoftBANK 4×4) или на Btrieve (RS-Bank)), но за его пределами царил «гибридный» документооборот. Сведение бухгалтерских книг между офисами происходило путём физической перевозки дискет, флешек или все еще бумажных реестров. Даже обязательную отчётность в ЦБ зачастую отправляли на дискетах и это в середине 2000-х. Каналы связи были медленными, модемы – ненадёжными и о шифровании трафика между площадками задумывались далеко не все.

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

Из-за этих ограничений и родилась позже легендарная фраза «где карту открывали, туда и идите». Это не было вредностью сотрудника у него просто не было физической возможности увидеть данные из другого офиса.

Проблемы такого подхода были очевидны всем: дорогая поддержка разношёрстного «зоопарка», мучительный аудит, полное отсутствие клиентоориентированности. Но с точки зрения ^[3] архитектуры главная характеристика этой эпохи – интеграционной платформы не существовало как класса. Её роль выполняли курьеры, модемы и человеческая память ^[4].

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

Уровень 1: Эпоха ESB. Порядок через централизацию

2005–2015 гг.

К середине 2000-х ситуация, описанная на предыдущем уровне, стала критической. На руках у банков – десятки разнородных «коробок», написанных в разное время, разными людьми и на разных языках. Где-то COBOL, где-то Delphi, где-то самописный Java. Слияния и поглощения только усугубили этот зоопарк: после очередной сделки банк мог получить в наследство сразу четыре-пять различных АБС. Переписать всё с нуля – значит потерять миллионы и парализовать бизнес на годы. Нужно было решение, которое бы «подружило» системы, не заставляя их меняться. Им стала ESB (Enterprise Service Bus) и построенный вокруг неё архитектурный стиль SOA.

Главным героем эпохи на российском рынке стала IBM WebSphere – не просто шина, а целая экосистема с брокерами, очередями, менеджерами и серверами приложений которая умела главное: содержать сложную логику ^[5] трансформации данных и гарантировать доставку сообщений. Схема была простой: к каждой legacy-системе дописывался адаптер, который с одной стороны общался с шиной, а с другой – напрямую лез в базу данных или работал с проприетарным протоколом древнего монолита. Шина же становилась универсальным переводчиком, например: забирала из системы А текстовый файл, преобразовывала в XML, дозапрашивала данные из систем Б и В, сверялась со справочником в системе Г и упаковывала результат для системы Д. Без переписывания самих «коробок». Таким образом, банк впервые получал единый, контролируемый канал передачи данных между всеми своими частями.

Внедрение ESB немедленно отразилось на клиентском опыте ^[6]. Легендарная фраза «где заявку оформляли, туда и идите» начала постепенно уходить в прошлое. «Ренессанс Кредит» на фоне внедрения SOA к 2011 году подключил к шине 15 систем, которые взаимодействовали через 150 переиспользуемых сервисов; в пиковый сезон шина прокачивала до 250 000 сообщений в день. Именно это (вместе с заменой АБС с диасофт на FIS Profile) позволило банку создать комбинированный продукт «кредит + карта» всего за два месяца – неслыханная для того времени скорость. УРСА Банк, в свою очередь, сумел подружить пять разных АБС в единый работающий организм, обеспечив устойчивость банка в целом. Подобных историй успеха в то время было множество, и банки один за другим вставали на рельсы SOA.

Однако к 2015 году эйфория спала. Умная шина оказалась палкой о двух концах. Во-первых, она превратилась в единую точку отказа: сбой в одном месте валил весь банк. Во-вторых, поддержка и развитие такой архитектуры требовали огромных команд дорогих специалистов, понимающих хитросплетения брокеров, очередей и отказоустойчивых кластеров. В-третьих, каждый новый проект требовал длительного цикла согласования изменений в канонической модели данных (CDM) и в логике самой шины. Централизованная «умная» труба стала «бутылочным горлышком», в котором тонули инновации. Неудивительно, что вскоре мир начал разворот к противоположному принципу – «глупый канал, умные конечные точки», но об этом в следующем уровне.

Уровень 2: Эпоха Agile трансформации. Хаос

2015-2020 гг.

Путь отказа от умной ESB тернист и сложен, и каждый банк проходил его по-своему. Всё сильно зависело от масштаба, наличия денег на глобальную трансформацию «сразу» и необходимости резких перемен. Кто-то начинал Agile-трансформацию и постепенно перестраивал архитектуру. Кто-то «выкидывал» старую архитектуру и, разом наняв больше двух тысяч специалистов, строил новую рядом, с нуля, а то-то до сих пор активно использует покупные коробочные решения. Но если банк хотел быть гибким и быстрым в условиях меняющегося рынка, трансформация была неизбежна.

К середине 2010-х большинство жило в похожих условиях: большая коробка интернет-банка (покупная вроде BIFIT или самописная), монстр-монолит на уровне мидл-слоя вроде Oracle Siebel CRM или Dynamics CRM, процессинг, АБС и прочие монолитные системы. От совсем древних монолитов многие уже избавились, но пришло понимание: развитие по «водопаду», отлично работавшее в SOA, больше не отвечает требованиям рынка. Коробочные решения развивались медленно, дорого и с непредсказуемыми сроками.

Agile-трансформация и микросервисы оказались неразрывно связаны: без одного достичь другого практически невозможно. Здесь железно работает закон Конвея: «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации». Пять продуктовых команд – пять сервисов, общающихся через Kafka. Две команды, которые не общаются, – два сервиса с разными моделями данных для одного и того же клиента.

Громадные монолиты вроде Siebel распиливаются на десятки систем. Логика связи из IBM MQ – «умного» канала с гарантированной доставкой – мигрирует в сами микросервисы, и взаимодействия идут уже по принципу «умная точка, глупый канал»: RabbitMQ, Kafka или прямые HTTP-вызовы.

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

Безопасность тоже рассыпалась. В монолите был один периметр, в микросервисах – десятки и сотни. И, например, неконтролируемая передача SAD при точечных интеграциях вела к многомиллионным штрафам и потере доверия клиентов (статья про SAD и PCIDSS ^[7]).

Контроль над архитектурой в таких условиях остаётся лишь формальным – через ADR (Architecture Decision Records) на архитектурных комитетах, которые никто не проверяет в реальном времени. Единственное реальное ограничение – фаерволлы: открыл доступ между двумя узлами, и всё, дальше делай что хочешь. При прямых интеграциях ничто не мешает разработчикам проигнорировать согласованные 10 RPS и пустить 10 000 000, положив критичную систему банка.

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

Уровень 3: Централизованный интеграционный слой

2020–2025 гг.

Прежде чем перейти к централизованному интеграционному слою, стоит упомянуть альтернативный путь – Service Mesh. Концепция «умная сеть, глупые конечные точки» выглядит элегантно: все микросервисы общаются через единую инфраструктуру с mTLS-шифрованием, динамическим сервис-дискавери, тонким разграничением доступа и многими другими плюсами из “коробки”. Казалось бы – идеальное решение! Однако на практике банков, которые перевели бы на Service Mesh значительную часть своего ландшафта я не встречал. Сбер, Альфа-Банк и многие другие применяют эту технологию, но в масштабах отдельных крупных систем, а не как единый всеохватывающий слой. Архитектура, основанная на Service Mesh – это сложно, дорого и требует совершенно иной культуры разработки. 

Мы наконец приходим к той архитектуре, которая была рассмотрена в прошлой статье(Как устроен финтех изнутри ^[1]). Вызовы децентрализации обязывают банк создавать единый интеграционный слой между слоями и там, где это возможно, отказываться от прямых интеграций между системами.

Вкратце механика такая: разворачиваются отказоустойчивые, геораспределённые кластеры для Kafka, MQ и API GW. Добавляются инструменты автоматизации заведения и доработки API, очередей и топиков. Сверху – мониторинг, троттлинг и непрерывный аудит через гибкую ролевую модель, завязанную на единую систему аутентификации(UAS).

Примерно по такому пути с 2020 по 2024 год шёл Россельхозбанк с платформой App.Farm, Альфа-банк, ВТБ и многие зарубежные. 

В такой архитектуре условный аналитик CRM уже не гадает, откуда и как взять нужные данные для нового бизнес-процесса, не бегает к синьорам других команд за информацией. Вместо этого на консоли можно находит нужные источники данных и парой кликов запускает процесс доступа. Банк чётко видит потоки данных между системами, аудит становится делом минутной выгрузки.

Однако есть у этой схемы и минусы, которые не позволяют однозначно утверждать, что все должны стремиться именно к этому уровню. Централизация по умолчанию создаёт точки отказа и в процессах, и в системах. Эти точки можно обложить “соломкой”, но полностью избавиться от них нельзя. Без автоматизации процесса управления заведением новых потоков данных и правок существующих минусов становится слишком много: отдельная огромная команда, которая вручную правит очереди, топики и API, вернёт нас в ту же пропасть «бутылочного горлышка», что и в эпоху ESB. Применять этот уровень нужно с умом и с правильной подготовкой.

Уровень 4: AI-Assisted – платформа самообслуживания и Internal Developer Platform

2025 – настоящее время

Итак, на предыдущем уровне мы получили централизованный интеграционный слой, который дал прозрачность, контроль и единые стандарты. Аналитик больше не гадал, откуда брать данные, а разработчик получил полную документацию для работы. Но осталась одна фундаментальная боль ^[8]: каждый новый интеграционный поток всё ещё требовал участия человека. Написать контракт, настроить маршрут, согласовать доступ, проверить SLA – путь от идеи до рабочей интеграции занимает недели, а то и месяцы. И это при том, что сама платформа уже готова к автоматизации. 

Ровно эту боль и начал закрывать AI-Assisted подход. Искусственный интеллект здесь не заменяет архитектора или разработчика, а снимает с него рутину. Мы с Сергеем видим в этом естественную эволюцию ^[9] Уровня 3: если интеграционный слой уже цифровизирован и все артефакты живут в машиночитаемом виде, почему бы не позволить ИИ управлять ими?

Ключевые элементы этого уровня это:

• Self-Service с каталогами API, очередей и топиков и AI-проводником. Разработчик заходит на внутренний портал, описывает на естественном языке, какие данные ему нужны, и AI-агент сам находит подходящий endpoint, генерирует контракт, предлагает политики безопасности и создаёт черновик Pull Request’а. Никакого ручного поиска по докам и долгих переписок с владельцами систем.

• GitOps. Все контракты хранятся в Git. Изменения проходят через автоматические проверки: линтеры, тесты на обратную совместимость, соответствие банковским стандартам. Ручное вмешательство нужно только для финального аппрува.

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

• AI-аудит и подсказки. Система сама подсказывает если новый контракт дублирует уже существующий, доработка нарушает SLA или противоречит регуляторным требованиям.

AI-Assisted уровень – это не серебряная пуля, а логичное продолжение курса на прозрачность и контролируемую автоматизацию. Он закрывает остаточную рутину и готовит почву для следующего шага – где ИИ перестанет быть помощником и станет ядром архитектуры. Но об этом в следующем уровне.

Уровень 5. AI First и AI Native подходы в финтехе

возможное будущее

Представьте себе банк, разорванный между двумя реальностями. С одной стороны – CORE-слой: жёсткая регуляторика, обязательные отчёты перед ЦБ, 850П с серьезными требованиями по отказоустойчивости и доступности. С другой – взрывной рост AI-агентов. Это напряжение и есть точка рождения AI-Native архитектуры.

Ключевой сдвиг по сравнению с предыдущим уровнем: на AI-Assisted помогал разработчику. Здесь агенты действуют автономно. Product owner описывает задачу на естественном языке, а AI-агенты сами проектируют, тестируют и выкатывают функционал клиенту. Разработчик из «писателя кода» превращается в куратора домена: пишет промпты, следит за инфраструктурой и вмешивается, только когда что-то пошло не так.

Интеграционный слой при этом не исчезает – он мутирует. Превращается в стандартизированную среду, которую многие уже называют AI Fabric: единый, управляемый слой, предоставляющий доменно-ориентированные потоки данных AI-агентам без необходимости перестраивать интеграции под каждую модель. Это смена того, как банковские данные производятся, передаются и потребляются – через событийно-ориентированную архитектуру и data mesh, а не точечные интеграции.

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

Но минусы столь же серьёзны. Первый – проблема общей семантики. Если AI-агенты получают доступ к разрозненным данным, они галлюцинируют и ломаются. Второй – объяснимость и аудит. Когда AI-агент принимает решение о кредитной заявке, регулятор захочет знать, на каком основании. Каждое решение агента должно прозрачно трассироваться и аудироваться. 

Наш с Сергеем прогноз: AI-агенты займут весь канальный слой и мидл-слой банка, но CORE и безопасность останутся под контролем человека. Это не «чёрный ящик», а система с прозрачными стеклянными стенами, где видно каждое действие, но выполняют эти действия не люди. Формирование систем и интеграций между ними будет происходить при помощи ИИ – быстро, без участия дорогостоящей разработки, но под надзором инженера-куратора.

Заключение. Отсутствующий интеграционный слой – венец развития?

Последний уровень этой статьи – наша фантазия. AI-Native банки, где агенты сами проектируют интеграции, пишут код и выкатывают продукты, пока существуют лишь в пилотных контурах и архитектурных документах.

Скоро ли банк придёт к тому, что 5-6 менеджеров, разбирающихся в домене, заменят команды разработки из тысяч людей? Сергей уверен, что да и скоро. Я чуть более скептичен и считаю, что спешить тут нельзя. Финтех – это не про edge-технологии и молниеносное следование трендам, а про надёжность и доверие людей. 

Но оба мы согласны с тем, что вместо того чтобы вручную настраивать очереди и контракты, человек станет тем, кто задаёт правила игры: определяет границы автономии агентов, выстраивает прозрачную систему аудита и следит, чтобы ИИ не превратился в чёрный ящик без объяснений. Доменную логику и ответственность за решения ИИ не заменит – потому что расписываться перед ЦБ придётся человеку. По крайней мере пока сам аудитор не перешел на AI-Native. 

Фраза «где карту открывали, туда и идите» ушла в прошлое. Когда-нибудь уйдёт и фраза «сделайте ADR и согласуйте с десятком команд». Интеграционный слой перестанет быть проблемой – и это финал нашей эволюции.