|
|||||||||
|
|||||||||
Литература: Лопатин В.А., заместитель начальника Департамента международных расчетов Дирекции расчетного обслуживания Внешэкономбанка.1 Проблемы интеграции и адаптации информационной системы банкаКак известно, практически любая информационная система банка представляет собой большое количество разнообразных компьютерных программ, приобретенных у сторонних производителей или разработанных собственными силами. Такое положение вещей обусловлено рядом причин, среди которых можно выделить:
Как правило, на этапе становления, банк ограничивается покупкой некоторой АБС стороннего производителя (ограничиваясь базовым набором модулей), а также установкой программ для обеспечения расчетов по корреспондентским счетам и выполнения требований регулирующих органов. По мере развития банка, идет наращивание функционала за счет установки дополнительных модулей АБС, покупки иного программного обеспечения и разработки программного обеспечения своими силами. В дополнение к АБС банки, как правило, устанавливают аналитическую систему, систему «Клиент-Банк», CRM-систему (Customer relationship management – управление взаимоотношениями с клиентами), систему управления знаниями и т.д. В последнее время появилась тенденция устанавливать еще и ERP-систему (Enterprise Resource Planning – планирование ресурсов предприятия). Все это неизбежно приводит к существенной неоднородности информационной системы банка. Фактически, информационная система любого банка представляет собой «лоскутное одеяло», причем, чем крупнее банк и длиннее история его развития, тем выше уровень дефрагментации его информационной системы. Особенно высок уровень дефрагментации информационной системы в банках, переживших слияние или поглощение. Вновь образовавшийся банк получает в наследство две неоднородные информационные системы и в течении длительного времени вынужден поддерживать функционирование многочисленных единиц программного обеспечения, одновременно увеличивая уровень дефрагментации за счет спешной разработки и внедрения дополнительного программного обеспечения для стыковки разнородных систем. Другой источник дефрагментации связан с постоянной работой банков по улучшению своих бизнес-процессов. В результате, банки вынуждены отклоняться от референтных моделей бизнес-процессов, жестко запрограммированных в АБС, CRM, ERP и т.д., что требует разработки разработки/приобретения дополнительных модулей для автоматизации перепроектированных бизнес-процессов. В связи с неоднородностью информационной системы, появляется достаточно много проблем, требующих постоянного отслеживания и решения: проблемы сопровождения сложной IT-инфраструктуры, проблемы управления конфигурацией, проблемы обучения и переобучения кадров и т.д. Но главной проблемой является экспорт/импорт данных между различными единицами программного обеспечения, который далеко не всегда осуществляется в автоматическом режиме. Учитывая, что в случае наличия N единиц программного обеспечения необходимо обслуживать, как правило, N-1 связей (стыковка всех систем с АБС), актуальность данной проблемы растет одновременно с развитием информационной системы2. Другой существенной проблемой, связанной с неоднородностью информационной системы, является проблема мониторинга бизнес-процессов. Естественно, в пределах одной системы (например, АБС) обеспечить мониторинг бизнес-деятельности на уровне экземпляров бизнес-процессов достаточно просто (если такой функционал предусмотрен в АБС). Но уже для бизнес-процессов, в рамках которых используется несколько систем, мониторинг, как правило, затруднен в связи с вышеуказанной проблемой экспорта/импорта данных. Как упоминалось выше, несмотря на дефрагментацию, неоднородная информационная система не обеспечивает необходимую гибкость для целей непрерывного совершенствования или реинжиниринга бизнес-процессов. Операции в рамках АБС, CRM, ERP и т.д. характеризуются «жесткими» связями, заданными референтными моделями бизнес-процессов3 и используемыми системами управления данными (как правило, на основе реляционных баз данных)4. Тем самым, при изменении стратегии банка, практически всегда требуются значительные инвестиции для доработки информационной системы в связи с автоматизацией перепроектированных бизнес-процессов (что еще больше увеличивает уровень ее дефрагментации). Учитывая, что одной из особенностью современного рынка банковских услуг является быстрое изменение среды функционирования банков (внешней и внутренней), информационная система с «жесткими» связями создает значительную проблему – проблему адаптации информационной системы к изменениям бизнес-процессов банка. При этом, отсутствие механизмов адаптации естественным образом приводит к отсутствию механизмов автоматического совершенствования бизнес-процессов. Потребность в интеграция и адаптации при автоматизации расчетов и операционной работы банкаВ наибольшей степени изложенная выше проблематика характерна для автоматизации расчетов и операционной работы банка. Технология расчетных операций банков, как правило, включает использование большого количества разнородных компьютерных программ, в числе которых могут быть:
В контексте общей проблематики, изложенной выше, основные проблемы автоматизации расчетов и операционной работы банка можно сформулировать следующим образом:
На решение перечисленных проблем, банки, как правило, направляют огромные ресурсы, однако до последнего времени эффективность таких усилий обычно оказывалась крайне низкой в силу отсутствия подходящих технологий решения проблем. Однако, в связи с появлением технологий SOA (Service-Oriented Architecture) и BPM5 (Business Process Management6), ситуация стала более обнадеживающая. И опыт первопроходцев7 показывает, что данные технологии имеют большие перспективы в банковском секторе России. Интеграция на основе технологии SOAВ наиболее общем виде, сервис-ориентированная архитектура8 (СОА или SOA) не является архитектурой в буквальном смысле этого слова (то есть, не является метаязыком для описания структуры информационной системы9), а определяется как «модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами»10. Так как любой сервис подразумевает наличие провайдера и потребителя сервиса, схематично концепцию SOA можно представить в виде схемы (Рис.1), включающей:
Рис. 1. Обобщенная схема SOA Однако, общий подход к определению SOA встречается редко, а для практических целей рассматриваются некоторые варианты SOA, которые включают дополнительные требования и соглашения. Процитируем несколько определений SOA, которые можно найти в литературе [1]:
Естественно, добавление каждого нового требования или соглашения сужает содержание SOA. Например, добавление соглашения об использовании только сервисов, созданных на основе Web-сервисов, исключает из рассмотрения SOA, сервисы которых реализованы на основе других технологий. Отметим два важных элемента SOA, которые отмечают большинство авторов:
Интеграционные возможности SOA непосредственно следуют из общей схемы, приведенной выше. Как известно, значение термина «интеграция» включает два аспекта:
В случае SOA, объединение элементов IT-структуры в целое осуществляется за счет использования сервисной идеологии и создания единого каталога сервисов. А процесс взаимного сближения и образования взаимосвязей основан на использовании стандартов при создании интерфейсов сервисов, методов публикации и поиска сервисов в каталогах, а также реализации сервисов в процессе соединения провайдеров с потребителями. Конкретные реализации SOA могут использовать различные варианты программного обеспечения среднего уровня14 (middleware): MOM (Message Oriented Middleware), интеграционные брокеры, серверы приложений и др. В настоящее время, наиболее перспективным решением, по-видимому, является решение на основе ESB (Enterprise Service Bus) – сервисной шины предприятия: появившись позже вышеперечисленных технологий, в нем были учтены многие ошибки и использованы многие перспективные элементы предыдущих технологий интеграции. Реализация SOA на основе ESBВ общем виде «сервисная шина предприятия – это основанная на стандартах интеграционная платформа, объединяющая обмен сообщениями, Web-сервисы, преобразование данных и интеллектуальную маршрутизацию» [2]. Данное определение необходимо дополнить такими отличительными чертами ESB, как:
Сразу необходимо отметить, что хотя Web-сервисы являются неотъемлемой частью архитектуры ESB, интеграция уже имеющихся или предполагаемых к приобретению приложений необязательно должна подразумевать их перекодировку в Web-сервисы. Обеспечение связанности указанных приложений в рамках ESB достигается путем использования подходящих протоколов, унаследованной среды обмена сообщениями, адаптеров приложений и т.д. (при интеграции старых приложений в рамках SOA обычно говорят об «обертывании» - wrapping – приложений в Web-сервисы16). При этом, важным является то, что ESB обеспечивает защиту инвестиций, сделанных в интеграцию ранее: интегрированные кластеры приложений (например, с помощью интеграционного брокера) могут подключаться к ESB как единое целое. Рассмотрим интеграционные возможности ESB на примере простейшей информационной системы, обеспечивающей расчеты и операционную работу головного офиса банка и двух его филиалов (в данном примере ИС филиала состоит из АБС, CRM и ПО НОСТРО, а головного офиса - из АБС, CRM, ПО НОСТРО и ERP). Легко заметить (Рис.2), что в данной ситуации интеграция информационной системы обеспечивается за счет многочисленных связей между единицами программного обеспечения (с использованием разнообразных протоколов обмена информации). Рис. 2. Схема ИС до внедрения ESB Как правило, приведенная схема интеграции реализуется с помощью методов извлечения, преобразования и загрузки ETL (Extract, Transform and Load) и ночной пакетной обработки данных, что является источником стандартных проблем автоматизации расчетных операций, перечисленных выше. В случае внедрения ESB (Рис.3), схема ИС существенно изменится. Все приложения через адаптеры будут соединены с локальными участками ESB, которые в свою очередь, будут соединены между собой защищенными соединениями, основанными на надежном обмене сообщениями. Рис. 3. Схема ИС после внедрения ESB Учитывая, что ESB включает в себя развитую инфраструктуру обмена сообщениями, преобразования данных и интеллектуальной маршрутизации, внедрение ESB позволяет реализовать полноценную интеграцию приложений, обеспечить обработку данных в реальном времени, обеспечить возможность мониторинга бизнес-активности на уровне отдельных экземпляров бизнес-процессов и т.д. Кроме того, необходимо отметить, что на этапе интеграции приложений в рамках ESB, из любого приложения может быть выделено несколько сервисов (точнее, столько, сколько необходимо или сколько позволяет приложение), доступ к которым будет осуществляться индивидуально. Тем самым, будут заложены не только основы для многократного использования функциональности приложений, но и основы для внедрения BPM-технологий, речь о которых пойдет в следующем разделе. Адаптация к изменениям на основе технологии BPMТак как неотъемлемой особенностью SOA (в частности, ESB) является слабая связанность сервисов и возможность практически неограниченного наращивания количества сервисов (в том числе, сложных сервисов, использующих другие сервисы как компоненты), появляется возможность достаточно просто осуществлять автоматизацию перепроектированных бизнес-процессов. Полноценная возможность использования SOA для целей адаптации и совершенствования бизнес-процессов появилась в результате развития BPM-технологий и создания так называемых BPM-систем или BPMS. Современная BPMS как минимум должна включать пять компонент:
Кроме того, в BPMS могут включаться такие компоненты, как:
Потенциально, BPMS может обеспечивать [3]:
В случае расчетных операций, фактически, речь идет о потенциальной возможности автоматизации бизнес-процессов силами бизнес-аналитиков, разрабатывающих технологию расчетных операций. После внедрения подходящей BPMS, они смогут моделировать бизнес-процессы в BPD-среде (исходя из каталога имеющихся сервисов) с последующим запуском (одним нажатием клавиши) необходимого числа экземпляров бизнес-процессов на выполнение в BPE-среде. При этом, BPMS самостоятельно (или с участием того же бизнес-аналитика) осуществит мониторинг выполнения всех экземпляров бизнес-процессов, выявит (с использованием BI-системы) дефекты бизнес-процессов и предложит (или осуществит самостоятельно) необходимую корректировку бизнес-процессов. В настоящее время рынок BPMS активно развивается и растет, причем лидерами рынка «чистых» BPMS по данным Gartner являются относительно небольшие компании, такие, как Pegasystems, Savvion, Lombardi, Tibco, Metastorm и Global 360. Однако уже сейчас наметилось движение рынка в сторону платформ бизнес-процессов BPP (Business Process Platform)17, которые фактически представляют собой связку SOA и BPMS. А здесь уже основными игроками являются SAP (NetWeaver Platform), IBM (IBM WebSphere Platform) и Oracle (WebLogic Application Server Platform)18. Литература[1] Норберт Биберштейн, Синджей Боуз, Марк Фиаммант, Кейт Джонс, Роун Ша. Компас в мире сервис-ориентированной архитектуры (SOA). М.: Кудиц-пресс, 2007. [2] Дэвид А. Шаппел. ESB – сервисная шина предприятия. С-Пб.: БХВ-Петербург, 2008. [3] James F. Chang. Business Process Management Systems. New York: Auerbach Publications, Taylor&Francis Group, 2006. Примечания1 При написании статьи использованы материалы лекции «Автоматизация бизнес-процессов», прочитанной автором в Банковском институте ГУ – ВШЭ в рамках курса «Управление бизнес-процессами в компании». 2 Максимальное количество связей, которые потенциально могут поддерживаться между N единицами ПО в режиме «каждый с каждым» будет N(N-1)/2. 3 Обычно АБС и ERP системы разрабатываются на основе некоторых референтных моделей бизнес-процессов, которые, в свою очередь, строятся на основе «лучших практик» (best practice). При этом современные АБС и ERP системы включают инструментарий, позволяющий изменять в определенных пределах встроенные референтные модели. Однако, при существенном изменении бизнес-процессов, гибкости инструментария для настройки моделей обычно не хватает. 4 Изменение структуры любой записи реляционной базы данных (добавление/сокращение количества полей или изменение формата полей) немедленно тянет за собой необходимость внесения изменений во все единицы кода, связанные с данной записью, причем изменение одних единиц кода влечет за собой необходимость внесения изменений в другие единицы кода и т.д. Без развитой системы управления конфигурацией, даже простое изменение формата одного поля одной записи может превратиться в серьезную проблему. 5 Аббревиатура BPM может обозначать не только Business Process Management, но и Business Performance Management (управление эффективностью бизнеса), а также Business Process Modeling (моделирование бизнес-процессов). Конкретное значение аббревиатуры обычно ясно из контекста. 6 В данном случае, термин Business Process Management обозначает IT-технологию, что необходимо отличать от другого его значения – управления бизнес-процессами, как дисциплины менеджмента. При этом BPM как IT-технологию часто обозначают BPMS (Business Process Management System). 7 См. например: Дарья Тренина. Банки осваивают SOA. Neoflex, 08.05.2008, http://www.mskit.ru/news/n48706. Или Дмитрий Назипов, ВТБ: Нормально организованные процессы в банке важнее самых развитых ИТ. Intelligent Enterprise, №2 (178), 11 февраля 2008 года. 8 В настоящее время в литературе примерно одинаково часто можно встретить перевод SOA как «сервис-ориентированная архитектура», так и «сервисно-ориентированная архитектура». 9 Глеб Галкин. Архитектура как метаязык. Intelligent Enterprise, № 4 (180), 10 марта 2008 года. 10 Википедия, http://ru.wikipedia.org 11 Simple Object Access Protocol – протокол обмена структурированными сообщениями в распределённой вычислительной среде (первоначальное значение – простой протокол доступа к объектам). 12 Web Services Description Language – язык описания Web-сервисов, основанный на языке XML. 13 Universal Description Discovery & Integration — инструмент для расположения описаний Web-сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы. 14 Необходимо отметить, что некоторые решения на основе MOM, интеграционных брокеров и серверов приложений иногда относят не к SOA, а к EAI (Enterprise Application Integration). 15 Построение в виде распределенной сети отличает ESB от интеграционных брокеров, построенных в топологии типа «звезда». 16 Наталья Дубова. На пути к SOA. Открытые системы, 29.08.2005. www.osp.ru/cio/2005/08/379555. 17 Игорь Костылев. Смерть BPMS или о новой «зонтичной» концепции. Intelligent Enterprise, №4 (180), 10 марта 2008 года. 18 После поглощения компании BEA, в платформу Oracle включены компоненты платформы BEA WebLogic. Комментарии |
|||||||||
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | |||||||||
|