IBM’s presentation at bpmNEXT of their implementation of case management inside of BPMN (and their subsequent launch of same at Impact) inspired Paul Harmon to start a lively thread on BPTrends on whether BPMN and CMMN should be merged.  To me the answer is an obvious “yes,” but I doubt it will happen anytime soon.  Most of the sentiment on BPTrends is either against or (more often) completely beside the point.  Fred Cummins, a honcho on the OMG committee that oversees both standards, was sneeringly dismissive of the idea.  BPMN, you see, is procedural while CMMN is declarative. There’s no comparison.  Yeah, right.

OK, so let’s look at the CMMN spec.  Here is the one example of a case model in the spec, which I will explain.

claimscase

The outer container, with the tab that looks like a manila folder, is the case file.  All activities in the case are contained within it.  Isn’t that like a pool in BPMN?  No, nothing at all like it!

The octagons, called stages, are fragments of case logic.  You can nest stages inside other stages.  Isn’t that sort of like a subprocess in BPMN?  NO!  Stop saying that.

The rounded rectangles are tasks, and the icon in the upper left signifies the task type.  I know that sounds like BPMN tasks, but I assure you, NOTHING LIKE THEM!

The rounded rectangles with the dashed border are discretionary, meaning things in the diagram that may not be executed in every instance.  Oh, BPMN has nothing like that!

The # markers mean retriggerable tasks.  In BPMN all non-interrupting events are implicitly retriggerable.  So there’s a big difference right there.

The dashed connectors (I think they are supposed to be dotted) represent dependencies.  The white diamond on a shape means an entry condition, and the connector into that diamond means that completion of the task at the other end of the connector is part of the entry condition.  In BPMN, instead of a diamond at the end of a connector, we have the diamond at the start of the connector, which is a solid arrow… so NOTHING AT ALL LIKE THIS!  Well, actually there is a difference, since there could be other parts of the entry condition, such as “a user just decided to do it.”  And you’re right, BPMN sequence flow can’t do that!  But a BPMN Escalation event subprocess can do that.

The double rings that look like BPMN intermediate events are CMMN event listeners.  The two shown here mean “a user just decided to do it.”  Kind of like an Escalation event sub in BPMN.  The black diamonds are exit conditions.  So this diagram means a user could decide to set the milestone Claims processed and close the case, or just close the case.

Here is the same case logic in BPMN.  What???!!

claimsbpmn

The operational semantics are essentially identical. They both include activities initiated ad-hoc by a user and possibly other conditions, sometimes constrained by the current state of the case/process.  Neither one really communicates the event dependency logic clearly in the diagram, although CMMN does a better job:  A BPMN Escalation event could represent ad hoc user action or an explicit throw, and Parallel-Multiple event could represent any event plus condition; CMMN at least tries to suggest the dependency with a connector.  But honestly, representing this type of logic clearly in a printed diagram is really hard!

Actually there is a lot in the CMMN spec to like, and it would be good if BPMN were expanded to include it.  Timer events, for example, are much more usable.  In BPMN, the start of the timer is the start of the activity or process level the event is attached to, and the deadline is a literal value.  In CMMN, the start is some selected event and the deadline is an expression.  Is that something that only “knowledge workers” need, as opposed to the mindless droids that use BPM?  I doubt it.  State changes in any case information – not just “documents” as some would have you believe, but data as well – can trigger case activities, and BPMN should have that also.

Here is the simple truth: There is a mix of procedural and declarative logic in most business processes.   CMMN expresses the declarative logic a bit better than BPMN, but only “hints” at the simplest procedural logic, as you see in the claims example.  As anyone who has been through my BPMN Method and Style book or training knows, the key to communicating process logic in a diagram is labeling, and CMMN fails totally there.  The thing most in need of labeling – the dependency connector – doesn’t even exist in the semantic model!  An entry condition merely has a sourceRef pointer to a task or other precursor object.  No connector element means no name attribute to hold a label.  I looked through the schema; maybe I just missed it…  Also, CMMN for some unexplained reason has NO graphical model at all!  After a false start, BPMN 2.0 eventually came up with a nice solution for that, completely separable from the semantic model, but CMMN didn’t use it (or substitute something else).  I guess model interchange between tools wasn’t a priority there.

The bottom line is that both BPMN and CMMN would benefit by unification.  The separation is purely vendor-driven and counterproductive.