Определение 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-тренингов, соблюдение баланса между оркестровкой и межпроцессным взаимодействием представляет определенную сложность.
Тут встречаются две крайности:
- При первом знакомстве с BPMN аналитик пытается обойтись одной оркестровкой. Но это проходит только для очень простых процессов типа оформления заявления на отпуск. Кроссфункциональные процессы, представляющие наибольший интерес с точки зрения бизнеса, принципиально многопоточны и не могут быть смоделированы оркестровкой.
- Познакомившись с сообщениями и выяснив, что их можно использовать только между пулами, аналитик начинает плодить пулы без всякой нужды. Например, использовать пулы и сообщения там, где достаточно подпроцесса:
Рис.1 Антипаттерн “Сообщения вместо подпроцесса”
Обычные аргументы в пользу такой схемы:
- “Вызываемый процесс выполняется другим подразделением.” - Чтобы показать исполнителя, пользуйтесь дорожками (swimlane), а не пулами.
- “Вызываемый процесс можно использовать где-нибудь еще.” - Как и повторно-используемые (reusable) подпроцессы.
- “Явно видна связь между вызывающим и вызываемым процессом.” - Во-первых, развернутый подпроцесс не менее нагляден:
Рис.2 Развернутый подпроцесс
- А во-вторых, диаграмма с грамотно выделенными уровнями абстракции вполне обходится свернутыми подпроцессами: когда мы смотрим на процесс верхнего уровня, мы должны понимать его логику без знания деталей подпроцессов. Содержимое подпроцесса будет изображено на отдельной странице, и это правильно:
Рис.3 Свернутый подпроцесс
Конечно это вопрос не корректности, а стиля - диаграмма на рис.1 формально корректна. Но я считаю, что это антипаттерн и изобретение велосипеда, потому что сообщениями тут смоделировано то же поведение, которое встроено в вызов подпроцесса:
- когда поток управления доходит до подпроцесса, появляется токен в подпроцессе, а вызывающий процесс переходит в состояние ожидания
- когда подпроцесс завершается, вызывающий процесс продолжает работу
Резюмируя, вот мои правила для оптимального баланса между оркестровкой и межпроцессным взаимодействием:
Правило 1. Если раз за разом ваши попытки смоделировать процесс оказываются неудачны и какие-то существенные аспекты процесса не удается отразить - остановитесь и задумайтесь: может быть, на самом деле тут не один процесс, а два или больше?
Правило 2. Не увлекайтесь межпроцессным взаимодействий - оставайтесь в рамках оркестровки, пока возможно. Никогда не вводите в диаграмму межпроцессное взаимодействие только потому, что вы недавно этому научились.
В следующей статье поделюсь опытом, как в ходе анализа выявлять независимые процессы.
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,
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.