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

Возможна ли альтернатива «референсной» схеме?
ООО «ЛУКОЙЛ-ИНФОРМ»
Захаров Д.Л. Сентябрь 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 на
основе «сервисных модулей» уравновешиваются в настоящее время
существованием ряда рисков:



При последовательном применении предлагаемой
архитектуры происходит заметное увеличение
трудоемкости создания информационных систем
(приложений), связанное с необходимостью
производить их декомпозицию на сервисы.
Создание полноценного интерфейса пользователя
на модульной основе не проработано и не имеет
стандартизованного решения
Необходима реализация единой системы управления
безопасностью
…но эти препятствия не выглядят непреодолимыми
Заключение о «сервисном апоптозе»
Отмирание ненужных (устаревших, переставших быть актуальными,
неудачно реализованных) сервисов является (подобно клеточному
апоптозу) важнейшим условием успешной эволюции сложной
информационной системы:



Сервисы, действительно, должны быть
«легковесными», чтобы их замена не была
катастрофически затратной
Сервисы, действительно, должны быть
«слабосвязанными», чтобы их замена или пауза в
функционировании не приводили к коллапсу всей
системы
И, кроме того, сервисы должны иметь публичные
интерфейсы, чтобы их замена была просто возможной
…что не является большой новостью, но о чем стоит
напомнить ещё один раз
СПАСИБО ЗА ВНИМАНИЕ