Frank Michael Kraft's Blog

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.

There is also a summary of process modeling purposes at Bruce Silver’s Blog.

http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-process-modeling-with-bpmn/

The three levels
1) Descriptive Modeling
2) Analytical Modeling
3) Executable Modeling
Match quite nice with the levels 1-3 that I proposed. However I named them purposes and not levels, because when we have levels I think of a stack of models, each in different levels and somehow related – which is not the intention here. Yes, having different purposes might imply having different levels, but not necessarily.
I think that Bruce Silvers’ level 2 modeling, though keeping the validation rules of BPMN, might have some difficulties in expressing all the special cases. Bruce Silver states, that on Level 2 both conditions need to be fulfilled:
a) The model must validate against BPMN rules and
b) the model must cover the special cases of the business process
I see especially b) as very challenging. At least if we assume that the resulting model should still be readable in the end.
About Bruce Silver’s Level 3 I want to say: I think that many business processes cannot be executed by a workflow engine (as a BPMN engine).
Therefore I have proposed the 4th purpose: Model Driven Development. This means creating for the purpose of using them in some development environment where models can be refined for implementation – may be with the help of more detailed models, which would validate against the BPMN models, but be not limited to it.
I am not saying, that the detailed models should or are necessarily BPMN models. But there is a difference between this modeling purpose and the modeling purpose of Bruce Silver’s level 2) or 3), because in this 4th purpose it is not necessary to model all the special cases in advance, because they can be added in the detailed model. This makes the models more readable. On the other side the models of purpose 4 have sticter rules than those 1) – because they need to define the constraints for the lower level models.
In practice one would probably start with purpose 1), then might go into 2) for simulation purposes. For selected processes, he would go into 3) – but only for those parts of a process that should be executed as workflow in the end – which is the lesser number of processes I would say. Then he would go into 4 for the other (non workflow) processes and would try to realize more detailed models. Possibly someone else would to this job. Because then the detailed modeler would find some inconsistencies or ambiguities in the overview model and needs to correct them (of course if he can make some assumption about what is required).

An important factor of how a BPMN model or generally spoken a process model would look like depends on the purpose for which the modeling is done.
I can think of mainly four purposes:

1. Documentation
2. Specification – i.e. modeling for later manual implementation
3. Execution – i.e. modeling for executing the modeled process by a BPMN execution engine (Workflow)
4. Model Driven Development – i.e. the model is used in an semi automated development process

Apparently most BPM models today are done for documentation.

With regards to documentation (only) projects I can mostly speak of my practical experience with bottom up documentation. This means, that I mostly do not go to a company and analyze the processes of the company and document them – although I did. Since I work in development, the generalized process knowledge is already coming through many channels into the development – and is in big parts already there for years – which is reflected in the code of the business software solutions, that we build. So the bottom up approach is documenting the processes which are already running in the software that has been developed.

I found in this that bottom up documentation is all about simplification. Because the software is so powerful with regards to the processes and all the special cases, for example cancellation and side paths of the process, modeling all of these variations with BPMN would result in very many detailed models, where one might lose the overview. So it is about setting priorities instead of documenting every detail.

Good priority may be the “sunny day” case – the good way forward of a business process – without special cases, interruptions, cancellations and the like. If it is a big software package, then this is already a lot of models.