BPMN is the global standard for process modeling and one of the most important pieces in the puzzle of successful business-it-collaboration.
As influencing members in OMG, we have been participating in the development of BPMN 2.0, the newest version of the standard, that allows both business modeling and technical execution of processes.
This is the reason why we created, besides other things, the “camunda BPMN-Framework”. This framework is a set of guidelines we use in our BPM projects, and it basically consists of three levels:
- We allow a really simple way of process modeling with BPMN, that should be syntactically correct, but can be semantically incorrect, if you interpret the diagram in BPMN’s formal way. The main purpose of that “level 1“, as we call it, is to give a very quick understanding of a process, even if you have never heard of BPMN before. We call this layer “strategic process model” or sometimes “logical-abstract model”.
- We demand a higher sophisticated way of process modelling on level 2, where you have to model syntactically and semantically correct. You do not have to model executable though, because this layer is mainly for clarifying things like requirements for IT-solutions with process participants etc. We call this layer “operational process model”, or sometimes “physical-concrete model”.
- On level 3, we actually get the process runing. Of course only if we have a process engine – based project, which is not always the case. And sometimes we have parts of the process automated in a process engine, other parts traditionally programmed in some backend-system and other parts that won’t be automated at all and are still completely human driven. THIS is BPM how you can find it in the nasty real world out there 😉 With BPMN 1.2, level 3 is still a technical process execution language like jPDL of jBoss jBPM, and sometimes also BPEL (though we would never recommend to use BPEL, for several reasons. I actually think that BPMN 2.0 has proven us right). With BPMN 2.0, we use BPMN on all three levels of modeling.
There are two important things about this approach: We allow semantical inconsistencies between level 1 and level 2 models, but we DO NOT allow any inconcistencies between level 2 and level 3 models. Actually, level 2 and level 3 are just different views on the same model (though you can argue about that, like Bernd pointed out).
Ah, and there is actually a third important point to remark: It works :-). We have used our approach in quite a lot of project in the last 12 months, and we have also published a book about BPMN (only in German so far), that describes it in detail. Look what Dr. Bartonitz, product manager workflow at SAPERION, has to say about it:
“In all chapters the authors’ profound practical experience with BPMN is obvious. This is especially true for the numerous examples and the corresponding modeling alternatives. Nothing remains unanswered and even the problems of the specification are discussed.”
We are currently implementing our methods in Activiti Cycle, an open source software framework that acts as a glue between the different tools we consider appropriate for the different roles involved in BPM projects (as you may guess, we do not believe in the “one tool for all”-Idea 😉 )
If your are interested in Activiti and/or our services about BPMN, like consulting and training, please have a look at our website.