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.

The new year arrived. What Do I expect for the new year?

I expect that many of us will have to re-evaluate the things we are doing and how we are doing them. Cost pressure has arrived on a grand scale and will not be released in the coming year. We have to find more effective ways of doing our work or the work of our company. Therefore this will increase the pressure to evaluate and utilize cloud solutions. We can’t affort to ignore the economies of scale.

Furthermore many things will change. Re-organizations will take place. Be it company departments, that are affected, be it the personal job description, be it the project(s) that each of us is part in. Thus, standard processes need to change. They need to be adapted to new situations.  This is the time when BPM as it is known today will be questioned. The lifecycle of a typical BPM project is much too long to react to unforeseen changes, to necessary adaptations and to ad hoc processes. Included in this is the development cycle, if the BPM projects goal is a system specification for an implementation project.

Instead, what we will be looking for are effective tools to manage processes, that have not been foreseen, or at least deviations from known processes. Still we want to monitor what we are doing, how the process progresses, to manage collaboration and to monitor the collaboration. We need the control over these processes, to stay cool in all the turmoil, and still consequently pursue our goals or the goals that have been entrusted to us. Thus, a new breed of software will arise that goes beyond BPM. I expect at the end of the year we will have prototypes and first successful pilot projects for that new breed of software. This will be the foundation for the following three to five years for that new breed of software to be established.

That is what I expect.

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.