Thoughts about “Approaches to Modeling Business Processes. A Critical Analysis of BPMN, Workflow Patterns and YAWL”

Prof. Börger published an article called “Approaches to Modeling Business Processes. A Critical Analysis of BPMN, Workflow Patterns and YAWL“.

I want to share some thoughts about it.

First Prof. Börger looks at some of weaknesses of the BPMN 2.0 Standard.

He sais:

The crucial criterion is how well the practitioner is supported when walking through the different levels of detail (refinement levels).

The standard does not support process structure at the risk of producing incomprehensible spaghetti diagrams.

The standard document fails to provide a seamless systematic mechanism for refinement from conceptual to executable models, which is necessary to guarantee the reliability of the implementation.

I discussed the same topic some days ago. I agree that the standard does not prescribe a solution to the problem, but as I said keeping some basic rules the solution is easy. It is always a question of discretion how much should be prescribed by a standard and how much should be described in a guideline or methodology or best practice how to use a standard effectively. There are always many ways to do it wrong, but as long as it is easily possible to do it right, it should not be such of a headache. As I said I will discuss the way to do it right in the seminar BPMNexpress. In general also I teach it also in the mentoring.

He also sais:

Furthermore a statistical evaluation (of BPMN 1.1) shows that `the average BPMN model uses less than 20% of the available vocabulary’ and that, out of the more than 50 graphical elements in BPMN, `Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed.’

Yes, and this is why it is possible to learn what you really need to know about BPMN in half a day. Of course full mastery is only reached within a longer process of modeling, mentoring and quality assurance. But this is normal with any modeling method.

The he talks about difficult modeling concepts in BPMN 2.0:

The lifecycle concept is an example of an underspecified feature, particularly in relation to the equally underspecified interruption mechanisms like exceptions or cancellation or compensation for transactions.

I have the same opinion. I tried to convince the BPMN 2.0 standardization team that these concepts are too difficult and problematic. Now I recommend to my clients not to use them. However for all of these problems, there is an easier way to solve them.

A general notion of state is missing and, as a consequence, the specification of relevant data dependent conditions is only poorly supported.

In fact BPMN 2.0 has a notion of state for data objects. This already helps a lot! I do recommend to my clients the use of state for data objects and it makes many modeling problems much simpler.

And yes, the state model is not very elaborated – but it can be extended.

Communication and process interaction are poorly supported for concurrent execution, e.g. of independent (not embedded) subprocesses or of processes belonging to different parts of one organization or to different cooperating organizations.

An analogous problem results from the poor interweaving of different BPMN diagram types, in particular that no consistency criteria are imposed for them, for example collaboration vs choreography vs process diagrams.

I do not agree at all. This is one major part of what is new in BPMN 2.0 compared to BPMN 1.x. I will teach this in BPMNdelta.

Later Prof. Börger looks at difficulties with WPI Workflow Patterns

The workflow patterns, as presented by the WPI, come without pragmatic or rational foundation. In fact there is no statistical underpinning showing how frequently which patterns appear in real-life business processes.

My opinion is that some of these are of practical relevance and others are not. I am preparing a publication on the topic, but it is not finished. Also most of these patterns that are relevant in practice can be reduced back to very simple principles of modeling.

Prof. Börger has the same opinion as he sais:

In fact most patterns are not of fundamental character but are easily definable from a small set of more basic and rather simple patterns.

In the last section Prof. Börger discusses YAWL and coloured petri nets. Some of his statements:

In this section, we show that the purported semantic foundation of YAWL using coloured Petri nets is not `suitable’ for the practice of BPM.

… deal with patterns that Petri nets have difficulty expressing, in particular patterns dealing with cancellation, synchronization of active branches only, and multiple concurrently executing instances of the same task.’

… languages which `lack the concepts to be able to deal with the broad range of requirements one may encounter when trying to precisely capture business scenarios’ directly applies to Petri nets, work flow nets, reset nets and other extensions proposed for modeling business processes.

I already discussed some days ago, why I would not build a new standard for Adaptive Case Management based on BPMN and I argued it is because of the “token logic” – actually what is meant is the petri net logic of BPMN. So we – Prof. Börger and me – have the same opinion on this if we refer to advanced scenarios. These are some of the topics that I will discuss in BPMfuture.

As I said BPMN is good for some problems, but it is difficult with more flexibility as it is needed for Adaptive Case Management and in general for the work of knowledge workers. Instead of building more and more complex formal constructs to address all of these special cases it is easier to not use petri net at all for Adaptive Case Management.

However I am more optimistic than Prof. Börger when we refer to cancellation scenarios and BPMN. Yes – he is right it is very difficult with petri net – but BPMN also has other features of modeling. It is possible in BPMN to use data objects and state – and therefore it becomes easier to model cancellation scenarios. I do teach this in BPMNexpress.

Finally he proposes to use a concept of introducing Product Lines to BPM. I have to study this more, before I say something about it.

Posted in BPMN Standard, BPMN in Practice, BPMN in Research | Leave a comment

Extend BPMN to include Adaptive Case Management?

In his blog post about a conference held in Darmstadt, Germany, Dr. Martin Bartonitz tells about the discussion to extend BPMN to include requirements from Adaptive Case Management. Seemingly more and more people are asking about it.

I think we should not do this.

Remark: Re-reading Mr. Bartonitz Blog I must admit, that he did not propose to extend BPMN, but was talking about CMPM, the effort of the OMG to standardize (Adaptive?) Case Management. So it turns out – we – Mr. Bartonitz, me, and the OMG are in agreement of the future strategy. The only thing I have a different opinion is, that I think it is too early to standardize. However I leave my text in the blog to reason about, why a separate effort is the right way and to show how migration and integration can work.

I have a high esteem for BPMN if it is used for the purpose that it has been designed for. That is classical process modeling, workflow modeling, and a two phase lifecycle:

  1. Modeling and deployment
  2. Execution

This is what BPMN is designed for and this is where it works best.

On the one hand I understand the request of people to extend BPMN with modeling elements for ACM, because BPMN is what they know and people tend to love what they know. And this is a good thing! And even BPMN 2.0 is quite fresh on the market.

Adaptive Case Management is a completely different kind of process management. There are no two phases, but only one: Modeling and execution at the same time. It is MUCH MORE flexible than BPMN. If you do not understand this statement, please read the books “Mastering the Unpredictable” and “Taming the Unpredictable“.

There are many attributes of BPMN that are not needed in ACM, even are burdensome. For example there are now so many gateways and event types and modeling elements in general that are not needed in ACM. I estimate that ACM can live with between 5 and 10 modeling elements overall. It is a different modeling philosophy. BPMN`s execution semantics is flow based. I.e. workflow engines manage “tokens” flowing between the activities. ACM must not have tokens. That is my conviction. If we introduce token flow to ACM, then we have lost. The reason is it makes the model too inflexible. If you do not believe me, just model a single approval, and then start the approval and later on while it already runs, add another approval. You will see how difficult this is and that is because of token flows. There have been many scientific efforts to make this easier, but it is not possible. The token flow logic however has been grained into BPMN from the very beginning. I would say ACM is rather constraint based than token flow based.

There are other attributes of BPMN execution semantics that makes it unfit for ACM. For example a sub-process is completed if all of its subtasks (following the token-flow semantics) are completed. This is not the case with ACM. As I use to say: Not in all cases when you shoot you actually hit the goal. But this is grained into BPMN as well and it is impossible to remove it. All BPMN process engines have been built around these basic assumptions. I believe that an ACM engine has to be designed as a Greenfield approach and trying to change a BPMN workflow engine to make it more “ACM” like is wasted time. I think I have agreement on this with most of the other authors of “Mastering the Unpredictable” and “Taming the Unpredictable”. This is why I designed the AdaPro Workstream Platform from scratch.

Also I believe it is too early to standardize ACM. Tool vendors have to have freedom to design and apply the new modeling concept to the application domain first, and then later, when a lot of tools are around, it makes sense to define a common exchange format and standard.

Of course I believe ACM is backward compatible to a degree. That is – it is possible to import BPMN models into an ACM model snippet. I already implemented this in the AdaPro Workstream Platform. I think also it makes some sense to export ACM models to BPMN models. I also believe that it will be possible to model all kinds of predictable process models with ACM, but with different means than with BPMN. I also know that it is possible to use BPMN already today, so that it is “kind of adaptable”. Is this not a contradiction to what I said before? No! This is possible by defining a modeling guideline that restricts the use of modeling elements for a BPMN model to make it more adaptable and better suited for exchange between the ACM and the BPMN world. I already have defined such a guideline and I teach it in my seminars here and here.

So, I think what people want is a “smooth migration” path from BPMN to ACM, and that is a very valid requirement. And what they want is a “smooth” integration of ACM, BPMN and SOA. And this is even more of a valid requirement. I am convinced that the way to this goal is to first learn the “adaptive way” to model. Then, second, is to use ACM tools for real use cases and third to create a new Greenfield standard for ACM and fourth to define a model exchange between BPMN and ACM.

 

Posted in Adaptive Processes | 2 Comments

Hierarchies and Level of Detail in BPMN modeling

It is often said, that there are difficulties in the levels of detail of a set of BPMN models – especially if you look to the model from a business view and from a technical view. Also in many sets of models there are so many “Jumps” between individual models that the models become cumbersome.

I disagree.

My modeling guideline gives some basic rules, and if they are followed, this does not happen.

  • First it is important to distinguish between level of granularity and degree of detail. These are not the same thing.
  • Second it is important to model the data objects and their state.
  • Third it is necessary to model different variants of one and the same process in different models.
  • Fourth we mostly do not work with sub-processes but with call activities
  • Fifths we model the preconditions and the post-conditions of a process in such a way, that they fit together.

If these simple rules are followed, then I can guarantee a concise and well integrated set of models.

You can learn this and more in the half-day seminar BPMNexpress.

Posted in BPMN in Practice | 1 Comment