Introducing the Case Management Model and Notation standard: CMMN
Blog: Flowable Blog
We’ve been getting increasing interest in using CMMN to
model business solutions, and while many people have some familiarity with BPMN
for business processes, there’s not the same awareness of this other OMG
standard for describing case models.
What we’ll do in a series of blog posts is introduce the ideas and
concepts behind CMMN and also how we’ve learned to use it in action.
The first thing to say is: do not think of CMMN as an
alternative to BPMN. In the same way
that the DMN (Decision Management) standard combines powerfully with BPMN,
using CMMN together with BPMN and DMN gives incredible expressiveness. In a later blog when we talk about some of
the best practice we’ve evolved working with businesses, you’ll see that a
common pattern is to have CMMN cases coordinate BPMN processes.
If you’re coming to this from a BPMN background, or a procedural and process-oriented viewpoint, it’s worth adjusting your mind to think about things in CMMN in a declarative way. CMMN describes what a situation looks like, its elements and phases; what actions and options are available to a person or system to take; and events that might trigger some action. You can think of CMMN defining what you can do in different situations, with BPMN defining how you do it. BPMN tells you how to ride your bike from A-Z, while CMMN says here’s a bike when it’s needed.
There is an overlap in how you can describe a solution in
BPMN and CMMN, with some people saying you can do everything you need with BPMN
(or very occasionally, the other way around). Well, you could do all of it in assembler
programming language if you had the time, but that’s really not the point. One of the main reasons for using models
rather than code to describe a solution is that it’s easy to share
understanding of what’s being described, as well as easy to change
quickly. Yes, you need to rely on
someone providing a fast and scalable tool to run these models, but that’s
precisely what we’re here for!
A lot of introductory waffle so far, but coming to CMMN with
the right perspective is important for you to gain its advantages. So, let’s get into it and explain the main
elements you work with.
Everything about a case is contained in a Case Plan Model, which is depicted visually as a large dossier. A case plan can represent a wide range of business situations, with typical case management scenarios, such as loan applications, insurance claims, customer complaints, and patients in healthcare. That doesn’t mean that conventional case management use cases are the only types of solutions that can be modeled by CMMN. In this video we give an example of using CMMN to manage chatbots.
Elements of a case are often grouped together in Stages, which might be used to represent the high-level phases of solving or completing a case (or situation), or for describing the life-cycle stages of some entity (onboarding, maintaining and offboarding a client or user; controlling a document for Records Management) or an event. Visually, stages are shown as rectangles with cut-off corners (Receive claim in the figure below).
Then you have Tasks of different flavors that represent some actual piece of work. These might be Human Tasks, Decision Tasks, Process Tasks or Case Tasks among others. These are drawn as rectangles with rounded corners. Tasks can be placed inside the case plan or within a stage. An important feature of tasks is that they can be defined as starting manually or automatically, as well as be used multiple times. The other element you’ll see used is a Milestone, displayed as a rectangle with semi-circular ends, which can be used to indicate when some key point in the case has been reached or met.
The final major elements are Event listeners, again with a variety of flavors, including Timer Event Listeners and User Event Listeners, represented as double-line circles. As you might expect, these are used to trigger things when certain events occur.
These items together allow you to describe how bits of work
might be structured together and potentially how they might be triggered. There’s a couple of final bits of glue that
tie things together to make all of it operational. The first of these are Sentries (diamond
shapes) that can be placed on items to determine when they are appropriate to
start or be available (using an Entry Criterion), or when an item should
be stopped or become unavailable (with an Exit Criterion). Sentries provide much of the power of
expressing how elements of a case can come into play. The second bit of glue are Links that
define dependencies between elements, not surprisingly represented by lines
connecting the elements.
Here’s a simple example of a CMMN model showing many of these elements. There’s links to the CMMN and referenced BPMN models at the bottom of this article, so you can download it an run it with Flowable’s Community and Enterprise UIs. Can you work out what will happen when a case is started using this model? If not, you’ll have to wait until the next post when we’ll go into more detail about how a CMMN model executes.
If you want to get further into CMMN, we highly recommend CMMN Method and Style by Bruce Silver.
Leave a Comment
You must be logged in to post a comment.
