Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN 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).