SOA – это Сервисно-Ориентированная Архитектура

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

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

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

Для реализации принципов SOA используются центральная сервисная шина и язык описания бизнес-процессов – BPEL (Business Process Execution). Язык BPEL понятен без «технического перевода» всем заинтересованным сотрудникам банка. Выделение и централизация бизнес-процессов банка облегчают их мониторинг, дают возможность гибкого внесения изменений в эти процессы без изменения низкоуровневых сервисов.

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

Денежный вопрос SOA

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

Часто SOA ассоциируется с закупкой дорогих продуктов, что мешает продвижению этой передовой идеологии. Однако SOA — это только архитектурный шаблон. Реализацию его можно проводить в различных промышленных продуктах – разной стоимости: от широкоформатной/широкомасштабной линейки SOA-продуктов IBM и Oracle до условно-бесплатных серверов приложений с открытым исходным кодом (open sourse-системы).

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

Проанализировав и оценив свои потребности, банк сможет  принять самостоятельное решение и выбрать то, что для него важно, что вписывается в его стратегию.

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

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

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

• Если стоит задача интеграции разнородных систем.

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

• Если задача интеграции требует быстрого синхронного обмена (время реакции –меньше 1 сек.).

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

• Если требуется надежная эксплуатация интеграционного решения.

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

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