The Hottest BPMN Process Modelling Debate

Just in case you didn't notice, a very important blog discussion is happening right now around BPMN. Bruce Silver is discussing with Michael Zur Muehlen about how BPMN is used, how it should be used and how it should be improved.

Michael: "How much BPMN do you need?"
Bruce: "On how much BPMN do you need"
Michael: "Who is at fault, the language or the speaker?"
Bruce: "Michael elaborates"

Bruce Silver is a BPM guru consultant. He advocates and teaches BPMN as a rigorous modelling notation. In his view process modellers need a very precise and expressive language so that a lot of details can be precisely documented in the shapes and decorations of a process diagram.

Michael Zur Muehlen is a BPM open academic with a practical touch. His point is that a better layering of the BPMN complexity is needed and that for most organisations, the more basic parts of BPMN are sufficient.

I very much appreciate both gentlemen. BPM minds like that are few and far between. In this case, I tend to agree with Michael. Michaels position reflects what I experience as well in the field. Depending on the culture in an organisation, only in very few occasions, modelling notations are used as mathematical science, in which case a lot of expressiveness is desirable and a lot of exact interpretation of the diagram is needed. In most cases, process diagrams are just drawings of boxes and arrows. We should not forget that multiple reports have indicated that Visio is by far the most used tool to draw business processes. If we assume that a majority doesn't use the BPMN Visio stencils, it means that many organisations now work without these precise modelling notations.

First, I think BPMN would benefit from a better layering. BPMN should introduce e.g. 3 levels. So that in a tool, you can choose whether you want to work in BPMN on level 1 (basics), level 2 (advanced) or level 3 (Bruce :-) ). Michael refers to the constructs already being divided into categories. If that is the case, it is certainly not prominent enough and a categorisation of the constructs is not enough. It should be verified that each level is a self contained language that is complete enough to satisfy a well defined set of modelling purposes.

Second, too formal is not good as it will get into execution semantics. That's why i indicated that maybe a third level will already be too detailed for a modelling notation.

Third BPMN should stick to being a modelling notation. That's what it is being adopted for. The properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.

But when these discussions are settled, still the question is left open of how to translate these process analysis models into executable processes that can be executed on a BPMS. We as BPMS vendors tend to see this as the only possible use case of process modelling. But in fact, a bit more modesty is probably appropriate. We should realise that most business process models are not intended to become executable. But anyway, *if* a process analysis model is to be made executable, I think there has to be a translation to an executable process language. And such a translation should make sure that the analyst still recognizes the diagram of the executable process. That guarantees good communication between analyst and developer. After a process has become executable, it is software and it becomes the responsibility of the developer. Therefore, I don't really believe in the analysis to executable process round tripping. Instead, I think that that it is much more practical to have a one-way translation to an executable process and then iterative updates under control of the developer, but with good input from the analyst on the diagram level.

Anyways, all this side tracks to indicate that we at jBPM still have got couple of challenges left to tackle. Because our goal is actually to bring the usage and knowledge of BPM and workflow technology to become ubiquitous amongst IT teams. I know this has been envisioned before, I know this is ambitious, but I still think we're actually close to getting there.

For a long time now, we've been preaching about multiple process languages. Only recently I start to encounter left and right messages like 'multiple forms of workflow' and 'BPEL is not a silver bullet'. That is a done deal. We are finalizing the Process Virtual Machine that actually runs multiple process languages (like jPDL, BPEL and XPDL) natively. The other point is that embeddability is still underestimated. BPM products are still too much silo's that are hard to integrate into day to day application development. That is where we will be ready soon.

I'll be looking forward to the rest of that conversation.