Проблемы монолитного интернет-банка

В предыдущем разделе описана типовая система интернет-банка такая, какая она была до конца 2010-ых годов.

С точки зрения разработчика он представляет собой довольно тяжеловесную кодовую базу с огромным количеством legacy-кода, который неизбежен в работе с финансовыми операциями, сменами кадров и постоянным пониманием того, что всё должно работать так, “как раньше” и непониманием того, как оно раньше работало.

С точки зрения тестировщиков и аналитиков – это очень большая база требований и особенностей функционирования, которая со временем только растёт. Как и с точки зрения разработчиков интернет-банка.

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

Также нельзя не отметить, что недостатки монолитного интернет-банка вытекают как следствие недостатков ИТ-инфраструктуры банка в целом. Давайте для начала рассмотрим инфраструктуру в целом.

Традиционно в банках использует сервис-ориентированная архитетура (SOA).

Как описано в книге Ньюмана [Ньюмана], SOA появилась в качестве подхода для борьбы с проблемами больших монолитных приложений. Этот подход был направлен на обеспечение возможности повторного использования программных средств, чтобы два и более приложения для конечного пользователя могли применять одни и те же сервисы. Он был направлен на то, чтобы упростить поддержку или переделку программных средств, поскольку теоретически, пока семантика сервиса не претерпит существенных изменений, можно заменить один сервис другим, никого не ставя об этом в известность. В сущности, SOA является весьма хорошей затеей. Но, несмотря на приложенные к этому существенные усилия, прийти к консенсусу о том, как именно достичь успеха в разработке SOA, пока не удается, так как, в отрасли информационных технологий отсутствует целостный взгляд на эту проблему и различные производители в этой области не представили какие-либо стройно изложенные и убедительные альтернативы. Многие проблемы на пути развития SOA, по сути, имеют отношение к сложностям, связанным с протоколами обмена данными (например, SOAP), поставщиками связующих программных средств, отсутствием методик, позволяющих определить степень детализации сервисов, или неверными методиками выбора мест разделения системы.

На рисунке 6 изображена примерная архитектура сервисной шины банка.

Рисунок 6 - Работа сервисной шины банка.

Подобных блоков в шине накапливает довольно много, и они тесно переплетены между собой. Если потребуется внедрить новый продукт и внести какие-то изменения, то на переработку этого внушительного монолита уйдет много времени. В целом согласно исследованию [8], для SOAвыделить семь основных проблем:

- Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно приводит к тому, что все команды разработки становятся настолько плотно связаны, что любое обновление интеграции требует регрессионной проверки практически всей шины.

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

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

- Данные. В SOA интерфейсы сервисов отделены от имплементации. Но сами данные ненастолько отделены друг от друга. Один сервис обращается к данным другого, используется механизм dblink’ов, возникает неразбериха и путаница.

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

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

- Отсутствие поддержки ITSec (информационной безопасности) на уровне концепции. Концепция ESB не учитывает особенности российского законодательства (например, защиту персональных данных при передаче из источника в приемник), а также контейнер ESB представляет собой периметр, который эффективно работает, когда внутри него уже не требуется соблюдение специальных требований ITSec.

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

На рисунке 7 изображена возможное текущее состояние ИТ-инфраструктуры банка.

Рисунок 7 - ИТ-инфраструктура банка в срезе ИТ-систем.

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

Итоги анализа

Таким образом, ввиду недостатков существующей монолитной системы интернет-банка необходимо перейти к такому подходу к разработке, в котором нашли бы своё примерение следующие идеи:

- Возможность быстрого пилотирования идей. Для этого потребуется простая (регулярная, повторяющаяся) структура связей между системами, быстрое развертывание и версионирование.

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

- Наличие экосистемы с командами разработки разных типов: внутренние, внешние, партнерские. Предоставление интерфейсов для внешнего доступа, контроль этого доступа и биллинг.