Frank Michael Kraft's Blog

I just took the BPMN Model understanding self test. It is a research project of Humboldt University of Berlin, that I can recommend. I was asked about 30 models and how I understand them. The test takes about 30 minutes and is a nice excercise.

http://www.bpmn-selftest.org/

I made it to rank 14 of 394. However I wonder who the 13 were, that were better . So give it a try, maybe you can beat me. The test is anonymous however.

Nevertheless I want to share what I thought when I saw the models. They were quite complicated. I think if models are as complicated in a real project as those in the test, then something went terribly wrong in the first place. I agree, that it is fine for a research project to use artifical complicated models, to find out more about human model comprehension. And I am very interested in the research result. But models must be much simpler than those.

Simpler models could be reached by limiting the scope of one model – i.e. splitting it up in different parts, using submodels for example. As far as I remember human comprehension can assess 7 items at once, not more. So in essence I think a model should not contain more than about 7 important steps.

Also it can mean to model only the most important cases and model the special cases in a different model.

And it can mean to question, if BPMN is the right model language for the purpose chosen. I know that BPMN is popular and becomes even more, because it is a standard. But in my eyes the question remains, if the task flow oriented modeling it does is really the best way to do it. In my eyes it should be evaluated as a result of this research project, if goal driven and constraint based modeling would not result in much easier models.

So – it is very useful to have this tool for the top-down design of process interaction now. Inversely it can be used for the validation of an already existing bottom-up modeling. In reality it will be a mixture between the two. It is of central importance to have the enforceability in mind, that is to define a process, that is actually executeable by the participants. For this the model levels serve as basis for validation.

If we go down to the technical modeling, it is now possible to model Conversations, which are groups of Message Flows, Correlations, which are assignments between a message and a process instance, Service Bindings, Data Flow, … Compared to BPMN 1.2 the DataFlow is more than an artifact now (i.e. more than just a pictogram). It has a datastructure and the Activities have DataInput and DataOutput. Also the DataObject can be used as Parameterspecification for reusable Subprocesses. The Events have been enhanced. There are complex Events, Events , that can interrupt an activity or not, it is possible to define Event-Subprocesses that run aside from the Sequence Flow.

Here some critical comments from my side may be allowed. I think the workflow type of modeling is too strong in this. First there are strong sequence flow relationships established, only to be loosened later by many Events. I think it would be better for the future to define the relationships more loosely from the beginning. For example they could be modeled as preconditions depending on the status. That is something for the future.

Personally I found the discussion around the relationship between public and private processes very fascinating. One time it seemed like we had so many problems with it, that we could not do it. And additionally to this there was the climax of the debate with the concurrent submission. We were blamed, that our model was too strict. A very good discussion! But we found a very simple and elegant solution to these problems. The sequence flow is now not so strict than it was before. It has been loosened, and the difficulties disappeared.

Furthermore one important area is to have in mind the asynchronity of messages. That can produce race conditions between messages. However this in my opinion is not mainly a technical problem, but is due to the asynchronous nature of business processes, that I hope to discuss in the Blog as well in the future. Most problems on the message technology side can be avoided on the business process design level – and that is good news.

There are more changes from 1.2 to 2.0, but in my view these were the most important.BPMN has become quite powerful. Sometimes it is not so clear as to how to solve a certain modeling problem. However the success will depend on elaborating best practices and good guidance.

My wishlist for BPMN in the future? Modeling of Interactions with and of Business Objects. Find simpler ways to model special cases. Model a Process specific  Status.

But now is the time that BPMN 2.0 has to be used and proven in practice. After that we can establish our common opinion about the wishlist for the future. It is a language. And the vocabluary is only the beginning of the process to learn to speak that language. Therefore a good coaching process is what I can recommend.

In my view, BPMN 2.0 is an important milestone in a greater journey with in a trend. The trend is the connecting of models from a business domain with those from system development.

First: What is the purpose of BPMN?

1. Description of as-is processes within a company and cross companies
2. Using the models for subsequent system development. The model is the high-level specification.
3. Execution of the model (for example in Appian Anywhere) – probably translation into another execution language like BPEL.
4. Model driven development of systems.

If we want to reach and achieve the fourth step, it is clear, that the execution semantics must be clearer as before – unambiguous.

On the one hand it is required to have “soft” models in the description of as-is models and also shall-be models. This will be so in all future. But especially the connecting of business domain models with system models within a holistic model cycle is a new level of effectiveness that we set our hope to.

In my opinion, this hope is not in vain.

Furthermore a complete meta model is needed for model exchange. This is – in my opinion – overdue anyway.

Why do we model at all? We want to utilize and connect flexibility with quality. This is reached by transparency. Only by transparency it is possible to execute the needed quality assurance on this level. If this is connected with model execution or model driven development, this is even better. We have laid the foundations.

This sounds quite enthusiastic. However I am a notorious BPMN critic. Even now more than enough critics comes to my mind. However I am exhilarated what we have reached within the scope of BPMN 2.0. We have made enormous progress in some key areas. I will elaborate on this in further blog posts.