BPM+ Virtual Coffee
5 min Intro to DMN

A short introduction to the Decision Model and Notation (DMN)

Presented by

Denis Gagne, CEO & CTO at Trisotech

Good day everybody and welcome to our BPM plus virtual coffee, I’m Denis Gagne, CEO & CTO of Trisotech, and today’s topic of the BPM+ virtual coffee session is a five-minute intro to DMN.

DMN

Let me jump right into the topic, DMN stands for the Decision Model and Notation, and DMN is a specification published by the Object Management Group (OMG). You can find the actual specification freely and openly available at this URL. DMN is a visual notation, and it basically offers you a simple visualization of business decisions with both the requirements for the decision, and the decision logic for the decision. In DMN the decision requirements are depicted in what we call the Decision Requirement Diagram (DRD) which is a visual way of organizing the dependencies between the decision, sub-decisions, and the various data that you’re using in your decision. We also depict the actual decision logic using what’s called box expressions and we have a whole set of different box expressions we can use in depicting and capturing the logic.

DMN is really meant to complement BPMN and CMMN. Basically, you can think of BPMN processes consuming DMN decisions or CMMN cases consuming DMN decisions which in turn the DMN decisions are consuming data. There is a complementary relationship between the three standards that I’ve been referring to for years now as the Triple Crown of process modeling.

DMN is as easy as one, two, three. The way of working with DMN is quite simple. The first thing you do is come up with the question the Decision will be answering and the possible answers to that question. That’s the core of your root decision. So, let’s say I want to find out who should be responsible for paying the cost of this particular car damage. The question would then be “who should be responsible” and the possible answers would be let’s say “the driver”, a “third party”, Etc. Once I have that, I have my scope of the decision. Then from there I can decompose this decision into its decision requirements — what information or what sub decision — do I need to make that decision, and finally, specify the decision logic of all these nodes. More concretely a DMN model will look something like what you have in the slide where I have a “Decision 1” that is dependent on a “Decision 2”, which is itself dependent on “Input 1” and “Input 2” , and “Decision 1” is not only dependent on “Decision 2” but also another “Input 3” . In the DRD the square shapes are the decisions, the oval shapes are the data inputs, or the input information, and the arrows are showing “requirements”. In this diagram, there is an “Information requirement” link and here we have a “Knowledge Requirement” link. We also have a “Business Knowledge Model” which is basically reusable decision logic that we’re bringing into the decision. Generally speaking, your logic will be expressed using “Box Expressions”. The “Decision Table” that is shown here is a particular case, or a particular style, of box expression that allows you to capture your decision logic.

FEEL

What is FEEL?

FEEL stands for Friendly Enough Expression Language, and this is the expression language that is used within DMN or specified as part of the DMN standard. What is very interesting about FEEL is that it is a standardized expression language. We hear a lot a lot about low code and no code these days, but all these approaches are relying on proprietary expression languages, but we do have a standard for these, and it’s called FEEL. FEEL provides you with a standard syntax and execution semantic, and the claim is that it’s simple enough for non-technical people but expressive enough for technical people.

What are some of the characteristic of FEEL?

FEEL is a functional expression language, it is stateless, it is side effectless, and it is context sensitive. A lot of very fancy words to say some very simple things: functional means that we compute the value — the resulting value — from the inputs provided. Which means that the variables are immutable, once we have the data we’re done. Side effect less means that we have a closed world assumption. There is no other effect possible than providing you with a result. Context sensitive means that we can use terms that are using spaces in them. That is quite interesting and important because it allows us to create or write expression that are closer to natural language in how we express the logic.

Box Expressions

Now let me give you a little bit more details about what box expressions are. It is a basic visual recursive construct of a name and an expression. Here we have a literal box expression, so we have the name and its expression.

We can then build up a structure where I have a name and its expression and then a name, but its particular expression is built up by two names with each their own expression. So, it is a recursive pattern of for defining the logic. We have different types of box expressions that I invite you to get acquainted with.

To see the full expressiveness of the FEEL language let me show you a very simple example. Here is a natural language policy that says: “The loan monthly installment is obtained by adding the loan monthly fee and the loan monthly repayment. A standard loan carries a 20$ monthly fee, while a special loan carries a 25$ monthly fee, and the loan monthly repayment is calculated based on the loan rate, term, and amount, using the standard Financial monthly payment function.” This simple policy or guidelines or whatever you may want to call it, express the logic and we can then use this actual language to create this box expression for it. Here my loan monthly installment is provided by the loan monthly fee plus the loan monthly repayment, and the loan monthly fee is defined with a conditional that if it is a standard loan, it is twenty dollars, else if it is a special loan, it is 25 dollars, otherwise it is zero. The loan monthly repayment is basically an invocation of a financial payment function with the rate, terms, and amount provided. You can see how, and I’ve put it in comments here, the natural language statement from the policy aligns. We just directly read it and it makes it very simple for anybody to understand. This portion here at the top is because I’ve created as a reusable function. This is a now a function that is defined and that I can reuse. The loan monthly installment function has these four parameters and it’s giving me this result. You can see how with FEEL and boxed expressions it is very easy to capture the logic of your decision in a language that is close to natural language.

In a nutshell

DMN in a nutshell is all about decisions, which are expressed using rules. These rules apply data in context, which gives us knowledge. It is a functional type of language, and it is based on a first order logic.

So that is my five-minute introduction to DMN. Here are a couple of books you may be interested in and that we recommend: the DMN Method and Style and the DMN Cookbook. There are also different trainings that are available.

Thank you for your attention.

View the slides

Videos

Recorded webinars

View all videos
Attend a live webinar

Learn how it works

Request Demo

Confirm your budget

Request Pricing

Discuss your project

Request Meeting
Graph