Единая цифровая платформа: как мы строили импортозамещенную экосистему для банка

Привет, Хабр!

Меня зовут Никита Шехов, я руковожу командой разработки "Единой цифровой платформы" (ЕЦП) в РСХБ.Цифра. В этой статье хочу рассказать, как мы создавали платформу для автоматизации бизнес-процессов банка, с какими вызовами столкнулись и какие решения оказались ключевыми. В будущем планирую рассказать про историю проекта, выбор архитектуры, сбор команды и борьбу с импортозамещением.

Единая цифровая платформа — это микросервисная экосистема, объединяющая технические компоненты и бизнес-сервисы для автоматизации процессов в Россельхозбанке. Её ядро включает следующие сервисы:

• Управление доступом (RBAC)
• Логирование и аудит
• UI-кит для фронтенда
• Работу с файлами и документами
• Интеграция с внешними системами (гибкий адаптер)
• Уведомления
• Шаблонизатор для печатных форм
• BPM-движок, для работы с процессами

На базе ЕЦП можно развернуть любой бизнес-процесс — от кредитования до управления проблемной задолженностью. При этом весь базовый функционал уже готов "из коробки". Мы используем PaaS-платформу AppFarm (рассказываем о нём в статьях на Хабре) для размещения наших сервисов, поэтому у нас не болит голова о процессах публикации от среды разработки до продакшена.

В конце 2022 года перед нами стояла амбициозная задача — импортозаместить зоопарк из 5+ legacy-систем (CRM, управление залогами, скоринг и др.), работавших на зарубежном стеке. Условия были жёсткими: было всего два года на переход, в интеграциях нужно было переключить 400+ потоков данных на импортозамещенные решения. Кроме того, в плане безопасности решения должны были соответствовать требованиям регуляторов. И, конечно же, переход должен был быть непрерывным для бизнеса: параллельно мы поддерживали старые и новые системы.

На старте внутренняя команда с опытом в микросервисы состояла всего из 5 человек, 40 зибилистов, 3 Jboss специалистов. Нас ожидал найм 60 человек на новое решение и 40 "плавающих" сотрудников от вендора, которые приходили на два месяца, а потом увольнялись.

Системы, которые требовалось заменить, дублировали функционал, имели устаревшие интерфейсы (например, IE с ActiveX) и слабо взаимодействовали друг с другом. Решение было очевидным — построить единую платформу.

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

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

Мы рассматривали коробочные решения (FIS, ELMA и т.д), но отказались от них по трём причинам:

1. Зоопарк технологий: каждая legacy-система использовала свой стек (Java, .NET, проприетарные СУБД), добавлять еще одно универсальное решение — всё равно, что принять тот факт, что "в мире было 12 стандартов, давайте сделаем один общий для всех, так в мире стало 13 стандартов".

2. Отсутствие команд: большинство систем поддерживали вендоры, а внутренние отделы занимались только сопровождением и чуть-чуть развитием.

3. Гибкость: готовые решения не позволяли быстро адаптироваться под меняющиеся требования регуляторов.

Выбор пал на собственную разработку и микросервисную архитектуру — это дало возможность переиспользовать общий функционал для всех 5 систем.

Сформировать команду из 60 человек за полгода — задача не для слабонервных. Собирать ИТ-команду — это не просто дело техники, это настоящее искусство. Возможно, именно поэтому этап набора сотрудников становится одним из самых сложных этапов проекта. Когда перед тобой стоят шестьдесят вакансий, а каждая позиция требует идеального кандидата, начинается настоящая гонка за таланты.

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

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

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

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

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

Ограничения и реальность банковского сектора. Про третью волну боли: разработка банковских продуктов накладывает особые ограничения. Административные права не разрешены (и так во всех банках), доступ в интернет ограничен, рабочее окружение строго регламентировано. Даже шутливая просьба сотрудника дать другой компьютер превращается в почти философский диспут — большинство ребят мечтает работать не через виртуальные машины и RDP, а на собственном ноутбуке, желательно с яблочком на крышке. Однако реалии в банковском секторе совсем другие: в то время пока Яндекс меняет м2 про на м4 про, некоторые компании переходят с Lenovo на Квадру.

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

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

Сначала мы создали технические компоненты, критичные для импортозамещения:

1. Фронтенд(UI-Kit): Переход с IE на современный стек (React + TypeScript).

2. Проработка архитектуры.

3. Проектирование базовых сервисов (ядровые компоненты платформы, перечислены в начале статьи).

4. Интеграции: Замена IBM на Apache Kafka и Artemis.

Импортозамещение: двойная нагрузка. Параллельно с разработкой ЕЦП приходилось поддерживать legacy-системы, интегрировать их с новыми импортозамещёнными сервисами (например, Kafka вместо IBM шины), работать с вендорами, которые часто "исчезали" из-за санкций. Пример: Переход на Artemis потребовал доработать все интеграции. Каждый сценарий тестировали дважды — на старой и новой шине.

Чего не хватало. Банковские ограничения добавили сложностей, например, не было доступа к продакшен-данным. Это норм, но даже взглянуть было нельзя. Тестировали на обезличенных данных, что приводило к багам в проде.

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

Запрещённые технологии. Частенько встречались ситуации, когда на рынке есть десяток хороших решений, но они были импортные и их нельзя было втащить за пару дней "клац-клац и в продакшен", приходилось разрабатывать свои аналоги.

Отсутствие инструментов разработки (в самом начале):

• Kafka UI — для работы с топиками, а доступ к Кафке был только у сервиса, развернутого в дев окружении банка.
• CloudBeaver — веб-интерфейс для СУБД (требовалось работать сразу с несколькими видами БД).
• Debezium — CDC для синхронизации данных.

Тестирование: Playwright vs. Java. Изначально автотесты писали на Java, но столкнулись с дефицитом специалистов. Перешли на Playwright, потому что нам были важны такие параметры:

• Low-code: Тесты можно "накликивать" без глубоких знаний программирования.
• Скорость: Параллельный запуск 50+ сценариев.
• Поддержка микросервисов: Интеграция с API Gateway.

У решения были и минусы — высокие требования к инфраструктуре, каждый тест — отдельный контейнер.

За первый год нам удалось:

• Сформировать команды ядра и продуктовые,
• Запустить ЕЦП в пилотной эксплуатации,
• Перенести 3 из 5 бизнес-направлений в виде MVP,
• Сократить время выпуска релизов с 1 месяца до 1 недели.

За второй год:

• Перенесли полностью функционал 4 из 5 направлений,
• Перешли от стадии импортозамещения к стадии развития действующих продуктов,
• Часть продуктовых команд переключились на развитие новых процессов вместо импортозамещения и даже успели какую-то часть внедрить в промышленную эксплуатацию.

Вернусь на Хабр с историями, что и как мы импортозамещали в 2025 году, как мы проектировали архитектуру ЕЦП, почему выбрали React вместо Angular.

Сталкивались ли вы с импортозамещением legacy-систем? Сталкивались ли с заменой Oracle/Siebel? Чем заменили? Какие инструменты и подходы оказались полезными?

P.S. Если есть вопросы по стеку или организации процессов, спрашивайте в комментариях!