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

«БАНКАМ ТЕСНО В ОДНОЙ АБС»

Работая над созданием интеграционных платформ в крупнейших российских банках, мы в компании «Синимекс» отметили следующую тенденцию, начавшуюся более чем 5-6 лет назад и набирающую обороты сегодня. Очень большой процент крупных игроков российского финансового сектора стал внедрять по две и более АБС. Кто-то из них недоволен своей устаревшей системой, доставшейся в наследство от прошлого. Другим банкам в дополнение к иностранной АБС необходим модуль, отвечающий за российскую отчетность в ЦБ. Третьи разделяют корпоративный и розничный бизнес в различных АБС. Причины могут быть разные, но тенденция одна и та же. Я бы сформулировал ее так: «банкам тесно в рамках одной АБС».

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

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

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

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

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

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

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

В ЧЕМ ПРЕИМУЩЕСТВА КОМПОНЕНТНОЙ МОДЕЛИ АБС?

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

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

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

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

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

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

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