We knew that BPMN needed fixing, but CMMN didn’t fix it enough.  This is another installment in the series on how we need to move beyond process models for automating work.  The last post pointed to limitations in BPMN, and this post covers CMMN.

Moving Toward a Declarative Model

By 2010 we began to understand the flaw of representing a processes as a static imperative diagram. This motivated an alternative approach to modeling processes known as Case Management Model and Notation (CMMN).  CMMN was aimed at meeting more flexible and more tuned to the ever-changing requirements in an organization. CMMN aimed to be a declarative model of the process. It was assumed that’s a problem with BPMN was that activities were linked up in a specific unchanging order like the way a car factory links up work into a single assembly line. This was viewed as too restrictive for case management.

Instead of forcing the process modeler to define a specific order that all of the tasks happen in, CMMN gives each activity a condition upon which they start or complete. One can lay down all of the activities that a case manager might want without linking them together in any particular order. Each activity starts when that condition is met. CMMN is viewed as a more declarative approach to describing the work to be done, allowing specific steps to be completed without regard to the order they are modeled in.

Removing the strict ordering which BPMN enforced on the diagram introduced a new problem for the CMMN diagrams. Now any activity could be started by a condition but the modeler has to correctly specify the condition—and that can be quite a challenge.

• It is a challenge to understand in the abstract all the various reasons why a case manager might need to do a particular activity.
• There is also the problem that the condition that indicates the activity to be performed might not be based on a value already available in the system.
• Making sure that all the appropriate variables with all the correct meanings are present can be a much larger task then simply drawing a set of activities with lines between them.

As is often the case with technology, increasing flexibility in a programming capability brings about the need for more sophisticated programmers capable of using it.

What is Next?

CMMN offers some innovative capabilities to reduce constraints on the order of activities.  This makes it more useful than BPMN, but both modeling formalism fail to meet the need of a dynamic organization for a completely different reason that we’ll see in the next post:   the problem with requiring an omniscient view.