В большинстве случаев основа программной инфраструктуры банка — банковское ядро (АБС). Работая над созданием интеграционных платформ в крупнейших российских банках, в компании «Синимекс» отметили следующую тенденцию, начавшуюся более чем 5–6 лет назад, и набирающую обороты сегодня: большой процент крупных игроков российского финансового сектора стали внедрять по две и более АБС. Причины этого могут быть разные, но общий вывод можно сделать такой: «банкам тесно в рамках одной АБС».

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

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

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

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

Каковы с учетом вышесказанного возможные сценарии для заказчика?

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

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

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

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