Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
Плюсы и минусы BPMN 2.0

BPMN 2.0: говорят о ней так часто и так много, что уже не все помнят, чем она отличается от версий 1.х. И еще вопрос, стоят ли изменения, которые ожидается увидеть в 2.0, того, чтобы так долго и с такой надеждой их ожидать?

BPMN – это графическая нотация для изображения бизнес-процессов. Задумана она с целью создания единообразных описаний процессов. Однако в первых версиях нотация не была рассчитана на исполнение процессов в BPM-системе, поэтому разработчиков стандарта мало заботило то, каким образом BPMN-схема будет переведена в XML формат. Все инициативы WfMC в этом направлении не находили поддержки со стороны OMG. Но необходимость создания исполняемых моделей процессов вызвала необходимость создания такой нотации, которая поддерживала бы XML формат и была бы одинаково интерпретирована любой, поддерживающей эту нотацию, системой. Статус стандарта вынуждал бы производителей BPM-систем поддерживать эту нотацию. Таким стандартом претендует стать BPMN 2.0.

Однако далеко не все члены BPM сообщества настроены по этому поводу оптимистично. Условно можно выделить несколько групп различного рода специалистов, ожидания которых не одинаковы, о чем пишет в своей заметке BPMN 2.0 – Marriage Made In Heaven or Trough of Disillusionment  Дерек Миерс (Derek Miers), шеф BPM-focus.

«Существуют противоположные лагеря, каждый из которых пытается свернуть спецификацию в своем направлении. Одна группа говорит: «давайте сделаем так, чтобы BPMN отражала потребности BPEL». Другие говорят, что «мы должны сделать BPMN частью UML» (я задаю этот вопрос на каждой конференции… и непременно вижу ужас в глазах). Третьи хотят, чтобы BPMN  лучше поддерживал хореографию (лично я хотел бы увидеть нечто, поддерживающее трансляцию в Role Activity Diagrams, который является более мощным подходом к моделированию взаимодействия ролей, чем то, что я видел на сегодняшний день в BPMN 2.0).»

Франк Пулман (Dr. Frank Puhlmann) выделяет две таких группы («BPMN 2.0 drafts»). Первая, в которую входят IBM, Oracle, SAP, Unisys в качестве инициаторов, а также IDS Scheer, Software AG, TIBCO, Intalio и другие предлагает базироваться строго на предыдущих версиях спецификации. В то время как вторая, к которой Франк относит Axway Software, EDS, Lombardi Software, MEGA International, Troux, Unisys в качестве инициаторов (Unisys и тут и там!) предлагают подогнать нотацию под Business Process Definition Metamodel (BPDM). Сам автор придерживается первого мнения, поскольку во втором случае мы получим набор таблиц и фигур, которые сделают модель нечитаемой.

Рассматривая BPMN 2.0 с позиции первой группы, Франк выделяет несколько областей расширения нотации по сравнению с 1.1.

  • формализация исполнительной семантики для каждого элемента
  • Расширение технических возможностей как для моделирования процессов, так и для графики
  • Уточнение событий объединения и корреляции
  • Расширение определение человеческого взаимодействия
  • Определение хореографию

«Эта спецификация также устраняет имеющиеся в 1.1 противоречия и неясности» (цитата из драфта спецификации)

За границами будущей спецификации остаются такие аспекты как

  • Определение организационных моделей и ресурсов
  • Моделирование функциональных прерываний
  • Модели данных и информации
  • Моделирование стратегии 
  • Модели бизнес-правил (цитата из драфта).

Основным достижением спецификации будет включение XML схемы на основе мета-модели, поддержка хореографии, семантика исполнения, усовершенствованное BPEL-отображение и множество мелких добавлений и исправлений.

Мета-модель, основанная на XML-схеме. Все BPMN элементы описаны в XML, что обеспечивает стандарт мета-модели. Было бы полезно, если бы это было визуализировано.

Хореография. Спецификация вводит третий тип модели – хореографию. Первые два – оркестровка и совместная работа. Хореография – это «определение ожидаемого поведения, по существу, процедурный договор между взаимодействующими участниками. В то время как обычный процесс существует внутри пула, хореография существует между пулами (или участниками)». Проект спецификации определяет ряд правил, по которым могут быть определены задания.

Говоря о хореографии, необходимо упомянуть обмен сообщениями, называемый «conversation», определяемый в BPMN как «набор обменов сообщениями, имеющими одинаковую взаимосвязь». Спецификация определяет несколько видов взаимосвязей (на основе ключей или выражений), тесно связанных с BPEL.

Семантика исполнения. Каждый объект имеет свой жизненный цикл с состояниями, такими как активирован, в работе (исполняется), завершен, выполняется компенсация и т.д. Семантика исполнения – это  описание в табличном виде различных состояний объектов процесса. Кроме того, описание непосредственно указывает на соответствующий шаблон процесса. Единственное, чего не хватает – это формального представления. К примеру, описание OR-Join до сих пор еще очень расплывчато. С другой стороны, неформализованное описание оставляет большую свободу исполнителям.

BPEL-отображение. BPEL-отображение является очень существенным шагом. Однако часть ответственности остается на производителях BPM-систем, поскольку такое отображение накладывает на WS-BPEL процесс определенные ограничения. По крайней мере, он должен соответствовать операционной семантике BPMN процесса.

Другие улучшения. Черновик спецификации содержит еще некоторые улучшения, такие как множественные пулы, маркеры для разных типов заданий, сборники данных, расширение взаимодействий между людьми (исполнителями, владельцами). Спецификация определяет расширенную модель, которая может использоваться для интеграции с другими артефактами.

Появился новый вид события, который  напоминает символ Star Trek и используется для эскалации. Промежуточные события могут быть представлены в виде подпроцессов.

Один из самых авторитетных аналитиков и специалистов в области BPMN, Брюс Силвер, будучи участником команды разработчиков стандарта, консорциума OMG, в своем блоге  часто обращается к этой теме. В заметке «5 Things to Love About BPMN 2.0» он приводит пять основных преимуществ 2.0:

  1. Обмен моделями между разными инструментами. Представляет собой XML-схему для обмена BPMN моделями, как исполняющими, так и не исполняющими инструментами.
  2. Не прерывающиеся события. Самым большим отличием BPMN от традиционных диаграмм всегда была поддержка событий. Событие – это сигнал, что «что-то случилось», и BPMN позволяет сказать, что делать с процессом дальше: запустить новый экземпляр, перенаправить по пути исключения, продолжить остановленное действие, прервать запущенное действие. В простых нотациях невозможно изобразить запуск нового действия или потока внутри процесса без прерывания текущего процесса. BPMN это позволяет.
  3. Пользовательские действия. В BPMN 2.0 есть новый тип событий, называемый эскалация. Эскалация означает сигнал, генерируемый внутри процесса.  Пользователь во время исполнения процесса может инициировать действия, обозначенные в диаграмме, отменить событие или же запустить параллельно другое действие.
  4. Задание - бизнес-правило. Никакой другой аспект PBM не отвечает за такое количество ложной информации, дезинформации и преднамеренное запутывание, как связь между процессом и бизнес-правилами. Это разные вещи, но они должны работать вместе. Основная проблема всегда была в том, что инструменты не позволяют должным образом отобразить бизнес-правила на процессной диаграмме.  BPMN 2.0 предлагает новый тип задания, обозначающий вызов бизнес-правила. Это специальный автоматический шаг. В процессной модели он не требует каких-либо действий. Он только возвращает результат правила, который дальше можно использовать в процессной логике.
  5. Более легкое выполнение событий. Некоторые номинально BPMN-совместимые BPM-системы поддерживают исключения, но не BPMN нотацию для них. Это плохо, поскольку укрепляют уверенность, что работа с исключениями – это уже область ИТ, а не бизнеса. На самом деле это проблема BPM-движков, которые не распознают семантику BPMN. В BPMN 2.0 добавлена специальная конструкция, называемая подпроцессом события. Подпроцесс события запускает подпроцесс в случае возникновения  исключений.

Теперь о том, что не вошло в стандарт. Заметки от того же автора (Брюса Силвера) «Five Things They Left Out of BPMN 2.0».

  1. Различие между информацией, связанной с моделью, и информацией, связанной с исполнением. BPMN 2.0 слишком ориентирован на исполняемые модели и слабо поддерживает информационные элементы, которые могут быть использованы в неисполняемых моделях.
  2. Семантика неисполняемых моделей. Не удалось избавить модель от таких специфических данных, как WSDL-ссылки и интерфейсы к данным. В семантике BPMN центральную роль играет движок оркестровки не зависимо от того, есть он или нет. BPMN, в сущности, предполагает одинаковую семантику для исполняемых и для неисполняемых моделей.  К примеру, сплошная стрелка означает на практике последовательную передачу управления. Т.е. действие А закончилось и немедленно начинается действие В. А как показать, что действие В происходит не сразу или В стартует после запуска А, но не сразу после его завершения? Как показать, что между А и В существует что-то еще? Сейчас такие действия можно изобразить при помощи каких-то дополнительных флагов, т.е. нестандартным образом.
  3. Переносимость модели. Модель, созданная в инструменте Х, должна открываться в инструменте Y. А это означает, что любой инструмент должен поддерживать BPMN. Но сейчас BPMN используется как нотация для диаграмм, а не как язык исполнения. И с появлением BPMN 2.0 это вряд ли изменится. По мнению Силвера члены команды разработчиков стандарта сами не уверены, насколько их собственный инструмент будет совместим с 2.0 релизом.
  4. Графический обмен. Силвер поясняет, что когда он говорит о графическом обмене, он имеет в виду такие инструменты как Appian, Lombardi, Savvion, TIBCO, and ITP Commerce. Вместо этого разработчики стандарта стремятся сделать его интегрируемым с такими инструментами, как Eclipse GMF или какую-то смесь UML и BPMN фигур и другими концептуальными вещами, которые далеки от кому в действительности нужен моделлер. Специфическая BPMN информация, такая как размеры, позиции, пулы и дорожки, действия, ветвления или события даже не определены XML схемой, только тем, что называется М1 библиотекой. Т.е. это может быть дружественно UML, но не дружественно XML. В этом случае основные потребители BPMN-спецификации ее попросту не примут.
  5. Свойства имитационного моделирования. Большинство инструментов имитационного моделирования основываются на параметрах, полученных от действий, исполнителей, ветвлений, событий. Стандартизация таких параметров была пропущена в BPMN 1.х, и имело смысл добавить их в 2.0. Есть разделы спецификации на тему «аудит» и «мониторинг», но ни слова об имитационном моделировании. Имитационное моделирование имеет большой потенциал, и это еще одна упущенная возможность.

Примерно о том же пишет Роберт Шапиро (Robert Shapiro) в заметке BPMN Process Interchange. Он считает, что некоторые нововведения усложнят модели, т.к. нет четкого разграничения атрибутов для исполняемых моделей и для более высокого уровня моделей, которые использует бизнес-аналитик. Кроме того, т.к. портативность модели подразумевает ее интерпретацию в XML, то необходимы будут инструменты, контролирующие структурную целостность XML данных. Причем, делать это надо как со стороны BPMN 2.0, так и со стороны XPDL 2.2.

Франк Михаэль Крафт (Framk Michael Frank), Success with BPMN 2.0 отмечает, что большим плюсом BPMN 2.0 является возможность изображения как сильно-, так и слабосвязанных процессов. Сильно связанным является процесс, в котором возможность регистрации клиентского заказа зависит от наличия утвержденной цены на продукцию. Слабосвязанный процесс – это клиент регистрирует заказ в любое время. В первом случае шаги процесса объединяются в один пул. Слабосвязанные процессы моделируются сквозь пулы как совместная работа или как хореография. Такое деление – на сильно- и слабосвязанные процессы – оказывает решающее влияние на успех. И это вопрос не столько разработки, сколько бизнеса, поскольку от него зависит гибкость компании.

А вот мнение Макса Пачера (Maks J. Pucher), основателя и главного архитектора ISIS Papyrus Software не такое радужное. В своей статье BPMN 2.0 - A Step Sideways! Он пишет, что несколько дезориентирован будущим стандартом. Он считает, что дополнения, сделанные в стандарте, делают модели очень неоднозначными. «Activity» может представлять любое количество различных функций, и новые типы событий недостаточно детализируют то, как они взаимодействуют в потоке. Там все еще нет артефактов, атрибутов и моделирования состояний и нет бизнес-правил. Обещанное UML-подобное моделирование данных, похоже, тоже отсутствует. Т.е. модели в BPMN 2.0 нельзя будет взять как есть, а необходимо будет перекодирование в BPEL+Java. Т.е. нет никакого замкнутого цикла («roundtrip») и вовлечения пользователей («user empowerment»). Весь входящий и исходящий контент и артефакты по-прежнему придется программировать. Правда, дальше выясняется, что автор вообще противник диаграмм и считает ущербным не столько BPMN 2.0, но и  подход к BPM на основе диаграмм («flowcharting BPM approach») в целом.

Это еще раз доказывает, что единого мнения по поводу будущего стандарта не существует (да и не может существовать), поскольку выбирая один путь развития, непременно остаются в стороне интересы другого «лагеря». Остается только надеяться, что если стандарт будет принят такими крупными BPM-вендорами, как IBM, SAP, Oracle, TIBCO, Appian и т.д., то остальное сообщество «подтянется». Лучшего-то пока не придумали…

=WJ

Комментарии
#1 Николай Войнов, 06.07.2009 21:51

Спасибо за статью - много, интересно и по делу.
Можно еще немного пояснить ситуацию с

> будет включение XML схемы на основе мета-модели

т.е. будет XML Shema и соответственно можно будет говорить о корректном и валидном XML-документе диаграммы процесса?

> усовершенствованное BPEL-отображение

т.е. будет постулированный путь прямого BPEL преобразования файла процесса, и может будет сразу готовый XLST?

> Мета-модель, основанная на XML-схеме. Все BPMN элементы описаны в XML,
> что обеспечивает стандарт мета-модели. Было бы полезно, если бы это было
> визуализировано.

возвращаемся к началу ... т.е. будет BPMN XML Shema, которая включает все возможные элементы BPMN-файлов процессов.

тогда вопросы переносимости моделей между средствами разработки должны сниматься или я не прав? разве что останутся проблемы одинакового отображения процессов в разных инструментах?

а визуализация схем это уже давно не проблема, редакторы есть, давно встроено в eclipse ee.

#2 Юлия Вагнер, 08.07.2009 13:33

Николай,
честно говоря, у меня не сложилось впечатления, что в 2.0 все будет прямо в шоколаде. Судя по оценкам Брюса (а именно его я считаю наиболее объективным, да и к тому же он ближе всех к источнику), разработчики стандарта несколько далеки от реальности, плохо себе представляют РЕАЛЬНОГО пользователя стандарта. Приближать стандарт к разработчикам... да эти и так что хошь запрограммируют. Поморщатся - и запрограммируют. Им нужен моделлер? Не думаю. Хотя есть надежда, что, благодаря влиянию того же Брюса, направление все же выровняется.
Но то, что в 2.0 BPMN XML будет - это уже точно. В этом даже самые отъявленные скептики не сомневаются.

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права