Executable BPMN for Business Analysts?

People asking for the differences between BPMN and BPEL they often hear BPMN is graph oriented whereas BPEL is block oriented. But what does that actually mean and why is it important?

Block orientation means that there is no way back in the process like a goto statement. In BPEL a common workaround is to use loops to move backwards in a process. But this approach is cumbersome and creates non intuitive models. Block orientation feels natural for developers as it is how programming languages such as Java or C# work.

For business people this feels odd, cause it is not how they perceive processes in their daily business.
Business people regularly need a way to say “Oh wait, there is a problem in step X, let’s go back to step A and fix it.”.

Graph orientation means that the process can flow between tasks even backwards. In terms of Business/IT aligment graph orientation is a clear advantage as it is closer to how people think and work.

Because BPMN is graph oriented it is way better suited for business analysts than BPEL. Does that mean that with BPMN business people can create executable processes? In theory yes! And in reality?

As long as the BPMN model is purely prescriptive, people can freely connect tasks in all directions (more or less). But if the aim is to create executable process models, the BPMN semantics come into play. Although your modeling tool might allow to create all kind of links, process engines are very strict in what they can do. An executable model is like source code and as such follows strict rules.

Let’s create a simple example:

For an analyst this might look like a perfectly modeled process. The problem is that it ignores the BPMN semantics. Neither the modeling tool (Signavio) nor the process engine (Activity) complains, but at runtime the process runs into a deadlock situation. Why that?
The parallel gateway used to join the process after the execution of Task 1 and Task 2 expects two tokens. On the first run it gets two tokens and everyting is fine. If the completed gateway continues with Task 2 on the second run, the joining gateway receives only one token and the process is on hold cause the second token never arrives.

Conclusion:
If the aim is process automation, it is essential that the process strictly adheres to the BPMN semantics.
For most business oriented people (at least the ones that I know) this is new completely new terrain.

2 thoughts on “Executable BPMN for Business Analysts?”

  1. It is not surprising that a pure modeling tool like Signavio cannot detect this error, as it requires a validator that can trace the token passing, which is hard. It is surprising that Activiti doesn’t flag it, for the reasons you state. The modeling tool carries the burden of detecting errors in BPMN semantics, not the business analyst. Right now tools don’t even detect much more basic violations of BPMN rules, but hopefully they will someday… On your larger topic of block vs graph orientation, a more instructive example might be to replace the AND gateways with XOR. There you see the benefits of graph vs block in a model that is semantically correct.

  2. Wolfgang:

    Great find. On of the things that BPMN continues to fail to deliver is the possibility to convert process maps process implementation language to be executed in a workflow engine, or construct web services, due to inability of business analysts follow the mapping standard and simultaneously the myriad technical standards systems vendors don’t comply. This is something I looked in the past in a different perspective:

    http://antiamba.blogspot.com/2010/05/bpmn-can-bring-death-to-your-process.html

    It’s a pity that BPMN has not yet been able to achieve its primary objective: to convert business process models language that can be implemented in BPMS automatically. Truly BPMN is becoming a “de facto” standard for modeling proposes only.

Leave a Reply to Bruce Silver Cancel reply

Your email address will not be published. Required fields are marked *