The biggest BPMN nonsense ever!

Sebastian;

Your suggested solution is fair enough, but I think this is based on what the model should be used for and what spread of notations are used/communicated within the company. Many processes are modelled to communicate to stakeholders on how the process flows/contain and for the stakeholder (ie. not always that familiar with BPM notations) it's indifferent if there is an "X" in an exclusive gw or not. As an architect I will have to explain the logic anyway. I have used the "blanc" gw since I started with BPMN and have never had any problems with that.

However; I can see that if you use several notations on daily/weekly basis (UML, EPC, BPMN, etc) this can be confusing. But if you are in such a position, you should start thinking about a common BPM language anyway. The BPMN spec describe the exclusive gw as default and to many "Visio" modellers the diamond have the same meaning without the "X".

Weather you should include the X or not should be part of HOW you make use of the standard within your company (ie. define the method & style). We have this described in a SOP (standard operation procedure) for BPM. The point is that one have to agree on how you do this to reach common understanding and always comply.

Kind regard

Jan

Hi Jan,

thanks for your input. Of course you are right that you would train people and create modeling conventions to support modeling. Still, I think it is a major fault if the symbols of a notation are not expressive as possible. Also, I think it is a very bad idea to have 2 symbols with the same meaning. In a natural language it is great to have synonyms, but not for a modeling language. Of course one could argue to only use the empty gateway and get rid of the one with the "X". Still, I think the "X" delivers more information than the empty gateway so why not use it?

I agree. But the bigger problem for a real-life project (you know, where you have to train new people and create universally readable models, and such) is the "richness" of BPMN to say the same thing in 3-5 different fashions. An example might be the process flow - you can use a gateway or you simply can draw to connections and add the conditions to them (meaning "xor"). If you merge those paths you have to use a gateway to connect them while drawing two connections into a function means "and" - this is inconsistent and the spec is full of those examples. You might think about exeptions, event-subprocesses and such.

Oh, and I don't want to talk about the "default" marker on the connection, which means "otherwise" in plain English.

For a project it is crucial IMHO to standardize on one way to model and then train your users in that one fashion. This is also crucial for model adoption by the business users, since they won't accept "consfusing" modeling style. Unfortunately I see the spec going into the wrong direction by adding more complexity instead of reducing it. The sub-classification (and let's not talk about strange naming like DoDAF, which no-one outside of the US knows) is just the band-aid on a more structural problem with BPMN.

Roland, the examples you mention would have been my next point. I added the problem about using conditional sequence flows instead of exclusive gateways to my diagram above. I also added that one should use parallel gateways instead of multiple outgoing/incoming sequence flows. Of course, Jan's argument applies here, too. You have to standardise on one way of expressing things. If you introduce to your people using conditional sequence flows, this is ok, too. Still, I would suggest to use gateways as they are visually more expressive.

Let's see if someone else wants to bring up any BPMN best practices.

I fully agree with you Sebastien.  Real non-sense to have blank gateways and having to guess what it means !

I would add an issue regarding the BLUE color used for activities in BPMN.  It is confusing with the color traditionaly used for IT systems and Application Systems in EPC, system landscape, application diagrams, etc.

In my company, we are used to green now for activities/functions/tasks after beeing exposed to process models for several years .  So, my question: is BLUE color a obligation for activities in BPMN?

Hi Thierry,

BPMN defines no colors at all, but a tool is free to choose colors. So the blue is our fault ;-) We introduced blue, because we wanted that EPC and BPMN models look different on first glance so that they are not mixed up by people.

Make sure to also read this post, even though it deals more with simplifying the BPMN meta model rather than simplifications applied easily during day-to-day modeling.

Sebastian,

I have seen some of your posts since we have been evaluating the use of BPMN and ARIS and I must say I do like them, however I found this one particularly misleading. I have recently studied the BPMN 1.2 normative spec and I notice that the Good/Bad labels are not really good or bad practices, but they actually refer to different use cases of BPMN. In the first diagram, the gateway without the X mark has always been used in swimlane diagrams (flowcharts) as an OR decision, I actually think that having an X is more confusing as it may lead you to think it has a different meaning. In the second diagram, I do think it is good not to use conditional sequence flows when the decision is exclusive, but using conditional flows also has another use case: when the decision is not exclusive (can go one way or both ways) and is also equivalent to using the inclusive gateway (O symbol inside). In the third diagram, having a parallel gateway merging the flows and having the parallel flows without a gateway is radically different. With the gateway, activity D will start only if it has received a token from activity B and C; without the gateway, activity D can start after it receives a token from activity B or activity C. I know all of these are subtle details, but they must be considered when using BPMN.

Keep up the good posts!      

Hello Mr. Stein, concerning your best practice for parallel gateways, I have some doubts. Actually, you already advise to use the parallel join. However, replacing a parallel join with sequence flows directly binding the following activity is not semantically identical, since you loose the token merging (synchronizing) effect of the parallel join. This leads to activating the  "task D" twice, especially if "task B" and "task C" last differently long. Different sequence flows bounding into an activity behave like an explicit (join) gateway. Please refer to page 36/38 of spec version 2.0 from 2011-01-03.

I agree with Stein while accepting the subtle corrections by other experts.

I have just joined ARIS.  I advocate MINIMAL ESSENTIAL BPMN which a general business user also should be able to create and interpret.  It should be upward compatible with more sophisticated additions.  I wish to discuss these topics in different posts.

Regards, 

PVN