They said it would never happen, but it has.  CMMN Method and Style is now available.  Here are the Table of Contents and Preface.

Table of Contents

Preface. v

• Method and Style. vi
• BPMN Method and Style. vi
• CMMN Method and Style. vii
• Structure of the Book. vii
• Acknowledgments ix

1. What Is CMMN?. 1

• What Is Case Management?. 1
• Applications of Case Management. 2
• Evolution of Case Management. 3
• CMMN Overview.. 8

2. Case Plan Elements. 11

• Tasks 12
• Stages 15
• Case Behavior Overview.. 17
• Case Behavior and the Task/Stage Lifecycle. 20
• Entry and Exit Conditions 22
• Control Symbols 24
• Milestones 27
• Event Listeners 28
• File Item Triggers 31
• Diagram Annotations 31

3. Case File Model. 33

• Case Variables as File Items 33
• Case File Item Definition Type. 34
• File Item Lifecycle. 36
• Method and Style: Implicit File Items and Related Case Logic. 36

4. Modeling Case Logic. 41

• Stage Start and Completion. 41
• Using CMMN and BPMN Together. 42
• Avoiding Zombie States 44
• Manual Termination. 44
• Method and Style: Task and Stage End States 45
• Stages as Exclusive Case States 51
• Plan Items as UI Elements 52

5. Styles of Case Modeling. 55

• Scenario: Write a Report. 55
• User-Driven Style. 56
• ECA Style. 58
• Hierarchical Style. 60

6. CMMN by Example: Social Care. 65

• Scenario. 65
• Case Model Structure. 66
• Intake. 66
• Social Care. 70

7. Style Rules. 73

• Labeling. 73
• Sentries 76
• Repeating Items 80
• Autocomplete. 83
• Deadlocks (Zombie States) 84

8. Declarative Modeling Patterns. 87

• Sequence Flow.. 88
• Branch on End State. 88
• Parallel Split. 89
• Conditional Split. 90
• Unconditional Merge. 92
• AND-Join. 93
• OR-join. 94
• Start-Start. 95
• Start-Finish and Finish-Finish. 95
• Start on Context Activation. 96
• Enable After Delay. 98
• Enable No-Later-Than. 99
• Enable No-Earlier-Than. 99
• Finish No-Later-Than. 99
• Event Gateway. 100
• Loop. 102
• Multi-Instance Sequential 103
• Instances Overlapping in Time. 104
• Multi-Instance Parallel 105
• Ad-Hoc Task Injection. 106

9. Executable CMMN with Method and Style. 107

Index. 109

About the Author. 113

Preface

Those familiar with my past writings may be surprised that I have written a book on the Case Management Model and Notation (CMMN) standard, because when CMMN was launched in 2014, I was unenthusiastic and vocal about it.  Business process modeling already had a standard – BPMN 2.0 – that was widely adopted by both business and technical modelers.  Why did we now need a different one?  CMMN’s creators maintained that it was necessary because there are many kinds of processes that BPMN is unable to handle.  Although BPMN could have been tweaked to handle them, those tweaks never happened.  In my opinion, they never will; the BPMN 2.0 spec appears to be forever frozen in stone.

Actually, CMMN’s backers have a valid point.  BPMN does have limitations, and in my BPMN Method and Style training we discuss them.  Those limitations mostly stem from the fact that BPMN’s conception of a process is quite narrow, much narrower in fact than that of BPM Architecture and most other areas of business process management.  For example, many of the “processes” listed in APQC’s Process Classification Framework are not what BPMN would call processes, and many cannot be modeled in BPMN at all.  CMMN, on the other hand, could handle them.  That’s reason number one for my change of heart.  Instead of describing the logic procedurally – following a defined sequence of steps – CMMN logic is declarative, each case element independently defining its own prerequisite conditions.  That gives it great flexibility, but makes the logic harder to communicate clearly.

A second reason was the observation that leading innovators in business process technology are now beginning to adopt and promote CMMN.  For example, Trisotech’s Digital Automation Suite uses CMMN in conjunction with BPMN and DMN to create a business-friendly model-driven platform based entirely on industry standards.  Also, at the annual bpmNEXT conference[1] that I host together with Nathanial Palmer of BPM.com, Flowable’s CMMN-based demos[2] have walked off with the Best in Show award two years in a row.  And in the past year, FICO, a leading decision management vendor, has made CMMN a key part of its solution development methodology, called xDRAW.[3]

After years of relative obscurity, CMMN is finally attracting the attention of leading technology innovators, completing the triad of business modeling and automation standards from the Object Management Group (OMG) – BPMN (process modeling), DMN (decision modeling), and CMMN (case modeling).  Trisotech, Flowable, and FICO are all basing their business automation projects on that triad.

Method and Style

Once I accepted CMMN’s rationale, I could see that it was badly in need of a book.  You cannot learn a modeling language from the spec, which is written for tool vendors, and a quick check of Amazon.com revealed zero CMMN books in print.  Moreover, CMMN was in need of Method and Style as well, an approach I developed over a decade ago for BPMN and have since applied to DMN.  Whereas the requirements specified in OMG’s business modeling standards emphasize precise execution semantics, modelers need something more: the ability to communicate the underlying logic to all stakeholders from the diagrams alone, without defining execution-related details usually left to programmers.  That’s what Method and Style tries to provide.

Method and Style is a set of modeling conventions layered on top of the official rules of the standard.  Created for non-executable models defined by business users, Method and Style encourages models that communicate the logic clearly and completely through the printed diagrams alone.  Although all three of OMG’s business automation standards in theory claim two objectives – visual communication of the model logic through diagrams and tables, and direct execution of the model logic on an automation engine – the rules of the specs, in reality, concern only the latter.

Having delivered BPMN training since 2007, I know that just a tiny fraction of BPMN models are intended for execution.  Instead they are used for process documentation, analysis, and improvement.  For those users the only thing that counts is what is displayed in the diagrams.  From the perspective of the spec, defining the process logic precisely requires adding variables and executable gateway expressions, details normally delegated to programmers and which do not appear in the diagrams.  That often leaves the process logic ambiguous and incomplete to stakeholders without direct access to the modeling tool.

BPMN Method and Style

Method and Style takes the view that any model details important to understanding the logic must be expressed somehow in the diagrams.  Thus BPMN Method and Style imposes various conventions that imply the existence of certain variables and gateway expressions simply from the labels of end events and gates.  Those conventions make the process logic clear from the diagrams alone, with requiring modelers to actually define variables and executable expressions.  In addition, various icons, symbols, and labels called optional in the spec are required by Method and Style.  Method and Style’s conventions can be formalized as style rules – in addition to the rules of the spec – that can be applied as validation checks on the models.

CMMN Method and Style

With CMMN, the situation is similar.  Making the case logic complete and unambiguous requires definition of variables and executable expressions for the entry and exit conditions of case model elements (called plan items), details that normally are not displayed in the diagrams.  CMMN Method and Style applies conventions that imply the existence of certain variables and condition expressions based on labels of diagram elements, such as milestones and sentries.  With these conventions, a wide variety of case behaviors can be described unambiguously from the printed diagrams alone.

Since CMMN’s declarative logic paradigm is unfamiliar to most users, diagrams are prone to modeling errors, such as tasks that repeat forever with no way to stop except manual termination, or deadlocked stages, unable to complete.  Many such errors can be detected by the style rules as well.

Some tools, like those of Trisotech, provide automated model validation based on the style rules.  When Method and Style’s rules are enforced by model validation, my own experience of BPMN and DMN training has shown them to greatly improve model quality and clarity.  Thus, in addition to explaining CMMN from the perspective of the spec, this book explains the Method and Style conventions, including the style rules.

Writing the book also revealed occasional inconsistencies and ambiguities in the CMMN spec itself, motivating a series of discussions with both Trisotech and Flowable about what the spec actually intends and how to handle the problem areas.  CMMN Method and Style reflects the consensus of those discussions.

Structure of the Book

The book explains the concepts of CMMN, its basic elements, and usage of these elements in various styles of case management models.  In addition, it explains the Method and Style conventions, the reasons for them, and their representation in the diagrams.

I recommend that readers go through the chapters in order, although Chapter 8, Declarative Modeling Patterns, may serve as a helpful reference for certain behaviors shown in earlier chapters, as well as those the modeler may encounter in practice.

Chapter 1, What Is CMMN?, shows how case management fits in the business process management landscape.  We describe how cases differ from the “structured” processes of BPMN and provide examples of typical case management scenarios.  We then discuss how the CMMN standard came about, in many respects as a reaction to BPMN.

Chapter 2, Case Plan Elements, explains the building blocks of a CMMN diagram, or Case Plan Model.  The case diagram shows the various actions that could take place in each state of the case, as well as how completion of those actions, in combination with other events, drive overall case behavior.  We discuss the various types of tasks, the actions of a case, and stages, containers of the case plan elements available in a particular state of the case.  In this chapter we also explain CMMN’s declarative logic paradigm, based on the lifecycle state of tasks, stages, and other model elements, as well as CMMN’s event-condition-action mechanism.

Chapter 3, Case File Model, discusses case data elements, known collectively as case file items.  Not all case file items are visualized in the diagrams, but file item standard events – such as create, update, or delete – are displayed in the diagram if they trigger advancement of the case plan.  We also introduce the Method and Style concept of implicit file items that capture the state of a task or milestone for use in condition expressions in event-condition-action logic.

Chapter 4, Modeling Case Logic, shows how the various diagram elements are used in combination to describe activity flow in a declarative manner.  We discuss the conditions under which a CMMN task or stage starts and completes and the benefits of using BPMN and CMMN in combination.  We extend BPMN Method and Style’s concept of end states to tasks and stages in CMMN, including their visual representation in the diagrams.

Chapter 5, Styles of Case Modeling, illustrates three basic styles used in CMMN models: user-driven, event-condition-action (ECA), and hierarchical.  Typically, a CMMN model contains a mix of all three styles.  In the user-driven style, the case advances based on manual user action, selecting from a menu of available actions such as completing or terminating a task or stage, or starting an available task or stage.  In the ECA style, the case advances automatically based on declarative logic defined at design time, in which lifecycle events of plan items and file items, in combination with file item conditions, determine whether a task or stage starts, completes, or exits.  In the hierarchical style, stages typically represent exclusive states of the case.  The top-level diagram displays stages in collapsed form and shows the logic determining which stage is active at any time.  The details of each stage are shown in hyperlinked child-level diagrams.

Chapter 6, CMMN by Example: Social Care, presents a detailed real-world example based on social care in a European country, using elements of all three case modeling styles.

Chapter 7, Style Rules, explains the Method and Style model validation rules.  The style rules are not part of the CMMN spec.  They are just my own recommendations, intended to (1) make the case logic clear from the printed diagrams, and (2) warn against logic that could lead to unintended behavior, such as deadlocked models.

Chapter 8, Declarative Modeling Patterns, explains CMMN’s various ECA “micropatterns” with reference to equivalent BPMN patterns using Method and Style.  This chapter can be used as a reference for understanding other models in the book as well as real scenarios encountered by the modeler.  Readers familiar with BPMN may want to read this chapter before Chapter 6.

Chapter 9, Executable CMMN with Method and Style, explains how executable CMMN tools can integrate Method and Style by automatically generating variables and condition expressions implied by the labels of various diagram elements.

Acknowledgments

This book would not have been possible without the efforts of Trisotech to create a tool that is not only faithful to the CMMN standard but adds support for the Method and Style conventions, including automated style rule validation.  Trisotech Case Modeler was used to create the diagrams used in the book, and I urge readers to go to www.trisotech.com to request a free trial of the software.

Special thanks go to Denis Gagne, Simon Ringuette, and Maciej Swiderski, the brains behind Trisotech Case Modeler, who also provided extensive review and comments on the book drafts.  I could not have wished for better partners.  I also received generous review and comments from members of Flowable’s CMMN team, including Paul Holmes-Higgin, Joram Barrez, Micha Kiener, and Tijs Rademakers.  Thank you all so much!

I am grateful as well to Serge Schiltz of processCentric GmbH, who contributed the Social Care scenario described in Chapter 6.  I took some liberties with it, so don’t blame Serge for any discrepancy between that model and “the way it ought to work.”

Thanks also to Carol Leyba for cover design and other assistance, as always.

Bruce Silver

Pasadena, CA, May 2020

[1] www.bpmnext.com

[2] https://documents.bpm.com/bpmnext/bpmnext2019/presentations/bpmnext2019-flowable.pdf

[3] https://slideplayer.com/slide/14292614