Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Баланс между оркестровкой и межпроцессным взаимодействием в BPMN

Определение 1: оркестровка (orchestration) - это диаграмма, показывающая последовательность выполнения активностей, координируемых из одного центра.

Примечания:

  • Синонимами оркестровки являются поток работ (workflow) и, собственно, процесс.
  • В BPMN оркестровка моделируется развернутым пулом (white-box pool), при этом на диаграмме могут опционально присутствовать внешние сущности, моделируемые свернутыми пулами (black-box pool).
  • Формулировка “координируемых из одного центра” означает, что, даже если процесс на каком-то шаге распараллеливается, исполнение разных ветвей процесса остается координированным: они могут в дальнейшем синхронизироваться в сходящейся развилке, а процесс в целом завершится тогда, когда завершатся все ветви.

Определение 2: межпроцессное взаимодействие (collaboration) - это диаграмма, показывающая взаимодействие между потоками работ.

Примечания:

  • В BPMN 1.x межпроцессное взаимодействие называлось хореографией (choreography). В BPMN 2.0 хореографией стал называться новый, отдельный вид диаграммы, а то, что раньше называлось choreography, теперь называется collaboration. Такие дела.
  • На диаграмме межпроцессного взаимодействия отображается больше одного развернутого пула (white-box pool).
  • Межпроцессное сообщение иногда сводят к обмену сообщениями (message), но в общем случае процессы могут взаимодействовать при помощи сообщений (message), сигналов (signal) и/или данных (data store, conditional event).
  • Отдельные процессы на диаграмме межпроцессного взаимодействия исполняются в целом независимо, за исключением явно обозначенных точек синхронизации - отправки и получения сообщения/сигнала, записи/чтения данных.

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

Тут встречаются две крайности:

  1. При первом знакомстве с BPMN аналитик пытается обойтись одной оркестровкой. Но это проходит только для очень простых процессов типа оформления заявления на отпуск. Кроссфункциональные процессы, представляющие наибольший интерес с точки зрения бизнеса, принципиально многопоточны и не могут быть смоделированы оркестровкой.
  2. Познакомившись с сообщениями и выяснив, что их можно использовать только между пулами, аналитик начинает плодить пулы без всякой нужды. Например, использовать пулы и сообщения там, где достаточно подпроцесса:

Рис.1 Антипаттерн “Сообщения вместо подпроцесса”

Обычные аргументы в пользу такой схемы:

  • “Вызываемый процесс выполняется другим подразделением.” - Чтобы показать исполнителя, пользуйтесь дорожками (swimlane), а не пулами.
  • “Вызываемый процесс можно использовать где-нибудь еще.” - Как и повторно-используемые (reusable) подпроцессы.
  • “Явно видна связь между вызывающим и вызываемым процессом.” - Во-первых, развернутый подпроцесс не менее нагляден:

Рис.2 Развернутый подпроцесс

  • А во-вторых, диаграмма с грамотно выделенными уровнями абстракции вполне обходится свернутыми подпроцессами: когда мы смотрим на процесс верхнего уровня, мы должны понимать его логику без знания деталей подпроцессов. Содержимое подпроцесса будет изображено на отдельной странице, и это правильно:

Рис.3 Свернутый подпроцесс

Конечно это вопрос не корректности, а стиля - диаграмма на рис.1 формально корректна. Но я считаю, что это антипаттерн и изобретение велосипеда, потому что сообщениями тут смоделировано то же поведение, которое встроено в вызов подпроцесса:

  • когда поток управления доходит до подпроцесса, появляется токен в подпроцессе, а вызывающий процесс переходит в состояние ожидания
  • когда подпроцесс завершается, вызывающий процесс продолжает работу

Резюмируя, вот мои правила для оптимального баланса между оркестровкой и межпроцессным взаимодействием:

Правило 1. Если раз за разом ваши попытки смоделировать процесс оказываются неудачны и какие-то существенные аспекты процесса не удается отразить - остановитесь и задумайтесь: может быть, на самом деле тут не один процесс, а два или больше?

Правило 2. Не увлекайтесь межпроцессным взаимодействий - оставайтесь в рамках оркестровки, пока возможно. Никогда не вводите в диаграмму межпроцессное взаимодействие только потому, что вы недавно этому научились.

В следующей статье поделюсь опытом, как в ходе анализа выявлять независимые процессы.

19.05.11 | Статьи | , ,    

Комментарии (2)

  1. Raj 02.11.12 23:37

    Hi Anatoly,

    I just want to know what other advantages can an orchestration process over other BPMN process bring e.g collaboration and choreography?

    And also, does a collaboration contain orchestration and choreographies?

    Regards,

  2. Anatoly Belychook 03.11.12 08:33

    Collaboration may be considered as a next step over orchestration. So yes, collaboration contains orchestration.

    Choreography is another track. It has a special purpose and a special choreography task.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии