Stephen White made a comment on my Human “Facilitator” Processes post that deserves highlighting.  You probably know the Stephen was the chairman of the working group that developed BPMN.

The discussion of the different diagrams shown in the post really have nothing to do with BPMN per se, but with the methodologies that would be used to model with BPMN. BPMN is generally methodology agnostic. The way that a process is modeled, to what level of detail, and what information should be captured, is really up to the methodology and the purpose for creating the process model.

He is completely right, and this is really really important.  I have discussed this with Stephen before, but this is something that very few of the experts seem to understand.  What he is saying is that the way you draw something with BPMN depends upon your methodology you use.  Given one method for one purpose (e.g. Automators) it would be right and correct to draw one way, but with a different method and different purpose (e.g. Facilitators) it would be right and correct to draw a different way.

This makes those who want ONE TRUE WAY to draw process diagrams extremely uncomfortable.  This was never the goal of BPMN.  BPMN instead had the goal to define a set of common elements that could be used for multiple different specific diagramming needs.  I might even venture that this is why BPMN did not have a meta-model to begin with.  I might also venture that BPMN success is precisely because it was flexible to be adopted in slightly different ways. Had it been overly rigid, it might have been rejected.

I would have said it slightly differently: that differences in the diagrams come from differences in the capabilities of the underlying system that will enact the processes.  This amounts to the same thing since tools are created with a particular methodology in mind, and that use of a particular methodology draws you to particuar tools.  What you are allowed to draw, and how you draw it, depends on things outside the BPMN standard.

What does this really mean?  It means that using one methodology one might draw a given process one way, while using another methodology one might draw it a different way.  Those who want a single diagramming approach, want a single methodology, as well as single set of underlying capabilities.  That would make life easier, in the sense that having a single flavor of wine would make life easier.  The world is not so simple, and some of those differences have great value and utility.

This calls into question all sorts of things.  For example, is it possible to exchange process models?  The answer depends upon whether the tools exchanging the models have similar enough underlying capabilities.  My position has always been that a process model has many aspects, and some aspects of the model will translate with full fidelity, but other aspects will not fare so well, and we must be satisfied with partial fidelity.  Still, it is worth-while to get the part that does carry over.

At the risk of being repetitive, let me stress this one more time.  You might be able to draw a particular diagram using one fully BPMN compliant tool, and not be able to draw that same diagram using a different BPMN compliant tool. Both tools are BPMN compliant.  I will leave you with that thought for today, but there is clearly much more to discuss, particularly when considering Facilitators and Automators.