Анатомия АБС: In-house разработка против архитектурной зависимости

Сардор Хужаев, город — Ташкент, тимлид команды разработки AБC, Kapital Lab, Uzum Technologies, LinkedIn

1. Иллюзия «коробки»

Когда банк подписывает контракт на вендорскую АБС, он убежден, что покупает продукт. Через три года становится очевидно: он купил зависимость.

Первые два года система ведет себя предсказуемо. Потом банк начинает расти — и поверхность трения с ядром увеличивается быстрее, чем команда успевает ее контролировать. Не потому, что вендор плохой. А потому, что классическая АБС строится как вертикально-интегрированный монолит: бизнес-логика, хранение, UI и workflow-движок живут в единой схеме СУБД с уровнем связности, при котором любое изменение тянет за собой цепочку неочевидных последствий.

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

2. Time-to-Market как структурное расхождение

Циклы поставки изменений у вендора и циклы продуктовой разработки банка живут в разных временных измерениях. Это не вопрос менеджмента и не вопрос приоритетов — это вопрос архитектуры.

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

Именно здесь начинается разговор о том, что банк должен строить сам — и о том, что именно.

3. Интерфейс как точка потери контроля

Есть проблема, о которой говорят меньше, чем о Time-to-Market. Это интерфейс.

Вендорские системы проходят через смену UI-парадигм: от тяжелых десктопных клиентов до различных поколений веб-интерфейсов. Главная боль здесь не в самом факте изменений — любой фронтенд требует адаптации пользователей. Проблема в том, у кого находится контроль над этим процессом: когда он меняется, в каком направлении и с какой скоростью.

Пока UX-слой принадлежит поставщику, банк реагирует — вместо того чтобы управлять. Это принципиальное различие, и оно дороже, чем кажется на старте.

4. Архитектурный выбор: между двух огней

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

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

Если у вас похожая задача, разговор стоит начать с архитектурного аудита существующей архитектуры.

5. Стабильность под нагрузкой: где прячутся проблемы

При нагрузке в 1800 TPS проблемы появляются не там, где их ждешь.

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

Аналогичная история — со стабильностью самой СУБД. Интеграционный код под нагрузкой способен создавать эффекты, которые незаметны при низком трафике и критичны при высоком. Планы выполнения, разделяемая память, статистика оптимизатора — все это живет своей жизнью, и без жесткого контроля оно «выстрелит» в самый неудобный момент.

Это не гайд — это просто список мест, где нас уже укусило.

Вместо вывода

Вендорская АБС — это не проблема и не решение. Это данность, с которой работает большинство банков региона. Вопрос не в качестве ядра — вопрос в том, способна ли команда выстроить вокруг него архитектурные границы, которые вернут банку контроль над собственной скоростью.

Сложность не в том, чтобы знать правильные инструменты. Сложность — в том, чтобы в нужный момент выбрать правильную точку приложения усилий. Это приходит с опытом работы именно в таких системах — и именно это отличает архитектурное решение от архитектурного намерения.