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

 

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

 

Нередки ситуации, когда, например, добавление одного поля в кредитную заявку оборачивается несколькими месяцами доработок, бюджет которых выражается просто астрономическими, на первый взгляд, цифрами. Почему так происходит? Чаще всего потому, что небольшая с точки зрения функционала доработка требует очень больших изменений в системе. Когда вам необходимо внести изменение в большое монолитное приложение, снабженное к тому же тонной проектной и эксплуатационной документации, вы просто вынуждены будете потратить колоссальные усилия на то, чтобы заставить новый функционал работать в рамках монолитной системы, внести изменения в нужные места обширного числа документов и, наконец, провести регрессионное тестирование всего функционала приложения, чтобы убедиться в его работоспособности. Неудивительно, что это требует много времени и средств. И чем больше происходит доработок монолитного программного продукта, тем дольше и дороже они становятся, так как функционал все усложняется и объем документации растет. Я уже не говорю о случаях, когда при внесении изменений и доработок забывают о сохранении полноты документации на систему.

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

 

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

 

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

 

Другими словами, для того чтобы дать бизнесу возможность быстро реагировать на требования рынка, нам необходимо обеспечить модульность на уровне не одного приложения и даже не одной программной платформы, но на уровне всего IT-ландшафта банка, а это всегда множество аппаратно-программных платформ и технологий. Необходимо отметить, что принцип модульности в программировании известен уже очень давно. Такие подходы, как, например, процедурное программирование, ООП, клиент-серверная архитектура, – это все примеры модульного подхода к разработке программных приложений. Все эти, а также многие другие технологии в момент их появления обеспечивали требуемый уровень модульности программного обеспечения. Однако с течением времени росла сложность приложений, увеличивался объем программного кода, появлялись и эволюционировали различные платформы, старые методы обеспечения модульности уже не справлялись со своими задачами, и требовались новые, то есть происходил естественный процесс эволюции, и сейчас мы делаем очередной шаг. Главный вопрос этого этапа – как обеспечить модульность на уровне всей IT-инфраструктуры банка? Основываясь на практическом опыте компании «Синимекс», предлагаю вниманию читателя два основных подхода к обеспечению хорошего уровня модульности программного ландшафта.

 

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

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

 

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

 

Однако положение сильно усложняется тем, что еще некоторое время назад на рынке не существовало готовых АБС, построенных по принципу СОА. Сейчас российские поставщики АБС, видя создавшуюся тенденцию со стороны заказчиков, уже начали движение в этом направлении. Но процесс идет небыстро, и его результаты пока не очевидны. На мой взгляд, на рынке уже существуют концептуальные модели СOA АБС, но до промышленного производства дело еще не дошло. Выход из данной ситуации есть, но, к сожалению, он применим только тогда, когда существующая АБС заказчика является модульной, или, назовем это пока условно, «внутренне сервисной». Что это значит? Внутри себя такая система уже построена по модульному принципу, то есть различные компоненты АБС достаточно независимы и предоставляют друг другу интерфейсы взаимодействия. Теперь, чтобы сделать АБС сервисно ориентированной, модульной в рамках всей инфраструктуры банка, необходимо регламентировать и разработать к существующим модулям АБС такие интерфейсы взаимодействия, которые можно будет использовать на межсистемном уровне внутри банковского ландшафта. Чаще всего, по опыту нашей компании, подобные интерфейсы разрабатываются посредством программных платформ для реализации сервисной шины предприятия – ESB.

 

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

 

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

 

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

 

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