In real life, organizations have workflows which may not fit into prescribed, sequential process path or which require human intervention or approval before the entire process can be completed. Within the business process world, more unstructured and unpredictable work is handled through case management rather than process management.
There are slightly different standards defined for case management and process management, which reflect the differences in the types of process flows and data being handled in each type of model.
But the question for business architects is which standard to use or whether to try to balance both -- and then for developers to try to create models on different or shared development platforms.
A Quick Comparison of CMMN and BPM for Development Standards
First, it may be helpful to explain why there is a difference between business process management and case management. Both models are defined by two separate specifications, Business Process Model and Notation (BPMN) and Case Model and Notation (CMMN), respectively.
BPMN is the older of the two specifications, with the first release in 2005 and a new major version in 2011. CMMN followed much later, with a first release in 2014.
The purpose of BPMN was to be able to effectively model business workflows. While these workflows could be highly complex, they were still largely predictable and procedural. The processes were sequential. The nature of the process models also gave them a high degree of integration with other applications.
However, in many business scenarios, the processes may not be reliably predictable. Some actions may require human intervention or the possible sequences are much more reliant on dynamic, interrelated variables. These workflows are more data- and situation-driven than process-driven. These kinds of workflows bumped up against the constraints of BPMN for some developers, and so there was a new, separate specification (CMMN) defined specifically for complex case management.
The idea for having separate specifications is that BPMN is a procedural language, while CMMN is a declarative language. Put another way, BPMN is supposed to define a specific process flow, while CMMN handles multi-path or dynamic flows.
Despite the declarative / procedural distinction, the elements defined and handled within both CMMN and BPMN models have a lot of similarities, even if the resulting models and workflows are different. For example:
|CMMN element||BPMN element|
|Entry condition||Escalation event subprocess|
Because of the conceptual overlap between CMMN models and BPMN models, there is a question whether to use one or both standards (just as within the larger standards community, there is a debate about whether to combine the two specifications).
Where Case Management Fits into a BPM Platform
In a sense, though, the very question “what specification should we use” puts the cart before the horse.
BPM.com had a great forum post which posted the question on whether focusing on the language or specification distracted from the actual customer needs and processes that the models are supposed to emulate. One of the responses (by Ian Gotts) essentially said that they had to be two halves of the same equation, instead of either-or. The business understanding defines what needs to be done for customers, and the specification is used to define how the application supports the model.
Gotts’ response highlights a unique challenge with process and case management modeling -- the development issues are only half of it. The success of the overall model is entirely dependent on the ability of business analysts and users to be able to describe their business logic. Without an understanding of the real customer issues, business processes, and industry expectations, the model is going to fail -- regardless of the specification used to implement it.
There is no hard line between processes and cases in real-life workflows. Processes will naturally interact with objects and data; cases will naturally follow some processes. It is certainly possible to represent a case model with BPMN or a BPM model with CMMN. The similar element definitions in both notation standards and the real-life overlap of processes, data, and objects makes this possible.
Example CMMN Model, from the spec
Example BPMN Model, in Red Hat BPM designer
Combining process and case management into a single platform offers several benefits:
- Developers can focus on a single development environment and specification.
- Because BPM is a more widely understood model within the business community, it can be an effective tool for business users to collaborate with developers.
- The resulting BPM-based diagrams are relatively simpler than CMMN diagrams, which can make it easier for non-technical users to understand the flows and dependencies in the model.
Assuming that the right development tools are in place, using a BPM platform to create case management models can create a more intuitive, better understood, and less complex environment for both business and technical users.
In our view, it is less complex from an architectural standpoint to use a BPM platform to develop case management models. This avoids having to integrate two separate applications, and it allows developers to develop their skills in a single application and specification.
- Case management examples in the Red Hat JBoss BPM documentation
- Red Hat Summit 2017 slide deck, "Case Management Applications with BPM"
About the author
Deon Ballard is a product marketing manager focusing on customer experience, adoption, and renewals for Red Hat Enterprise Linux. Red Hat Enterprise Linux is the foundation for open hybrid cloud. In previous roles at Red Hat, Ballard has been a technical writer, doc lead, and content strategist for technical documentation, specializing in security technologies such as NSS, LDAP, certificate management, and authentication / authorization, as well as cloud and management. She also wrote and edited the Middleware Blog for Red Hat and led portfolio solution marketing for integration and business automation.