While it no longer has the marketing cachet it once enjoyed, the fact that the foundations of the Trisotech platform are the three business automation standards from the Object Management Group – BPMN, CMMN, and DMN – remains a key advantage, with enduring benefits to users. In this post we’ll discuss what these standards do, how we got them, and their enduring business benefits.

In the Beginning

In the beginning, lets say the year 2000, there were no standards, not for business automation, not for almost anything in tech, really. The web changed all that. I first heard about BPMN in 2003. I had been working in something called workflow, automating and tracking the flow of human tasks, for a dozen years already, first as an engineering manager and later as an industry analyst. There were many products, all completely proprietary. But suddenly there was this new thing called BPM that promised to change all that.

Previously, in addition to workflow, there had been a completely separate technology of enterprise application integration or EAI. It was also a process automation technology but based on a message bus, system-to-system only, no human tasks, and again all proprietary technology. It was a mess.

Now a new technology called web services offered the possibility to unify them based on web standards. In the earlier dotcom days, the web just provided a way to advertise your business, maybe with some rudimentary e-commerce. Now people realized that the standard protocols and XML data of the web could be used to standardize API calls in the new Service-Oriented Architecture (SOA). A Silicon Valley startup called Intalio proposed using web services to define a new process automation language called BPML that unified workflow and application integration in this architecture. But they went further: Surprisingly, solutions using this language would be defined graphically, using a diagram notation called BPMN. The goal was engaging business users in the transition to SOA, and BPMN offered the hope of bridging the business-IT divide that had made automation projects fail in the past.

Enterprise application software vendors liked it too. Functionality that previously was embedded in their monolithic applications could be split off into microservices that could be invoked as needed and sequenced using the protocols of the world wide web. This was a game-changer. Maybe you could make human workflow tasks into services as well.

As it evolved, BPMN 1.0 took on the look of swimlane flowcharts, which were already used widely by business users, although without standard semantics for the shapes and symbols. Now with each shape bound to the semantics of the execution language BPML, BPMN promised “What You Draw Is What You Execute.” Intalio was able to organize a consortium of over 200 software companies called BPMI.org in support of this new business automation standard.

But in fact, they were too early, since the core web services standard WSDL was not yet final, and in the end BPML did not work with it. So BPML was replaced by another language BPEL that did. While the graphical notation BPMN remained popular with business for process documentation and improvement, it was not a perfect fit with BPEL for automation. There were patterns you could draw in BPMN that did not map to BPEL. So no longer could it claim “what you draw is what you execute.” BPMI.org withered and ultimately was acquired by OMG, a true standards organization.

Even so, BPMN remained extremely popular with business users. They were not, in fact, looking to automate their processes, merely to document them for analysis and potential improvement. Still the application software vendors and SOA middleware vendors pushed for a new version of BPMN that would make the diagrams executable. But it was not until 2010 that BPMN 2.0 finally gave BPMN diagrams a proper execution language. I had been doing BPMN training on version 1.x since 2007, and somehow I wound up on the BPMN 2.0 task force, representing the interests of those business users doing descriptive modeling.

BPMN 2.0 was widely adopted by almost all process automation vendors. Later OMG developed two other business automation standards, CMMN for case modeling and DMN for decision modeling, all based on a similar set of principles. There are three standards because they cover different things. They were developed at different times for different reasons. So let me briefly describe what they do, their common principles, and why they remain important today.

BPMN

BPMN was the first. BPMN describes a process as a flowchart of actions leading from some defined triggering event to one of several possible end states. Each action typically represents either a human task or an automated service, for the first time unifying human workflow and EAI. The diagrams include both the normal “happy path” and branching paths followed by exceptions. It is easy to see the sequence of steps the process may follow, but every instance of the process must follow some path in the diagram. That is both its strength and its basic limitation.

BPMN remains very popular because the diagrams are intuitive. Users understand them in general terms without training, and what you draw is what you execute. BPMN can describe many real-world processes but not all of them.

There are actually two distinct communities of BPMN users. It is interesting that they interact hardly at all. One uses BPMN purely for process description. They have no interest in automation, just documentation and analysis. Those BPMN users simply want to document their current business processes with hope of improving them, since the diagrams, if made properly with something like Method and Style, more clearly express the process logic than a long text document. For them, the value of BPMN is it generally follows the look of traditional swimlane flowcharts.

The other community is interested in process automation, the actual implementation of new and improved processes. For them, the value of BPMN is what you draw is what you execute. It is what allows business teams to better specify process requirements and generally collaborate more closely with development teams. This reduces time to value and generally increases user acceptance.

As a provider of BPMN training, my interactions have been mostly with the first community. In a prior life as an industry analyst, they were exclusively with the second community. So I have a good sense of the expectations of both groups. And while I believe the descriptive modeling community is probably still larger, it is now declining, and heres why.

In a descriptive modeling team, there are typically meetings and workshops where the facilitator asks how does the process start? What happens next? And so forth. Thats good for capturing the happy path, the normal activity flow to a successful end state, which is the main interest. But BPMN diagrams also contain gateways and events that define exception paths, since, remember, every instance of the process must follow some path drawn in the diagram. In reality, however, you are never going to capture all the exceptions that way.

So over the past decade, a lot of process improvement efforts have shifted away from descriptive process modeling in this way to something called process mining, instrumenting key steps of the process as it is running however they are achieved and correlating the timestamps to create a picture of all the paths from start to end including, importantly, that small fraction of instances that take much too long, cost way too much, and are responsible for complaints to customer service. Dealing with those cases leads to significant process improvement, and automating them requires accommodating them somehow.

Some process mining tools map their findings back to BPMN, but BPMN demands a reason some gateway condition or event to explain each divergence from the happy path. This points out the key weakness of BPMN as an automation language, the difficulty in accommodating all the weird exceptions that occur in real world scenarios. Something more flexible is needed.

CMMN

CMMN was created to handle those processes that BPMN cannot. It focuses on a key difference from BPMN, work taking an unpredictable path of over its lifetime, emphasizing event-triggered behavior and ad-hoc decisions by knowledge workers.

A case in CMMN is not described by a flowchart, where you can clearly see the order of actions, but rather a diagram of states, called stages, each specifying actions that MAY be performed or in some cases MUST be performed, in order to complete some milestone or transition to some other state. That allows great flexibility, a better way than BPMN, in fact, to handle real-world scenarios in which it is impossible to enumerate the all the possible sequences of actions needed.

This comes at a cost, however. While what you draw is still what you execute, what you draw is not easy to understand. CMMN diagrams are not flowcharts but state diagrams. They are not intuitive, even if you understand the shapes and symbols well. Each diagram shape goes through various lifecycle states Available, Enabled, Active, Completed or Terminated – and each change of state is represented by a standard event that triggers state transitions in other shapes. So in the end the diagram, when fully expanded down to individual tasks, shows actions that MAY be performed or MUST be performed, and the events that trigger other shapes.

In practice, CMMN is almost always used in conjunction with BPMN, as the specific actions described, typically a mix of automated services and human interaction, are better modeled as BPMN processes. So typically in a business automation solution, CMMN is at the top level, where the choice of what actions to perform is flexible and event-driven. Many of the CMMN actions are modeled as process tasks, meaning enactment of a BPMN process. Organizing the solution in this way has the benefit of CMMNs flexibility to handle the events and exceptions of real-world end-to-end scenarios, and BPMNs business-understandable automation of the details of the required actions.

Above is an example from my book CMMN Method and Style, based on social care services in a European country. The stage Active Case contains 4 sub-stages without any entry conditions. That means they can be activated at any time. The triangle marker at the bottom means manually activated; without that they would activate automatically. And notice within each stage are a mix of human tasks, with the head and shoulders icon, and process tasks, with the chevron icon. At the bottom are 4 more tasks not in a substage that deal with administrative functions of the case. They potentially can occur at any time when Active Case is in the active state, but they have entry conditions the white diamonds meaning they must be triggered by events, either a user interaction or a timer. This diagram does not include any file item events receipt or update of some document or data which also triggers tasks and stage entry or exit. As you can see, the case logic is very flexible almost anything could be started at any time but at this level not too revealing as to the details of the actions. Those are detailed within the BPMN processes and tasks.

Here is another CMMN example that illustrates the flexibility needed for what seems like a simple thing like creating a user account in a financial institution. Yes, that is a straightforward process BPMN but it lives inside a wider context, which is managing the users status as a client. A new client has to be initialized, set up thats another BPMN process and then you can add one or more accounts as long as the client remains an Active User. You can deactivate the user thats another process which automatically terminates the Manage Active User stage, thats the black diamond, and triggers the Manage Inactive User stage thats the link to the white diamond labeled exit, exit being the lifecycle event associated with the Terminated state of Manage Active User.

The only thing that happens in the Manage Inactive User stage is you can reactivate the user, another process. And when that is complete, since there is nothing else in that stage, the stage is complete, meaning the link to the white diamond in Manage Active User labeled complete triggers activation of that stage. The hashtag marker on both stages means after completion or termination they can be retriggered; without that marker they could not. And finally, the process task Delete user has no entry conditions, so it can be activated manually at any time, and when complete terminates the case, the black diamond. So what seemed initially like a simple process, Add User Account, in a real world application expands to a case handling the whole lifecycle of that client.

DMN

DMN describes not actions but business logic, understandable by non-programmers but deployable nevertheless as an executable service. DMN is a successor to business rule engine technology from the 1990s, better aligned with today’s microservice-oriented architecture. In DMN, a decision service takes data in and returns data out. It takes no other actions. Like BPMN and CMMN, design is largely graphical.

The diagram you see here, called a Decision Requirements Diagram, shows the dependencies of each rectangle, representing a decision, on supporting decisions and input data connected to it via incoming arrows called information requirements. The value expression of each decision can reference only those direct information requirements. Even if they are unable to model the value expressions, business users are able create these diagrams, which serve as verifiable business requirements for the executable solution.

But DMN was designed to let non-programmers go further, all the way in fact to executable decision services. Instead of program code, DMN provides standard tabular formats called boxed expressions. These are what define the expressions that compute the value of each decision.

Decision tables, like the one shown above, are the most familiar boxed expression type, but there are many more, such as Contexts, like the one shown below, where rows of the table define local variables called context entries, used to simplify the expressions in subsequent rows. Note here that the value expression of a context entry, such as Loan amount here, can itself be a context or some other boxed expression.

The expressions of each context entry, the cells in gray here, use a low-code expression language called FEEL. Although FEEL is defined in the DMN spec, it has the potential to be used in BPMN and CMMN as well. More about that later.

The combination of DRDs, boxed expressions, and FEEL means business users can create directly executable decision logic themselves without programming. In BPMN and CMMN, graphical design is limited to an outline of the process or case logic, the part shown in the diagram. To make the model fully executable, those standards normally still require programming.

On the Trisotech platform, however, that’s no longer the case. When BPMN and CMMN were developed, they did not define an expression language, because they assumed, correctly at the time, that the details of system integration and user experience would require programming in a language like Java. But DMN was published 6 years later, when software tools were more advanced. DMN was intended to allow non-programmers to create executable decision services themselves using a combination of diagrams, tables, and FEEL, a standard low-code expression language. An expression language is not a full programming language; it does not define and update variables, but just computes values through formulas. For example, the Formulas ribbon in Excel represents an expression language.

While adoption of FEEL as a standard has been slow, even within the decision management community, many business automation vendors have implemented their own low-code expression languages with the objective of further empowering business teams to collaborate with developers in solutions.. Low-code expression languages should be seen today as the important other half of model-based business automation, along with diagrams composed of standardized shapes, semantics, and operational behavior. The goal is faster time-to-value, easier solution maintenance, and improved user acceptance through close collaboration of business and development teams.

Shared Principles

Three key principles underlie these OMG standards, which play a key role in the Trisotech platform today, and I want to say more about why they are important.

The first is that they are all model-based – meaning diagrams and tables and those models are used both for outlining the desired solution, what have been called business requirements, and creating the executable solution itself, going back to the original promise of What You Draw Is What You Execute.

The traditional method of text-based business requirements is a well-known cause of project failure. Instead, models allow subject matter experts in the business to create an outline of the solution in the form of diagrams and tables that can be verified for completeness and self-consistency. Moreover, the shapes and symbols used in the diagrams are defined in a spec, so the models look the same, and work the same, in any tool. And even better, the execution semantics of the shapes is also spelled out in a spec, so what you draw is actually what you execute. Engaging business users together with IT from the start of the project speeds time to value and increases user acceptance.

Second, the models have a standard xml file format, so they can be interchanged between tools without loss of fidelity. In practice, for example, that means business users and developers can use different tools and interchange models between them. Ive been involved in engagements where the business wants to use modeling tool X, and IT, in a separate organization, insists on using tool Y for the runtime. Thats not great, but doable, since you can interchange models between the tools using the standard file format.

Third, OMG procedures ensure vendor-neutrality. Proprietary features cannot be part of the standard, and the IP is free to use. In practice this tends to result in open-source tools and lower software cost. It may not be widely appreciated but many, possibly the majority, of BPMN diagramming tools today stem from an open source project, and another open source project created a popular BPMN runtime. DMN is a similar story. Tool vendors were stumped by the challenge of parsing FEEL, where variable and function names may contain spaces, until Red Hat made their FEEL parser and DMN runtime open source. Implementing these standards is difficult, and open source software has been a big help in encouraging adoption.

Enduring Business Value

So where is the business value of these standards? What are the benefits to customers? In my view, these fall into 3 categories:

First, common terminology and understanding. I remember the days of workflow automation before BPMN. There was no common terminology. You learned a particular tool, and tools were for programmers. Now BPMN, CMMN, and DMN provide tool-independent understanding of processes, cases, and decision logic. There is much wider availability of information about these technologies, through books, web posts, and training, down to the details of modeling and automation. This in turn makes it easier to hire employees and engage service providers already conversant and experienced in the technology. It also lowers the re-learning cost if it becomes necessary to switch platform vendors.

Benefit #2 is faster time-to-value. Today this might be the most critical one for customers. Model-based solutions are simply faster to specify, faster to implement, and faster to adapt to changing requirements than traditional paradigms. Faster to specify because you can more easily engage the subject matter experts up front in requirements development and more quickly verify the requirements for completeness and self-consistency. Faster to implement because you are building on top of standard automation engines. The custom code is just for specific system integration and user experience details. And faster to adapt to changing requirements because often this involves only changing the model not the custom code.

So, for example, a healthcare provider can go live with a Customer Onboarding portal in only 3 months instead of a year, leveraging involvement from business users across multiple departments and close collaboration between business and IT. Everyone is using the same terminology, the same diagrams, and what you draw is what you execute.

A key feature of the 3 OMG standards is they were designed to work together. CMMN, for example, has a standard task type that calls a BPMN process and another that calls a DMN decision service. BPMN can call a DMN decision service and, on the Trisotech platform, a CMMN case. And so you have platforms like Trisotech that handle the full complement of business automation requirements event-driven case management, straight through process automation, long-running process automation, and decision automation. The alternative is a lot of custom code expensive and hard to adapt to changing requirements or separate platforms for process, decision, and case management, again expensive and requiring a lot of system integration.

A single platform that handles all three especially one based on models, business engagement, and vendor-independent standards lowers costs the cost of software, of implementation, and of maintenance of the solution over the long term.

SDMN, a Common Data Language

While BPMN, CMMN, and DMN work together well, they still lack a common format for data. DMN uses FEEL, but in most tools, executable models BPMN and CMMN use a programming language like Java to define data. It would be better if they shared a way to define data. Trisotech uses FEEL for all three model types, which is ideal. But now there is an effort to make that common data language a standard.

BPM+ Health is an HL7 “community of practice” in the healthcare space seeking industry convergence around such a common data language, SDMN. That language is essentially FEEL. Technically, it is defined by the OMG Shared Data Model and Notation (SDMN) standard, a key BPM+ Health initiative seeking to unify data modeling across BPMN, CMMN, and DMN.

Data modeling is primarily used in executable models and omitted from purely descriptive models. The challenge for SDMN is to unify DMN variables, BPMN data objects, and CMMN case file items, and describe them as what DMN calls item definitions.

SDMN defines a standards-based logical data model for data used across BPMN, CMMN, and DMN. Data linked to SDMN definitions is not specific to a particular model but usable consistently across models of different types. In this sense it is the logical data model equivalent to the Trisotech Knowledge Entity Modeler. But where KEM defines a conceptual data model, with focus of KEM is on term semantics, SDMN is a logical data model, with focus on data structure, what DMN calls item definitions.

At this time, SDMN 1.0 is still in beta, but two artifacts illustrate what is planned. The DataItem diagram, shown below, describes the names and types of data items, and structural relationships between them.

In addition, an ItemDefinition diagram, again shown below, details the structure of each data item.

Trisotech users will recognize this as an alternative way to create item definitions, easier for tool vendors without Trisotech’s graphics capability. I still prefer Trisotech’s collapsible implementation:

The Path Forward

Going forward, look for more solutions developed using BPMN, CMMN, and DMN in combination. Typically CMMN is used at the top level, where it can handle all possibilities in a real-world process application. Specific actions are best implemented as BPMN processes, invoked from CMMN as a process task. Decision logic can be called from either CMMN or BPMN as a decision task. So you see why having common data definitions for all three modeling languages is valuable in such integrated solutions.

On the Trisotech platform, SDMN, in the form of FEEL, is already supported in all three languages, providing the additional benefit of Low-Code business automation. Starting in healthcare, SDMN will make this integration enabler available on other platforms as well.

Follow Bruce Silver on Method & Style.

Blog Articles

Bruce Silver

View all

DMN List and Table Basics

Blog

By Bruce Silver

(Read Time: 5 Minutes)

BPM+ : The Enduring Value of Business Automation Standards

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Make Way for B-FEEL

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is a Decision Service?

Blog

By Bruce Silver

(Read Time: 5 Minutes)

FEEL Operators Explained

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Lookup Tables in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is Method and Style?

Blog

By Bruce Silver

(Read Time: 3 Minutes)

Instance Alignment in BPMN

Blog

By Bruce Silver

(Read Time: 3 Minutes)

DMN 101

Blog

By Bruce Silver

(Read Time: 5 Minutes)

All Blog Articles

Read our experts’ blog

View all

DecisionCamp 2024 Presentation
Revolutionizing Credit Risk Management in Banking

Revolutionizing Credit Risk Management in Banking – DecisionCamp 2024 Presentation from Denis Gagné

Presented By

Stefaan Lambrecht (The TRIPOD for OPERATIONAL EXCELLENCE)

Description

The European Banking Authority (EBA) Dear CEO letter, typically issued to provide guidance and expectations for banks on key regulatory issues, emphasizes the need for stringent credit risk management, continuous monitoring, and compliance with evolving regulations.

The primary challenge for banks in monitoring customers and credit risks is the complexity and volume of data that must be continuously analyzed and acted upon. This complexity arises from several factors: the variety of triggers, the volume and complexity of metrics, continuous monitoring, quickly adaptable regulatory compliance, a comprehensive 360-degree customer view.

By leveraging DMN modeling & execution banks can effectively meet the EBA’s expectations outlined in the Dear CEO letter. DMN engines provide a robust solution for automated decision-making, continuous monitoring, regulatory compliance, and transparency, ensuring that banks can manage credit risks proactively and efficiently while maintaining the required standards set by the EBA and other regulatory bodies. This alignment not only helps in fulfilling regulatory obligations but also strengthens the overall financial health and stability of the bank.

During his presentation Stefaan Lambrecht will demonstrate an end-to-end solution to these challenges inspired by a real-life case, and making use of an integrated use of DMN, CMMN and BPMN.

Watch the video

Content

Presentation

View all

DecisionCamp 2024 Presentation
Revolutionizing Credit Risk Management in Banking

Presented By

Stefaan Lambrecht (The TRIPOD for OPERATIONAL EXCELLENCE)

Description

During his presentation Stefaan Lambrecht will demonstrate an end-to-end solution to these challenges inspired by a real-life case, and making use of an integrated use of DMN, CMMN and BPMN.

View the slides

Videos

Recorded webinars

View all videos
Attend a live webinar

Blog

Going from Zero to Success using BPM+ for Healthcare.

Part I:
Learning Modeling and Notation Tools

By Dr. John Svirbely, MD

Read Time: 3 Minutes

Welcome to the first installment of this informative three-part series providing an overview of the resources and the success factors required to develop innovative, interoperable healthcare workflow and decision applications using the BPM+ family of open standards. This series will unravel the complexities and necessities for achieving success with your first clinical guideline automation project. Part I focuses on how long it will take you to reach cruising speed for creating BPM+ visual models.

When starting something new, people often ask some common questions. One is how long will it take to learn the new skills required. This impacts how long it will take to complete a project and therefore costs. Learning something new can also be somewhat painful when we are set in our old ways.

Asking such questions is important, since there is often a disconnect between what is promoted online and the reality. I can give my perspective based on using the Trisotech tools for several years, starting essentially from scratch.

How long does it take to learn?

The simple answer – it depends. A small project can be tackled by a single person quite rapidly. That is how I got started. Major projects using these tools should be approached as team projects rather than something an individual can do. Sure, there are people who can master a wide range of skills, but in general most people are better at some things than others. Focusing on a few things is more productive than trying to do everything. A person can become familiar with the range of tools, but they need to realize that they may only be able to unlock a part of what is needed to automate a clinical guideline.

The roles that need to be filled to automate a clinical guideline with BPM+ include:

1 subject matter expert (SME)

2 medical informaticist

3 visual model builder

4 hospital programmer/system integrator

5 project manager

6 and of course, tester

A team may need to be composed of various people who bring a range of skills and fill various roles. A larger project may need more than one person in some of these roles.

The amount of time needed to bring a subject matter expert (SME) up to speed is relatively short. Most modeling diagrams can be understood and followed after a few days. I personally use a tool called the Knowledge Entity Modeler (KEM) to document domain knowledge; this allows specification of term definitions, clinical coding, concepts maps and rule definitions. The KEM is based on the SVBR standard, but its visual interface makes everything simple to grasp. Other comparable visual tools are available. The time spent is quickly compensated for by greater efficiency in knowledge transfer.

The medical informaticist has a number of essential tasks such as controlling terminology, standardizing data, and assigning code terms. The person must understand the nuances of how clinical data is acquired including FHIR. These services cannot be underestimated since failures here can cause many problems later as the number of models increase or as models from different sources are installed.

The model builder uses the various visual modelling languages (DMN, BPMN, CMMN) according to the processes and decisions specified by the SME. These tools can be learned quickly to some extent, but there are nuances that may take years to master. While some people can teach themselves from books or videos, the benefits of taking a formal course vastly outweigh the cost and time spent. Trsiotech offers eLearning modules that you can learn from at your own pace.

When building models, there is a world of difference between a notional model and one that is automatable. Notional models are good for knowledge capture and transfer. A notional model may look good on paper only to fail when one tries to automate it. The reasons for this will be discussed in Part 3 of this blog series.

The hospital programmer or system integrator is the person who connects the models with the local EHR or FHIR server so that the necessary data is available. Tools based on CDS Hooks or SMART on FHIR can integrate the models into the clinical workflow so that they can be used by clinicians. This person may not need to learn the modeling tools to perform these tasks.

The job of the project manager is primarily standard project management. Some knowledge of the technologies is helpful for understanding the problems that arise. This person’s main task is to orchestrate the entire project so that it keeps focused and on schedule. In addition, the person keeps chief administrators up to date and tries to get adequate resources.

The final player is the tester. Testing prior to release is best done independently of other team members to maintain objectivity. There is potential for liability with any medical software, and these tools are no exception. This person also oversees other quality measures such as bug reports and complaints. Knowing the modeling languages is helpful but understanding how to test software is more important.

My journey

I am a retired pathologist and not a programmer. While having used computers for many years, my career was spent working in community hospitals. When I first encountered the BPM+ standards, it took several months and a lot of prodding before I was convinced to take formal training. I have never regretted that decision and wish that I had taken training sooner.

I started with DMN. On-line training takes about a month. After an additional month I had enough familiarity to become productive. In the following 12 months I was able to generate over 1,000 DMN models while doing many other things. It was not uncommon to generate 4 models in one day.

I learned BPMN next. Training online again took a month. This takes a bit longer to learn because it requires an appreciation of how to design a process so that it executes optimally. Initially a model would take me 2-3 days to complete, but later this dropped to less than a day. Complex models can take longer, especially when multiple people need to be orchestrated and exception handling is introduced.

CMMN, although offering great promise for healthcare, is a tough nut to crack. Training is harder to arrange, and few vendors offer automatable versions. This standard is better saved until the other standards have been mastered.

What are the barriers?

Most of the difficulties that I have encountered have not been related to using the standards. They usually arise from organizational or operational issues. Some common barriers that I have encountered include:

1 lack of clear objectives, or objectives that constantly change.

2 lack of commitment from management, with insufficient resources.

3 unrealistic expectations.

4 rushing into models before adequate preparations are made.

If these can be avoided, then most projects can be completed in a satisfactory manner. How long it takes to implement a clinical guideline will be discussed in the next blog.

Blog Articles

John Svirbely

View all

Suicide Prevention with Modeling Tools

Blog

By John Svirbely

(Read Time: 3 Minutes)

Getting FHIRed Up with SDMN

Blog

By John Svirbely

(Read Time: 2 Minutes)

Modelling Preauthorization Part II: Modelling a Solution

Blog

By John Svirbely

(Read Time: 3 Minutes)

Modelling Preauthorization Part I: The Problem

Blog

By John Svirbely

(Read Time: 3 Minutes)

Healthcare Orchestration versus Healthcare: Handling Interactions Between Processes

Blog

By John Svirbely

(Read Time: 3 Minutes)

In Healthcare: To Automate or Not to Automate, that is the Question

Blog

By John Svirbely

(Read Time: 3 Minutes)

Are you looking for Diagrams or Models of your Clinical Guidelines?

Blog

By John Svirbely

(Read Time: 3 Minutes)

Clinical Models at Scale

Blog

By John Svirbely

(Read Time: 3 Minutes)

Do Healthcare Process Models Need Attended Tasks?

Blog

By John Svirbely

(Read Time: 2 Minutes)

Orchestrating Generative AI in Business Process Models

Blog

By John Svirbely

(Read Time: 2 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part III: Going from Paper to Practice

Blog

By John Svirbely

(Read Time: 3 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part II: Getting Started

Blog

By John Svirbely

(Read Time: 3 Minutes)

Going from Zero to Success using BPM+ for Healthcare. Part I: Learning Modeling and Notation Tools

Blog

By John Svirbely

(Read Time: 3 Minutes)

In Healthcare, Interoperability is Just the Start

Blog

By John Svirbely

(Read Time: 3 Minutes)

Transforming Healthcare with Trisotech

Blog

By John Svirbely

(Read Time: 5 Minutes)

All Blog Articles

Read our experts’ blog

View all

What is FEEL?

FEEL (Friendly Enough Expression Language) is a powerful and flexible standard expression language developed by the OMG® (Object Management Group) as part of the Decision Model and Notation (DMN™) international standard.

Request a demo

It is a valuable tool for modeling and managing decision logic in many domains, including healthcare, finance, insurance, and supply chain management. FEEL is designed specifically for decision modeling and execution and to be human-readable to business users, while still maintaining the expressive power needed for complex decision-making. Its simplicity, expressiveness, domain-agnostic functionality, strong typing, extensibility, and standardization make FEEL a valuable tool for representing and executing complex decision logic in a clear and efficient manner. Organizations using FEEL enjoy better collaboration, increased productivity, and more accurate decision-making.

What Are Expression Languages?

FEEL is a low-code expression language, but what is the difference between Expression Languages, Scripting Languages, and Programming Languages. They are all different types of languages used to write code, but they have distinct characteristics and uses.

Expression Languages

Expression languages are primarily designed for data manipulation and configuration purposes. They are focused on evaluating expressions rather than providing full-fledged programming capabilities. Expression languages are normally functional in nature, meaning that at execution the expression will be replaced by the resulting value. What makes them attractive to both citizen developers and professional developers is that they are usually simpler and have a more limited syntax compared to general-purpose programming languages and/or scripting languages. Due to their simplicity, expression languages are often more readable and easier to use for non-programmers or users who don’t have an extensive coding background. FEEL is a standard expression language.

Scripting Languages

Scripting languages provide abstractions and higher-level constructs that make programming using them easier and more concise than programming languages. They are usually interpreted rather than compiled, meaning that the code is executed line-by-line by an interpreter rather than being transformed into machine code before execution. Popular examples of scripting languages are Python, JavaScript, and Ruby.

Programming Languages

Programming languages are general-purpose computer languages designed to express algorithms and instructions to perform a wide range of tasks and create applications. They offer extensive features and capabilities for developing complex algorithms, data structures, and user interfaces. They offer better performance compared to scripting languages due to the possibility of compiling code directly into machine code. Examples of programming languages include C++, Java, and C#.

Is FEEL Like Microsoft Power FX (Excel Formula Language)?

FEEL and Power FX are both expression languages used for data, business rules, and expressions, but in different contexts. Power FX is a low-code programming language based on Excel Formula Language, tailored for Microsoft Power Platform, with some limitations in handling complex decision logic. As soon as the business logic gets a bit tricky, Power FX expressions tend to become highly complex to read and maintain. On the other hand, FEEL is a human-readable decision modeling language, designed for business analysts and domain experts, offering a rich set of features for defining decision logic, including support for data transformations, nested decision structures, and iteration. FEEL provides clear logic and data separation, making it easier to understand and maintain complex decision models.

While Power FX has a visual development environment in the Microsoft Power Platform, FEEL is primarily used within business rules and decision management systems supporting DMN and process orchestration platforms. FEEL is a language standard across multiple BPM and decision management platforms, providing interoperability, while Power FX is tightly integrated with Microsoft Power Platform services. For further comparison, Bruce Silver’s articles FEEL versus Excel Formulas and Translating Excel Examples into DMN Logic.

FEEL Benefits for Technical people and for Business people.

Technical Benefits of FEEL

Decision focus language

FEEL is designed specifically for decision modeling and business rules. It provides a rich set of built-in functions and operators that are tailored for common decision-making tasks. This decision focus nature makes FEEL highly expressive and efficient for modeling complex business logic.

Expressiveness

FEEL supports common mathematical operations, string manipulation, date and time functions, temporal logic and more. This expressiveness enables the representation of complex decision rules in a concise and intuitive manner.

Decision Table Support

FEEL has native support for decision tables, which are a popular technique for representing decision logic. Decision tables provide a tabular representation of rules and outcomes, making it easy to understand and maintain complex decision logic.

Strong typing and type inference

FEEL is a strongly typed language, which means it enforces strict type checking. This feature helps prevent common programming errors by ensuring that values and operations are compatible.

Boxed Expression Support for FEEL

Boxed expressions allow FEEL expressions and statements to be structured visually including:

If, then, else statements
For, in, return statements
List membership statements
… and more.

These visual constructs, along with autocomplete make creating, reading, and understanding complex expressions easy to model and debug.

Flexibility and modularity

FEEL supports modular rule definitions and reusable expressions, promoting code reuse and maintainability. It allows the creation of decision models and rule sets that can be easily extended, modified, and updated as business requirements change. This flexibility ensures agility in decision-making processes.

Testing and Debugging

FEEL expressions can be tested and debugged independently of the larger application or system. This enables users to validate and verify decision logic before deployment, ensuring accuracy and reliability. FEEL also provides error handling and exception mechanisms that help identify and resolve issues in decision models.

Execution efficiency

FEEL expressions are designed to be executed efficiently, providing fast and scalable performance. FEEL engines often use optimized evaluation algorithms and data structures to ensure high-speed execution of decision logic, even for complex rule sets.

Integration FEEL

can be easily integrated with other programming languages and platforms. Many decision management systems and business rules engines provide support for executing FEEL expressions alongside other code or as part of a larger application. This enables seamless integration of decision logic via services into existing IT architectures and workflows.

Extensibility

FEEL can be extended with domain-specific functions and operators to cater to specific industries or business domains. These extensions can be defined to encapsulate common calculations, business rules, or industry-specific logic, enabling greater reusability and modularity.

Interoperability

FEEL also enables the sharing and reuse of decision models across different organizations and applications.

Business Benefits of FEEL

Standardization and Vendor-neutrality

FEEL is a standardized language within the OMG DMN standard, which means it has a well-defined specification and is supported by various software tools and platforms. Standardization ensures interoperability, as FEEL expressions can be used across different DMN-compliant systems without compatibility issues. FEEL is designed to be portable across different platforms and implementations.

Business-Friendly

FEEL focuses on capturing business rules and decision logic in a way that is intuitive and natural for business users. This allows subject matter experts and domain specialists to directly participate in the decision modeling process, reducing the dependency on IT teams and accelerating the development cycle.

Simplicity and Readability

FEEL has a syntax that is easy to read and understand – even for non-technical users like subject matter experts and citizen developers. It uses natural language constructs including spaces in names and common mathematical notation. This simplicity enhances collaboration between technical and non-technical stakeholders, facilitating the development of effective decision models.

Ease of Use

FEEL is supported by various decision management tools and platforms. These tools provide visual modeling capabilities, debugging, testing, and other features that enhance productivity and ease of use. The availability of modeling and automation tooling support simplifies the adoption and usage of FEEL.

Decision Traceability

FEEL expressions support the capture of decision traceability, allowing users to track and document the underlying logic behind decision-making processes. This traceability enhances transparency and auditability, making it easier to understand and justify the decisions made within an organization.

Decision Automation

FEEL has well-defined semantics that support the execution of decision models. It allows the evaluation of expressions and decision tables, enabling the automated execution of decision logic. This executable semantics ensures that the decision models defined in FEEL can be deployed and executed in a runtime environment with other programs and systems.

Compliance and Governance

FEEL supports the definition of decision logic in a structured and auditable manner. This helps businesses ensure compliance with regulatory requirements and internal policies. FEEL’s ability to express decision rules transparently allows organizations to track and document decision-making processes, facilitating regulatory audits and internal governance practices. FEEL includes several features specifically tailored for decision modeling and rule evaluation. It supports concepts like ranges, intervals, and temporal reasoning, allowing for precise specification of conditions and constraints. These domain-specific features make FEEL particularly suitable for industries where decision-making based on rules and constraints is critical, such as healthcare, finance, insurance, and compliance.

Decision Analytics

FEEL provides the foundation for decision analytics and reporting. By expressing decision logic in FEEL, organizations can capture data and insights related to decision-making processes. This data can be leveraged for analysis, optimization, and continuous improvement of decision models. FEEL’s expressive capabilities allow for the integration of decision analytics tools and techniques, enabling businesses to gain deeper insights into their decision-making processes.

Trisotech FEEL Support

Most comprehensive FEEL implementation

Trisotech provides the industry’s most comprehensive modeling and automation tools for DMN including support for the full syntax, grammar, and functions of the FEEL expression language. To learn more about basic types, logical operators, arithmetic operators, intervals, statements, extraction and filters supported by Trisotech see the FEEL Poster.

FEEL Boxed Expressions

Boxed Expressions are visual depictions of the decisions’ logic. Trisotech’s visual editor makes the creation of Boxed Expressions and FEEL expressions easy and accessible to non-programmers and professional programmers alike.

FEEL Functions

FEEL’s entire set of built-in functions are documented and menu selectable in the editor. The visual editor also offers supports for the Trisotech-provided custom FEEL functions including functions for Automation, Finance, Healthcare, and other categories.

Autocompletion

The Trisotech FEEL autocompletion feature proposes variable and function names including qualified names as you type when editing expressions thus saving time and improving accuracy.

FEEL as a Universal Expression Language

Trisotech has also expanded the availability of the international standard FEEL expression language to its Workflow (BPMN) and Case Management (CMMN) visual modelers. For example, FEEL expressions can be used for providing Gateway logic in BPMN and If Part Condition expressions on sentries in CMMN.

FEEL Validation and Debugging

Trisotech provides validation for FEEL and real-time full-featured debugging capabilities. To learn more about testing and debugging read the blog Trisotech Debuggers.

Additional Presentations and Blogs

You can also watch a presentation by Denis Gagne on using FEEL as a standards-based low-code development tool and read a blog by Bruce Silver about how using FEEL in DMN along with BPMN™ is the key to standards-based Low-Code Business Automation.

OMG®, BPMN™ (Business Process Model and Notation™), DMN™ (Decision Model and Notation™), CMMN™, (Case Management Model and Notation™), FIBO®, and BPM+ Health™ are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

Trisotech

the
Pioneer

View all

BPM+ Virtual Coffee
5 min Intro to CMMN

A short introduction to the Case Management Model and Notation (CMMN)

Presented by

Denis Gagne, CEO & CTO at Trisotech

Good day and welcome to our BPM+ virtual coffee. I am Denis Gagne CEO and CTO of Trisotech, and this is a five-minute introduction to CMMN.

Some of the motivations or characteristics behind Case Management, as opposed to process management, was that we wanted to deal with business processes where the sequence of activities is not well defined. Contexts in which activities may happen in all kinds of different orders and we must deal with these evolving circumstances. We also wanted to make sure that the evolution of the Case depended on decisions made by the Knowledge Worker. The Knowledge Worker is front and center to the notion of Case Management. It is all about managing a particular context, which is the Case. To support the performance of the Knowledge Worker required that we had a great deal of flexibility due to the dynamic nature of the work. You can think of it as your input box being your Case File, a manifold where different data comes into it, and you must react to this new information and progress with the work needed by the Case. This requires a lot of adaptability to the information context where this context of information is really the Case File. We also wanted to leave to the Knowledge Worker complete control over what to do next, for him to figure out what’s the next best action. But we also wanted to provide some scaffolding to the Knowledge Worker by also providing ideas of what could be done next. These ideas of what co be done next is where the Case Plan Model comes into play.

CMMN stands for the Case Management Model of Notation, and it is an open standard produced by OMG. The spec is available at the URL here. I invite you to go and consult this specification document.

Fundamentally CMMN is about managing a context to achieve a desired outcome where the context is a Case File. A Case in CMMN consists of a Case File and a Case Plan Model. The Case Plan Model is there to help the Knowledge Worker to figure out what possible next action would be ideal in the current context, but the activities to be carried out are really decided by the Knowledge Worker. This provides a lot of flexibility where everything is decided at runtime rather than pre-defined at design time as in the case of BPMN.

CMMN is as easy as one-two-three because CMMN uses an Event-Condition-Action (ECA) semantic. This means basically that when a particular Event happens, if a condition is met, then a possible an action is available. CMMN offers all the variations of ECA. We can have Event-Condition-action or just Condition-Action or just Action. You therefore have the full flexibility of defining the needed activities.

Now looking at the CMMN notation, the folder shape depicts your context. This gives you the information context of the Case File in which you are working. We then have different symbols to capture the notions of Event, Condition and Actions. Events can be actual Event Listeners, like for example Timer Events or User Events but it can also be Case File Events. For example, a new Case File Item being provided into the Case File, or a particular information item is updated, or a document is done or updated. We use these events as triggers, and we verify whether a particular condition is met. An Entry Criterion will be a condition for entering into this element and an Exit Criterion will be the Criterion for terminating the work. We then have our actions. In this ECA depicted here we have a Timer Event trigger, so when this Event happens, if the Condition is met then I can do this Task. We also have the notion of Discretionary Tasks. The Planning Table is a way to turn on and off, and controlling, which Discretionary Tasks are available. A Planning Table at the top of the folder is managing basically the floating Discretionary Tasks within the Case context and a Planning Table on a Task is managing the Discretionary Tasks that are attached to this particular Task. We then have that when the Event happens, if the Condition is met, while I am in this Task, there are other Discretionary Tasks that I can take on. Then we have the notion of Stages, where you can structure your Plan Items and mostly helping you to create some kind of the life cycle for accomplishing the desired outcome of the Case. We also have the notion of Milestones and different triggers.

So, this is a very quick and broad review of CMMN. There is book on CMMN that I highly recommend you read. It is the CMMN Method and Style from Bruce Silver. You can go and read that book. It will give you an intro to CMMN and provide you with some Style and Method on how to do a good CMMN models.

That was our five-minute introduction to CMMN.

View the slides

Videos

Recorded webinars

View all videos
Attend a live webinar

Vlog

Design tips for combining BPMN, CMMN and DMN models

By Sandy Kemsley

Video Time: 5 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here today for the Trisotech blog with some practical design tips for when you’re combining process and decision models.

let’s start with the big three modeling standards for processes and decisions. There’s BPMN for structured processes, CMMN for case management and DMN for decisions. The standards tell you how to combine the models and you can look at graphical versions like Trisotech Triple Crown infographic to see how this works. Basically, process models and case models can call each other, and then either of them can call a decision model. Now what the standards don’t show is why you would use a particular model type to model different parts of your operations? Now, this might seem like a really silly question. If you have a process, you model it using BPMN, if you have a case structure, you use CMMN and if you have a decision you use DMN. But the real world is not that simple. In any sort of business, operation, any sort of complex business operation, you’re going to have a combination of process, case, and decision logic. And you need to be able to use more than one model type together. Now when you start doing modeling, you’ll find that process people and rules people come at these business models from different directions: if you’re a process person, like me, then you’ll tend to start with a BPMN or a CMMN model and that’s going to show the overall flow, and then you’re going to add in decision tasks where you need to call out to more complex decision models and then build the DMN models that are called from there. Now, on the other hand, a rule specialist will start by modeling the key decisions in the business operation and then they’re going to add processes to tie those decisions together.

Watch this short video for more…

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all

Process Pain Points: Pended Processes

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Process Pain Points: Handoffs

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process Pain Points: Spreadsheets and Email

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

AI and Automation: Friends or Foes?

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

AI and BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Future-Proofing Your Business With BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Best practices in business automation application – Implementation

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 3)

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

Business automation best practices #3 – Application development – Design (part 2)

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 1)

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #2 – strategic vision

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #1 – Introduction

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Composability: Low-code versus model-driven

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Leveraging best-of-breed

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Old Wine in New Bottles?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Treating Your Employees Like Customers

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Process latency – not always a bad thing

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process notifications in action

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

End to end processes in action

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

From Modeler to Citizen Developer

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

What Are You Modeling For?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Design tips for agile processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for end-to-end processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for combining BPMN, CMMN and DMN models

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Case Management Work Patterns

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

In financial services, process rules content

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Not the New Normal for Mortgage Lending

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Expanding Across the Organization

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Picking Your Next Project

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

From Project to Program: Post-Implementation Review

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Building Incentives Into Processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Discovering Processes In Unusual Places

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Foiling BEC Fraud With Better Distributed Processes

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Better Process Analysis Using Analytical Techniques

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Designing Loosely-Coupled Processes to Reduce Fragility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

The Changing Nature of Work

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Case for a Business Automation Center of Excellence

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Designing Processes for Agility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Conway’s Law and End-To-End Business Processes

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Need for Goal Alignment

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

All Blog Articles

Read our experts’ blog

View all

Blog

Case Management Work Patterns

By Sandy Kemsley

Read Time: 6 Minutes

My last post on process, rules and content has me thinking about the style of application where they all come together: case management. Not about when or whether to use the Case Management Model and Notation (CMMN) versus the Business Process Model and Notation (BPMN) versus the Decision Model and Notation (DMN), which I covered in a post on this “triple crown” of modeling standards, but the business requirements for different styles of processes including case management.

For business analysts, the distinction between work patterns is important, since different patterns lend themselves to different types of user interfaces, use cases, systems and levels of automation. And yes, they need to be modeled differently, possibly using different modeling notations, but first it’s necessary to identify the work patterns in order to classify them. There are some types of work that are so unpredictable that it’s difficult to model them at all, but let’s stick with the broad array of work that can be modeled in some way: we know a bit about the goals of the work, or the steps required to achieve the goals, or the information that is being used, or the rules that must be followed along the way.

At one end of the spectrum is transactional workflow, where most of the process is known: the order of the steps, the rules that dictate when things move from one step to another, and the step that defines when the process has been completed. These processes are often codified in BPM systems or line-of-business systems, and are partially or even fully automated.

At the other end of the spectrum is case management: a work style for goal-oriented scenarios that don’t have a predefined method of resolution. This is commonly used for problem resolution, but is also for work that doesn’t have a defined order of steps, such as claims management or legal cases. A case may be initiated directly by someone – a customer, or an internal worker – as a standalone piece of work, or a case may be triggered by a transactional workflow to handle an exception or resolve a problem before returning to the predefined process.

As more and more routine tasks within transactional processes become fully automated, more workers are engaged in doing knowledge work within case management. The goals and metrics for this type of work are very different from transactional processes: since cases are often related to resolving problems, case management metrics such as customer satisfaction can be a key competitive differentiator. Case management workers need a much richer informational context in order to do their job, and very different tools than workers engaged in routine tasks within transaction processes.

In my practice, I often help organizations to understand the different work patterns within their operational areas. They may not even recognize some of these as definable work patterns, just “the way that we do it.” Let’s look at identifying case management work patterns:

Case management doesn’t have a predefined order of steps or endpoint, but is considered completed when the central issue has been resolved. The set of all possible steps may be known, but it’s unknown the order in which they will be executed, or even if some of them will be executed at all. Each case will follow a different path, since the worker decides what must be accomplished to complete the case, and they may not decide on what the next step is until information has been gathered by the current step.
Case management is centered around a case file/folder that is used to collect all related content. This case folder is persistent, since it holds a record of decisions and the documentation required to make those decisions. This is the crossover with content management, and why case management systems often are built on the foundation of a content management system.
Case management relies on knowledge workers to gather information from a variety of sources and guide the work towards a resolution. This includes assigning tasks to other participants and making decisions that cannot be automated. There can also be automated processes and triggers that gather information into the case folder, make decisions and assign tasks, but case management scenarios almost always involve some level of human decision-making.

I use the following diagram to visualize all the components that may involved in case management:

Sandy Kemsley Blog - Case Management Work Patterns

What do the three characteristics of case management that I list above mean for the business architects and analysts involved in defining and implementing these processes?

First of all, these are goal-oriented processes, and the metrics need to reflect that. For example, the success of a case isn’t tied to how fast it is completed, or how few resources were consumed, although those may be secondary metrics: it’s primarily about whether the issue was resolved satisfactorily. That might be a customer satisfaction measurement, or a legal or regulatory measure, depending on the goal of the case. Business analysts need to identify the goals for each type of case, and ensure that those are the metrics that are being captured. If more traditional process metrics are used, you could end up with cases being resolved very quickly but a lot of unhappy customers or lost sales.

Second, these are content-rich processes, and there must be robust content management as well as the type of content governance that I discussed in my previous post. Since many different types of people may participate in completing a case, you need to be sure that people are seeing all of the content that they need to do their work, but not parts of the case folder that they should not have access to.

Lastly, these are knowledge processes that require people to look at information and make decisions. That means that they need a rich informational context in order to make the right decisions: the right content from the case folder at the right time, but also information from other systems, organized in a fashion that requires a minimum amount of searching. Currently, a lot of case management work is performed with an ad hoc assortment of methods and applications – including spreadsheets, email and external applications – often without support from IT-supported systems; this makes it difficult for the case workers to be sure that they are looking at the right information to support the decision that they’re making.

Once you’ve identified work that looks like case management based on these characteristics – even if it has some predefined processes tucked into part of it – you’re ready to start into the detailed analysis. This is where you will likely use CMMN (and possibly BPMN and DMN) to model how the cases will work, but don’t lose sight of the human side of case management: making decisions in a content-rich environment to reach a specified goal.

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all

Process Pain Points: Pended Processes

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Process Pain Points: Handoffs

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process Pain Points: Spreadsheets and Email

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

AI and Automation: Friends or Foes?

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

AI and BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Future-Proofing Your Business With BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Best practices in business automation application – Implementation

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 3)

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

Business automation best practices #3 – Application development – Design (part 2)

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 1)

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #2 – strategic vision

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #1 – Introduction

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Composability: Low-code versus model-driven

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Leveraging best-of-breed

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Old Wine in New Bottles?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Treating Your Employees Like Customers

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Process latency – not always a bad thing

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process notifications in action

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

End to end processes in action

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

From Modeler to Citizen Developer

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

What Are You Modeling For?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Design tips for agile processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for end-to-end processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for combining BPMN, CMMN and DMN models

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Case Management Work Patterns

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

In financial services, process rules content

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Not the New Normal for Mortgage Lending

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Expanding Across the Organization

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Picking Your Next Project

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

From Project to Program: Post-Implementation Review

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Building Incentives Into Processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Discovering Processes In Unusual Places

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Foiling BEC Fraud With Better Distributed Processes

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Better Process Analysis Using Analytical Techniques

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Designing Loosely-Coupled Processes to Reduce Fragility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

The Changing Nature of Work

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Case for a Business Automation Center of Excellence

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Designing Processes for Agility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Conway’s Law and End-To-End Business Processes

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Need for Goal Alignment

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

All Blog Articles

Read our experts’ blog

View all

What is CMMN?

Case Management Model and Notation™ (CMMN™) is an international standard modeling language and graphical notation for case management.

What is case management?
Case management is used for capturing and automating work methods and information to handle unstructured and adhoc processes requiring activities that may be performed in an unpredictable order in response to evolving situations. The CMMN notation combined with an automation engine provides a low-code worldwide standard solution for managing cases in diverse business settings. While using CMMN is easy enough for business people to understand and depict case handling procedures, it is also expressive enough to allow CMMN models to become software process components that can be automated. CMMN has an easy-to-use flowchart-like graphical notation that is independent of any specific implementation environment.

The CMMN standard is published and supported by OMG, an international, open membership, not-for-profit technology standards consortium.

Learn More

BPMN™ (Business Process Model and Notation), DMN™ (Decision Model and Notation™), and CMMN notation are all OMG visual modeling standards that can each be used independently yet were designed to be complementary. BPMN workflows can be embedded directly as process tasks in CMMN models and CMMN can also invoke DMN models to automate business decisions and create or change case file item values.

The CMMN standard utilizes visual models which are standardized, verifiable, and where the model can serve as both the documentation and as the executable source for case management automation engines. A CMMN case can be automated directly from the visual model into case management engines without any translation from IT. CMMN diagrams can be programmatically validated and can be created and maintained by subject matter experts (SMEs) and IT professionals thus eliminating business-to-technical specification handoff issues and errors.

When comparing structured processes versus unstructured processes, we are in fact describing the difference between BPMN and CMMN. Unlike BPMN process management models, adaptive processes are unstructured, so CMMN does not use sequential control flows to describe case activities. A case contains a Case File that holds Case File Items (the case data and information) and is described by a Case Plan, the CMMN model. In CMMN, a model (diagram) could have multiple cases with each case described by a Case Plan. CMMN Case Plan models use a descriptive event-condition-action (ECA) paradigm. That is, when an event occurs, if the condition(s) for the task are fulfilled, the task action is carried out.

The Case Plan is visually captured as a collection of activities (Tasks) that may occur in an unpredictable order where events or workers determine how the case work progresses. Due to how cases are typically managed, not all work that happens during a case is actually modeled in the Case Plan. For example, the interaction of case workers with the Case Plan and Case File Items may not be modeled or be only partially modeled. Typically, how the Case File Items actually get into the Case Plan isn’t modeled. Case data can be added, removed, modified or simply viewed by the case workers at any time during the processing of a case without the need for these data interaction to be modeled specifically.

Adaptive case management uses documents and contextual information to determine the flow of the case at runtime reacting to events and directed by knowledge workers. To facilitate this dynamic case management, the Case Plan can also contain discretionary items modeled to be used only when the case worker decides they are appropriate and needed. Additionally, manually activated Tasks and Stages in a case may have all the conditions met for execution but still will only be executed if the case worker chooses to do so.

A Case File Item can represent information of any kind, both unstructured or structured, and from simple items to complex data structures. Typically, Case File Items represent documents, because organizations usually interact via documents like PDFs and word processor documents, spreadsheets, presentations, images, videos, and other recordings. Usually, these are kept in common file types that are supported by most operating systems and browsers (think PDF, PowerPoint, Word, .png, .jpeg, .gif, .MP3, etc.) The ability to view, add, change, or delete data (Case File Items) from a case at any time while the case instance is active is a main feature of CMMN and causes many of the events that trigger actions like additional Tasks becoming active (the ECA paradigm.)

CMMN gives case workers access to all the relevant case information associated with a case and gives them empowering control to decide how a case evolves while still providing a reusable organizational frame of reference via a non-proprietary international standard modeling notation.

Who Uses CMMN?

Since CMMN is a non-proprietary and software vendor neutral language, it lends itself to solutions in every type of organization. A CMMN Case Plan can provide a reusable organizational frame of reference for resolving cases in a wide range of business situations. CMMN examples include, government services, loan applications, insurance claims, customer complaints, and patient cases in healthcare. CMMN is also being used to manage legal cases, investigate fraudulent activities, administer social programs and other non-profit case activities like charities. CMMN models are also used for specific problem solving that requires human decision making in addition to automation such as automobile roadside assistance, financial planning, compliance tracking, facilities management, and contract management.

Because CMMN supports defining case diagrams at different levels of abstraction, it can be used in different ways to meet varying organizational needs. CMMN can be used to create only a graphical depiction that visualizes and documents case activities. Adding more details to models enable their use as the source code of an automation engine to create case applications. Using the Trisotech case management system, models can be created by non-IT personnel and enriched for execution by subject matter experts, power users, or IT.

According to OMG, Quote Applications of Case management include licensing and permitting in government, application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centers, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made-to-order products.

Not many tool vendors fully support the CMMN standard, known as “Complete Conformance.” For example, most tools do not support the full compliance infrastructure required to automate cases or interact with BPMN and DMN.

Case Management Model and Notation in Financial Services

CMMN in Financial Services

In addition to an ever-increasing demand for mobile and online banking services, financial services organizations including retail and commercial banking, insurance, mortgage, investments, etc. need to constantly re-engineer existing business processes.

More info on Finance

Process agility and continuous improvement are required to stay competitive so nearly every financial services business uses various forms of process automation. More and more of these organizations are turning to case management to improve activities where human decision making must often supplement or replace procedural workflows. This is especially true with customer-facing activities where a customer-centric human touch adds value. Using CMMN modeling software and automation engine, one can document, track, and orchestrate the activities of administrators, users, systems, and customers while allowing human judgement to control the pace and path of interactions.

Standards play a big part in the financial services world. Using an international standard like CMMN is supported through multiple CMMN modeling tools and makes finding modeling and automation workers easier as the talent pool of trained and certified staff is globally available.

CMMN is being used to document and automate the management of hundreds of financial case types including:

On-boarding New Customers
Customer Retention
Know Your Customer (KYC) Reviews
Wealth Management
Portfolio Management
Records Management/Archiving
Risk Management
Regulatory Reviews
Content Management & Distribution

Customer Document Requests
Credit Card & Other Dispute Management
Digital Mortgages
Fraud Detection
Underwriting
Account Reviews & Servicing
Document/Transaction Tracking
Cross-selling & Up-selling
Off-boarding Customers

Case Management Model and Notation in Healthcare Services

CMMN in Healthcare

On the adoption of CMMN (as well as BPMN and DMN) as a standard at Mayo Clinic from the press release for Field Guide to Shareable Clinical Pathways:

More info on Healthcare

Healthcare is one of the fastest-growing sectors in the world economy and many healthcare organizations are undergoing one or more digital transformation initiatives. As part of these transformations, there is an increased need for technology innovation and increased reliance on evidence-based medicine. Healthcare automation needs have become so critical and pervasive that to address these concerns head-on, a community of practice, BPM+ Health, has been created. BPM+ Health was established based on the use of open standards-based notations including CMMN (case management) and other open IT standards which allows for all types of health organizations, professional societies, and vendors to document their care pathways, cases, and workflows, so they are sharable, discoverable, and automatable. By applying standard CMMN to healthcare practice patterns, the information becomes computer-consumable and automatable, giving doctors and clinicians evidence-based information at the point of care.

According to members of BPM+ Health and the OMG Healthcare Domain Task Force who publish the Field Guide to Shareable Clinical Pathways, Quote Certain clinical pathways and activities can be prescribed (deterministic) at design time – during the process of designing the model, such as making a doctor’s appointment for the flu – but other processes are more ad hoc and non-deterministic. These ad hoc processes may be due to sudden and unexpected events that occur in the real world or due to known events that are unpredictable in their timing. Often the environment requires care providers to adapt to unexpected, emerging and/or changing environmental conditions (e.g., no fetal heartbeat is observed during a regular prenatal care exam). As such, the traditional method of representing clinical pathways using BPMN is difficult at best. An agile ad hoc environment cannot be easily represented with BPMN and requires an adaptive “case management” style of representation. This is the role of CMMN: specifying clinical responses to ad hoc events based on the state of the particular case. CMMN allows real-time response to the unfolding of sudden and unforeseen events in the form of flexible choices/selection of activities as the care provider determines necessary.

Today, most healthcare organizations use textual descriptions, diagrams, and flow charts to document clinical processes. CMMN is a proven international standard and as part of many transformation efforts, CMMN is being used to create automatable graphical representations of healthcare cases and clinical pathways. CMMN case diagrams are visual, unambiguous, intuitive, and easily understood by both providers and IT professionals thus making them superior to text documents.

Well designed and documented CMMN case models are also easy to maintain which is important in healthcare where constantly changing regulations, rapid advances in medications and treatment, and frequently changing policies all contribute to high-volume and constant maintenance.

According to Wikipedia, The American Case Management Association (ACMA), a non-profit professional membership organization supporting the practice of hospital case management through education, networking, publications, bench-marking, and research describes a hospital Case Manager’s responsibilities to include the following functions:

Advocacy & Education – ensuring the patient has an advocate for needed services and any needed education.
Clinical Care Coordination/Facilitation – coordinating multiple aspects of care to ensure the patient progresses.
Continuity/Transition Management – transitioning of the patient to the appropriate level of care needed.
Utilization/Financial Management – managing resource utilization and reimbursement for services.
Performance & Outcomes Management – monitoring, and if needed, intervening to achieve desired goals and outcomes for both the patient and the hospital.
Psychosocial Management – assessing and addressing psychosocial needs including individual, familial, environmental, etc.
Research & Practice Development – Identifying practice improvements and using evidence-based data to influence needed practice changes.

CMMN can be used to create healthcare-case models and automation in hundreds of ways. Here are some representative CMMN examples:

Create/improve clinical guidelines
Planning & delivery of care
Evaluate patient results & adjust care plan
Verify coverage/benefits with insurers
Prior authorization
Referrals to specialists
Coordinate claims with multiple benefit plans
Coordinate insured services with community services
Coordinate discharge/return home services
Provide post-care follow-up

Clinical decision support (CDS)
Catastrophic & large claim management
Maternity case management
Recommend coverage exceptions
Arrange special services
Coordinate services with other providers
Transitional care management
Negotiate rates with out of network providers
Provide patient education
New patient referrals

Trisotech and CMMN

Trisotech is a world leader in business automation solutions and an active contributor to the CMMN standard. Trisotech’s Case Modeler is known as the reference implementation for CMMN modeling tools and supports all CMMN symbols (shapes) ,a.k.a. “Complete Conformance.” Trisotech also supports and integrates the BPMN and DMN standards into its Case Modeler and in the Trisotech Case Management Automation Engine for automating CMMN models.

CMMN model creation, administration, and management as well as automation, library management, administration, configuration, debugging, simulation, and audit logging are all visual and browser based and can be hosted in public or private clouds – making Trisotech’s offering a complete case management and automation solution.

Trisotech provides free case management tools through self-service trial subscriptions and Visio templates.

Trisotech
CMMN in Financial Services

Trisotech also provides CMMN extended modeling support in the form of drag-and-drop “Accelerators” for the MISMO™ and FIBO® (Financial Industry Business Ontology®) standard data structures that can be assigned as Case File Items in CMMN case models. Trisotech financial clients include governments, insurance organizations, mortgage finance organizations, loan originators, retail and commercial banks, stock trading exchanges, credit card organizations, real estate brokers, investment brokerage houses and more.

Trisotech
CMMN in Healthcare

Trisotech is a founding member of BPM+ Health which promotes usage of CMMN, as well as BPMN and DMN, as an integral standards technology. Trisotech healthcare clientele include international and U.S. acute care hospitals, healthcare insurance organizations, HMOs, renowned teaching hospitals, PPOs, and healthcare professional organizations.

The Trisotech extends the Case Modeler (CMMN) with healthcare-specific additions. Through a combination of features and functions, healthcare organizations can now access FHIR® data structures and APQC Health Care Provider tasks, in their modeling and automation of CMMN cases. Predefined FHIR Data types (simple, complex, and special purpose) are provided as reusable drag and drop data structures that can be assigned as Case File Items in CMMN case models and APQC Health Care Provider tasks from the APQC Health Care Provider accelerator can be used as tasks in CMMN models.

1,000
free pre-built evidence-based workflow and decision models

As part of its Healthcare Feature Set (HFS), Trisotech also provides nearly 1,000 free pre-built evidence-based workflow and decision models including care pathways, clinical guidelines, and healthcare calculators in the BPM+ Health standard (CMMN, BPMN and DMN). These models are human-readable, machine automatable, and embeddable in most medical encounter systems. Healthcare organizations can use these models, created under the direction of Trisotech CMIO John Svirbely, MD, as they are, or quickly and easily modify them to fit the exact nature of their organization’s policies and procedures. Healthcare organizations can also create their case models from scratch with the easily understood CMMN visual modeler that can be shared by practitioners, IT, SMEs, and business people.

Trisotech
Case Modeler Differentiators

Trisotech’s adaptive case management software is a CMMN-based business automation architecture built upon SaaS cloud technologies including API-first design which allows for the invocation of cases from practically any programming language in mobile, cloud, and on-premise server environments. These automated CMMN case models are scalable high-performance services. The automated case (Case Management) services and case automation engine are also structured to provide full support for today’s complex availability needs including containerization and docker technologies. The Trisotech CMMN offering, including modeling and automation, is completely browser based and can be run in any modern browser environment including Chrome, Edge, Safari, Firefox, etc. Automation servers can be hosted by Trisotech, or Clients including on-premise and public/private clouds like AWS, Azure, Google, etc. Advanced configurations allow for 24 X 7 operation, concurrent geographic dispersion and failover, and containerization operating environments.

The Trisotech Case Modeler offers many features other CMMN modelers do not. These include:

Complete “Conformance Level” modeling support
Single click integration with BPMN and DMN
Import of CMMN, MS Visio files
CMMN Method and Style Validation
Issue tracking and management by model
Multimedia model animator
Diagram Overlays (tags, flags, attachments, comments, time, cost, etc.)
Versioning of models
Dependency view of re-use and where-used
FEEL expression language from DMN for Low code automation (condition specifications in “If Part” on sentries for entry and exit criterion)
Heatmap visualizations

Drag & drop re-use by copy and re-use by reference (DEG: Digital Enterprise Graph)
Single Click deployment to execution library
Export to CMMN (XML) & images
CMMN Standard Validation
Threaded commenting down to element level
Lean/Six Sigma analysis
Configurable Documentation in Word or HTML including Overlays on models
Complete model element search
Deep Model diff to compare models to one another
Scope view of multi-diagram elements in a single CMMN model
Support for Custom attributes

OMG®, BPMN™, (Business Process Model and Notation™), Decision Model and Notation™, (DMN™), CMMN™, (Case Management Model and Notation™), BPM+ Health™, and FIBO®, (Financial Industry Business Ontology®) are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries. MISMO™ is a registered trademark of Mortgage Industry Standards Maintenance Organization, Inc.

Trisotech is an active contributor to the CMMN standard.

Trisotech Case Modeler and Automation are known as the reference implementations for CMMN.

Ask for a free Trial

Resources

Related to CMMN

Trisotech

the
Pioneer

View all

Get started with BPMN, CMMN, and DMN in Visio *

Use the Trisotech Free Visio templates to create visual representations of your operations using the BPMN, CMMN, and DMN notations.

Download Free Templates

To get you started, these templates include stencils containing all shapes and markers of these three standard notations. You can then utilize all the familiar features of Visio to apply variants and styles to customize your drawings. Simply use these templates to get you started on your journey to become acquainted with the triple crown of process improvement standards.

* Requires that you have a version of Visio.

The triple crown of process improvement standards

The Business Process Model and Notation (BPMN) , the Case Management Model and Notation (CMMN) and the Decision Model Notation (DMN) are powerful and expressive standards published by the Object Management Group (OMG) . This triple crown of process improvement standards offers universally recognized graphical notations in support of organizations seeking efficiency and effectiveness of their operations.

Go beyond just a Visio drawing

Creating Visio drawings describing your operations is a great first step toward Digital Transformation. To fully leverage your existing Visio drawings and take them to the next level, you can import them in the Trisotech’s Digital Enterprise Suite to instantly obtain these benefits:

Turn your diagrams into flexible and reusable models that can be versioned
Check correctness and validate your models against the standard specification
Export your models using the standard interchange file format
Augment your models with documentation and multimedia content and then animate them
Collaborate and share your work with the rest of your organization via modern Web Browsers
Get access to a multitude of other capabilities to help you Visualize, Innovate, Transform, and Improve your organization

Start a Free Trial

Trisotech

the
Altruist

View all

Blog

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

By Sandy Kemsley

Read Time: 8 Minutes

Last week was the annual DecisionCAMP conference, where mostly-technical decision management (DM) aficionados gather to talk about the technology, standards and application of DM.

I attended in person last year, but this year was all virtual, and I helped to organize the conference platform using Zoom for live presentations, YouTube for rebroadcast (you can see replays of the presentations there), and Slack for discussion. Although not a replacement for an in-person event, we did manage to capture some of the camaraderie and interactive conversations that would have happened if we had all been in the same room. We even had an after-conference Zoom cocktail hour on the last day!

The great thing about DecisionCAMP is that it’s really a grass roots labour of love by the DM Community site, rather than a for-profit or vendor-sponsored conference. Vendor presenters are requested not to plug their products, so the presentations are a combination of university research, updates and usage of the DMN (Decision Model and Notation) standard, and case studies of practical applications. For a process-centric practitioner/analyst like me, there are always interesting presentations exploring the overlap between decisions and processes. The most noticeable example of this was in a presentation on the “triple crown” of business modeling standards, namely, the Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) and DMN.

In my post on designing for agility, I mentioned that agility often depends on the design decisions such as the split between process and decision logic – what do you model in as a decision, and what do you model as a process – and went into some detail on when to consider splitting out decision logic from a process. Unsurprisingly, many DM practitioners don’t think first about processes, but suggest that you first focus on determining and modeling your business decisions, then build processes to gather the information and execute the steps required to make those decisions. Within those decisions, however, they often use rule flows, which are really processes that link together individual rules/decisions into larger decisions; this starts to muddy the waters in terms of designing decisions and processes, and may spread your processes over two different model types. To this we add case management (CM), which also provides some process and decision modeling, but may also link to DM and BPM models. Three model types based on three standards: this is the triple crown of process improvement standards.

The standards show how to combine the models: use a decision task in a BPMN or CMMN model to call a DMN model; use a case task in a BPMN model to call a CMMN model; or use a process task in a CMMN model to call a BPMN model. What the standards don’t show is why to combine the models, that is, what parts of the business to model using which standard. Technical proponents of the standards talk about applying the three standards to the “core management practices”, as if businesses were aligned along managing processes, cases and decisions, rather than their actual business capabilities and functionality. From a business operations standpoint, processes, cases and decisions are “implementation details”, not management practices.

There are some general guidelines for combining the standards, such as using CMMN for less structured knowledge work and BPMN for more structured processes, and DMN with either of those for repeatable business decisions. If you have ad hoc processes and decisions, that’s most likely to be modeled completely in CMMN, while repeatable processes with repeatable decisions would combine BPMN and DMN. However, many business scenarios aren’t that clear-cut, and contain a combination of ad hoc and repeatable processes, as well as ad hoc and repeatable decisions.

This presents two challenges.

First, business analysts who are tasked with documenting and analyzing business operations not only need to understand how the business works, but also need to decide how to map different parts of the business operation to the appropriate model type. In the absence of guidance on how to do this, business analysts will tend to use the model type and tool with which they are most familiar, and will tend to create a single model rather than multiple model types. This is how we end up with cases and decisions modeled as incomprehensible BPMN models, or processes being modeled as (non-standard) rule flows combined directly with DMN decisions within a DM tool. The solution to this is straightforward, although not necessarily easy: better training, mentoring and support of business analysts on the use of all three standards together. This is why I advocate a combined business automation center of excellence rather than centres for each skill or product: there needs to be a source of knowledge on how to appropriately combine model types (standards) and related technologies when analyzing business operations and making recommendations for improvements. This should include training on the three standards and how they relate to each other, but also specific use cases and examples of why to use one model type over another for a given scenario. For example, a CMMN model may manage the stages of an overall operation, with BPMN models used to drill into specific functional areas, and DMN models invoked from BPMN for repeatable decisions. Or a BPMN model may manage an end-to-end process, and call CMMN models for exception handling or other knowledge work activities.

The second challenge is that of model understandability by the broader business audience within an organization. The triple crown modeling standards are intended to bridge between business and IT by providing graphical representations of business operations that can be understood by business people while being directly executable for automation purposes; although often used by business analysts and developers, in their simpler forms they can be used as documentation and communication of the business operations to everyone from executives to front-line workers. This type of simplified communication is much more difficult when you have multiple interlinked models with three distinct model types. The viewers need to be able to understand enough BPMN to make sense of a process model, including the fact that “case task” symbol means they need to drill into a CMMN case model for that activity; then, they need to understand enough CMMN to make sense of the linked case model. Same goes for linking from a BPMN or CMMN model to DMN via a decision task, or linking from a CMMN model to a BPMN model. If the viewers don’t understand all three model types and how they interlink (much less why to interlink them at any particular point), the models become less useful as a broader communication tool. The solution to this second challenge is much less straightforward. It’s difficult to mandate or even motivate training on these standards for an entire organization: for business analysts, it’s an integral part of their job, but for everyone else, it’s just another thing that they have to learn but may not see the value. The best solution may be for business analysts within an organization, in conjunction with the business automation center of excellence, to create a simplified template for the three model types that they can use for communication purposes. Not perfect, but don’t let perfect be the enemy of good (enough).

Watch Trisotech’s Presentation at DecicionCAMP 2020

Watch now

Blog Articles

Sandy Kemsley

View all

Process Pain Points: Pended Processes

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Process Pain Points: Handoffs

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process Pain Points: Spreadsheets and Email

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

AI and Automation: Friends or Foes?

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

AI and BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Future-Proofing Your Business With BPM

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Best practices in business automation application – Implementation

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 3)

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

Business automation best practices #3 – Application development – Design (part 2)

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Business automation best practices #3 – Application development – Design (part 1)

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #2 – strategic vision

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Business automation best practices #1 – Introduction

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Composability: Low-code versus model-driven

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Leveraging best-of-breed

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Composability: Old Wine in New Bottles?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Treating Your Employees Like Customers

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Process latency – not always a bad thing

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Process notifications in action

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

End to end processes in action

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

From Modeler to Citizen Developer

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

What Are You Modeling For?

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Design tips for agile processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for end-to-end processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Design tips for combining BPMN, CMMN and DMN models

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Case Management Work Patterns

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

In financial services, process rules content

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Not the New Normal for Mortgage Lending

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Expanding Across the Organization

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

From Project to Program: Picking Your Next Project

Blog

By Sandy Kemsley

(Read Time: 7 Minutes)

From Project to Program: Post-Implementation Review

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Building Incentives Into Processes

Blog

By Sandy Kemsley

(Read Time: 6 Minutes)

Discovering Processes In Unusual Places

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Foiling BEC Fraud With Better Distributed Processes

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Better Process Analysis Using Analytical Techniques

Blog

By Sandy Kemsley

(Read Time: 10 Minutes)

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

Blog

By Sandy Kemsley

(Read Time: 8 Minutes)

Designing Loosely-Coupled Processes to Reduce Fragility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

The Changing Nature of Work

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Case for a Business Automation Center of Excellence

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

Designing Processes for Agility

Blog

By Sandy Kemsley

(Read Time: 5 Minutes)

Conway’s Law and End-To-End Business Processes

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

The Need for Goal Alignment

Blog

By Sandy Kemsley

(Read Time: 4 Minutes)

All Blog Articles

Read our experts’ blog

View all

Blog

CMMN Method and Style – Part 2

By Bruce Silver

Read Time: 8 Minutes

Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard.

As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as “style rules” that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler. As described in that post, CMMN’s event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine. The problem for most modelers is that the detailed logic depends on case variables and conditional expressions that are typically delegated to programmers and in any case do not appear in the case diagram. Method and Style conventions make them visible.

In CMMN’s ECA style, the triggering event is a lifecycle state transition of a task or stage (e.g., start, complete, exit), milestone (e.g., occur), or file item (e.g., create, update). The condition is a Boolean expression of case variables (file items). The action is enablement or termination of a plan item. In the diagram, enablement is signified by a white diamond shape, called a sentry, on the boundary of the triggered plan item. The sentry is connected to the triggering item by a dash-dot connector called an ON-part link, labeled with the triggering event, such as complete. In similar manner, termination is signified by a black sentry. The condition is called the sentry’s IF-part, an expression of case variables (file items). The rules of the spec do not describe how the condition – if there is one – is made visible in the diagram, but Method and Style provides a way. The ON-part determines when the action occurs; the IF-part determines whether it occurs.

For example, in the diagram below, task b is enabled when task a is complete. Here there is no IF-part, i.e., the condition is true by default.

BPMN Method and Style has the concept of an activity end state, meaning how did the activity end, successfully or in some exception state? The end state names, typically Adjective or Noun-Adjective, are the labels of the gates on an XOR gateway following the activity.

For example, the BPMN diagram above means that task a has end states “OK”, leading to task b, and “Exception”, leading to task c. CMMN Method and Style borrows this idea, with the task end state indicated by the sentry label of an entry condition triggered by the complete event of another plan item.

Here, CMMN task a again has end states “OK”, leading to task b, and “Exception”, leading to task c. In CMMN Method and Style, the end state of a task is captured in an implicit variable [taskname].end, and here the sentry label represents the entry condition’s IF-part expression, a Boolean. When the ON-part link – the dash-dot connector – from the triggering plan item is labeled with the complete event, the sentry label is visual shorthand for the full IF-part expression,

[triggering task].end = [sentry label]

The expression syntax depends on the expression language employed. The syntax I use is FEEL, which is the default in the Trisotech tools.

A milestone is a plan item signifying an achieved state of a stage in the case. Like task end states, milestones are used in Method and Style to signify the end state of a stage, determining what happens next (or what is possible to happen next). Unlike task end states, which are exclusive, more than one milestone in a stage may be achieved. In Method and Style, global variable Milestones contains the list of all case milestones that have been achieved, in the format [stagename].[milestone name]. Similarly to the example above, when completion of a stage determines what happens next, a sentry labeled with the name of a milestone in the triggering stage is visual shorthand for the FEEL IF-part expression,

list contains(Milestones, [stagename].[milestone name])

Let’s take a look at a few of the style rules. From the above examples you see that labels play a key role. In the spec, executable CMMN references elements by ids, which are not visible, and pays little attention to labels, which are. Many style rules require labels on CMMN elements and ascribe particular meaning to them, as we saw above with sentry labels signifying the IF-part condition. The label of a plan item signifies its name, which must be unique in its context. For example, style rule 0010 checks for this:

In the diagram on the left, the stage and its enclosed task have the same name, Registration. This is a style error. The diagram on the right is correct.

In the spec, dotted line connectors called associations are optional annotations with no operational semantics, but Method and Style may require them, in order to make the case logic visible from the diagram. For example, the trigger of a timer event listener (similar to a timer intermediate event in BPMN) has no official representation in the diagram, so Method and Style uses a directional association labeled with an event of the triggering item. Without this connector, the trigger is assumed to be activation of the containing stage. If the connector is present, style rules require the event label:

The diagram above means that Registration Stage is terminated automatically (black sentry) if it is not completed within 7 days of the actual start of task Registration. The association labeled manual start defines the trigger of the timer. The timer label defines its duration. The diagram on the left is missing the event label, and thus is a style error. If the timer event listener is missing its duration label, that is also a style error.

Other style rules resolve inconsistencies in the CMMN spec. Style rule 0100, for example, prohibits ON-link connectors from crossing stage boundaries. In one part of the spec, it says such links are not allowed; in another part it says they are allowed, and in the wild you often see them. But such links do not work when a stage is rendered collapsed, and a basic principle is that the semantics should not depend on an element’s graphical rendering. In Method and Style such links are not allowed. The top diagram below is thus a style error; the bottom diagram is correct.

The diagram above also illustrates how milestones are used as stage end states. Task Acceptance is enabled when Registration Stage completes in the end state “Registration OK”. The sentry label is visual shorthand for the FEEL IF-part expression

list contains(Milestones, "Registration Stage.Registration OK")

And note also that the milestone Registration OK is activated when the task Registration completes in the task end state “OK”.

Still other style rules guard against infinite loops. The hashtag symbol indicates a plan item is Repeatable, meaning when it completes a new instance becomes Available immediately if its Repetition Rule is true. Like IF-part expressions, Repetition Rules are Boolean expressions of case variables (file items) that are normally invisible in the diagram. Method and Style requires a text annotation to reveal the Repetition Rule; otherwise the rule is assumed to be true by default. Thus if a Repeatable task or stage is not manually activated, has no entry condition, and does not have a text annotation indicating a Repetition Rule, the new Available instance will become Active as soon as the previous one completes, an infinite loop that prevents completion of its containing stage.

In the left diagram above, task Registration is an infinite loop, a style error. In the center diagram, Registration is ok, since it is manually activated, and task Acceptance is ok as well, since it has an entry condition. In the right diagram, Registration is ok as well, since it has a Repetition Rule that prevents an infinite loop.

A final style rule example is intended to eliminate deadlocks caused by zombie states, when a stage is completed manually before its expected end state milestones are set. The rule says that if a stage has multiple milestones tested by the IF-parts of complete links, it should contain a single Required milestone triggered by all those milestones, in order to ensure proper stage completion. A stage may not be manually completed unless all of its Required elements are Completed. The example below illustrates:

In the top diagram, Registration Stage has two milestones tested by complete links, and one leading to exit. Since no plan items are Required, it is possible for a case worker to manually declare Registration Stage complete without achieving any of the milestones, and in that case there is no next step available. Style rules flag this with a warning. The bottom diagram is correct. Here achieving either milestone New registration or Existing registration sets the Required milestone Registration completed. The stage may not complete unless the Required milestone is achieved, preventing the zombie state.

If all of this looks wildly unfamiliar, that’s because it is! But help is on the way. My book CMMN Method and Style explains it all at length, and it is available on Amazon. You can play around with CMMN by starting a free trial.

Read part 1

Blog Articles

Bruce Silver

View all

DMN List and Table Basics

Blog

By Bruce Silver

(Read Time: 5 Minutes)

BPM+ : The Enduring Value of Business Automation Standards

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Make Way for B-FEEL

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is a Decision Service?

Blog

By Bruce Silver

(Read Time: 5 Minutes)

FEEL Operators Explained

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Lookup Tables in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is Method and Style?

Blog

By Bruce Silver

(Read Time: 3 Minutes)

Instance Alignment in BPMN

Blog

By Bruce Silver

(Read Time: 3 Minutes)

DMN 101

Blog

By Bruce Silver

(Read Time: 5 Minutes)

All Blog Articles

Read our experts’ blog

View all

blog

CMMN Method and Style – Part 1

By Bruce Silver

Read Time: 10 Minutes

Case Management Model and Notation (CMMN) is the poor stepchild of process modeling standards. It was developed a decade ago, around the same time as BPMN 2.0 and largely as a reaction to it by vendors who believed that “real” business processes were about knowledge workers interpreting documents, not web services orchestration following rigid rules.

In case management, the order of actions typically cannot be precisely defined at design time, and many different things happen concurrently. The list of available actions changes with the state of the case, and initiation of those actions is typically the result of manual case worker decisions. Such a different process paradigm demands a different standard.

There is some merit to that thinking, but in the meantime just a few tools have adopted CMMN. Part of the problem was self-inflicted. Unlike BPMN, which sought to emulate the familiar look of swimlane flowcharts, CMMN went for a decidedly unfamiliar look. Unless stakeholders make a modest effort to learn the language, the meaning of a CMMN diagram is utterly lost on them. Adding to the difficulty is the fact that case logic defined in the model is declarative, not procedural. That means that each case task and stage (phase) independently defines the conditions under which it is available to start or complete. That gives the case logic flexibility lacking in BPMN, but at the expense of intuitive visual communication.

I decided to take on this challenge with a new book, CMMN Method and Style, that attempts to make case management diagrams more comprehensible and the standard more widely adopted. This post provides a very brief introduction.

CMMN Basics

In a CMMN diagram, or case plan, actions are represented by tasks (rounded rectangles). The head-and-shoulders icon means a human task; other task types invoke a BPMN process, a DMN decision, or a CMMN subcase. Tasks are contained in stages (rectangles with clipped corners). The oval shapes are milestones, a type of event signifying some state of the case has been achieved. Tasks, stages, and milestones collectively are called plan items. Symbols at the bottom of a plan item indicate additional attributes. The triangular Play symbol indicates the plan item is manually started. The hashtag symbol indicates it is repeatable. The exclamation point indicates it is required, meaning it must be completed in order for its containing stage to complete.

Tasks and stages evolve through a sequence of lifecycle states: Available, Enabled (if manually started), Active, Completed or Terminated. A task or stage becomes Available when its containing stage becomes Active. (The case plan as a whole – the tabbed folder shape – is considered the outermost stage of the case.) Each lifecycle state transition generates a standard event that can trigger advancement of the case logic. Diamond shapes called sentries on the boundary of a task or stage represent entry or exit conditions triggered by a standard event and further controlled by a Boolean expression of case data. Once it is Available, a manually started task or stage becomes Enabled when its entry condition is satisfied, and then becomes Active when manually started by a case worker. If not manually started, it becomes Active as soon as the entry condition is satisfied. A stage may be marked Completed as long as none of its contained plan items are Active and all of them marked required are either Completed or Terminated.

Case data and documents, collectively called the case file, are available to all plan items at any time. Like plan items, each case file item also progresses through a series of lifecycle states, and those state transitions likewise generate standard events that can trigger plan item entry and exit conditions. Each file item is assigned a datatype. In Trisotech, these are modeled as FEEL item definitions as they are in DMN and BPMN models.

All of that is from the CMMN spec. Method and Style is my own methodology layered on top, aimed at making the logic as clear as possible from the printed case diagram. It uses milestones and sentry labels – which appear in the diagrams – to signify the end states of stages and tasks, without requiring modelers to explicitly define case variables for them.

Case Modeling Styles

When creating case models in CMMN, there is no single “best” style for representing the logic. Some modelers may consider progression of the case to be entirely based on the judgment of case workers rather than events and rules specified at design time. What happens in what order is not revealed by the diagram, even though this permits illogical ordering of tasks. The case worker is simply assumed to know the correct thing to do next.

Others may take the opposite point of view, describing most case logic explicitly using event-condition-action (ECA) via lifecycle events and sentries. While intrinsically more flexible than BPMN, CMMN models in this style are similar in that they try to reveal all possibilities of “what happens next” through the diagram.

Scenario: Write a Report

To illustrate, let’s look at the similarities and differences when applied to a very simple case model, writing a report. Here is the scenario:

The report may or may not require research. If it does, tasks include researching the topic and organizing references.
Preparing the draft is always required. It includes writing the text, also always required, and generating the table of contents. If the report contains graphics, additional tasks include creating the graphics, integrating them with the text, and generating a list of figures.
Periodically the draft in progress is reviewed. Tasks include seeking comments, discussing possible changes, and verifying spelling and grammar.
When ready, the draft is submitted for approval. The case completes successfully when the report is approved. It is also possible that the Approver cancels the report.

User-Driven Style

In the purest user-driven style, all choices of what to do when are made by case workers at runtime using their judgment about what needs to happen, as illustrated below.

The stage Do Research is discretionary (dashed border), meaning it occurs in some instances and not in others, as determined by an applicability rule defined in the planning table indicated by the small grid on the case boundary and described in Method and Style using a text annotation on the stage. If research is required, this stage transitions to Enabled when directed via the applicability rule, awaiting manual start by a case worker. When it starts (becomes Active), its tasks Research Topic and Organize References become Enabled, awaiting manual start. As drawn here, whether this stage ends in Completed or Terminated does not affect case completion.

Since it has no entry condition, the stage Prepare Draft is Enabled as soon as the case becomes Active. Since it is marked Required, the case cannot complete until this stage is Completed or Terminated, and the stage cannot complete until its Required task Write Text is Completed or Terminated. Other than that, the order in which its contained plan items are performed is determined entirely by the case worker.

The contained stage Add Graphics is discretionary, as it applies only to reports that contain graphics. Again, the applicability rule is defined in a planning table, here on the containing stage Prepare Draft, and visualized in the diagram by a text annotation on the discretionary stage. If the applicability rule is true, Add Graphics is Enabled when Prepare Draft becomes Active and must be manually started by a case worker. Its tasks include Create Graphics, Integrate Graphics, and Generate List of Figures.

Prepare Draft also includes the task Generate ToC, which could be considered “optional” since it is not marked Required. In practice there is little difference between such an optional task and a non-Required discretionary task.

The case also contains the task Approve report. It is not enclosed in a stage, meaning it becomes Enabled as soon as the case is Active. Presumably it would not be started until a draft of the report was complete or nearly so, but this is not required by the case plan model.

The milestone Report Approved is marked Required, meaning the case can end in the Completed state only if this milestone is set manually by a case worker. Alternatively, a case worker in the role Approver may terminate the case at any time, depicted as a user event listener triggering an exit sentry.

In the diagram above, all the stages and many tasks are marked Repeatable. Since no entry conditions are specified, that means that after being marked Completed or Terminated a plan item immediately becomes Enabled again. The effect of Repeatable here is simply protection against a case worker mistakenly completing or terminating a task or stage. Technically, this creates a new instance of the plan item, as CMMN has no way to “reopen” a completed or terminated plan item, but we assume the artifacts created by the original instance are available as file items to the new instance.

ECA Style

The ECA style, in contrast, represents the allowed order of plan items explicitly as much as possible using lifecycle transitions and sentries. It allows for a great deal more automated behavior than does the user-driven style, but at the same time may be more difficult for stakeholders on the business side to understand.

The same scenario is illustrated in ECA style in the figure below. Here the order of case actions is explicit. Because it is the plan item’s complete event that usually triggers what happens next, this case could probably be modeled more simply and clearly as a BPMN process. Let’s take a closer look.

When the case first starts, the only plan item enabled is Plan Report, as all the others have entry conditions. Plan Report creates the file item Plan, indicated by the page symbol with a dotted arrow from the task. The dotted arrow in the spec is an association, just a diagram annotation, but in Method and Style we say a task that creates or modifies a file item should display this connector. File items are represented in the case diagram when their values or events are used in the case plan logic. We need something like this to say that Do Research and Create Graphics are only performed under certain conditions.

When Plan Report is Completed, its complete event triggers the sentry on Prepare Draft, making that stage Enabled. Every entry condition has two components: zero or more ON-parts, dash-dot links to a plan item or file item, labeled with a standard event, signifying when entry occurs; and an IF-part, a Boolean expression of file item values, signifying whether entry occurs. In Method and Style, the IF-part condition is represented by the label of the diamond shape. No label means the IF-part condition is satisfied by default. Here there is no label, so Prepare Draft becomes Enabled when Plan Report completes. Once Prepare Draft is manually started, it becomes Active and all its contained plan items become Available.

The contained stage Do Research has an entry condition with no ON-part, meaning its IF-part condition is evaluated as soon as its containing stage Prepare Draft becomes Active. Here the IF-part references the Research required component of the file item Plan. Do Research is Enabled only if Plan.Research required is true. Similarly, the task Create Graphics is Enabled only if Plan.Graphics required is true. Note that the entry condition for Integrate Graphics has two ON-parts, meaning both Write Text and Create Graphics must first be completed.

If Create Graphics is not performed, then Integrate Graphics and Generate List of Figures are not performed, either. The task Generate ToC has two entry conditions, meaning it is Enabled either when Write Text is Completed and there are no graphics, or when Integrate Graphics is Completed.

None of the plan items of Prepare Draft are Required, meaning the stage may be declared Completed whenever none of its plan items are Active. This triggers the stage Review draft, which contains tasks Obtain comments, Discuss changes, and Correct Grammar and Spelling, performed in parallel.

A basic concept of BPMN Method and Style is the end state of a process or subprocess, indicated by the end event reached and signifying how did it end, successfully or in some exception state. CMMN Method and Style uses a similar idea for stages, with milestones playing the role of end events. Here Review draft has two manually set end state milestones, either Draft complete or Revision required. Technically a milestone is an event, but Method and Style assumes each milestone in the Completed state is listed in an implicit Milestones file item that can be tested by sentry IF-part expressions. If the stage ends with Draft complete set, Approve report is triggered. If it ends with Revision required set, it goes back to Prepare draft. In order to prevent a “zombie state” in which the stage is manually declared Completed without setting either milestone, we also need to add the Required milestone Review Complete, which depends on setting one of those two end states.

In Method and Style, tasks also have end states, captured in the implicit file item [taskname].end. Approve report has task end states “Approved” and “Not approved”, which are tested by sentry IF-parts to trigger either the milestone Report approved or the milestone Changes required. These milestones act as end states of the case as a whole, although the case can end in the Completed state only when Report approved is set. Changes required goes back to Review draft and then likely back to Prepare draft for revision.

As in the user-driven model, an Approver also can exit the case at any time.

* * *

Where the User-driven style requires less explanation, the logic of what happens under what conditions is not contained in the model. It’s entirely inside the heads of the case workers at runtime. The ECA style makes that logic explicit, but the declarative modeling paradigm takes some getting used to. In many case models, both styles are used, with User-driven in some stages and ECA in others. Method and Style adds some extras that put needed logic details in the diagram, where they can be seen by stakeholders other than those who created the model.

As you might expect, there are style rules as well, with style rule validation built into the Trisotech software.

Read part 2

Blog Articles

Bruce Silver

View all

DMN List and Table Basics

Blog

By Bruce Silver

(Read Time: 5 Minutes)

BPM+ : The Enduring Value of Business Automation Standards

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Make Way for B-FEEL

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is a Decision Service?

Blog

By Bruce Silver

(Read Time: 5 Minutes)

FEEL Operators Explained

Blog

By Bruce Silver

(Read Time: 5 Minutes)

Lookup Tables in DMN

Blog

By Bruce Silver

(Read Time: 5 Minutes)

What Is Method and Style?

Blog

By Bruce Silver

(Read Time: 3 Minutes)

Instance Alignment in BPMN

Blog

By Bruce Silver

(Read Time: 3 Minutes)

DMN 101

Blog

By Bruce Silver

(Read Time: 5 Minutes)

All Blog Articles

Read our experts’ blog

View all

How a Swiss government uses Case Management and CMMN to keep track of parliamentary interventions

Abstract

The processing of parliamentary interventions in a Swiss state (canton) involves many different parties: Parliamentary Services, Government, Ministries, Commissions, etc. In this jurisdiction, it is lawfully required that the government responds to each intervention within precise delays. Additionally, the government must publish an overview of the progress of answering and executing all interventions on a regular basis.

With multiple actors, varying delays and numerous ongoing instances, the government needed a flexible solution to communicate and deliver services to the citizens.

On these bases, the state administration initiated a project to implement a system for keeping track of parliamentary interventions, from their tabling to their classification by parliament after execution. To be able to communicate the courses of action easily and graphically, it was decided to use a model-driven approach. Not only should the models be understandable by all stakeholders, technical or not, but they also needed to be directly implemented on the state administration’s process engine.

At first sight, the processes might have looked like typical linear processes with several parties involved that can be modeled and implemented using BPMN. When diving into the details, it however became clear that it was a better approach to view the intervention as an object (case file) transitioning from one state to another through the occurrence of events or actions triggered by the different process participants, which corresponds to the CMMN view of a process.

In this webinar, we will demonstrate:

How CMMN allows to focus on the activities that the different parties involved can perform on an intervention, depending on its current state;

How each of the activities can be analyzed in the context of the current state of the intervention without having to take into account the rest of the process;

Why CMMN fits an agile software development approach; and

How CMMN can provide the workflow logic behind user-facing software applications.

Serge Schiltz, CEO and founder of processCentric GmbH is the founder of processCentric GmbH, a firm that provides expertise in the field of business process and rules management based in Switzerland and working all over Europe. He has delivered business process analysis, decision management and software development projects for over 25 years. Dr. Schiltz is also an author, university lecturer and instructor in project management, business analysis and BPM. He as published several articles and books in English, German and French.

Jean-François Gonguet, Senior Solution Architect at adesso Schweiz AG At adesso, Jean-François is in charge of developing partnerships for business process management, containerization and cloud-ready applications with various technology providers. Before that, he spent 28 years at IBM as technical pre-sales architect and has been involved in different projects around BPM and integration for large customers.

Jean-Christophe Crettenand, Head of Information System, Canton of Valais Government Controlling For fifteen years, Jean-Christophe devoted himself as a PowerBuilder and PL/SQL specialist in the development of an IT solution allowing the management of the State by performance mandate. In 2012, during his master’s degree in Information Systems Management, he discovered BPMN and project management. Since then, he is coordinating inter-agency projects, including ViaParl: “Keeping tracks of parliamentary interventions”.

Blog

BPM+ : The Enduring Value of Business Automation Standards

In the Beginning

BPMN

CMMN

DMN

Shared Principles

Enduring Business Value

SDMN, a Common Data Language

The Path Forward

Blog Articles

Bruce Silver

All Blog Articles

Read our experts’ blog

DecisionCamp 2024 Presentation Revolutionizing Credit Risk Management in Banking

Presented By

Description

Content

Presentation

DecisionCamp 2024 Presentation Revolutionizing Credit Risk Management in Banking

Presented By

Description

Videos

Recorded webinars

Blog

Part I: Learning Modeling and Notation Tools

How long does it take to learn?

My journey

What are the barriers?

Blog Articles

John Svirbely

All Blog Articles

Read our experts’ blog

What is FEEL?

What Are Expression Languages?

Expression Languages

Scripting Languages

Programming Languages

Is FEEL Like Microsoft Power FX (Excel Formula Language)?

FEEL Benefits for Technical people and for Business people.

Technical Benefits of FEEL

Decision focus language

Expressiveness

Decision Table Support

Strong typing and type inference

Boxed Expression Support for FEEL

Flexibility and modularity

Testing and Debugging

Execution efficiency

Integration FEEL

Extensibility

Interoperability

Business Benefits of FEEL

Standardization and Vendor-neutrality

Business-Friendly

Simplicity and Readability

Ease of Use

Decision Traceability

Decision Automation

Compliance and Governance

Decision Analytics

Trisotech FEEL Support

Most comprehensive FEEL implementation

FEEL Boxed Expressions

FEEL Functions

Autocompletion

FEEL as a Universal Expression Language

FEEL Validation and Debugging

Additional Presentations and Blogs

Trisotech

the Pioneer

BPM+ Virtual Coffee 5 min Intro to CMMN

Videos

Recorded webinars

Vlog

Design tips for combining BPMN, CMMN and DMN models

Watch this short video for more…

Blog Articles

Sandy Kemsley

All Blog Articles

DecisionCamp 2024 Presentation
Revolutionizing Credit Risk Management in Banking

DecisionCamp 2024 Presentation
Revolutionizing Credit Risk Management in Banking

Part I:
Learning Modeling and Notation Tools

the
Pioneer

BPM+ Virtual Coffee
5 min Intro to CMMN

Trisotech
CMMN in Financial Services

Trisotech
CMMN in Healthcare

Trisotech
Case Modeler Differentiators

the
Pioneer

the
Altruist