Complete BPMN palette includes hundreds of elements if all allowed combinations are counted. Seasoned professional should know the semantics and usage rules of any but at the same time shouldn’t seek to use them all.
Firstly, exotic elements would make the diagram less comprehensible for business users, leading to refusal in some cases. Probably the biggest BPMN advantage is that it’s both intuitive and strict enough, allowing business users, analysts and IT developers to be on the same page. But this is going to happen only if a good style and healthy minimalism are followed.
Secondly, if BPMS powered processes are considered, no engine implements BPMN completely and strictly. Hence the popular questions: how critical is a given BPMN element being not supported? Is there a workaround?
In this article we’ll investigate BPMN gateways - which ones are must-have and how others can be workarounded. The other BPMN elements will follow.
1. Exclusive gateway (data based)
We won’t try to substitute this one of course.
Side note: empty diamond and the one with a slanted cross inside are just two alternative graphical representations of the same element. It’s pretty obvious that it’s better to follow either one or another style throughout the diagram (or the organization, on that matter).
2. Parallel gateway
The parallel gateway is essential too.
3. Inclusive gateway
Can be replaced by a combination of exclusive and parallel:
= |
Inclusive gateway is useful because it models a specific and common enough business scenario: a set of independent options; the alternative diagram presented on the right is more cumbersome. On the other hand, the novice users would hardly get the diagram on the left without explanations.
The process engine may encounter difficulties synchronizing flows at the merge gateway; from this point of view the diagram on the right may have preference, too.
4. Complex gateway
Complex gateway controls tokens on merge. Can be replaced by a pair of exclusive gateways:
= |
5. Event-based gateway (exclusive)
Can be replaced with the help of a subprocess:
= |
This technique borrowed from Bruce Silver can be used for any combination of events.
If one of the events is message catch then a simpler hint may be used:
6. Start (instantiating) exclusive event-based gateway
= |
Both styles should be avoided because 1) they aren’t obvious for business users and 2) most BPMS can’t execute them anyway. Better model flows from each event as a separate process and leverage reusable/call subprocesses.
7. Start (instantiating) parallel event-based gateway
= |
This gateway mostly has purely academic value.
Conclusions
It’s basically enough to have just exclusive and parallel gateways. Others may help building more compact diagrams yet their value is diminished by the fact that an average reader not trained in BPMN would hardly understand them.
Анатолий, очень красиво и элегантно изложено, добавлю статью себе в закладки.
Не смогу, наверное, отказаться от и/или, и развилки по событиям, - привык к ним, а остальными, кроме 2х базовых не пользуюсь.
“Развилка “и/или” полезна, так как моделирует вполне определенный и достаточно распределенный сценарий”.
Видимо, “… и достаточно РАСПРОСТРАНЕННЫЙ сценарий”?
Спасибо, исправил.
Упрощение сейчас в тренде:
https://habrahabr.ru/post/319344/
Статья неплохая по содержанию, но хамская по форме. И она точно не про упрощение. Оставлю ваш комментарий в виде исключения, но обсуждать ее тут не надо.