This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

This Is A Custom Widget

This Sliding Bar can be switched on or off in theme options, and can take any widget you throw at it or even fill it with your custom HTML Code. Its perfect for grabbing the attention of your viewers. Choose between 1, 2, 3 or 4 columns, set the background color, widget divider color, activate transparency, a top border or fully disable it on desktop and mobile.

BPMN and CMMN Compared

Home/BPMN/BPMN and CMMN Compared

BPMN and CMMN Compared

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.

 

By | 2016-12-29T13:40:01-08:00 May 14th, 2014|BPMN|8 Comments

About the Author:

8 Comments

  1. Alberto Manuel May 16, 2014 at 2:02 am

    Hi Bruce:

    Very enlightening post.

    I am not go deep into the semantics about what is expressive, declarative, whatever, because unfortunately there is a huge pit between what creators of the language do and the needs of the people that need to implement it in the real world.

    I would only point out, that for many years it was argued that a new modeling language was necessary to express the unpredictability of routine work that BPMN could not deal with, and in the end CMMN does not address that important challenge.

    I leave here a pointer to a post about it I wrote last year with some very interesting conversation after it was published. Does combined Case Management Model & Notation fits its purpose? http://ultrabpm.wordpress.com/2013/07/02/does-combined-case-management-model-notation-fits-its-purpose/

    Best

    Alberto

  2. ilya May 19, 2014 at 7:01 am

    Hi

    How would you redesign bpmn interpretation if “Attach Base information” became Discretionary stage in CCMN diagram?

    Thanks

  3. ilya May 19, 2014 at 7:39 am

    I’ve read cmmn spec once again. Seems like my question isn’t valid as stages can be discretionary only as a PlanningTable item of another Stage

  4. Scott Francis May 24, 2014 at 3:22 pm

    Bruce, great writeup – and a great service to BPMN aficionados. One interesting thing – whether CMMN and BPMN are combined or not, it is quite likely (already happening) that software products will include both in the same diagramming solutions… This will cause some challenges for model interchange efforts, I fear.

  5. bruce May 26, 2014 at 8:31 am

    Scott, I agree software tools will combine the semantics, but I doubt they will combine the metamodels and schema — certainly any with a runtime, way too much semantic overlap for that. The notion that BPMN and CMMN are complementary, meant to work together, is preposterous, unless you believe a case calling a BPMN process on a separate runtime is “working together”. As for interchange, CMMN needs to add a few things, like extensibility, like a graphical model, before that can happen. I don’t think interchange was on their mind.

  6. Arash May 27, 2014 at 9:29 am

    Hi Bruce,

    There is one thing that is missing in BPMN and UML which is correlation between Process/Activity Diagram and State Machine.

    Dev and QA always ask me, “What is the Status of the Object/Token at this Task”?
    They want to know [when/how] and [which] task can change the Status of Business Process.

    I agree, CMMN cannot be used for Process Modeling, but I see, it can help for this one – by using “Stage” 😉

    Any thought?

    Thanks,

  7. Murray Macdonald July 30, 2015 at 5:45 am

    Can you tell me where I can get a CMMN Visio stencil?

  8. bruce July 30, 2015 at 2:31 pm

    Not sure about stencil but Business Process Incubator has CMMN tool.

Leave A Comment