Sandy Kemsley's Blog - Understanding the Why, not just the How, of the BPMN-CMMN-DMN Triple Crown
Sandy Kemsley
Blog

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

By Sandy Kemsley

Read Time: 8 Minutes

Last week was the annual DecisionCAMP conference, where mostly-technical decision management (DM) aficionados gather to talk about the technology, standards and application of DM.

I attended in person last year, but this year was all virtual, and I helped to organize the conference platform using Zoom for live presentations, YouTube for rebroadcast (you can see replays of the presentations there), and Slack for discussion. Although not a replacement for an in-person event, we did manage to capture some of the camaraderie and interactive conversations that would have happened if we had all been in the same room. We even had an after-conference Zoom cocktail hour on the last day!

The great thing about DecisionCAMP is that it’s really a grass roots labour of love by the DM Community site, rather than a for-profit or vendor-sponsored conference. Vendor presenters are requested not to plug their products, so the presentations are a combination of university research, updates and usage of the DMN (Decision Model and Notation) standard, and case studies of practical applications. For a process-centric practitioner/analyst like me, there are always interesting presentations exploring the overlap between decisions and processes. The most noticeable example of this was in a presentation on the “triple crown” of business modeling standards, namely, the Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) and DMN.

In my post on designing for agility, I mentioned that agility often depends on the design decisions such as the split between process and decision logic – what do you model in as a decision, and what do you model as a process – and went into some detail on when to consider splitting out decision logic from a process. Unsurprisingly, many DM practitioners don’t think first about processes, but suggest that you first focus on determining and modeling your business decisions, then build processes to gather the information and execute the steps required to make those decisions. Within those decisions, however, they often use rule flows, which are really processes that link together individual rules/decisions into larger decisions; this starts to muddy the waters in terms of designing decisions and processes, and may spread your processes over two different model types. To this we add case management (CM), which also provides some process and decision modeling, but may also link to DM and BPM models. Three model types based on three standards: this is the triple crown of process improvement standards.

Triple Crown

The standards show how to combine the models: use a decision task in a BPMN or CMMN model to call a DMN model; use a case task in a BPMN model to call a CMMN model; or use a process task in a CMMN model to call a BPMN model. What the standards don’t show is why to combine the models, that is, what parts of the business to model using which standard. Technical proponents of the standards talk about applying the three standards to the “core management practices”, as if businesses were aligned along managing processes, cases and decisions, rather than their actual business capabilities and functionality. From a business operations standpoint, processes, cases and decisions are “implementation details”, not management practices.

There are some general guidelines for combining the standards, such as using CMMN for less structured knowledge work and BPMN for more structured processes, and DMN with either of those for repeatable business decisions. If you have ad hoc processes and decisions, that’s most likely to be modeled completely in CMMN, while repeatable processes with repeatable decisions would combine BPMN and DMN. However, many business scenarios aren’t that clear-cut, and contain a combination of ad hoc and repeatable processes, as well as ad hoc and repeatable decisions.

This presents two challenges.

First, business analysts who are tasked with documenting and analyzing business operations not only need to understand how the business works, but also need to decide how to map different parts of the business operation to the appropriate model type. In the absence of guidance on how to do this, business analysts will tend to use the model type and tool with which they are most familiar, and will tend to create a single model rather than multiple model types. This is how we end up with cases and decisions modeled as incomprehensible BPMN models, or processes being modeled as (non-standard) rule flows combined directly with DMN decisions within a DM tool. The solution to this is straightforward, although not necessarily easy: better training, mentoring and support of business analysts on the use of all three standards together. This is why I advocate a combined business automation center of excellence rather than centres for each skill or product: there needs to be a source of knowledge on how to appropriately combine model types (standards) and related technologies when analyzing business operations and making recommendations for improvements. This should include training on the three standards and how they relate to each other, but also specific use cases and examples of why to use one model type over another for a given scenario. For example, a CMMN model may manage the stages of an overall operation, with BPMN models used to drill into specific functional areas, and DMN models invoked from BPMN for repeatable decisions. Or a BPMN model may manage an end-to-end process, and call CMMN models for exception handling or other knowledge work activities.

The second challenge is that of model understandability by the broader business audience within an organization. The triple crown modeling standards are intended to bridge between business and IT by providing graphical representations of business operations that can be understood by business people while being directly executable for automation purposes; although often used by business analysts and developers, in their simpler forms they can be used as documentation and communication of the business operations to everyone from executives to front-line workers. This type of simplified communication is much more difficult when you have multiple interlinked models with three distinct model types. The viewers need to be able to understand enough BPMN to make sense of a process model, including the fact that “case task” symbol means they need to drill into a CMMN case model for that activity; then, they need to understand enough CMMN to make sense of the linked case model. Same goes for linking from a BPMN or CMMN model to DMN via a decision task, or linking from a CMMN model to a BPMN model. If the viewers don’t understand all three model types and how they interlink (much less why to interlink them at any particular point), the models become less useful as a broader communication tool. The solution to this second challenge is much less straightforward. It’s difficult to mandate or even motivate training on these standards for an entire organization: for business analysts, it’s an integral part of their job, but for everyone else, it’s just another thing that they have to learn but may not see the value. The best solution may be for business analysts within an organization, in conjunction with the business automation center of excellence, to create a simplified template for the three model types that they can use for communication purposes. Not perfect, but don’t let perfect be the enemy of good (enough).

Watch Trisotech’s Presentation at DecicionCAMP 2020

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Learn how it works

Request Demo

Confirm your budget

Request Pricing

Discuss your project

Request Meeting
Graph