CC BY
34
СЕРВИСНО-ОРИЕНТИРОВАННЫМ ПОДХОД КАК ИНСТРУМЕНТ ПОСТРОЕНИЯ БАНКОВСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ
УДК 004.415.2
Антон Сергеевич Поляков,
Аспирант кафедры Управления знаниями и прикладной информатики в менеджменте (УЗиПИМ ) +7 903 700 9757 [email protected] Руководитель группы разработки трейдинговых платформ, Дойче Банк г. Москва
В данной статье рассматриваются актуальные проблемы проектирования эффективных банковских ИТ-систем на примере использования сервисно-ориентированного подхода, позволяющего получить существенную экономию средств при построении последних. Анализируются требования,
предъявляемые к эффективным ИТ-системам банка, а также приводятся существенные преимущества от использования сервисно-
ориентированного подхода при проектировании эффективных банковских ИТ-систем.
Ключевые слова: информационные системы, банки, методолгоия, сервисно-ориентированная архитектура.
Anton Sergeevich Polyakov,
Graduate student, MESI+7 903 700 9757
Team lead, trading platforms department,
Deutsche Bank Moscow
SERVICE ORIENTED APPROACH AS A TOOL FOR IMPLEMENTING IT INFRASTRUCTURE IN BANKS
This paper describes challenges of constructing aqile IT systems in banks using service-oriented approach (SOA) form a perspective of cost reduction and increased ROI. Requirements and challenges of constructing effective IT infrastructure are analyzed and addressed with SOA approach.
Keywords: information systems, banks, methodology, service-oriented approach
1. Введение
На современном этапе развития экономики рост производительности труда и эффективности того или иного бизнеса в доминирующей степени определяется уровнем развития информационных технологий. В свою очередь, и банковская система, являющаяся неотъемлемой частью любого сектора экономики, должна эф-фетивно использовать преимущества информатизации своей операционной деятельности. Еще несколько лет назад большинство операционных процессов, проистекающих в банках, были либо полностью ручным, либо лоскутно-автоматизиро-ванными. Отличительной особенностью настоящего этапа эффективного развития банковского сектора экономики для обеспечения прозрачности и контроллируемо-сти ключевых операционных процессов является использование банками быстрых и надежных каналов связи, реорганизация внутренних процессов управления для мониторинга корпоративных рисков и обеспечение согласованности действий между различными подразделениями. В идеале все процессы управления должны быть сосредоточены в одном месте.
Но создание такого своего рода единого "центра управления полетами", отвечающего общепризнанным международным стандартам коммуникаций не может полностью эффективно ответить на поставленную проблему.
2. Современные требования к информационным системам банка
Наряду с вышесказанным актуальным на сегодня остается реструктуризация и автоматизация внутренних операционных бизнес-процессов банковской деятельности при условии их максимальной эффективности. Поэтому современные экономические условия предъявляют более жесткие требования к информационным системам, используемым в работе банка. Учитывая нестабильность развития финансового бизнеса, новые тенденции и все возрастающую конкуретную борьбу, сформируем общий набор требований, предъявляемых к эффективным ИТ-системам банка:
• минимизация затрат на модернизацию или расширение
• наличие возможности относительно простого изменения отдельных модулей или групп модулей без потери эффективности;
• возможность получения большого возврата инвестиций (ROI, return of investment);
• минимизация операционного времени выхода на рынок;
• использование возможности широкой интеграции в существующую инфраструктуру;
• возможность предоставления клиентам услуги в виде различных гибких интерфейсов;
• возможности B2B (business-to-business) и B2C (business-to-client) интеграции.
Реинжиниринг бизнес-процессов потребует от банка в свою очередь пересмотра и расширения существующих информационных систем, поддерживающих эти процессы. Сегодня обойтись программным продуктом единственного поставщика уже невозможно, и для эффективного управления практически любым банковским бизнес-процессом приходится использовать потенциал нескольких ИТ-систем.
Но с ростом числа взаимодействующих между собой приложений становится все труднее интегрировать их старым способом «каждый с каждым». Используемые современные технологические платформы, составляющие внутреннюю ИТ-инфраструктуру банка, должны не только отвечать текущим потребностям бизнеса, но и обеспечивать должный уровень масштабируемости и расширяемости для обеспечения результативной интеграции с существующими и разрабатываемыми информационными системами.
Используемый ранее подход к информатизации, когда под конкретную задачу разрабатывалась соответствующая система уже не отвечает требованиям современного развития экономики и, как следствие, банковской деятельности. Сегодня в рамках одного банка функционирует множество подразделений, решающих различные задачи, однако условия таковы, что связь между различными направлениями деятельности банка становится все более тесной, а следовательно, информационные системы должны быть интегрированы в единую динамическую среду с
широкими возможностями по повторному использованию различных компонентов и способностью к быстрой самоадаптации под новые требования.
3. Service-oriented architecture
3.1. SOA как новый подход к проектированию информационных систем
Принципиально новый подход к организации информационных ресурсов предприятия заложен в методологии так называемой сервис-ориентированной архитектуры или на общепринятом языке ИТ-специалистов, SOA (service-oriented architecture, сервисно-ориентированная архитектура) . SOA обеспечивает построение эффективного решения, в рамках которого разнородные системы могут прозрачно взаимодействовать на уровне бизнес-логики. Такое взаимодействие обеспечивают специальные интеграционные платформы, содержащие набор необходимых сервисов, таких как интеграция, управление бизнес-процессами, а также процедуры аудита и мониторинга получаемого решения [1].
Методология SOA базируется на использовании модульного подхода к разработке программного обеспечения с использованием сервисов (служб) со стандартизированными интерфейсами. Такой подход позволяет распределить нагрузку между различными сервисами и, как следствие, улучшить параллельную обработку запросов, а также обеспечить единую точку входа (single sign-on) и построение низкозатратной инфраструктуры с тонкими клиентами. Под термином "тонкий клиент" мы понимаем подход, при котором основная часть бизнес-логики скрывается от ее конечного потребителя, который обладает минимальной функциональностью, необходимой для использования предоставляемых сервисов. Этот потребитель и называется тонким клиентом. Однако, еще более важным является то, что системы, построенные с помощью такого подхода являются легко расширяемыми и гибкими. Так как архитектура предлагает открытые, высокоуровневые, крупно-композитные интерфейсы, клиенты могут легко интегрировать свои решения в существующие системы.
3.2. Преимущества применения SOA для проектирования банковских информационных систем
С точки зрения банковских информационных систем достоинства SOA проявляются в том, что различные части могут быть выделены в общие компоненты, например такие как сервис
расчета цен и встроены в систему. Затем на основе отдельных компонентов могут быть созданы другие системы, инкорпорирующие в себе более сложную логику. В последствии, клиенты могут как использовать готовые сервисы, так и разрабатывать свои или адаптировать существующие.
"Создавая компоненты согласно принципу SOA" - говорит Матс Лиллин-берг (Mats Lillienberg), технический директор Фронт Кэпитал Системс, "мы уверены, что принесем компании как технические, так и бизнес примущества. Системы, спроектированные и построенные на базе SOA могут быстро адаптироваться и масштабироваться чтобы поддерживать постоянно меняющиеся бизнес-процессы используя существующие сервисы, которые согласуются с SOA-моделью".
Такая отличительная особенность как гибкость систем, построенных с использование SOA-подхода позволяет получить ряд существенных преимуществ при проектировании эффективных банковских систем:
• Повторное использование существующих модулей.
Рассмотрим пример. Способы генерации цены для деривативов, основанные на модели Блэка-Сколса и ее разновидностях. Одна и та же модель генерации цены может быть эффективно использована для различных классов инструментов, например, акции, деривати-вы, структурированные продукты и др. При этом помимо использования бизнес-функций однажды разработанных модулей в различных приложениях, при повторном использовании кода повышается его стабильность и эффективность за счет всестороннего тестирования в различных частях системы [2].
• Быстрое создание новых компонентов, оценка рисков и доставка новых продуктов клиентам.
Стремительно развивающийся рынок требует введения новых инструментов, моделей и продуктов. Успевать отвечать тенденциям рынка или даже предвосхищать их является сегодня необходимым условием успешного развития любой компании, в том числе и банков.
• Легкое встраивание и использование проприетарных моделей, в частности, моделей генерации цен и подсчета рисков. В современном мире далеко не все продукты и системы разрабатываются одним поставщиком. Зачастую, для банка более выгодно купить или заказать готовый модуль у стороннего раз-
работчик чем создавать свое решение с нуля.
• Простое и удобное объединение компонентов в комплексные структуры.
•Объединение стратегий с получением результатов онлайн в режиме реального времени
• Прямое и мгновенное исполнение сделок
• Гибкость в изменении различных процессов для удовлетворения специфичных потребностей.
• Простой и удобный доступ к данным для генерирование различной отчетности.
• Более эффективная интеграция с другими участниками рынка и партнерами.
• Улучшенная интеграция данных и обеспечение целостности данных.
3.3. Реализация концепции SOA
С технической точки зрения, SOA по своей сути является набором сервисов, обменивающихся информацией друг с другом. Коммуникация может подразумевать как простую передачу данных, так и координирование какой-либо активности двумя или более сервисами. Для этого необходимо использование некоего третьего сервиса, обеспечивающего соединение. На рис. 1. изображена примитивная схема взаимодействия потребителя и поставщика сервисов в концепции сервисно-ориентированного подхода [3].
Провайдер сервиса, обладая четко заранее определенным интерфейсом, регистрируется с помощью реестра сервисов (иногда называемом репозитори-ем) в каталоге доступных сервисов. Когда потребител. Сервиса необходимо воспользоваться сервисом, предоставляемым провайдером, он делает запрос в реестр и получает так называемый дескриптор провайдера - указатель на конкретного провайдера, предоставляющего необходимый сервис, после чего он может использовать указанный сервис, не обладая знаниями о внутренней реализации провайдера сервиса [4].
В системах, построенных по сервисно-ориентированному принципу важную роль играет низкая связанность компонентов (от англ. loose coupling -низкая связанность). Сервисы проектируются и создаются таким образом, что каждый из них решает конечную ограниченную задачу, не используя никаких предположений относительно внутренней реализации других сервисов, а лишь используя их интерфейсы как средство для решения подзадач своей задачи. Та-
№2, 2010
134
Рис. 1. Схема взаимодействия потребителя и поставщика сервисов в концепции 80Л
кой подход позволяет абстрагировать провайдеров сервисов от их поставщиков, что позволяет изменять внутреннюю реализацию сервисов без изменений (или с минимальными изменениями) в зависимых сервисах.
4. Адаптация существующей ИТ-инфраструктуры для применения 80Л
Применение сервисно-ориентированного подхода, однако, не предполагает полный отказ от использования существующих систем, не отвечающих данной концепции. Многие ИТ-системы банка являются продуктом многолетней эволюции и обеспечивают исполнение ключевых бизнес-процессов, таких как прогнозирование риска или расчет финансовых показателей банка. Хотя для извлечения большей пользы от их применения и может потребоваться их рационализация, документирование и более четкое выделения ключевых концепций, списывать их со счета сегодня не следует - они представляют собой высокую интеллектуальную ценность и, кроме того, в их развитие могут быть вложены значительные средства. Для их эффективной интеграции с новыми системами, построенными на основе сервисно-ориентированного подхода, их ключевые функции должны быть выделены в отдельные сервисы с четко определенными задачами и возможностями повторного использования другими системами. Таким образом, выделяя и разбивая на логиечские части бизнес-логику старых систем, становится возможным их "обертывание" в новую сервисно-ориентированную оболочку. При таком «разумном» подходе издержки на расширение и поддержание работоспособности этих систем могут быть существенно снижены.
Таким образом, сервисно-ориентированный подход является ключевой
технологической концепцией для достижения нужного уровня повторного использования и предотвращения необходимости полной замены существующей ИТ-инфраструктуры банка.
Современный опыт проектирования банковских ИТ-систем показывает, что использование сервисно-ориентированного подхода позволяет получить существенную экономию средств, так как низкая связанность сервисов позволяет снизить затраты на адаптацию системы к новым условиям, увеличить ее гибкость и возможности по расширению. В то же время такая система представляет собой единое целое, интегрируя в себе модули, отвечающие за поддержку бизнес-процессов на всех уровнях фронт-, мидл- и бэк-офиса.
При построении сервисно-ориентированных систем важно выделять сервисы таким образом, чтобы с одной стороны каждый из них представлял собой логически завершенную сущность и решал конечную бизнес-задачу, с другой стороны, сервисов было бы не слишком много, так как в этом случае возрастает сложность их интеграции, увеличиваются временные задержки, связанные с пересылкой сообщений и растет архитектурная сложность системы в целом [5].
5. Заключение
Подводя итоги, стоит отметить, что банковский сектор добивается и поддерживает доходность путем постоянного стремления снижать издержки, гибко изменяться под современные тенденции, в то же время эффективно используя накопленный опыт и избегая лишних рисков. В лидеры выбиваются те организации, которые понимают и эффективно используют конкурентные преимущества, привносимые эффективной организацией внутренних про-
цессов и современной информационной инфраструктуры. Индентификация и повторное использование существующих решений вкупе с грамотным построением новыгх дают банку это самое конкурентное преимущество, а использование сервисно-ориентированного подхода - один из наиболее эффективных способов достичь этого.
Литература
1. Эволюция: через ESB к SOA. URL: http://www-01.ibm.com/software/ru/ success/soa/ (дата обращения: 15.03.2010)
2. Service Oriented Architecture in investment banking, Mahesh Sunderaraman. URL: http:// www.websesame.co.uk/wp9.pdf (дата обращения: 17.03.2010)
3. The Central Role of Registries. Managing SOA Metadata, Stefan Tilkov. URL: http://www. innoq.com/blog/st/ presentations/2006/20060921_ The_Central_Role_of_Registries.pdf (дата обращения: 17.03.2010)
4. SOA Benefits, Challenges and Risk Mitigation, Eric Roch. URL: http:// it.toolbox.com/blogs/the-soa-blog/soa-benefits-challenges-and-risk-mitigation-8075 (дата обращения: 15.03.2010)
5. Стандарты электронного обмена данными, Уринцов А.И. URL: http:// www.rus-lib.ru/book/38/men/urinson/ Urincov_35-42.html (дата обращения: 17.03.2010)
References
1. Evolution: through ESB to SOA. URL: http://www-01.ibm.com/software/ru/ success/soa/ (date of access 15.03.2010)
2. Service Oriented Architecture in investment banking, Mahesh Sunderaraman. URL: http:// www.websesame.co.uk/wp9.pdf (date of access 17.03.2010)
3. The Central Role of Registries. Managing SOA Metadata, Stefan Tilkov. URL: http://www. innoq.com/blog/st/ presentations/2006/20060921_ The_Central_Role_of_Registries.pdf (date of access 17.03.2010)
4. SOA Benefits, Challenges and Risk Mitigation, Eric Roch. URL: http:// it.toolbox.com/blogs/the-soa-blog/soa-benefits-challenges-and-risk-mitigation-8075 (date of access 15.03.2010)
5. Standards of electronic data interchange, Urintsov A.I. URL: http:// www.rus-lib.ru/book/38/men/urinson/ Urincov_35-42.html (date of access 17.03.2010)
