Even before the Object Management Group (OMG) had released the CMMN Specification in 2014, Camunda had already started building a CMMN engine. In the years that followed, we invested in symbol support, modeling capabilities, and admin tools.
But after a couple of years, we decided that we would not be adding any more CMMN features to Camunda and that it will simply be maintained but not fully supported. This post is about the experience Camunda and its Community had with the CMMN standard and how this led to the choices we made to first embrace and then distance ourselves from CMMN.
The Promise of CMMN
Case Management Model and Notation (CMMN) was introduced as a direct result of the massive popularity of Business Process Model and Notation (BPMN), to address the concept of an unpredictable process.
The BPMN standard was designed to model predictable, repeatable processes. However, this was interpreted to be a rigid notation, which wouldn’t be able to properly represent unpredictable processes orchestrated primarily by a human “knowledge worker”.
CMMN was meant to solve this problem, as a purpose-built notation from a group already fresh off creating a very successful modeling standard. There was a lot of hype around CMMN upon release and conferences were full of industry experts speaking about what innovation possibilities would exist now that unpredictable processes could now be modeled.
In fact, there was so much hype that existing BPMN vendors — Camunda included — were quickly exploring ways to implement tooling for it. Like BPMN, the standard would be a visual model with an executable metamodel, so that what was built in a graphical model would be executable by an engine. Modelers and engines would need to be built and brought to market, but with what seemed to be a very enthusiastic audience waiting for CMMN, this seemed like a solid investment.
Camunda’s Embrace of CMMN
Realizing the potential of an executable case management solution, Camunda’s very own Falko Menge joined the OMG’s CMMN taskforce and, along with its other members, helped shape the standard.
We moved quickly to embrace CMMN. As a company famous for our Java BPMN engine, we decided to start with a CMMN engine. We assumed, as with what happened with BPMN that other vendors were building CMMN modelers. Knowing that they would all be standard compliant, a user could model a CMMN diagram in a modeling tool and then execute that model with the Camunda Engine. In the same year that the standard was released, we released our engine. Reading this blog post from 2014, you get a good impression of how fast we were moving.
The movement was not just about technical implementation — the consulting team (which at the time included me!) was working on learning, creating, and delivering training for people interested in using CMMN. I really don’t want to down-play this, because as a company of about 25 people at the time, this meant that most of our employees were involved in some way with the CMMN implementation.
Earlier in the year, we had started to build bpmn.js, the underlying project now ubiquitous across many BPMN and workflow projects. Having already seen success with it we started to build cmmn.js, so that as well as having an engine implementation we would have a visual representation with the goal of a fully functional modeler, something we would end up achieving as early as version 1.1 of the Camunda Modeler.
The final part of the puzzle came with tooling for use in runtime. For this, we added a CMMN viewer in our admin tool cockpit so that administrators could see what was going on and what had already happened for the cases deployed.
After just a few short years of the CMMN specification being published Camunda had:
- Developed an open source CMMN engine
- Developed a CMMN modeler and viewer
- Created and delivered expert training
- Developed admin tools to make CMMN ‘in production’ more achievable
It’s fair to say that we not only wanted CMMN to be a success – we actively fought for it. We made CMMN the topic of keynote presentations at various conferences and eager to find use cases we also educated all our customers and prospects about it.
The Shortcomings of CMMN
The problems with CMMN came to us slowly over time. Our continued support could be seen as optimism that these problems could be overcome, or even the good old-fashioned sunk cost fallacy. But our first signs that CMMN would take a little longer to embrace than BPMN actually came from community feedback.
From conversations with developers and reactions at training. It became clear that even the most complex case management processes still had quite a lot of predictable parts that CMMN was obviously quite bad at. This means that in real-life use cases, CMMN would have to be used in conjunction with BPMN.
On the surface that isn’t much of a problem. You’ve got BPMN for the predictable, repeatable parts and CMMN for the less predictable, dynamic parts. Best of both worlds – but from the point of view of these second-wave adopters they were asking – Is it worth it to have my team learning a second standard just for the features that CMMN brings? Especially prudent questions considering BPMN was still more than capable of dynamic cases itself. In fact IBM went as far as just taking some CMMN features and adding them to their own flavour of BPMN.
When training people on CMMN it was becoming evident that this notation has a steep learning curve. Unlike BPMN, which we found to be fairly intuitive and easy to follow even with very basic training, CMMN was hard to follow right out of the gate, not being based on existing notations like flowcharts people were confused as to where to start reading. What made things worse is that because of its design, predicting what might happen in a given situation for a given model was actually quite hard this is down to the fact that a lot of behavior is hidden within the rules of CMMN rather than as explicitly modeled symbols. The only way to know how a sentry would trigger for instance would be if the designer had happened to add a text annotation to it.
The reason this was such a big problem is that a fundamental idea of an executable graphical model is that it can act as a bridge between developers and designers by being a universal language. BPMN managed to succeed as a standard primarily due to the adoption it was able to encourage by both of these teams. CMMN, in a lot of cases, was just too hard to understand and too much of an investment to learn — especially for those who had already learned BPMN.
Below is close to the same functionality modeled in both BPMN and CMMN. This type of case is said to be better implemented in CMMN than BPMN. The CMMN model looks like this:
The BPMN model of the same process:
An advantage found by customers’ migration from CMMN back to BPMN was that events are explicitly modeled and labeled. That makes the trigger for an optional task visible, even if that costs a little extra modeling area.
Plus: BPMN has a shortcut notation for collapsed Event Sub-Processes that still shows the triggering event. So it’s as compact as CMMN and still more explicit.
The bottom line was that when compared in the wild people found that BPMN was simply better than CMMN.
So not long after releasing the engine, we reached out to customers for feedback on their CMMN adoption experience. We found that people didn’t want to use an engine from Camunda if they had to use a modeling tool from another vendor. So we expected to see an uptick as soon as we released our modeler. That never happened, sadly. So we went back to asking our customers what they felt was missing for their adoption of CMMN. This time feedback was clear — we needed the same admin features in the cockpit for CMMN as we did for BPMN. But building these also failed to help traction.
It wasn’t just us though. Since picking up and running with CMMN, it seemed the initial enthusiasm had died off and vendors looking to serve that need dropping out. Very few modelers or engines currently exist and fewer and fewer people are looking to engage with CMMN.
Camunda leaving CMMN behind
In September 2019, our Co-Founders released the 4th Edition of Real-Life BPMN and they made the choice to remove the chapter on CMMN. They describe why they made that choice:
We gave CMMN two years to take off, but, within that time, we experienced limited value from CMMN in our projects, especially if you compare it to BPMN or DMN. One observation was, for example, that most logic in CMMN models was hidden in complex rule-sets if certain activities are possible, impossible, mandatory, or unnecessary. These rules were often expressed elsewhere and also not represented graphically. Exaggerating a bit, the CMMN model becomes kind of a graphical bullet point list. So we decided to remove CMMN from this book to not confuse anybody that just embarks on their BPM journey. Instead, we want to emphasize how to tackle unstructured processes with BPMN … and point out the limits of this approach.
It’s worth saying that we could have concluded that, in fact, our software — not CMMN — was what people didn’t want to embrace. But around the same time, DMN was released and we suddenly learned what it’s like to build tooling for an excited and motivated community.
With DMN we had a completely different experience, despite following the same roadmap to adoption. I’ll leave the story of our DMN adoption for another time, but suffice to say — it was, and remains, a huge success for us and the BPM community. So we were left with a simple question: Should we put more time into trying to grow the CMMN community, or should we put more resources into DMN, whose community was already adopting the standard much faster and with more enthusiasm? It’s also our responsibility to customers and the community to avoid wasting time on unwanted features.
The decision at this point was not about if we should stop supporting CMMN; it was holding off on more features until we started to see traction. We never ended up seeing it.
People still use Camunda for CMMN, but most have simply re-built their CMMN cases into BPMN models, which is something that I personally quite enjoyed doing.
The future of Camunda right now is with BPMN and DMN, a decision made for us by the community. And as we’ve established previously, our decisions are largely made as a result of the feedback we receive from community members like yourself. Come talk to us in the forum and let us know what you’d like to see next.