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

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

Одной из современных технологий, успешно зарекомендовавших себя для решения подобных задач, является внедрение специализированного про­граммного обеспечения класса middleware, реализующего принципы сервис­но ориентированной архитектуры (SOA, service-oriented architecture).

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

В основу концепции сервисно ориентированной архитектуры положена центральная сервисная шина (ESB, Enterprise Service Bus) и язык описания и исполнения бизнес-процессов (BPEL, Business Process Execution Language). Язык BPEL понятен без «технического перевода» всем заинтересованным сотрудникам банка. Применение для интеграции центральной сервисной шины и концепции SOA позволяет развивать информационные технологии банка эволюцион - но — в случае необходимости изменяя только отдельные «локальные» области интеграционной технологии, обусловленные произошедшими изменениями в программных приложениях банка. Важным преимуществом для банка является также отсутствие дополнительных затрат на обеспечение совместимости разных программных продуктов при обновлении их версий на более новые.

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

Как правило, SOA ассоциируется с закупкой дорогих программных ре­шений middleware. Однако SOA представляет собой только «архитектур­ный шаблон», реализацию которого можно проводить на базе различных промышленных продуктов — разных по стоимости: от широкой линейки SOA-продуктов компаний IBM и Oracle до условно бесплатных серверов приложений с открытым исходным кодом (open-sourse-системы). Каждый банк должен объективно оценить свои потребности, оценить преимущества и недостатки возможных решений в конкретной ситуации и сделать выбор.

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

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

Применение SOA может быть оправданно в случае необходимости ор­ганизации быстрого синхронного обмена данными (в случае, когда время прохождения транзакции обмена данными составляет менее 1 с). В такой ситуации файловая интеграция часто может быть неприменима, так как вре­менные затраты на «транспортные» расходы (обработку файлов) составляют в большинстве случаев более 1 с. Применение «прямых запросов» данных из одних приложений к другим в случае большого количества подобных взаимодействий делает всю «схему» обмена данными в целом непрозрачной и запутанной. Выбирая SOA-решение, важно понимать, что сервисно ори­ентированная архитектура, будучи более дорогим решением, обеспечивает необходимую скорость синхронного обмена и возможность расширения для потребностей и задач будущих проектов. Если же говорить о разнородных интегрируемых системах (например, на основе MS SQL Server и Oracle), то SOA-решение может быть единственным верным выбором.

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