| Все о системах управления |  |
| Почитать |
| Поговорить |
| Побродить |
| Завершить |
|
|
||||
|
Не ставьте знак равенства между BPM и BPEL
|
|||||
По общему мнению, BPEL и BPMN – два наиболее перспективных стандарта в области BPM.
Что касается BPEL, то отдельные вендоры столь сильно преуспели в его популяризации, что некоторые стали считать его практически синонимом BPM: говорим BPM, подразумеваем BPEL. Хотя аналитики всегда предупреждали: «beepel is not for people».
С BPMN ситуация менее ангажированная, но и тут не обходится без завышенных ожиданий: реализация этого стандарта в движках существующих BPMS пока далека от полноты.
За последнюю пару недель появилось сразу несколько интересных статей авторитетных авторов, без прикрас рассматривающих возможности BPMN и BPEL:
Why BPEL is not the holy grail for BPM, Pierre Vigneras.
Автор констатирует, что даже сторонники BPEL признают, что он с трудом воспринимается бизнес-пользователями, BPMN в этом отношении явно предпочтительнее.
В поисках фундаментальной причины такого положения дел автор указывает, что BPEL по сути является структурированным языком программирования. Со времен Дейкстры и его крестового похода против оператора «go to» всем программистам известно, что это зло. Но беда в том, что реальный мир сложнее компьютерной программы, и бизнес-аналитикам, которые находятся в более тесном контакте с ним, приходится с этим считаться. В частности, у них постоянно возникает желание протянуть стрелку «вот отсюда вот туда», что является аналогом оператора «go to» в языках программирования. BPMN это позволяет, а BPEL, вообще говоря, нет.
Если программист продолжает настаивать на своем видении, то это приводит к тому, что программист и бизнес-аналитик оперируют разными артефактами, а в итоге – к драматичному разрыву между бизнесом и ИТ, который сегодня осознан как фундаментальная проблема. И для решения которой, в том числе, собственно и был предложен BPM. Таким образом, логически вытекает, что BPEL не может решить все проблемы BPM.
Отсюда путь, который выбрали несколько вендоров: моделирование в BPMN и автоматическая трансляция в BPEL, рассматриваемый при этом как исполняемый код. В качестве примера такого подхода в статье приводится Intalio BPMS. Однако, после многочисленных попыток, сегодня можно констатировать, что в общем виде эта задача не решается. С одной стороны, приходится ограничивать использование BPMN некоторым подмножеством. А с другой, для многих технических подробностей процесса, относящихся к его исполнению, нет места в BPMN – они должны быть внесены в BPEL. Последний факт делает весьма проблематичным «round-trip» – замкнутый цикл разработки, вовлекающий и аналитика, и разработчика.
Проще говоря, BPMN в BPEL автоматически транслировать можно, но только один раз. После этого у аналитика и программиста на руках оказываются два разных артефакта, и мы снова возвращаемся к тому, от чего хотели уйти.
Why All This Matters, Ismael Ghalimi (Intalio).
Поскольку в первой статье упоминается Intalio в качестве апологета генерации BPEL из BPMN, уместно дать ссылку на статью, в которой Исмаэль Галими делает экскурс в историю появления BPEL и подробно объясняет, чем лично его привлекает BPEL, попутно не слишком лестно отзываясь о вендорах, не разделяющих его пристрастия. Не вдаваясь, впрочем, в проблематику BPMN->BPEL генерации.
BPMN-BPEL in Perspective, BPM Standards in Perspective, Bruce Silver.
В своем отклике Брюс замечает, что и BPMN, и BPEL не идеальны. Но BPMN пользуется успехом несмотря на его недостатки, в то время как недостатки BPEL по факту ограничивают его применение в основном областью интеграции и SOA.
Брюс начинает с того, что оценивает оригинальную статью как «местами интересную», но большей частью «не о том». Однако после этого фактически выступает в поддержку. Он отмечает, что BPMN позволил уйти от представления о диаграмме процесса как об эскизе бизнес-требований и относится к ней как к непосредственно исполняемой (после добавления к ней программистами соответствующих атрибутов). А ведь именно в этом, по мнению Брюса, заключается «выигрышная идея» BPM.
BPMN позволяет, например, вернуться от развилки к некоторому предшествующему шагу, в то время как BPEL накладывает на такие вещи серьезные ограничения. Это означает, что на BPMN можно нарисовать диаграмму, которую нельзя транслировать в BPEL, или по крайней мере, нельзя транслировать обратимым способом, чтобы сделать возможным замкнутый цикл разработки. В основном вендоры решают эту проблему, накладывая ограничения на использование BPMN, одни больше, те что получше – меньше, но в любом случае, что мы получаем в итоге – BPMN или графический дизайнер BPEL? Вердикт рынка по этому вопросу – подобные ограничения затрудняют использование нотации бизнес-пользователями.
Вместе с тем, BPMN проигрывает BPEL в стандартизации семантики. В случае BPEL вы обязаны поддерживать определенный набор требований, чтобы претендовать на совместимость. BPMN же слишком сложно реализовать в полном объеме, а никаких промежуточных уровней совместимости стандарт не определяет. В результате каждый вендор произвольным образом решает что из стандарта поддерживать, а что нет, и это не идет на пользу никому.
В качестве ремарки к заметке Исмаэля Галими Брюс напоминает, что недавно в сторонники непосредственного исполнения BPMN движком записались Oracle и SAP (мы об этом писали), использование BPEL они ограничивают областью SOA/интеграции. Действительно, эти два тяжеловеса способны решить исход спора «за» и «против» BPEL одним фактом своего предпочтения, что называется, не прибегая к аргументам.
BPEL-Grail, Keith Swenson (Fujitsu).
Кейт Свенсон, представляющий еще одного BPM-вендора, делится своим наблюдением, что фанаты BPEL делают три предположения:
- процессы проектируют программисты
- шаги процесса сводятся к отправке, приему или трансформации XML-данных
- любой стандарт лучше отсутствия стандарта
Предположения 1 и 2 истинны применительно к задачам интеграции (EAI). Что касается предположения 3, то при огромном числе журнальных «доказательств» правильности BPEL некоторые начинают считать, что любой, кто не поддерживает BPEL, либо слишком ленив, либо пытается раздробить рынок. На деле же мир процессов сложнее, чем кажется. Не упускайте из виду собственных требований: если BPEL им удовлетворяет – отлично, но не принимайте априори, что он годится везде и всюду.
=АБ
Проблема прямой и обратной трансляции BPMNBPEL бородата, мне также кажется (где-то недавно у вас опубликовано) что в перспективе будет именно исполняемый BPMN, либо конкретные без поддержки стандартов скриптовые языки типа того же SimPEL от Intalio.
Николай, а что, Вы пробовали этот самый SimPEL? И как, стоит тратить на него время?
Мое мнение об этой полемике следующее – надо обсуждать не недостатки других подходов и проталкивать этим свой продукт, а искать общее понимание и согласие того к чему надо всем стремиться. Некоторые моменты идеальной ситуации
1) Наличие стандартов необходимо, но не достаточно.
2) What you model is what you execute – как общепринятое видение дисциплины BPM.
3) BPMN-подобное описание бизнесс процессов, которое интерпретируется ОДИНАКОГО всем ПО. То есть одно описание для разных приложений – тестирования (проверка функционирования), иммитирования (проверка производительности) и исполнения бизнесс процессов. Возможно, что необходим согласованный набор стандартов аналогично HTML (структура и содержание), CSS (интерпретация) и DOM-based API (динамическая модификация).
4) Адаптация описания бизнесс процессов для конкретного потребителя (пользователь видит грубую диаграмму, аналитик – более подробную и т.п.)
5) Возможность работы в рамках одного IDE со многими артефактами (правила, роли, события и т.п.).
6) Явное описание зависимостей между артефактами.
7) Устранение необходимости работы с промежуточными форматами.
В этом случае, вместо round-trip и BPMN vs. BPEL мы будем осуждать соответствие стандарту исполнения BPMN (OMG называет его BPMN execution semantic) и производительность различного ПО. К сожалению, в настоящее время, голос конечного потребителя весьма разобщен и потому не слышен.
Корни вышеупомянутых дебатов уходят в борьбу различных BPM продуктов. Информация для справки.
IBM использует исторически два различных продукта для бизнес-моделирования и для исполнения (BPEL) – необходим round-trip; компании предписывают (т.е. ограничивают) использование этих продуктов, чтобы облегчить обмен между ними.
Oracle (до приобретения BEA) использовал ARIS для моделирования и Fusion для исполнения (BPEL) – для упрощения round-trip планировал создать свой промежуточный формат.
SAP тоже использовал ARIS для моделирования, но решил создать в NetWeaver 7.1 свой продукт, интегрированный с исполнением. Очень похоже на Intalio, но без промежуточного преобразования в BPEL (то есть прямая интерпретация BPMN).
jBPM – все свое, но идельное решение для workflow, встроенного в Java программу.
Bonita+Orchestra (поддержка OW2.org и Bull) – пытаются частично повторить Intalio путем разработки своего IDE для моделирования и Process Virtual Machine для исполнения XPDL и BPEL.
Intalio – использует автоматическую генерацию BPEL из BPMN. Естественно, этим самым предлагается свой вариант BPMN execution semantic. Привлекательность такого подхода в относительной простоте создания и модифицированния исполняемых БП. В простых случаях не нужно изменять программный код.
Я рекомедую использовать этот продукт (есть бесплатная функционирующая версия) для улучшения понимания того, как дисциплина BPM может и должна использоваться в конкретном предприятии. Только после достижения общего понимания “контекста” BPM уже следует производить выбор продукта BPM suite для Ваших нужд. В некоторых случаях – это корпоративная версия Intalio.
Конечно, Intalio тоже не идеален -- использование BPEL как промежуточного языка уже упоминалось. Интергация с human tasks довольно примитивна, что затрудняет декомпозицию процессов. В версии 6 Intalio наконец-то отказался от zero-line coding принципа в пользу фрагментов из интерпретационных языков программирования. Нечто похожее на snippets от продуктов IBM. Вещь полезная, но живьем еще не видел.
Мой основной критерий выбора BPM suite – это насколько легко вносить изменения. Пригласите производителя BPM suite для презентации продукта и попросите внести изменить в демонстрируемый БП. Насколько это просто? Какая требуется квалификация?
Насчет BPEL и BPMN. Оба эти стандарта – типичные представители “Internet” поколения, когда стандартом объявляется предложение рабочей группы по объединению спецификаций от всех участников этой группы. У BPMN было больше “родителей” и соотвественно больше ненужных функций и странностей. Примерно половина форм не нужна, а на остаток надо навести некий порядок использования (execution semantic).
Например, многие ратуют за возможность неструктированно соединять отдельные формы. Если пользователи утверждают , что они так работают, то для меня это сигнал, что что-то неправильно с их процессом. Правильный процесс всегда структирирован – несколько последовательных этапов с определенной гибкостью внутри каждого этапа. Замечено, что владельцы бизнес-процессов не любят “прыжков” назад, так как это делает непредсказуемым время исполнения процесса (т.е. SLA становиться непредсказуемым).
У одного клиента такие “прыжки” назад использовались из-за отсутствия явного понятия “версиy обрабатываемого документа” – мы заменили эти “прыжки” на инциирование нового экземпляра процесса (иногда в параллель к уже существующему) для каждой версии документа. В результате модель процесса существенно упростилась.
Главное эмпирическое правило – диаграмма процесса должны быть понятной всем участника этого процесса. Это лучшая гарантия успешной реализации.
Естественно, в некоторых случаях надо синхронизировать задачи более сложным образом, что “нарушает” структурность диаграммы (пример – диаграмма из первой статьи). В неструктированных процессах можно реализовать такую синхронизацию, но в довольно ограниченном виде и посредством запутанной (а следовательно непригодной для пользователя) диаграммы.
BPMN предлагает использовать дополнительный механизм – события – для такой синхронизации (попробуйте перерисовать в Intalio вышеупомянутую диаграмму без обсуждаемого в первой статье дефекта). Явное использование разных механизмов обычно упрощает диаграмму.
Я специально не говорю про BPEL, так как считаю, что этот язык должен быть скрыт – как, например, PostScript, на котором много лет назад приходилось программировать, а теперь– нет. То есть round-trip должен уйти в прошлое, хотя BPEL может использоваться для исполнения фрагментов БП.
Кто же проектирует процессы? – люди с рациональным, систематическим и критическим складом ума – в чем-то программисты, в чем-то бизнес-аналитики, в чем-то инженеры и в чем-то психологи...
Thanks,
AS
Александр, комментарий настолько развернутый, что слегка придавливает
По поводу целесообразности обсуждения подходов - конечно надо быть позитивными, а не заниматься критиканством. Но как быть если сталкиваешься с массовыми заблуждениями? А в случае с BPEL, боюсь, оно имеет место.
Ценное замечание относительно "прыжков". Согласен, это "анти-паттерн", и повод задуматься - а нельзя ли улучшить схему процесса? Но если выбирать из двух зол меньшее, я бы предпочел пусть такую схему процесса, но сделанную живым бизнес-аналитиком, чем идеальную, но сделанную без его участия. "Жизнь реальна, жизнь сурова" - применительно к процессам, схему реального процесса от демки отличают как раз такие мелкие уродства. Поэтому я убежден, что инструмент обязан поддерживать такие вещи, даже при том что они очевидно не относятся к best practice.
Возвращаясь к теме Intalio - я так и не понял, решена в нем проблема round-trip? Не могу для себя решить, стоит ли тратить на него время, а вопрос о round-trip для меня ключевой.
Спасибо Анатолий, постараюсь по возможности короче.
Лучший метод против заблуждений – это просвещение. “Post tenebras lux” как написано га гербе моего клиента.
Насчет "Жизнь реальна, жизнь сурова" я обычно привожу “Seven clever monkeys effect”. Ученые провели эксперимент – в клетку посадили 7 обезъян, подвесили банан и приставили к нему лестницу; если какая-нибудь обезъяна поднимается по лестнице за бананом, то включается холодный душ для всех. Естественно, все обезъяны достачно быстро усваивают, что за бананом нельзя. Ученые убирают душ – обезъяны строго соблюдают правило. После этого ученые меняют одну из обученных обезъян на новую. Естественно новичок лезет за бананом, а остальные ему сильно препядствуют. После нескольких попыток, новичок усваивает, что за бананом нельзя. Далее меняют еще одну из обученных обезъян на новую. Ситуация повторяется, интересно, что обезъяна, которая не знает причину запрета, настаивает на его исполнении наиболее рьяно. Далее заменяются все обученные обезъяны. В результате все обезъяны следуют запрету, которого уже нет и никто не может объяснить почему. Что и происходит во многих организациях. Задача бизнес-аналитика как раз состоит в том, чтобы докопаться до истинной причины. Lean например рекомендует 4 раза задавать вопрос “почему”. Надо конечно объяснить этот подход заранее, иначе люди начинают обижаться.
В Intalio нет round-trip как такового. BPMN и фрагменты для BPEL поддерживаются в одном и том же IDE. Идея в том, что бизнес-аналитик и разработчик работают совместно перед одним и тем же экраном.
Thanks,
AS