Почему банки застряли в коробках и как aPaaS помогает выйти из цикла кастомизаций и интеграций

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

Чтобы объединить их, IT-команды выстраивают интеграции, поддерживают разные версии API и отслеживают изменения у вендоров.

Весь корпоративный софт можно разделить на два больших класса:

• Внутренние системы, с которыми взаимодействуют в основном сотрудники банка.
• Внешние системы, с которыми взаимодействуют клиенты банка.

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

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

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

Все системы в процессе своей работы генерируют данные.
Эти данные необходимо сохранять в хранилища. Хранилища могут быть разными: S3, файловая система или база данных.
Механизмы работы с хранилищами также имеют стандартную типизацию: при сохранении файлов используется потоковая запись, а для работы с базами данных — инструкции Insert или Update.

Большинство систем не может существовать в изоляции, поэтому у всех есть интерфейсы взаимодействия.

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

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

Если посмотреть на типичную инфраструктуру банка глазами проекта внедрения, получится полностью кастомизированная структура.

В итоге, повышая автоматизацию банковских процессов, банк неизбежно повышает связность систем.

А рост связности ведёт к увеличению стоимости проектов внедрения и дальнейшего сопровождения.

Мы предлагаем не кастомизировать коробки, а создавать их с помощью графической среды разработки (IDE). Так же, как программисты делают это через код, только с помощью визуального интерфейса.

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

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

Компания сама управляет своим жизненным циклом цифровизации и формирует те системы, которые соответствуют её текущему этапу развития.

Архитектуру платформы можно сравнить с телефоном на базе Android.
Есть физическое устройство, на нём работает Linux, поверх него запускается Android, а уже в Android — приложения.

У нас устроено похоже.
→ Первый слой — физические серверы.
→ Поверх них работает средство оркестрации на базе Kubernetes.
→ В Kubernetes запускаются микросервисы, из которых состоит nocode-платформа.
→ Внутри неё собираются приложения, где слой представления данных может быть реализован в виде мобильного или веб-интерфейса.

Под популярным термином «микросервисная архитектура» может скрываться разная логика.
Можно делать микросервисы бизнес-функций — платежей или переводов.
А можно — системных функций: работу с файлами, отправку уведомлений, выполнение запросов в другие системы, описание структуры данных.
Наша платформа в основном строится на втором подходе — системных микросервисах.

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

Архитектура платформы состоит из четырёх слоёв:

• представление — веб- и мобильные интерфейсы,
• бизнес-логика — процессы, операции и действия,
• интеграции — REST, SOAP, Kafka, OpenID, OAuth 2.0,
• хранилище — базы данных, файловые системы и S3.

В платформе реализованы принципы классического программирования: компонентный подход, ООП, проектирование интерфейсов и принципы дизайна, схожие с Figma.

Коробкой в нашей концепции считается собранное внутри платформы решение.
Такое решение можно выгружать в виде файла-бэкапа и переносить с одного стенда на другой.

Если nocode-подход используется для создания внешних и внутренних систем одновременно, можно применять инструмент пространств — для изоляции пользовательских баз.
Например, клиентские системы ДБО и открытие счёта можно разместить в одном пространстве, а внутренние системы HRM и документооборот — в другом.

Это физически разные базы данных, что обеспечивает безопасность и независимость контуров.

На банковском рынке распространены системы на базе Camunda, а также low-code платформы, такие как Elma и GreenData, ориентированные на автоматизацию бизнес-процессов.
Подобные решения, как правило, не предназначены для разработки клиентских интерфейсов, с которой банки сталкиваются при создании систем дистанционного банковского обслуживания.

Abanking работает иначе.
Это полноценная aPaaS-платформа, где визуальное проектирование объединено с архитектурой корпоративного класса — микросервисами, API, системой мониторинга и управляемым масштабированием.
Платформа позволяет строить не отдельные процессы, а законченные цифровые продукты: ДБО, кредитные конвейеры, корпоративные порталы.

В системе предусмотрены два типа виджетов — In-виджеты и Out-виджеты.

In-виджеты используются, когда в платформу нужно встроить внешний интерфейс или компонент.

Out-виджеты — когда требуется встроить собранное в платформе решение в другую систему, например, добавить функциональность цифрового рубля в существующее ДБО.
Для этого собираются нужные процессы, настраивается интерфейс и публикуется готовое решение на домене.

На платформе Abanking уже реализовано ДБО для банка с клиентской базой более 500 000 пользователей.

Решение собрано без традиционного кода, работает стабильно и масштабируется без изменений архитектуры.

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

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

Это позволяет запускать новые сервисы за недели, а не за месяцы, и быстро адаптировать логику под изменения в бизнесе.

aPaaS-подход превращает IT-ландшафт банка из набора разрозненных систем в единый контур, где продукты можно собирать, изменять и масштабировать как конструктор.

В классической архитектуре банк обслуживает несколько самостоятельных систем — ДБО, CRM, кредитные конвейеры, HRM, документооборот.
У каждой своя команда, лицензии, интеграции и договоры сопровождения.
Любое изменение требует согласований между подрядчиками и занимает недели.

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

Банк снижает расходы на инфраструктуру и поддержку, а скорость изменений становится управляемой. Новые продукты создаются быстрее, а развитие IT-ландшафта перестаёт быть зависимым от внешних подрядчиков.

Банкам больше не нужно выбирать между готовой коробкой и долгим циклом разработки.
aPaaS-подход объединяет скорость визуального конструирования и масштабируемость корпоративной архитектуры.
На платформе Abanking цифровизация перестаёт быть набором отдельных проектов и превращается в управляемую экосистему.

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

Запишитесь на демо Abanking, чтобы увидеть, как платформа превращает «зоопарк коробок» в единую архитектуру.