Behind the scenes of business process management workflows is a network of complex decision-making. The data runs through the decision tree, turning left at one point and right at another to conclude. To the untrained eye, the code that routes data via the process reads like a foreign language, preventing communication between computer science experts and front-office team members. The decision model and notation (DMN) are at the intersection of these two diverse groups.
What is DMN?
The Decision Model and Notation (DMN) is a standard issued and managed by the Object Management Group (OMG). Provide a standard approach to describe, model, and implement repeatable decision-making within an organization or initiative. It also aims to facilitate the sharing and exchanging of decision-making models among organizations.
This modeling notation consists of a visual grammar that allows decision-making and business rules to be documented in a manner readable by both business and technical audiences, thereby preventing misinterpretation of decision-making and rules. As a result, the decision model also describes how to evaluate the logic of the decision defined in the decision table using Friendly Enough Expression Language (FEEL).
The DMN defines two levels of language to better align with the organization’s role:
Request Level
Work with business professionals to invent, analyze, and define decision rules. It provides a mechanism for people who own businesses to model them without requiring technical knowledge of how they are implemented.
Logic level
To collaborate with an implementation team that reinforces the definition to include decision logic in the form of decision tables that business staff can manage or expression logic that technical staff manage.
How does DMN complement BPMN and CMMN?
DMN is one of three key languages for business process modeling. Along with Business Process Modeling Notations (BPMNs) and Case Management Models and Notations (CMMNs), organizations can take advantage of a complete library of languages to help civic developers and IT professionals collaborate on workflows and automation.
Business Process Modeling Notation
Business Process Modeling Notation (BPMN) outlines a predictable and repeatable process. The BPMN diagram not only pinpoints the start and end of the workflow but also shows the sequence of events that occur throughout.
Case Management Model and Notation
Not all processes are predictable enough to follow a specific, fixed set of steps to make decisions. In fact, there are many automated processes that require human intervention to make decisions. Case management is a technique used to manage out-of-the-box situations. The case management model and notation help the team model these fringe processes to integrate the steps performed by the knowledge workers involved.
Decision Model and Notation
The DMN zooms in on the detailed logic behind each step.
A simple example: The activity in the BPMN diagram may say, “Create a seat table,” but DMN provides detailed logic to drive this step. The DMN pinpoints detailed input, such as relationship compatibility and attendee age, to determine where each guest sits.
Elements for decision service modeling
The DMN notation describes the various elements required to understand and model decision services:
Determination: Choosing an output value from a set of input values using logic that describes how the output is selected from the input values.
Input Data: Information used as input values for one or more decisions.
The decision “requires” the INPUTS to determine the OUTPUT. The INPUT is input data or a decision OUTPUT.
Business knowledge: Business rules, decision tables, analytical models, and other functions or methods encapsulating business knowledge.
The decision logic that explains how to choose the output may include one or more business learning models that encapsulate business knowledge in the form of rules, analytical models, or other formalities.
Knowledge Source: Decision Making Power
These are references to real-world factors that must be consistent in decision making, such as domain experts, source documents, and test case sets.
- People who define and maintain logic
- Documents
- Organizations
- Legislation
- Tests
Knowledge sources are typically associated with business knowledge models to show how business knowledge is managed or maintained.
Decision Service: This is like a bunch of decisions you can use over and over again. It sets out the logic that can be reused. It shows one or more findings from a decision model that you can use repeatedly like a tool. You can use it inside (for decisions) or outside (for BPMN tasks).
Any Decision Service that wraps around a DMN decision model won’t have any lasting effects and will be “stateless.”
The decision requirements level of a DMN decision model includes a Decision Requirements Graph (DRG) shown in one or more additional Decision Requirements Diagrams (DRD).
Benefits of DMN
Extensive experience:
Despite being a relatively young standard, DMN benefits from professionals with decades of experience in business rule management. Although this standard does not define specific mounting patterns, it supports modern and lightweight mounting and provides greater flexibility than traditional business rule engines.
Direct Execution:
DMN enables both modeling and execution of decision making using the same language. Business analysts can easily express decision rules in a clear table and execute them directly in a decision engine (like Camunda). This minimizes the chance of misunderstanding between business analysts and developers and enables rapid changes in production environments.
Standardize:
The DMN is not owned by a specific company but by an established organization (OMG). The institution has already set global standards in other widely used frameworks such as BPMN and UML. Compliance with DMN reduces reliance on single-vendor products.
Create decision tables using DMN.
To begin, make sure you’ve registered for a Camunda 8 account.
Set up a cluster.
To deploy and run your process in Camunda 8, it’s necessary to establish a cluster.
Follow these steps:
- Go to the Console, open the Clusters tab, and select Create New Cluster.
- Name your cluster. We suggest choosing the Stable channel and the latest generation for this guide. Also, pick your region. Then, click Create cluster.
- Allow a few moments for your cluster to be created. Monitor the status on the Clusters page or within the cluster by checking the Applications section.
- Even if the cluster is still being created, you can continue with the modeling process.
Development Clusters
Users on the Starter Plan have access to one development cluster as part of their plan. This cluster allows free execution for development purposes and includes deployment and execution of models (such as process instances, decision instances, and task users) at no additional cost. If needed, extra clusters can be acquired through your billing reservations.
Beginning with DMN
After logging in to your Camunda 8 account, follow these steps:
- Access the Modeler by clicking the square-shaped icon at the top left corner of the page.
- Choose “New project” and give your project a name. In this instance, let’s call it “Deciding what to wear.”
- Click “Create a new file,” then select “DMN Diagram” and assign a name to your diagram. For our example, we’ll call it “Picking an outfit.”
Run DMN
The modeling process starts with the Decision Requirements Diagram (DRD) view. Here, you can build a DMN model by simply dragging and dropping elements from the palette on the left onto the diagram canvas.
Start with the default rectangular decision-making symbol. Double-click the symbol to rename it to Clothes to wear. In the Properties panel, select the General drop-down menu to update the ID to clothingChoice.
In this figure, we want to include two input data elements, temperature, and activity, which affect the choice of clothes. There are two ways to do this:
Drag and drop the elliptical input data element from the left menu to the DRD, give it a name, and click the decision and arrow icon to connect.
Click directly on the decision, then click on the input data element to drag and drop it onto the canvas. The second option shows that the input data is automatically connected to the decision.
Assign the appropriate ID to the input data icon. In this example, we give the IDs “temperature” and “activity”.
Creating a DMN Table
Once the Decision Requirements Diagram (DRD) has been finalized, it is time to create a DMN table for the decision.
Click on the table icon in the upper left corner of the box containing the decision “Clothes to wear.”
This table sets rules based on weather and activity and determines what to wear. For example, a specific result is triggered for clothing selection when certain conditions are met (e.g. when two values match for weather and exercise).
Click the + icon next to the “When” column to analyze the weather and the activity.
Double-click the first column. In the Expression field, type “temperature.” Since the Type remains string, input “Hot” and “Cold” in the Add Predefined Values field, separated by commas. Hit the “enter” on your keyboard to save these values.
Similar to the first column:
Enter “activity” for the expression.
In the Add Predefined Values field, type “inside” and “outside,” separated by commas.
Hit the “enter” on your keyboard to save these values.
Manage the Output:
Double-click the Output column.
In the Output Name field, enter “clothingChoice.”
Input “shorts” and “pants” in the Predefined Values field, separated by commas.
Click the pencil icon to outline the potential outcomes. For example, you can establish a rule that when the input values are “hot” and “outside,” the decision is to wear shorts. These inputs can also be combined with other rules.
Deploy Your Diagram
Click “Deploy” to activate your DMN decision table.
You can now incorporate your DMN table into a BPMN diagram using features such as a business rule task.
When a process instance reaches a business rule task, the decision is assessed using the internal DMN decision engine. Once the decision is made, the process instance progresses.
If the decision evaluation encounters an issue, an incident is raised at the business rule task. Upon resolving the incident, the decision is re-evaluated.
Conclusion
DMN (Decision Model and Notation) stands as a vital component bridging the gap between business and technical realms in the intricate landscape of business process management. It provides a standardized approach, allowing for precise and repeatable decision-making within organizations. DMN seamlessly complements BPMN (Business Process Modeling Notation) and CMMN (Case Management Model and Notation), forming a powerful trio for efficient workflow and automation collaboration. By offering extensive experience, direct execution capabilities, and standardization advantages, DMN is a flexible and valuable tool in modern business rule management. Its step-by-step implementation, from model creation to table deployment, ensures a streamlined and effective decision-making process within Camunda 8.
