Frank Michael Kraft's Blog

Modeling is always about a certain level of detail. There always is a level of detail below the lowest model level, which is not modeled. But the model or models themselves can span multiple level of details.
This can be done without a special method. Intuitively model designers may create models, which cover different detail levels. They might even define certain levels for themselves. Or they might use a predefined definition of modeling levels. Even then, the relation between those model levels are intuitive in such a way, that there is no formal relationship. The compliance of the models between the different levels is made sure by the model designer or by a governance process.
Im am not speaking here about the BPMN model element sub-process. This is a defined modeling method within one model. I am speaking of two or more set of models, that cover two or more levels of details of a process. This is important, because the sub-process construct has only limited ability to cover certain dependencies on the detailed level. It is for example not possible to define a sequence flow between activities, which are inside different sub-processes, whereas in having two set of models for different layers, it would be allowed to model more dependencies on the lower level set of models.
If it is required to define a more formal relationship between models of different levels, then more needs to be done. It is necessary to identifiy or relate activities with each other on the different levels and to define how constraints defined on the higher modeling levels apply to the lower modeling level. If there is such a definition, it may be possible to check compliance of models of different levels.
However this is an area of research with regards to BPMN. See also Umfrage zu Alignment von Prozessmodellen.
In BPMN 2.0 a similar case is the relation of public abstract processes and private processes.

It is a trend to offer tooling that supports BPMN modeling together with model syntax checking and model simulation. For example see BPMN simulation and syntax checking in ARIS.

Model syntax checking can make sure, that modeling rules, that are statically checkable are kept. It is definitely a help. Especially beginners do not know all of the syntax rules and are guided by the checks. Also experts might find this feature helpful.

Model simulation can be distiguished into

1. Interactive simulation of a single process instance and
2. Cumulative simulation, where many process instances are created and throughput and latency are determined

Especially the ineractive simulation of a single process instance can also be a great help in understanding the model and even the modeling elements and it’s semantics.

The cumulative modeling itself is more like a determination, if the underlying business process is optimal or not.

Another category is thinkable: The verification. While cumulative simulation or single model instance simulation can not ensure, that certain attributes for a process hold, like the absence of deadlocks, verification can. Here it is decisive to find the right attributes of a process that shall be tested.

All of this are technical means to achieve better model quality, and all of these are useful. But none of these is so useful as a governance process. Just because humans can without all of these means do the same thing and they can do even more. They find problems, that even the most sophisticated syntax checker, simulator or verification routine will never find. Also what all of these methods can only find is the consistency of the model in itself (or with another model), but never can test the correspondence of the model with the real world process. This will still be left for humans for all times.

Therefore while all of these means of checking and testing are useful, because they are comfortable, they can or should never substitute a governance process.

A blog entry titled “Model and Pasta” has inspired me to ask: What can happen without model governance?

This may happen: The right means are used for the wrong purpose, and the result is a disaster.

I have already discussed, that the modeling purpose does determine the outcome of a modeling exercise.

So what happens, if you use the right modeling language for the wrong purpose? It ends up in spaghetti models.

If you try to use a BPMN model for the purpose of model driven development – as mentioned in the blog (i.e. to generate coding) – for a business process with many special cases, then the result can be a spaghetti model. But this is not because BPMN is not good, it is because the right means for the wrong purpose has been used.

What is the level of detail that should be modeled? By which modeling technique it should be modeled? These difficult questions are best solved within the scope of a model governance process. As soon as a model become a subsitute for coding only – i.e. it is not human readable any more – it misses it’s purpose. Then it would be better to code. A governance process makes sure, that it is still human readable.

Furthermore it needs to be considered, that BPMN is not the only modeling language in the world and should not be used for purposes, where other means are better. I will elaborate on this later.