CMMN Method and Style – Part 1

Case Management Model and Notation (CMMN) is the poor stepchild of process modeling standards.  It was developed a decade ago, around the same time as BPMN 2.0 and largely as a reaction to it by vendors who believed that “real” business processes were about knowledge workers interpreting documents, not web services orchestration following rigid rules.

In case management, the order of actions typically cannot be precisely defined at design time, and many different things happen concurrently.  The list of available actions changes with the state of the case, and initiation of those actions is typically the result of manual case worker decisions.  Such a different process paradigm demands a different standard.

There is some merit to that thinking, but in the meantime just a few tools have adopted CMMN.  Part of the problem was self-inflicted.  Unlike BPMN, which sought to emulate the familiar look of swimlane flowcharts, CMMN went for a decidedly unfamiliar look.  Unless stakeholders make a modest effort to learn the language, the meaning of a CMMN diagram is utterly lost on them.  Adding to the difficulty is the fact that case logic defined in the model is declarative, not procedural.  That means that each case task and stage (phase) independently defines the conditions under which it is available to start or complete.  That gives the case logic flexibility lacking in BPMN, but at the expense of intuitive visual communication.

I decided to take on this challenge with a new book, CMMN Method and Style, that attempts to make case management diagrams more comprehensible and the standard more widely adopted.  This post provides a very brief introduction.

CMMN Basics

In a CMMN diagram, or case plan, actions are represented by tasks (rounded rectangles).  The head-and-shoulders icon means a human task; other task types invoke a BPMN process, a DMN decision, or a CMMN subcase.  Tasks are contained in stages (rectangles with clipped corners).  The oval shapes are milestones, a type of event signifying some state of the case has been achieved.  Tasks, stages, and milestones collectively are called plan items.  Symbols at the bottom of a plan item indicate additional attributes.  The triangular Play symbol indicates the plan item is manually started.  The hashtag symbol indicates it is repeatable.  The exclamation point indicates it is required, meaning it must be completed in order for its containing stage to complete.

Tasks and stages evolve through a sequence of lifecycle states: Available, Enabled (if manually started), Active, Completed or Terminated.  A task or stage becomes Available when its containing stage becomes Active.  (The case plan as a whole – the tabbed folder shape – is considered the outermost stage of the case.)  Each lifecycle state transition generates a standard event that can trigger advancement of the case logic.  Diamond shapes called sentries on the boundary of a task or stage represent entry or exit conditions triggered by a standard event and further controlled by a Boolean expression of case data.  Once it is Available, a manually started task or stage becomes Enabled when its entry condition is satisfied, and then becomes Active when manually started by a case worker.  If not manually started, it becomes Active as soon as the entry condition is satisfied.  A stage may be marked Completed as long as none of its contained plan items are Active and all of them marked required are either Completed or Terminated.

Case data and documents, collectively called the case file, are available to all plan items at any time.  Like plan items, each case file item also progresses through a series of lifecycle states, and those state transitions likewise generate standard events that can trigger plan item entry and exit conditions.  Each file item is assigned a datatype.  In Trisotech, these are modeled as FEEL item definitions as they are in DMN and BPMN models.

All of that is from the CMMN spec.  Method and Style is my own methodology layered on top, aimed at making the logic as clear as possible from the printed case diagram.  It uses milestones and sentry labels – which appear in the diagrams – to signify the end states of stages and tasks, without requiring modelers to explicitly define case variables for them.

Case Modeling Styles

When creating case models in CMMN, there is no single “best” style for representing the logic.  Some modelers may consider progression of the case to be entirely based on the judgment of case workers rather than events and rules specified at design time.  What happens in what order is not revealed by the diagram, even though this permits illogical ordering of tasks.  The case worker is simply assumed to know the correct thing to do next.

Others may take the opposite point of view, describing most case logic explicitly using event-condition-action (ECA) via lifecycle events and sentries.  While intrinsically more flexible than BPMN, CMMN models in this style are similar in that they try to reveal all possibilities of “what happens next” through the diagram.

Scenario: Write a Report

To illustrate, let’s look at the similarities and differences when applied to a very simple case model, writing a report.  Here is the scenario:

1. The report may or may not require research. If it does, tasks include researching the topic and organizing references.
2. Preparing the draft is always required. It includes writing the text, also always required, and generating the table of contents.  If the report contains graphics, additional tasks include creating the graphics, integrating them with the text, and generating a list of figures.
3. Periodically the draft in progress is reviewed. Tasks include seeking comments, discussing possible changes, and verifying spelling and grammar.
4. When ready, the draft is submitted for approval. The case completes successfully when the report is approved.  It is also possible that the Approver cancels the report.

User-Driven Style

In the purest user-driven style, all choices of what to do when are made by case workers at runtime using their judgment about what needs to happen, as illustrated below.

The stage Do Research is discretionary (dashed border), meaning it occurs in some instances and not in others, as determined by an applicability rule defined in the planning table indicated by the small grid on the case boundary and described in Method and Style using a text annotation on the stage.  If research is required, this stage transitions to Enabled when directed via the applicability rule, awaiting manual start by a case worker.  When it starts (becomes Active), its tasks Research Topic and Organize References become Enabled, awaiting manual start.  As drawn here, whether this stage ends in Completed or Terminated does not affect case completion.

Since it has no entry condition, the stage Prepare Draft is Enabled as soon as the case becomes Active.  Since it is marked Required, the case cannot complete until this stage is Completed or Terminated, and the stage cannot complete until its Required task Write Text is Completed or Terminated.  Other than that, the order in which its contained plan items are performed is determined entirely by the case worker.

The contained stage Add Graphics is discretionary, as it applies only to reports that contain graphics.  Again, the applicability rule is defined in a planning table, here on the containing stage Prepare Draft, and visualized in the diagram by a text annotation on the discretionary stage.  If the applicability rule is true, Add Graphics is Enabled when Prepare Draft becomes Active and must be manually started by a case worker.  Its tasks include Create Graphics, Integrate Graphics, and Generate List of Figures.

Prepare Draft also includes the task Generate ToC, which could be considered “optional” since it is not marked Required.  In practice there is little difference between such an optional task and a non-Required discretionary task.

The case also contains the task Approve report.  It is not enclosed in a stage, meaning it becomes Enabled as soon as the case is Active.  Presumably it would not be started until a draft of the report was complete or nearly so, but this is not required by the case plan model.

The milestone Report Approved is marked Required, meaning the case can end in the Completed state only if this milestone is set manually by a case worker.  Alternatively, a case worker in the role Approver may terminate the case at any time, depicted as a user event listener triggering an exit sentry.

In the diagram above, all the stages and many tasks are marked Repeatable.  Since no entry conditions are specified, that means that after being marked Completed or Terminated a plan item immediately becomes Enabled again.  The effect of Repeatable here is simply protection against a case worker mistakenly completing or terminating a task or stage.  Technically, this creates a new instance of the plan item, as CMMN has no way to “reopen” a completed or terminated plan item, but we assume the artifacts created by the original instance are available as file items to the new instance.

ECA Style

The ECA style, in contrast, represents the allowed order of plan items explicitly as much as possible using lifecycle transitions and sentries.  It allows for a great deal more automated behavior than does the user-driven style, but at the same time may be more difficult for stakeholders on the business side to understand.

The same scenario is illustrated in ECA style in the figure below.  Here the order of case actions is explicit.  Because it is the plan item’s complete event that usually triggers what happens next, this case could probably be modeled more simply and clearly as a BPMN process.  Let’s take a closer look.

When the case first starts, the only plan item enabled is Plan Report, as all the others have entry conditions.  Plan Report creates the file item Plan, indicated by the page symbol with a dotted arrow from the task.  The dotted arrow in the spec is an association, just a diagram annotation, but in Method and Style we say a task that creates or modifies a file item should display this connector. File items are represented in the case diagram when their values or events are used in the case plan logic.  We need something like this to say that Do Research and Create Graphics are only performed under certain conditions.

When Plan Report is Completed, its complete event triggers the sentry on Prepare Draft, making that stage Enabled.  Every entry condition has two components: zero or more ON-parts, dash-dot links to a plan item or file item, labeled with a standard event, signifying when entry occurs; and an IF-part, a Boolean expression of file item values, signifying whether entry occurs.  In Method and Style, the IF-part condition is represented by the label of the diamond shape.  No label means the IF-part condition is satisfied by default.  Here there is no label, so Prepare Draft becomes Enabled when Plan Report completes.  Once Prepare Draft is manually started, it becomes Active and all its contained plan items become Available.

The contained stage Do Research has an entry condition with no ON-part, meaning its IF-part condition is evaluated as soon as its containing stage Prepare Draft becomes Active. Here the IF-part references the Research required component of the file item Plan.  Do Research is Enabled only if Plan.Research required is true.  Similarly, the task Create Graphics is Enabled only if Plan.Graphics required is true.  Note that the entry condition for Integrate Graphics has two ON-parts, meaning both Write Text and Create Graphics must first be completed.

If Create Graphics is not performed, then Integrate Graphics and Generate List of Figures are not performed, either.  The task Generate ToC has two entry conditions, meaning it is Enabled either when Write Text is Completed and there are no graphics, or when Integrate Graphics is Completed.

None of the plan items of Prepare Draft are Required, meaning the stage may be declared Completed whenever none of its plan items are Active.  This triggers the stage Review draft, which contains tasks Obtain comments, Discuss changes, and Correct Grammar and Spelling, performed in parallel.

A basic concept of BPMN Method and Style is the end state of a process or subprocess, indicated by the end event reached and signifying how did it end, successfully or in some exception state.  CMMN Method and Style uses a similar idea for stages, with milestones playing the role of end events.  Here Review draft has two manually set end state milestones, either Draft complete or Revision required.  Technically a milestone is an event, but Method and Style assumes each milestone in the Completed state is listed in an implicit Milestones file item that can be tested by sentry IF-part expressions.  If the stage ends with Draft complete set, Approve report is triggered.  If it ends with Revision required set, it goes back to Prepare draft.  In order to prevent a “zombie state” in which the stage is manually declared Completed without setting either milestone, we also need to add the Required milestone Review Complete, which depends on setting one of those two end states.

In Method and Style, tasks also have end states, captured in the implicit file item [taskname].end.  Approve report has task end states “Approved” and “Not approved”, which are tested by sentry IF-parts to trigger either the milestone Report approved or the milestone Changes required.  These milestones act as end states of the case as a whole, although the case can end in the Completed state only when Report approved is set.  Changes required goes back to Review draft and then likely back to Prepare draft for revision.

As in the user-driven model, an Approver also can exit the case at any time.

*                                   *                                 *

Where the User-driven style requires less explanation, the logic of what happens under what conditions is not contained in the model.  It’s entirely inside the heads of the case workers at runtime.  The ECA style makes that logic explicit, but the declarative modeling paradigm takes some getting used to.  In many case models, both styles are used, with User-driven in some stages and ECA in others.  Method and Style adds some extras that put needed logic details in the diagram, where they can be seen by stakeholders other than those who created the model.

As you might expect, there are style rules as well, with style rule validation built into the Trisotech software. 

Read part 2