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.