Business Process Model and Notation (BPMN) is the fundamental standard ubiquitous throughout Camunda’s products. It can perfectly define and execute predictable and repeatable processes. Which is good, because that’s what it was designed to do in the first place. Case Management Model and Notation (CMMN) is another standard also from the OMG that was originally designed to be more dynamic than BPMN for less predictable processes. While BPMN was designed to have a process engine decide on how things should proceed, the fundamental change for CMMN was it wanted to give more control to users to decide (within defined boundaries) what should happen next.
I’ve written about CMMN before, specifically regarding the decision Camunda took to stop supporting it. In that post I didn’t go into too much detail about the features, symbols or patterns in Case Management Model and Notation that are said to be key in making it stand out for those dynamic use cases that CMMN was designed for. Some of those features are indeed really handy for cases like the often cited medical treatment examples, but I would still argue they aren’t good enough to make someone who already understands BPMN want to spend the effort of learning a new standard. I also feel that by far the greatest drawback is how quickly a CMMN model can become overly complex, but most of all—the belief that BPMN cannot be used for dynamic processes is simply wrong.
In this post I’ll discuss the fundamental features of CMMN as well as larger examples and in all these cases how BPMN can match CMMN in dynamism.
Table of contents
CMMN vs BPMN
There are some features in CMMN that don’t exist at all in BPMN, but that doesn’t mean that you can’t model them quite easily with existing symbol sets. In isolation, I really like some of the ways CMMN can reduce a lot of complexity into only a few symbols, but the downside of this is that as you grow a model, the amount of complexity hidden behind the symbols grows to a point where being able to read the model can be extremely difficult. In the following examples I’ll slowly grow a model showing a BPMN alternative to each model. I’ve always thought that while BPMN is far more verbose, the explicit nature of the standard means that scaling a model’s size doesn’t make it more difficult to read—and the same can not be said for CMMN.
A really nice function of CMMN is its ability to define a task as being “optional” (I would really have liked to see this in BPMN). CMMN calls these discretionary tasks. Visually, they’re just tasks with a dashed line.
The BPMN alternative is far more verbose, requiring a non-interrupting start event on an event subprocess. The functionality is almost the same. The only difference being that in the CMMN version that task can only be activated and completed one time, while the BPMN equivalent doesn’t enforce that requirement.
When I started learning CMMN, it was constructions like this that gave me the initial impression that there was a place for CMMN within the workflow modeling lexicon. It’s simple to build, easy to understand, and the BPMN equivalent—while functional—is not as easy to understand at all. But this is more of the exception rather than the rule.
Required and repeatable tasks
CMMN added new task markers, the two standouts are the required `!` marker, denoting a task that must be completed, and the repeatable `#` marker, which shows a task that can be completed multiple times.
The below example also shows a few other CMMN symbols, but these won’t be new to any BPMN users. There’s a stage (which looks and acts a lot like a subprocess), a sequence flow, that shows a dependency between one element and another and finally a sentry. A sentry is a diamond that acts like a conditional event to activate the symbol it’s attached to.
This is unarguably a dynamic case, and a very good example of what CMMN is designed to excel at.
- An optional task
- A task that can be done any amount of times
- A required task that opens optional options when completed
But you look at the BPMN equivalent below—it’s not only fairly easy to replicate, but the complexity of the model as compared to the previous BPMN example hasn’t really escalated at all. The CMMN model on the other hand actually looks far more complicated.
Milestones and exit criterion
Next, we can improve the example by trying to make our model both a little more dynamic and a little more clear for the reader.
To help make things easier to follow, CMMN has milestones. These act in the same way as none-intermediate events in BPMN but when combined with sentries—they give the reader a visual indicator as to the consequences of certain changes in the state of the case.
In this case, I’ve added it to show that when `Final Check Two` and `Final Check One`are completed the milestone will become active.
There’s one more thing a milestone can do by virtue of its activation, and that is to trigger exit criteria. Which is a lot like ending a process with a conditional event in BPMN.
The BPMN model once again executes more or less the same logic, using more explicit symbols and more predictable flows.
A parallel gateway shows a much clearer indication of what is expected after the completion of the “Final Check” tasks. Although I added the milestone as a non-intermediate event, it is actually unnecessary because all the necessary context to understand what’s happening is already evident by looking at the parallel gateway.
Comparing a real CMMN example to BPMN
For the final models, I went looking for examples in the wild. Where CMMN is being used in a clear cut case of what it was designed for. Anyone who has ever given a cursory look into CMMN might know, but the boilerplate example is to use CMMN for cases of medical intervention. These systems are traditionally thought to be too complex or dynamic for a process to handle and a user should be given more power to decide on how a case can proceed.
I found the above model as part of an academic paper and below I’ve created a BPMN equivalent. They look very different and while I believe the BPMN one is far clearer, that’s quite a subjective opinion. Instead look at them both and consider that one of these models is designed to be doing something that the other supposedly cannot. It’s simply not the case. They look like two standards both capable of modeling the same thing using different symbols.
This post has explored how CMMN is capable of modeling a lot of complexity, but not without sacrificing clarity. I’ve also shown how there are in fact good use cases for CMMN out there, but nothing that I believe can’t be done at least equally clearly in BPMN. Finally, I’ve hopefully been able to prove my view that CMMN is not as ubiquitous as BPMN, harder to learn than BPMN and can’t even offer the visual clarity you’d hope from a purpose built modeling standard. Considering all that, CMMN isn’t at all necessary or even all that helpful for successful case management solutions.
Curious to see how well BPMN can do in a real healthcare scenario? Check out this case study from Babylon Health to see how BPMN helped them deliver the right treatment to individual patients with clinical safety.