My Concluding Nuance On BPMN

Before I try to summarize my position, I'll reference all the related blogs in this discussion:

Michael zur Muehlen: How much BPMN do you need?
Bruce Silver: On How Much BPMN Do You Need
Michael zur Muehlen: Who is at fault - the language or the speaker?
Bruce Silver: Michael Elaborates
Me: The Hottest BPMN Process Modelling Debate, BPMN Conformance Sets And Unrealistic Ambitions and The Devil Is In The Technical Details
And overviews from InfoQ and Sandy Kemsley.

After the above and another good discussion at the Dolmen event: Do’s en don’ts van Business Process Management yesterday, I would like to give another shot at summarizing my point of view around BPMN and indicate where I see most misunderstandings around analysis to implementation.

BPMN can be used for analysis. In that sense, the BPMN analysis model is a model or a description of the real world. BPMN can also be used to represent executable process languages. But in that case the BPMN diagram represents a piece of software.

So my point is that, in general, it is impossible for an analysis model to automagically be translated into an implementation model. Even while for both models BPMN can be used, at some point, the purpose of the model changes. I believe that the purpose-change from analysis to implementation can not and should not happen automatically or transparantly.

In some cases, the BPMN model representing the executable process could very well be exactly the same as the original analysis diagram. In fact, the better the executable process language, the closer the implementation diagram will be to the original analysis diagram. William Vampenepe's post already shows that BPMN to BPEL doesn't really succeed in that goal.

BPMN to XPDL would be much closer, but XPDL doesn't really aim to be an executable process language.