Захаров Д.Л. Сентябрь 2013 Возможна ли альтернатива «референсной» схеме? ООО «ЛУКОЙЛ-ИНФОРМ»

Пример «удачного» проекта BPM Автоматизация кредитной деятельности в банке «Х» Присутствуют явно выраженные хорошо формализованные БП (принятие решения по кредитованию) Характерна большая повторяемость БП (исполняется часто) Привлечен мощный подрядчик (у проекта солидный бюджет) Подрядчик внедрил инфраструктуру SOA от серьёзного поставщика. Подрядчик написал несколько сотен сервисов SOA Подрядчик дописал «сверху» ещё собственную интегрирующую среду В процессе реализации проекта, было достигнуто повторное использование сервисов (!) Вся система отдана подрядчику практически в полный аутсорсинг

Пример «неудачного» проекта BPM Попытка использования BPM для решения текущих вопросов автоматизации на предприятии «Y» Развернуто достаточно много больших приложений от очень «уважаемых» поставщиков. Поставщика – монополиста нет. Присутствуют серьёзные проблемы интеграции. Хотя инфраструктура SOA, практически, развернута. (Есть USB. У приложений есть сервисные интерфейсы или для них написаны «врапперы») При попытке применить BPM выясняется, что сервисы реализованы «не те и не так» - не в интересах построения композитного BPM приложения. Переделывать - нет возможности и нет бюджета Самих БП слишком много, а выполняются они достаточно редко Вывод: BPM это «малопригодная игрушка»

Одинаковы ли бизнес процессы? S1 S2S3 S1 S2 S3 S5 S4 Высоко формализованный БП Слабо формализованный БП

«Референсная» модель BPM BPEL script Service Bus BPEL Interpreter WS1 T2 WS2 T3 WS3 WS4 WS5

Стоит ли всегда «скрывать» СУБД? A2A1 WS1 WS2 T3 WS3 T1 T2

Обе ли архитектуры «сервисные»? SOA infrastructure A subsystem B subsystem SOA infrastructure soap B subsystem soap A subsystem

Что такое «хорошо»… SOA infrastructure Application 1 Application 2

…и что такое «плохо»! Vendor`s «A» proprietary system Vendor`s «B» proprietary system Vendor`s «C» integration solution X2 XX Accounting function Synchronization and error handling X1

Ради чего «ломаются копья»?

Всё дело только в сервисах? Portal Composite аpp BPM Service Web server Application server Database server

«Сервисные модули» - request for comments Composite GUI (BPM+) Composite app BPM Service Terminal server Application server Database server Service modules

Финальная «ложка дегтя» При последовательном применении предлагаемой архитектуры происходит заметное увеличение трудоемкости создания информационных систем (приложений), связанное с необходимостью производить их декомпозицию на сервисы. Создание полноценного интерфейса пользователя на модульной основе не проработано и не имеет стандартизованного решения Необходима реализация единой системы управления безопасностью Потенциальные преимущества применения концепции BPM&SOA на основе «сервисных модулей» уравновешиваются в настоящее время существованием ряда рисков: …но эти препятствия не выглядят непреодолимыми

Заключение о «сервисном апоптозе» Сервисы, действительно, должны быть «легковесными», чтобы их замена не была катастрофически затратной Сервисы, действительно, должны быть «слабосвязанными», чтобы их замена или пауза в функционировании не приводили к коллапсу всей системы И, кроме того, сервисы должны иметь публичные интерфейсы, чтобы их замена была просто возможной Отмирание ненужных (устаревших, переставших быть актуальными, неудачно реализованных) сервисов является (подобно клеточному апоптозу) важнейшим условием успешной эволюции сложной информационной системы: …что не является большой новостью, но о чем стоит напомнить ещё один раз

СПАСИБО ЗА ВНИМАНИЕ