Decision Model and Notation, or DMN, is a novel way to model business decisions. DMN allows the capture and modeling of business decisions in a way that is easy to understand for business people and subject matter experts. It is a combination of the following:
- Decision Requirement Diagram – DRD
- Decision Table
- Boxed Expressions
- Friendly Enough Expression Language (FEEL)
Decision Requirement Diagram (DRD)
This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge sources.
In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.
In the table below, all of the elements on a DRD model are illustrated:
Element | Notation | Description |
---|---|---|
Decision | ![]() | The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models. |
BusinessKnowledge Model | ![]() | A function encapsulating business knowledge in the form of business rules, decision table or analytic model. Some of the tools may not support this element. In such cases the decision logic is directly linked to the Decision rather than the business knowledge model. |
KnowledgeSource | ![]() | The authority for a business knowledge model or decision. |
Input Data | ![]() | Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model. |
Information Requirement | ![]() | Information – input data or decision output – required for a decision. |
Knowledge Requirement | ![]() | The invocation of a business knowledge model. |
Authority Requirement | ![]() | Showing the knowledge source of an element or the dependency of a knowledge source on input data. |
Decision Table
In Decision Model and Notation, the Decision Table is a tabular form that models rules based on conditions and actions which are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them alongside decision table.
Learn more – How to use Decision Table in modeling business rules.
Boxed Expressions
Decision Model and Notation (DMN) is a simple two column table and an effective way to model business formulas, calculations, values and expressions. Then you can share these across multiple decisions and logic.
Boxed expressions simply allows modeling: constant, values, invocation, formulas, etc. Boxed expressions allows you to put together building blocks of logic (i.e. decision table, natural language, flow, etc.) and enables you to reuse these over and over again.
Friendly Enough Expression Language
In Decision Model and Notation, FEEL is an expression language for business people. FEEL defines a syntax for expressing conditions, actions and formulae. FEEL is like using Excel formulas in that it allows you formulate your thinking about a domain in a context. FEEL is designed for ease of use by business people and subject matter experts.
Advantages
There are benefits to using Decision Model and Notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the logical implementation of the actual rules. But the DMN approach provides a higher-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and potentially losing the context and oversight of the solution.
This change of approach:
- Allows scaling of business rules in a more manageable, reusable visual approach across applications and processes.
- Allows better communication between the business, domain experts and IT by enabling a more productive involvement of business people and subject matter experts.
- Allows clearly defined decision boundaries and exposes the decision as a service with a click!
If your tool supports simulation and execution, error checking at design time and runtime with debugging capability, then you will not overlook anything by using a business rules approach, but you will also have a better way to reuse and scale your business rules in a systematic way.
Read More
- Natural Language Business Rules Modeling in DMN
- Assessing Borrowing Capacity Using Decision Automation
- Why Automate Insurance Pricing Model?
- Insurance Premium Calculation
- Import DMN models – XML 1.1
- Boxed Expressions – DMN
- Decision Model and Notation – DMN
- Reusable DRD or Sub DRD in Decision Model and Notation (DMN)
- Decision model and Notation – Policy Example
- Reuse Business Decision as a Function
Last updated September 22nd, 2020 at 11:29 am, Published June 11th, 2016 at 11:29 am
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.
Leave A Comment
You must be logged in to post a comment.