CMMN for Dummies

26th of September 2017

OMG’s Case Management Modeling Notation (CMMN) has been on my radar of stuff to check out ever since it graced the analysis stage way back in 2014. But I have been put off a bit by Bruce Silver scepticism of the notation, stating that its purpose could just as easily been handled by expanding the current BPMN 2.0 spec with a few new elements. If we look at tooling supporting the CMMN spec, the adoption on this front has also been a bit lackluster. This kicked into a higher gear end of last year when the 1.1 spec came out, with a surprising adoption of CMMN by IBM without them even announcing they had done this. A bit weird marketing-wise.

 

Another trigger for looking at CMMN is already more than a year old. I found myself charmed by the 2016 BPMNext keynote of Lloyd Dugan (Chief Architect of BPM.com:) on the topic, labeled “Simplified CMMN”. His approach to the subject was simple: take 3 BPMN constructs that feel a bit out of place in the spec, and show how they can be more easily represented using CMMN: the event sub process, the event-driven process flow, and the ad hoc sub process. In his view, each of these constructs use exotic BPMN elements to mimic case management that are governed by strange rules no vendor seems to agree on.

So last week, instead of plowing through the spec document, trying to figure out how the elements and rules of the modeling notation work; I decided to follow an introductory course, given by a colleague of several years, Christian Gijsels. During the course, it quickly became clear to me that this notation does not yet have the maturity needed to warrant a wide scale adoption. As Lloyd Dugan states in his keynote, it does not yet reach the ideal of the true stateless Adaptive Case Management (ACM). Christian is an excellent teacher, but you can only work with the material at hand. I did remark the same divide that Lloyd Dugan calls the BPMN 2.0 Conundrum in the classroom, as I was the only person there of a more technical nature. The Conundrum states that modeler purists find BPMN to be to execution-oriented, and that BPMS vendors state that it is not execution-oriented enough.

The course focused on the descriptive level of the notation (in accordance to the levels stipulated by Bruce Silver for BPMN), and went into detail on each of the elements, and how to correctly use them. An overview of each of the elements can be seen in the illustration below, taken from the CMMN Poster made by Trisotech. As the executable level was not included in the course, some of these elements however become difficult to explain, such as for example the Planning Table and the Decorators.

Overview Elements of CMMN

 

The Planning Table is one of those elements I find hard to explain if you don’t take into account the executable level. It would seem only to indicate whether or not discretionary tasks are present in the case. Clicking on the element would switch showing or not showing these tasks. The element is intended to address the scope of the discretionary task. It can be placed on the case elements, and on the task model indicating that the related discretionary tasks are only available to be started when the respective element is active.

 

Another hard to explain element pops up when discussing decorators: manual start and automatic start, which is the default behavior for all tasks. This poses the question how a discretionary task gets started that does not have the manual activation decorator. The answer to this is once again a sinister affair when not taking into account the executable level. The decorators only activate once a discretionary task is promoted to a normal task. This happens when the case worker decides to perform a discretionary task. Which results in this task being moved to the state “enabled”. From there, if it were to have the manual activation decorator , an additional user action would be needed to actually activate the task. The same logic applies for discretionary stages. This can be seen on the lifecycle for this element in the CMMN spec (diagram on the right), which introduces this new state unknown to the BPMN Task lifecyle (diagram on the left).

Lifecycle of the BPMN Task        Lifecycle of the CMMN Task
Lifecycle of the BPMN TaskLifecycle of the CMMN Task

Linked to the Planning Table particularity and the lifecycle, the difference between blocking and non-blocking tasks should really be explained using the lifecycle. When a non-blocking tasks is activated, it is immediately set to completed, while a blocking task waits for the task instance to complete. This results in the consequence that Planning Tables can only be associated with blocking tasks. This already being the third concept relying heavily on the interactions of the lifecycle, I reference once more to our Conundrum, and find myself wondering why people would ever think CMMN focuses less on the executable aspect than BPMN. I would say it focuses even more on this.

A topic on which I am still not clear, is the optionality of sequences. There are a lot of texts stating that the order in which to execute tasks within a case depend completely on the interpretation and knowledge of the knowledge worker, and there is no need to explicitly model them (using connected sentries for example) even if they are there implicitly. For example, it the case would have the tasks “Write Essay” and “Revise Essay”, it is clear that the revision can only happen when the writing has been done. Should we model this relationship, or let the knowledge worker apply his experience? I hope this will become clear in future versions of this notation. Just as I would hope that future versions also provide a mechanism to illustrate the conditions contained within sentries and planning tables in a more visual manner. Now we have to either document them elsewhere, or add them as an annotation.

In conclusion, I put a question mark next to the maturity of the notation, and hope that some of the points I have raised here can be assuaged in following releases. There are some good qualities that might even make it in future BPMN releases, such as the discretionary task. But overall I fear for the moment, the focus lies too much on how the elements influence each other, and their respective lifecycle. Executability is important for me, but the current state of affairs of CMMN seems to make it extra hard to explain to business people what is represented on the diagram drawn in this notation.

Thought ACM BPM