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.

At the Workflow Management Coalition BPMN Industry Day we also discussed about the implications, that BPMN 2.0 now has a meta model. In itself this is a very good thing. However some problems appear, when thinking about backward compatibility, especially with XPDL as de-facto standard for model exchange. If there are models, which are incomplete, but they still need to be exchanged, how can this be handled, if the BPMN 2.0 metamodel requires strict cardinality conformity, that was not required by XPDL? The same problem appears in tools in general, if the model is in an incomplete state and it is saved. Tools need to react gracefully to this situation, otherwise the usability of the tool is harmed.

So if in this example the incomplete model is validated against the meta model, then it fails, because the meta model requires at least two participants for the conversation node. However it makes completely sense to have the cardinality 2..* in the metamodel, because there is no meaningful Conversation without at least two participants. A possible solution would be to water down the metamodel. This is not discussed for BPMN 2.0, but may be for XPDL.

So in this watered down metamodel the participants cardinality is only *, allowing for 0 participants as well. The validadion succeeds, but the semantic suffers. Furthermore the check has to be done whatsoever at some stage. So watering down the metamodel is not a good idea in my view. Instead the solution should be a model lifecycle.

In this proposal the model itself has a lifecycle, which can be active or inactive. If the model is inactive, the validation reacts gracefully against the metamodel. Only if the model is active, the validation fails, but this is indeed intended. So it is unter the control of the modeler, if he wants the full strength of the validation or not.

Such a model lifecycle is not planned in BPMN 2.0 as far as I know, but I think it is a good idea and should be considered. There is a MOF 2.0 Facility and Object Lifecycle Specification that might be considered to be used in order not to invent something new that exists already.