What’s the Difference between DMN and BRM?

The Decision Model and Notation (DMN) standard is becoming increasingly popular. And with it, there comes confusion. We experience some ambiguities, especially with regard to the question “What is the difference between DMN and BRM (Business Rules Management)?” In this blog post, we want to provide some answers to clarify this question.

Decision Management is definitely on the rise. This rather new discipline currently benefits from the momentum of the DMN standard. The result: decision modeling seems to become a discipline for itself. In our opinion, it really is – simply because decision modeling is the precondition for decision automation which in turn is the precondition for many digital business models, especially in the finance industry.

However, many companies have already invested in business rules management (BRM) technologies in the last years or even decades. Since BRM vendors seem to reposition themselves in the decision management and DMN space, their customers feel a little bit insecure. They understandably want to know, whether their BRM investments are safe. We want to shed some light on the dark.

DMN and BRM – Standard vs. Discipline

First, DMN simply is a standard specification. It defines a vendor-independent, systematic approach for documenting and implementing decisions and business rules. Its goals are:

• Eliminating shortcomings of the BPMN (Business Process Model and Notation) standard when it comes to decision logic
• Increasing the transparency of business decision making
• Improving future security and investment protection through standardization

BRM on the other hand is the basic discipline that addresses the issue of defining, automating and managing rules-based decisions in a highly efficient, flexible and autonomous way. Its goals are:

• Increasing efficiency through automation of rules-based decisions
• Improving business agility
• Improving business-IT alignment & strengthening business autonomy
• Optimizing the efficiency and flexibility of IT architectures

BRM thus has evolved through digital business needs, and DMN now provides a standard for some parts of BRM. DMN does not address typical issues relating to the management of business rules, such as best practices on an IT architecture level, on business-IT collaboration or on deployment or governance topics. It is simply a standard – but a useful one.

DMN Adds a New Level to BRM

When we look at classic BRM approaches, they typically start directly with defining the decision logic through business rules. The previous step, the requirement documentation, is usually not in the scope of BRM. This is where DMN comes in. The standard adds a new level to BRM. This is one of the most important benefits of the standard. It helps you get the overall decision model right first (with all interdependencies and relationships), before starting with decision logic definition.

This holistic decision requirements level is particularly important in the financial industry, where business decision making often has two parallel dimensions: The business dimension and the regulatory dimension. For example, look at an investment advisory process: A bank definitely wants to provide a good investment advice to its clients. “Good” in this context means: Reducing risks while increasing profitability for both the bank and the client. To a large extend, this is a business question based on a lot of investment business knowledge. Besides this, there is also lots of regulatory knowledge that has to be taken into account in the advisory process: Has the bank properly informed the client about potential risks? Has the bank taken into account the client’s individual risk profile? All of these regulatory compliance questions are decisions. DMN now allows companies to combine business decisions and compliance decisions in one holistic, transparent decision model by implementing the Decision Requirements Diagram (DRD) concept.

BRM is One Implementation Option of DMN

DMN starts with the Decision Requirements Diagram, i.e. with a well thought-through, optimized, holistic decision model. The implementation of the decision logic happens just after that. This is where BRM usually comes into play (but does not have to). The big difference between DMN and BRM is, though, that DMN does not dictate to use “classic” business rules. Instead, it allows various options to implement decisions. This is where it gets interesting, because not all decisions (or sub-decisions) will be made based on business rules. In modern digital business, some parts of the decision making will be based on artificial intelligence (predictive), while other parts will remain rules-based (predefined). DMN provides an option to define decision logic and to implement business rules. However, it lets you continue to use your existing business rules and even any other, non-BRM technology (such as machine learning) that is used to make a decision.

In the figure above, you can see a DMN Decision Requirements Diagram in the middle (although the DRD is not really in the middle, but on another layer). The figure shows a decision model that combines (aggregates, orchestrates) various sub-decisions with each sub-decision using a different approach for decision-making:

• A DMN Decision Table which implements business rules based on the DMN standard
• A proprietary flow rule which implements business rules from an existing BRM project
• A machine learning model which implements predictive decision logic

As you can see, DMN augments BRM – it does not replace it.

DMN vs. Flow Rules

DMN introduces a lot of useful ideas and approaches. However, DMN is not able to realize a flow-oriented business rules approach. What does that mean? Decision making often follows a process-like flow with a clearly-defined start point. These use cases require a clear order which part of the decision-making is executed step by step. In DMN, a decision will not be made until all sub-decisions have been made – but the order of the individual sub-decisions will be kind of random. Decision automation scenarios that require something like a process-flow will probably be better off with a non-DMN BRM approach that allows to define and execute flow rules.

Decision Engine vs. Rules Engine

With the growing visibility of DMN, many people are talking about Decision Engines instead of Rules Engines. What is that all about? Well, the DMN standard introduces an expression language for defining decision logic. It is called FEEL (Friendly Enough Expression Language) and aims at better enabling business users to define and understand decision logic.

Companies need an execution engine that is able to interprete decision logic defined with FEEL to automate decisions based on DMN and FEEL. In our understanding, such an execution engine is called ‘Decision Engine’ (and at ACTICO this is the case). In contrast to that, a ‘Rule Engine’ typically is a proprietary execution engine that allows the execution of vendor-specific business rules logic.

However, do not rely on the wording. In the market you can see execution engines that fully support FEEL and still are called ‘Rule Engine’ by its vendor, but you can also find the word ‘Decision Engine’ on execution engines that do not support DMN or FEEL.

Modeling Standards and DMN Conformance Levels

A huge advantage of DMN is, though, that it allows companies to introduce a standardized approach across the organization. This makes sense, because especially in large organizations, you might find various BRM technologies and different approaches to document and automate decisions and rules.

When looking at DMN, we can witness the same phenomenon that we already know from the business process management (BPM) era. There were (and still are) many proprietary BPM approaches and technologies. The Object Management Group (OMG) then introduced the BPMN (Business Process Model and Notation) standard. Some companies adopted the BPMN standard, some stayed with proprietary (vendor-specific) approaches – simply because the latter met their needs better. With DMN, it is (and probably will remain) the same. Simply put, DMN is for BRM (and Decision Management) what BPMN is for business process management.

When researching on the DMN standard, you will come across the ‘DMN Conformance Levels’ at some point. What is it all about? The DMN specification defines three conformance levels. These conformance levels demonstrate the compliance of a software product with the DMN standard specifications. All conformance levels have in common that they support the definition of DMN decision requirements, decision logic and decision tables. However, they differ when it comes to the automated execution of DMN decision models, and the interchangeability of these models with DMN software from another vendor.

• Conformance Level 1 means, the DMN decision models cannot be interpreted. This means, a DMN project would be restricted to decision modeling.
• Conformance Level 2 means, that a DMN implementation can interpret S-FEEL (Simple Enough Expression Language), a subset of FEEL.
• Conformance Level 3 means, that a DMN implementation can interpret FEEL (and S-FEEL). This is the highest (full) conformance level.

So, when evaluating DMN software, the goal to be achieved should be clear: Is it just documenting decisions? Then a simple modeling tool with conformance level 1 support is sufficient. If you want to fully benefit from the standard with vendor independency and decision automation, you should think about a DMN software with full standard compliance (Conformance Level 3).

DMN vs. BPMN – Decisions vs. Processes

As mentioned earlier, DMN is for decision management what BPMN is for business process management. Since the DMN standard is being published by the Object Management Group (just like the BPMN standard), it is no surprise that these standards are complementary. If you have adopted the BPMN standard, DMN can be a useful extension to reduce complexity and optimize your BPMN models, especially on a requirements documentation level.

Modeling decisions directly in BPMN models can become very intransparent and complex. It makes sense to outsource decision models (and logic) into DMN models, which are then connected to your BPMN models. However, this is at first a question of requirements engineering. Technically, decisions will be provided and executed as decision (web) services.

Why this is important to separate process models from decision models?

• Process models focus on orchestration (process logic) while decisions focus on intelligence and complex business logic. Processes ensure that process steps are streamlined and executed efficiently; decisions ensure that business value is created, i.e through decision models that are optimized for high profitability and low risk.
• Processes are usually stable over months or years while decision logic changes more frequently (due to market changes, new policies, new regulations, etc.). By decoupling decisions from processes, you can realize independent change cycles. Decision management technology is a key solution to manage short change cycles.
• Various processes, systems and channels often reuse decisions. In many cases, there is not even business process management in use. The solution is to centralize the management and deployment of decisions to ensure consistency, reduce maintenance efforts and increase business agility (if you are interested, read our white paper on the topic).

The Difference between DMN and BRM – Key Take Aways

There is a fundamental difference between DMN and BRM, and there are as well  interdependencies and overlaps with other approaches and disciplines. To summarize the key take aways:

• What are the primary benefits of DMN over BRM?
  DMN is a vendor-independent, open standard, and it improves transparency by introducing a new layer on top of BRM.
• Do you need to adopt DMN?
  If you want to become vendor-independent and drive standardization across your organization, maybe yes. However, you also have to take a look at your use case: Does DMN meet the business and technical needs? Software vendors still provide many proprietary approaches to use their technology, and there is a reason why companies still adopt these approaches.
• Will the importance of BRM diminish?
  No. Decision-making will continue to require prescriptive elements (predefined business rules such as regulatory requirements, internal policies, risk models, customer communication preferences etc. However, other elements of decision-making will probably be implemented using predictive technologies (artificial intelligence and machine learning), e.g. fraud detection or customer next best actions.
• How is DMN software different from BRM software?
  Again, DMN is just a standard. The real value comes through decision automation. The automation and management of decisions still requires a decision engine and other components that support you across the decision management life cycle. This might be a business rules management system or a decision management suite with DMN support.

We hope this article helped clarify questions on the difference between DMN and BRM. If you have any questions, please do not hesitate to contact us.