Что останется после ACM и BPMS?

Интерес к системам Business Process Management не может всегда оставаться на высоком уровне. Про термин adaptive case management через пару лет, вообще, никто не вспомнит. ACM и BPM освободят место новым трехбуквенным сокращениям, оставив после себя некоторое количество информационных систем. Хочется надеяться, что унаследованные приложения будут хоть в каком-то виде вписываться в новый корпоративный ИТ-ландшафт. Поэтому, есть смысл уже сейчас смотреть на те компоненты, которые присутствуют в системах обоих типов.

Очевидно, что таким компонентом является пользовательское приложения для работы с задачами. (В Oracle SOA Suite это называется Worklist application, у других производителей более распространено название Human Task) Недавно в обзоре блогов, посвященных тематике BPM, Adam Deane обратил внимание на сообщение Upside down Procedures and Processes в котором Michael J. Cunningham призывает нас начинать не с процессов, а с выполняемых пользователями задач. Подход более чем разумный. Конечному пользователю не очень интересно как устроен наш workflow движок. Для работы ему необходим список задач, экранные формы, специфичные для каждого типа задач и кнопки, позволяющие этими задачами управлять.

Идея разделения процессного движка и приложения, с которым работают пользователи, была четко сформулирована еще в спецификациях BPEL4People WS HumanTask (год назад эти спецификации обновились)

Architectural Impact of WS-HumanTask on Workflow Management Systems

Наиболее интересные аспекты данной спецификации:

  1. Декомпозиция задачи на подзадачи может осуществляться как на основании описания задачи, так и в ходе выполнения.
  2. Определены механизмы назначения исполнителей на основании имен ролей и сотрудников, логических групп пользователей, а так же с использованием вычисляемых выражений.
  3. Описан Task Rendering. Механизм построения пользовательских интерфейсов для отображения задач, шаблонов уведомлений и т.п.
  4. Введено понятие Lean Task. Возможность создавать задачи вне контекста сложных бизнес-процессов. Примером такой задачи является запись из to-do list. Причем для пользователя lean task представляются так же, как и задачи из сложных процессов.
  5. Разделение данных экземпляра задачи на презентационные данные, конекст (статус, приоритет и т.п.) и оперативные данные, относящиеся к этой задаче
  6. Ad-hoc attachments и комментарии. Определен порядок присоединения дополнительных данных или гиперссылок на такие данные и комментарием пользователей
  7. Шаблоны маршрутизации задач и условия завершения
  8. Перехват задач по истечению тайм-аута и эскалация
  9. Порядок протоколирования операций (task history) и нотификации внешних систем
  10. Простые API ко всему этому, типа: getTaskHistory()

Одним словом, во-первых, велосипед уже давно изобретен, а во-вторых, в определенном виде уже реализован. Даже open-source пытается ввязаться в эту игру. Как это выглядит в OpenESB я писал в сообщении Glassfish ESB v2.2

Еще одна попытка реализации предпринята Apache HISE (Human Interactions Service Engine)


У Oracle и IBM все это выглядит несколько более зрелым. Однако, лукавство в том, что флагманские BPMS и {Dynamic | Adaptive | Advances} Case Management решения этих компаний построены с использованием совершенно других компонент. Поэтому, сейчас покупать бы я их не стал. Тем более, что на горизонте появилась волна, именуемая Digital Workplace, которая вероятно и поглотит задачу управления списком работ сотрудника компании. Worklist приложения просто встроят в корпоративный интранет портал. Ну а телеком в этой задаче, как всегда, пойдет своей дорогой, именуемой системы Work Ordering.

Реклама

4 responses to “Что останется после ACM и BPMS?

    • Максим Смирнов

      Да, Intalio — конечно. Слежу за ними несколько лет — с функционалом и здравым смыслом у intalio всегда было все ОК. Чтоб в них поверить очень хочу увидеть своими глазами хотя бы один крупный reference в телекоме.

      • Слава

        http://www.intalio.com/customers — список впечатляет, хотя конечно явно не говорят, где были инсталляции именно BPMS:)

        По своему опыту (около-телеком проекты ISP, Биллинги и т.п.), при наличии инфраструктуры сервисов, Intalio вполне себе работает — мы проводили продолжительные, нагрузочные тесты с 10к достаточно сложных long-running process instance OM (в связке с http://wso2.org/library/brs и ESB оттуда же), в которых каждые несколько минут происходили какие-то вызовы/срабатывали таймеры и т.п. — конечно, нужно тюнить политики гидрации/дегидрации экземпляров процессов в БД, иначе узким местом будет именно она или сеть. Но в целом всё решаемо, если с умом подходить и понимать, что не нужно делать слишком часто срабатывающие события в процессе, использовать компенсации, а также каким-то «не очевидным» образом решить проблему миграции экземпляров между версиями процессов — для наших задач с long-running это было критично. Другой проблемой были ограничения на доступные возможности BPMN (вроде inter-process событий и т.п.), которые в первую очередь следуют из-за ограничений Apache ODE BPEL, на котором строится сам BPMS — можно утверждать, что исключительно в IDE Intalio у вас вряд ли получится построить сложный процесс — всёравно придётся заглядывать в исходник BPEL:). На мой взгляд, ещё один недостаток Intalio в отсутствии native-интеграции с какой-то ESB — это бы сильно упростила для аналитика разработку и отладку в IDE: при необходимости можно было бы достаточно просто создавать mock-сервисов и т.п. (особенно, если использовать process-driven подход).

        В итоге, у нас был разработан некий прототип grid-кластера из серверов BPMS работающий по принципу memcached (вроде распределения инстансов по пулу серверов на основе хэша correlationID). А дальше мы пока остановились в силу не технических причин… — по-прежнему используем для подобных проектов (см. начало) JBoss jBPM/Drools:).

        p.s. насколько слышал, сейчас пытаются Intalio|BPMS интегрировать как-то нативно с jBilling — на выходе может получиться более менее монолитный открытый движок обслуживания заказов.

  • maxxannik

    Большая часть указанных особенностей свойственна Мегаплану

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s