The power of Decision Model and Notation (DMN)
How and when to use DMN as a business logic solution.
Every industry has a need to scale their business logic and business processes. Determining what technology to use for that automation can be confusing and overwhelming. Solutions such as application code, decision tables, rules engines, workflow engines and machine learning are just a sampling of some of the possible solutions. The best place to start is to clearly understand the problem you are trying to solve and the characteristics of the use case. This key information will then help guide you to the right solution.
In this blog, we will provide an overview on some of the common business logic solutions and the use case characteristics they align to. We will double click on one in particular—Decision Model Notation (DMN). DMN is an industry standard for describing business decisions and rules via visual modeling, decision tables and a domain-specific language known as FEEL—Friendly Enough Expression Language. These DMN solutions provide a way to manage the complexity of rules through configuration with an industry specification that is supported by many Open Source products today including BPM products such as Camunda, Activiti, Flowable, jBPM along with rules engines like Drools.
What is business logic?
In one of my previous blogs, I gave an overview of business logic. Let’s recap some of those key points to provide some context.
What is business logic? At its simplest form, it’s logic that contains decisions that govern a business process. These decisions are business decisions. The logic tends to be variable with the market and may change often depending on that particular industry’s drivers. The logic focuses on the why and the when. Ultimately, a condition has to be true before an action can be taken.
Business logic typically leverages business calculations. Unlike business logic, business calculations tend to stay the same. They focus on the what and the how. It’s important to decouple these two from a deployment aspect as they change at different rates. As a general rule, any reusable logic should be independently deployable. If reusable logic is tied to an application deployment, it can’t be individually reused and is coupled to other components. Ideally, we want to break apart the reusable pieces of an application into microservices so they are independently reusable and deployable. See Martin Fowler’s illustration under “Figure 1: Monoliths and Microservices” as an example.
How do we connect the different steps of business logic together? Workflows. They are the structured flow or sequencing of work tasks in a business process. Workflows can either be human-based, system-based (e.g. orchestration) or a hybrid between the two. Similar to DMN, there is Business Process Modeling Notation (BPMN), which provides an industry standard notation for modeling business processes.
History of Decision Model and Notation
Now that we have a good understanding of business logic, let’s dive deeper into DMN. As mentioned earlier, BPMN (v1 released in 2004) is the standard notation for Business Process / Workflow modeling which is used for managing the overall steps of a business process. What was lacking in BPMN was an internal structure often observed in decision making. The founders of DMN intended to create another perspective that creates the connection between business process models and decision logic models (see spec).
What is DMN and how does it work?
There are several different ways to use DMN, such as a Decision Requirements Diagram (DRD) and Decision tables. Let’s go into those in deeper detail in the following examples.
Decision Requirements Diagram (DRD)
Below is a DMN example (which can also be found in my 2022 Open Source BPM Comparison blog), that shows a BPMN Business Rule task (i.e. Decode routing) using a DMN Decision Requirements Diagram (DRD). The DRD is a graphical representation of the decisions to be made in a business domain, along with their dependencies on each other and input data. This example also shows a decision table for the Eligibility rules, which is a structured way of providing IF THEN logic. The DRD can be used on its own for analysis purposes or can be used for executing a decision service.
DMN example from https://www.omg.org/spec/DMN/1.4/Beta1/PDF
Decision tables
Decision tables are a second way to use DMN, also known as boxed expressions for clearly expressing business rules. Similar to BPMN, DMN is stored as XML data behind the scenes. With decision tables, there are columns for inputs, expressions/functions, and outputs. In the below example from the DMN spec document, the blue columns are inputs and expressions while the red column Eligibility is the output.
From DMN spec https://www.omg.org/spec/DMN/1.5/Beta1/PDF
Each row in the above table corresponds to a single rule and if the inputs (blue) columns are met then the corresponding output (red) column is returned. Note there is not a constraint on the number of input or output columns. Multiple input columns by default are connected by an AND, unless a cell is empty such as noted in the example above with the “ — “ which will exclude that column from being evaluated. To have multiple OR values within a single input column, just separate the values by a comma and there is not a limit on the number of values (e.g. < 18, 19, 20) You can also add an additional column and use the range notation (e.g. [ 18..20] ).
Hit policy
The very first column labeled P in the example above is the hit policy, which describes how the rules are executed. P stands for the Priority hit policy which means these rules will execute in the order listed. In our Eligibility Rules example above, the rules execute in order they are listed from top to bottom—if a customer is unemployed, not in the UK or under the age of 18, they will be ineligible; otherwise they are eligible.
Other types of hit policies include:
- Unique (U): Exactly one rule applies. This is the hit policy by default unless one is specified.
- First (F): Only the first matching row is returned. In regards to order, it starts at the beginning of the table and works downward, thus order is significant. Note this may not be a good hit policy for very large decision tables from a performance perspective.
- Any (A): Multiple rows can match, but have all have to provide the same output
- Collect (C): Returns the output of all matching rows
- Collect with aggregation (C+): Provides a sum of all of the matching rows
- Rule order (R): Provides output in the same order as the input rows
- Output order (O): Provides output in the order of priority
FEEL—Friendly Enough Expression Language
FEEL is an expression language used for conditions in decision tables or in components of a DRD in DMN. It is similar to a Domain Specific Language (DSL) and was created to be usable by business personas but also accurate enough that it can be executed by engines. Before decision tables are executed, they are converted to FEEL in the background. FEEL can also be leveraged outside of decision tables as part of a literal expression in DMN tasks. For example, using our previous Eligibility Rules decision table example from before, the corresponding FEEL syntax would be:
if EligibilityRules.EmploymentStatus = "UNEMPLOYED" then Eligibility = "INELIGIBLE"
if EligibilityRules.Country not("UK") then Eligibility = "INELIGIBLE"
if EligibilityRules.Age<18 then Eligibility = "INELIGIBLE" else "ELIGIBLE"
FEEL supports various data types including text, numbers, boolean, timestamp, and duration. It also leverages common comparison operators and basic math operators to perform calculations.
The benefits of DMN
Now that you have a good handle on what DMN is and how it works, what is the so what? How can it make a difference in the solution and maintainability in your projects? Here are some of the main benefits of DMN:
- Enables better communication between business and IT roles. Decision tables make the input, expressions and outputs easy to understand while DRDs provide a visual decision tree framework that makes it easier to understand complex flows.
- Simplifies the design of business rules when implementing in application code is overly complex. Complexity can be handled in a simpler way via visual modeling (DRDs) and decision tables, enabling creation of reusable components
- Solves for the lack of a decision making structure in BPMN. Provides decision tables and DRD structures along with FEEL expression language
- Provides a standard notation for decision tables, which are a common style of business rules in a BRMS. Drools is an example of a BRMS that supports DMN and decision tables.
- DMN models are portable between DMN compliant products. This enables decision logic to be migrated from one product to another. Additionally, it enables business analysts to create DMN in one product and then engineers to implement the execution of it in another.
DMN integration with BPMN and CMMN
In addition to DMN and BPMN, there is also CMMN—Case Management Model and Notation. It tends to focus on ad-hoc processes that often are found in case management involving investigation and research type activities. Below is a view (also referenced in my previous Open Source BPM Comparison blog) that summarizes the three different industry standard notations. Typically open source BPM products will support some combinations of these—either all three or BPMN and DMN.
Summary of three different industry standard notations from https://www.omg.org/intro/TripleCrown.pdf
BPMN integrates nicely with DMN by providing a Business Rule Task (see BPMN spec). A number of open source BPM products enable the Business Rule Task to support DMN.
Example Business Rule Task in BPMN (https://www.omg.org/spec/BPMN/2.0/PDF)
DMN was also designed to work with CMMN (Case Management Model and Notation) and provides a mechanism for modeling decision-making that is associated with cases. It provides a Decision Task for DMN which is basically the equivalent of the Business Rule Task in BPMN. Not all open source BPM products support the CMMN spec, as some have opted to support just BPMN and DMN as it is easier to achieve case related flows in BPMN.
When to use DMN
Now that we have a good understanding of the benefits of DMN, the next key question is when should you use it vs. other solutions. The answer is it depends on the use case. I’m going to reuse some of the key points from my previous blog and add some additional insights. In addition to DMN Decision Tables and Decision Requirement Diagrams (DRDs), there are at least two additional alternatives for implementing business logic outside of DMN: Application code or a Rules engine (a.k.a. Business Rules Management System—BRMS).
Application code
Application is a good fit when the logic doesn’t change much and is fairly straightforward.
Rules engine
A rules engine is a good fit for logic that changes often and is highly complex, involving numerous levels of logic. Rules engines are typically part of a Business Rules Management System (BRMS) that provide extensive capabilities to manage the complexity.
Examples rule engine flow
DMN Decision Tables and Decision Requirement Diagrams
As we discussed earlier, DMN Decision Tables make it clear and easy to understand decision logic. They also can be easier to maintain when there are more frequent changes in the logic. Decision Requirement Diagrams provide a visual flow of the decision logic, enabling a very complex decision process to be followed as part of an overall decision tree.
Overall guidance of using DMN vs. other solutions
Decision complexity and rate of change are two key characteristics of use cases that can be used to drive towards a particular solution. Plotting the four solutions above across these two dimensions would look like this:
Business logic guidance graph
What this tells us is as the decision complexity and rate of change in decisions increases, application code is no longer suitable for business logic. Decision tables provide some relief as the rate of change and complexity increases, but reach a point where visual modeling is needed. Decision Requirement Diagrams handle complexity well but reach a point where they are not optimal when the rate of change in decisions is high. Ultimately, a Business Rules Management System (BRMS) provides the best fit for high rate of change and high complexity.
DMN relevance with machine learning/AI
Gen AI is revolutionizing the industry right now. It will be interesting to see what new capabilities will be incorporated into DMN modelers. Could we see some self service capabilities leveraging LLMs in a co-pilot type fashion? That seems to be the trend right now across the industry, where Gen AI is assisting engineers in being more efficient in existing tooling. In regards to determining when to use rules vs. machine learning, I touched on this in a previous blog. Here is a quick recap:
| Rules | ML | |
| Logic | Exact logic is known. With rules you know ahead of time the logic you want to execute. | Exact logic is not known. Rather the inputs/features that are significant in creating a prediction may be known. |
| Logic Type | Precision based. If then business logic is precise and does not involve any predictions. It results in boolean type outcomes based on evaluation of facts. | Prediction based using algorithms. |
| Logic Creation | Done by a human. Software engineers or business users create the rules that represent business logic. | Created by machine learning software the runs algorithms via training. |
| Data | Don't need to automatically derive the logic from the data. Analysis typically occurs on data beforehand to determine what the exact logic should be. | Is used to ultimately generate the model logic. Ideally want to use as much data as possible and also make sure the data is unbiased. If the data is biased, then the model will become biased. |
In summary, leverage rules when you need precision and know the logic. Leverage machine learning when you want to predict something but don’t know exactly how.
Decision Model and Notation as a business logic solution
DMN is a powerful industry notation that is backed by a number of open source products. It provides a way to simplify decision logic by providing frameworks to handle additional complexity through tables, visualization and expression languages. As with any technology, it's important to make sure it's the right solution for your problem. I hope you found this article helpful!
Learn more about tech at Capital One
New to tech at Capital One?
- Learn how we’re building and running serverless applications at a massive scale.
- Learn how we’re delivering value to millions of customers with proprietary AI solutions.
- Explore tech careers at Capital One and join a world-class team of engineers working to change banking for good.
