Возможна ли альтернатива «референсной» схеме? ООО «ЛУКОЙЛ-ИНФОРМ» Захаров Д.Л. Сентябрь 2013 Пример «удачного» проекта BPM Автоматизация кредитной деятельности в банке «Х» Присутствуют явно выраженные хорошо формализованные БП (принятие решения по кредитованию) Характерна большая повторяемость БП (исполняется часто) Привлечен мощный подрядчик (у проекта солидный бюджет) Подрядчик внедрил инфраструктуру SOA от серьёзного поставщика. Подрядчик написал несколько сотен сервисов SOA Подрядчик дописал «сверху» ещё собственную интегрирующую среду В процессе реализации проекта, было достигнуто повторное использование сервисов (!) Вся система отдана подрядчику практически в полный аутсорсинг Пример «неудачного» проекта BPM Попытка использования BPM для решения текущих вопросов автоматизации на предприятии «Y» Развернуто достаточно много больших приложений от очень «уважаемых» поставщиков. Поставщика – монополиста нет. Присутствуют серьёзные проблемы интеграции. Хотя инфраструктура SOA, практически, развернута. (Есть USB. У приложений есть сервисные интерфейсы или для них написаны «врапперы») При попытке применить BPM выясняется, что сервисы реализованы «не те и не так» - не в интересах построения композитного BPM приложения. Переделывать - нет возможности и нет бюджета Самих БП слишком много, а выполняются они достаточно редко Вывод: BPM это «малопригодная игрушка» Одинаковы ли бизнес процессы? S1 S2 S3 Высоко формализованный БП S2 S1 S4 S5 S3 Слабо формализованный БП «Референсная» модель BPM BPEL script BPEL Interpreter Service Bus WS1 WS4 WS2 WS5 T2 WS3 T3 Стоит ли всегда «скрывать» СУБД? A1 A2 WS2 WS1 WS3 T3 T1 T2 Обе ли архитектуры «сервисные»? SOA infrastructure A subsystem soap soap A subsystem soap SOA infrastructure soap soap B subsystem soap B subsystem Что такое «хорошо»… SOA infrastructure Application 2 Application 1 …и что такое «плохо»! Synchronization and error handling Vendor`s «C» integration solution XX Accounting function Accounting function X1 Vendor`s «A» proprietary system X2 Vendor`s «B» proprietary system Ради чего «ломаются копья»? Всё дело только в сервисах? Composite аpp BPM Service Portal Web server Application server Database server «Сервисные модули» - request for comments Composite app BPM Service Service modules Application server Composite GUI (BPM+) Terminal server Database server Финальная «ложка дегтя» Потенциальные преимущества применения концепции BPM&SOA на основе «сервисных модулей» уравновешиваются в настоящее время существованием ряда рисков: При последовательном применении предлагаемой архитектуры происходит заметное увеличение трудоемкости создания информационных систем (приложений), связанное с необходимостью производить их декомпозицию на сервисы. Создание полноценного интерфейса пользователя на модульной основе не проработано и не имеет стандартизованного решения Необходима реализация единой системы управления безопасностью …но эти препятствия не выглядят непреодолимыми Заключение о «сервисном апоптозе» Отмирание ненужных (устаревших, переставших быть актуальными, неудачно реализованных) сервисов является (подобно клеточному апоптозу) важнейшим условием успешной эволюции сложной информационной системы: Сервисы, действительно, должны быть «легковесными», чтобы их замена не была катастрофически затратной Сервисы, действительно, должны быть «слабосвязанными», чтобы их замена или пауза в функционировании не приводили к коллапсу всей системы И, кроме того, сервисы должны иметь публичные интерфейсы, чтобы их замена была просто возможной …что не является большой новостью, но о чем стоит напомнить ещё один раз СПАСИБО ЗА ВНИМАНИЕ