BPMN 2.0 is just about to get finalized, and it has surely become some kind of hype. This has led to a couple of critics advising against BPMN, telling us that the new version is too complex for business, or that it is not comprehensive enough for business, which sounds a bit inconsistent. However, I share those concerns and I definetely support every ambition to name the problems about BPMN, as long as it helps us to improve the standard. Since camunda is an active member in OMGs FTF, I know that this is not at all as “impossible” as it is sometimes suggested. We just had to concentrate on the execution in this version, because there is no use in a standard that tries to solve every issue in one version and therefore does not solve anything right.

Anyway, what I don’t like is the feeling that a lot of people criticize BPMN who never used it in practice. Writing books and giving lessons about BPMN is one thing (we do both), but using it in real-world projects is a completely different story. We do this a lot for 2-3 years now, and because of our experiences I cannot agree with the following statements about BPMN:

- BPMN is too complicated for “the business”
- BPMN (2.0) is only for process engine – based projects (i.e. process execution)
- Only programmers understand the concepts of different pools, message flows, event-based gateways etc.

I just came home from a client, a German manufacturer in the metal industry. Our client uses SAP, mostly still R/3. They have acquired a US-company a couple of years ago, and that was the main reason why they decided to introduce BPMN for process documentation and as a communication medium for their IT projects: It is the global standard for process modeling. They downloaded BizAgi, the free modeler, and played around with it a bit. They soon realized that BPMN is quite powerful, but also complicated and hard to learn without external help. I won’t deny this, it’s a fact. So they asked us for a coaching. This is important: Coaching does not just mean training session, but is a combination of an initial training, then let them working with BPMN in practice, with a couple of review workshops in between where we looked over their diagrams. We also helped them to realize their own guidelines for BPMN, which are mostly about “patterns and styles”, as we call it (which is a bit different to Bruce Silver’s “method and style“. though it is an excellent book). Those guidelines were documented in a mediawiki at first, later in Atlassian confluence.

We coached about 30 employees, mostly project managers who work as translators between business departments and the developers. As you can see in the video, they have produced quite a lot of diagrams during our coaching. Of course there have been misunderstandings of BPMN in the first place. But especially the project managers soon realized that they could actually draw quite simple BPMN diagrams for business people and then draw precise diagrams for developers, while using the same notation and often without building up a new process model (model, not view ). After a while they got used to work with different pools, connecting them with message flows, events etc., not only for modeling different companies, but also for different departments and even for specifiying the interaction of end users with SAP. This was the point when they realized how powerful BPMN actually is. When I asked one of them why he decided do draw a diagram with 5 pools, representing the interaction between different Software-Systems and some end users in a wonderful clear and semantically correct way, he just shrugged and said: “Well, I didn’t really think about that. It’s just what’s actually happening there”. Then I knew our job was done.

OK, this sounds like a fairy tale, and maybe I am exaggerating a bit. But it’s basically true, especially the statement I just cited. And they are not even using a process engine, though they do evaluate Netwaver 7.2 these days. You don’t imagine how happy they were when they figured out that you can draw different pools in the process composer as well, repesenting both organizational flows and technical flows in one diagram…

As you may guess, we have certain ideas about how to get the best out of BPMN. I don’t want to claim them the one-and-only-truth, but so far they have proven quite useful. Most of them are described in our book, that is unfortunately only in German. But we are about to put them in software as well! The new Open Source BPM platform Activiti will contain the features we consider helpful for an agile collaboration between business and IT, based on BPMN. And this is not about zero-coding, it is about communication! Here you can find an incident management – process that I have modeled in Signavio Process Editor, of which you can find an open source edition in the Activiti stack. You can even leave your comments by clicking on the elements in the diagram, though this cool feature is unfortunately not part of the oss edition.

So why do I tell you all this, apart from soliciting our stuff . It’s just that I have recently read some blog posts, articles etc. about BPMN, following discussions or even (wannabe) “flame wars”, that deny BPMN’s capabilities to serve as an improvement for business-it-communication. But most of those authors do not seem to have any real project experience with BPMN. Well, maybe I am wrong. I just thought I should tell the world that there are enough people out there who do not have any programming skills at all, but use BPMN the way it is meant to be used, and it works.

So BPMN is no silver bullet, and must be improved, I totally agree with that. But it is a step in the right direction that we should benefit from instead of asking for the business-it-silver-bullet that cannot become reality anyway. Sometimes I think we ask for magic solutions and then moan about getting fooled by vendors…