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.

BPMN is very powerful, but applying it in practice can become a big struggle. This does not mean that BPMN does not work, e.g. because it is too complicated for business (see also “BPMN – just DO it“). The important thing is that you recognize BPMN’s complexity which is a direct result of it’s expressiveness, and learn how to use BPMN for your special purposes. This often leads to your individual guidelines for using BPMN, that are based on the standard, enabled by appropriate tooling and defined with respect for your organization’s culture and procedures, e.g. the software development process that is either “waterfall” or “agile”.

We have been using BPMN for several years now, in a lot of projects. Sometimes, those projects were about pure process documenting for business purposes, and some were only about technical process execution, but most of our projects have been a mixture of both. Based on those experiences, we have developed a couple of methods and best practices for using BPMN in practice. They work like a “methodical toolbox”, and most of them are centered around the question of Business-IT-collaboration. For example, on of the biggest problems when you do BPM in practice is that people in business departments cannot read, left alone create, process diagrams that are directly executable. And this won’t change with BPMN 2.0!

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”.


Typical BPM-Roles

• 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.