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.
Elaborating more on what I said before about loosely coupled processes, I want to emphasize today, that the cut of the processes is of major importance – i.e. which parts are loosely coupled and which parts are tightly coupled. Furthermore if process parts are loosely coupled, it is of big importance which process parts are public and which are private. Public process parts constitute a contract, that the other participant can rely on (when to request, when to confirm), while private processes are only needed within the operations of one participant’s organization – for example an approval or a special form of approval that is irrelevant to the other partner. This has these benefits:
- Flexibility: It is possible for one participant to adapt the private process to changes as business requires it without the need to negotiate with the other partner, as long as the change still complies to the public process.
- Stability: The participant can rely on the behavior of the opposite participant, even when the opposite participant makes changes that comply to the public process.
- Visibility: In Process Monitoring internals are not visibible because they should not. It is a decision of discretion which parts of the process should be visible to other partners. However I believe that BPMN 2.0 might be amended for this purpose, because for this it might be necessary that also non-communication activities can be part of a public process.
- Decoupling: The number of private processes that comply to a public process needs not to be multiplied with the number of choreographies, that comply to a public process. Say you have 3 choreographies that you want to combine with 3 private processes. Then without decoupling you have 3*3=9 process models. With decoupling you have 3 + 1 + 3 = 7 process models.
It is important to understand, that the Choreography is an abstract process while the private process is a concrete process – i.e. can be executed by a process engine and has process instances. So the Choreography Model will never be executed by a process engine. It is the summary view of the participants. It never proceeds on it’s own. It proceeds, if one of the participants proceed (as far as the public process is concerned).
If you ever tried to build a central process with process instances that decide about the message flow, you might have tasted how difficult that is. For simple processes this might still be possible. However you always find these difficulties:
- Either the central process does not have enought information to decide – and that are business decisions in the end – or
- The central process needs to know nearly everything.
- As soon as information reaches the central process by means of messages, it is already outdated (because the sender might have evolved in the mean time).
- Also in many decisions it is necessary to involve humans, not just rules.
- If humans are involved, they might not only to decide left-right, but regroup – solve differently (e.g. create return instead of lowering delivery quantity).
This all leads to the conlusion, that I have made for myself: If there is a middle tier, it needs to be a full fledged business application in the end. With business objects, UIs and the like.
Then we have 3 partipants instead of 2 – which is fine. Then we have 2 Choreographies between them, which are still abstract.
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?
- Description of as-is processes within a company and cross companies
- Using the models for subsequent system development. The model is the high-level specification.
- Execution of the model (for example in Appian Anywhere) – probably translation into another execution language like BPEL.
- 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.
