Going DMN-tal

As of September 2013, the Object Management Group (OMG) approved the submission of the Decision Model and Notation (DMN) specification. V1.0 was published in September 2015, with V1.1 due out later in 2016.

For those that have read some of my previous blogs, or know anything about my particular skillset, you may know that I’ve done a lot in the way of decision modelling, specifically “The Decision Model (TDM)”  from Sapiens over the last few years. I’ve done huge amounts of real-world modelling, using simple tools like Excel and Visio, through to full-on implementation of executable decision models in a Tier 1 Investment Bank.

I’m a big fan of TDM, but equally, things move on, so I attempted to learn DMN from the spec (and applying those things I know from TDM), starting with the alpha spec, published in January 2014. Books are starting to come out in 2016, which will blow this whole thing wide open.

I’m not claiming to understand it all, but what I’m hoping this post will do is give people a glimpse into this standard by using a worked example.

Please note that this post has been published as a more formal PDF: The Decision Model and Notation (DMN) standard – a worked example.


What’s this post about?

It’s designed to give a taster for DMN, what it looks like, how it fits in with BPMN. It’s based on what I’ve learned from the spec (it’s a tough read, but the specs are not designed for ‘business’ use – they’re more aimed at technology vendors).

Most of the detail about DMN is contained in the annotations for each diagram that I’ve included – click on the diagram to expand it to full size.

What’s this post NOT about?

  • It’s not a comparison of TDM to DMN – DMN is a standard and primarily a notation; TDM is both a notation and a method. So DMN will prescribe a format for decision tables, but TDM has principles that underpin how tables (or Rule Family Views in TDM-speak) should be constructed, normalised etc. There has also been a whole raft of other work in decision modelling over the last few decades and it would be doing a disservice to that work that’s got us where we are today to only consider TDM. TDM is also a subset of DMN – DMN supports modelling of human decision making in addition to requirements for automated decision making. I have done another article on how one might interchange between TDM and DMN.
  • It’s not an in-depth review of the full scope of DMN – DMN’s got a lot of moving parts – predominantly this blog looks at the graphical notation and the modelling of decisions using decision tables, but, there’s more to the scope that just decision tables.
  • It’s not an introduction to Decision Modelling – so it’s not looking at the whys and wherefores of decision modelling. There are far more knowledgeable folk out there to provide that kind of background, plus, if you can stomach it, there is the LinkedIn group for DMN that has all of the discussion about the standard as it was developed. I did a slideshare presentation on how decision modelling fits in with other aspects of understanding your business, but that was based around TDM. That said, all of what’s in there (and more) applies to DMN. There’s also the brief post I did on the fit of process modelling with decision modelling.

Please note that this post represents the application of my own learning from the spec; I am not involved with the DMN committee, nor has the following work been exhaustively reviewed by any of the DMN submitters. 

The process model has been defined using the ITP Commerce BPMN add-in for Visio. The Visio stencil for the DMN diagram and the Excel template for the Decision Logic notation was created by me.


Worked example context

I picked something relatively straightforward – a credit card application. It’s not dissimilar to the concepts used in part of the worked example in the Section 10 of the alpha spec.

All I’ve done is crib a bit of information from the public website of one of the UK’s top reputable banks (I’m joking, of course, there are none). So I’ve included some of the information on there, plus some I’ve had to make up specifically around credit scoring because it’s something of a black art. I’ve drafted a BPMN 2.0 Process Model to provide the context (it’s a stub – the process in practice would only be considered successfully complete when a card was issued).

Process brief: an Applicant submits an Application for a credit card, which is received by a member of the Credit Card Processing Team. The information is recorded and basic information about the Applicant assessed to determine whether it is worth requesting their Credit File from an external Credit Reference Agency. If it is, then the Credit File is requested and the Applicant is assessed based on specific criteria for the card for which they’ve applied.

The process ends successfully when the eligibility for the card has been determined and the Applicant informed of the result:

BPMN process model for Assess Credit Card Application

BPMN process model showing the receipt and assessment of a credit card application, with two key decisions

The business rule tasks (small table marker in top-left corner of the activity) denote that decisions are required at those points.


The Decision Model and Notation – Decision Requirements

OK. Let’s take the red pill.

From an analysis perspective, DMN’s got two main bits: Requirements and Logic. The decisions required in a given ‘domain’ are represented in a Decision Requirements Graph (DRG). That could get quite big. So the DRG itself can be made up of one or more Decision Requirements Diagrams (DRDs).

As mentioned above, the process in the real world would probably continue until the card is actually issued. There are also other elements associated with the credit card once it is issued: statements; interest charges; defaults; closure etc. All of the decisions across those processes would represent the entire domain and thus a DRG.

However, right now, as a Business Analyst, I’m interested in defining the requirements for Credit Card eligibility and thus want to define the DRD for that process scope. I know my two key decision points from my initial process analysis: ‘Applicant Demographic Suitability’ and ‘Applicant Credit Card Eligibility’. So I’m going to start there and define my decision requirements. In a nutshell, I’ll look at the key bits of information that need to be evaluated by talking to my stakeholders and establish how they might be packaged up to make those decisions more manageable.

What I’ll eventually end up with is a DRD something like this:


Shows the DRD for decisions required in assessing a credit card application

Lovely. Practically, the diagram has been developed iteratively along with the logic and the process, but I’m not going to show every incarnation of it.

What does that diagram tell me? It shows that the two main Decisions require other Decisions as their inputs, along with other Input Data. It also tells me that the logic for those decisions are contained in the Business Knowledge Models that they invoke. Those Business Knowledge Models may be governed/owned by Knowledge Sources.

That’s already starting to sound a bit techy, so let’s try and simplify it: The Decision gives me what I need to know, but it has to ask a Business Knowledge Model to work it out (usually, but see Expressing decision logic without invoking a Business Knowledge Model) . Put another way, I see the Business Knowledge Model as the script writer for the Decision speaker. The speaker tells people what they need to know (hopefully) but he’s called upon his script writer to evaluate the necessary information (Input Data) and present it in a format where that output can be communicated as required to his audience.

As a point to note, if you refer back to the process model, you’ll see that the Data Items associated with the User and Service tasks match the Input Data in the DRD.


The Decision Model and Notation – Decision Logic

We then get into the detail of the logic that sits behind the Decisions. DMN has created a standard for Decision Tables; a Decision Table is a Business Knowledge Model, but not all Business Knowledge Models are Decision Tables. What that means is I could use a TDM Rule Family View as a Business Knowledge Model. I could also use an analytics model or a natural language expression.

DMN has also created a standard language for expressing Decision Logic called ‘FEEL’ (Friendly Enough Expression Language), although that depends on who you are as to whether it’s friendly enough for you 🙂 I’ve tried to express as much of the following examples as possible using FEEL but it can be hard going using the spec alone. I’m not going to go into huge amounts of detail on FEEL.


Applicant Demographic Suitability

Decision Model and Notation (DMN) Decision Requirements Diagram (DRD) for Applicant Demographic Suitability

A portion of the DRD showing the first decision in the process

Taking the first decision, the partial view above shows that it depends on two other decisions, two lots of input data and a number of business knowledge models. From a process point of view, the idea behind having this as a decision that doesn’t just form an overall input to the eligibility assessment is because there are basic criteria that need to be met for a given credit card product before stamping all over a credit report.

DMN First Hit Single-Hit Decision Table for Applicant Demographic Suitability

The Decision expression and the Business Knowledge Model invoked by it

Example: applicant is 19, applying for a Student card but is not an existing customer. Row 2 would be triggered, giving an ‘Unsuitable’ outcome.

The picture above shows both the Decision itself and the Decision Table invoked by it. If you click on the image, you can see the information explaining what each section contains. But, in summary, the Decision Logic is encapsulated in ‘Boxed Expressions’. I’ll be honest, I’m not a fan of the term – for some reason ‘Boxed’ makes it sound very ‘IT’, but that’s what it’s called. As far as I can see, it’s because everything’s in a box.

Anyhow, the type of Boxed Expression for the Decision is a ‘Boxed Invocation’ – it’s the speaker asking his script writer to make some magic happen. It passes the required input data into the Business Knowledge Model.

Decision Model and Notation (DMN) Boxed Context Business Knowledge Models

The two other Business Knowledge Models invoked by the Decision, providing input data into the Decision Table

The Decision Table takes two of its inputs from two other Business Knowledge Models. Rather than Decision Tables, these use ‘Boxed Contexts’. These are good for calculations. This example highlights that a company will most likely derive the Applicant’s Years of Age – applications typically ask for a date of birth instead of years of age.

These models return the required input data to the Decision Table from the previous figure.

I mentioned ‘FEEL’ – I gave it a crack in the second of the Boxed Contexts above, but wasn’t going to even attempt it for the first one, so have just expressed it as a natural language calculation.

Decision Model and Notation (DMN) Unique and Any Single-Hit Decision Tables for Applicant Demographic Suitability

The two Decision Tables required for the logic assessing Student and Private Credit Card Demographic Suitability

Example: an Applicant applies for a Private Credit Card, they are an existing customer and they have mortgage borrowings of £350,000 and a sole annual income of £200,000. Both rows 1 and 2 will be triggered, where both outputs are ‘Suitable’.

Another couple of Decision Tables for the two Decisions that are ‘required’ by the main ‘Applicant Credit Card Demographic Suitability’ decision (I’ve left off the Boxed Invocations for the decision itself). The first table allows ‘A’ny row in the table to be ‘hit’, which makes it almost identical to a TDM Rule Family View.


Applicant Credit Card Eligibility

Decision Model and Notation (DMN) Decision Requirements Diagram (DRD) for Applicant Credit Card Eligibility

Partial view of the DRD showing the Applicant Credit Card Eligibility decision and its requirements

The second decision now uses the Credit File obtained from the external Credit Reference Agency. This information is used in the Applicant Credit Score Table Business Knowledge Model, which is dictated by the Credit Policy of the Lender (shown as a Knowledge Source).

Decision Model and Notation (DMN) Unique Single-Hit Decision Table for Applicant Credit Card Eligibility

The Decision and its invoked Decision Table to determine the eligibility of the Applicant for the Applied Card

Example: Applicant is applying for a Balance Transfer card and they have a credit score of 570 resulting in an outcome of ‘Ineligible’.

This decision uses a more limited set of input data than you might expect. That’s because some of the criteria were established in the first decision and the wheat separated from the chaff. On that basis, the process would never have got to this point without it the Applicant being a fit for the target demographic. So that input data is not required by this decision.

Decision Model and Notation (DMN) Any Single-Hit Decision Table for Applicant Credit Card Eligibility

The Decision Logic for the Applicant Balance Transfer Credit Card Eligibility decision.

Example: Applicant has a sole income of £15,000, hasn’t applied for the card at any time in the last 6 months, has 5 years of address history and lives in France. Row 3 would be triggered with an outcome of ‘Ineligible’.

As with the Applicant Years of Age, application forms usually get applicants to list their address history, so this requires another expression to return the information. I decided not to document the associated calculations.

Decision Model and Notation (DMN) No-Order Multi-Hit Decision Table for Applicant Credit Score

Credit Scoring Multi-Hit Decision Table that aggregates the outputs together as a sum

Example: Applicant has defaulted once in the last 12 months, has not declared bankruptcy, has 4 years with their bank and has used 67% of their available credit. This triggers rows 1, 6, 9 and 12, giving individual scores of 100, 250, 250 and 150. This is aggregated to give an overall score of 750.

I FEEL I should mention FEEL again. The input and output values in a DMN Decision Table are specified by FEEL and I have attempted to include that here. Ranges of values are of particular interest and FEEL accommodates all combinations of start and end points being included/excluded in the expression.

Expressing decision logic without invoking a Business Knowledge Model

The spec states on page 26 that, “In most cases, the logic of a decision is encapsulated into business knowledge models, and the value expression associated with the decision specifies how the business knowledge models are invoked, and how the results of their invocations are combined to compute the output of the decision. The decision’s value expression may also specify how the output is determined from its input entirely within itself, without invoking a business knowledge model: in that case, no business knowledge model is associated with the decision”.

What that means is that it is possible, should you wish to do so, to include a Decision Table within the Decision itself, rather than in a separate model. Why would you want to do that? Reusability, primarily. Expressing logic in a separate Business Knowledge Model allows that logic to be reused in multiple Decisions, potentially with different Input Data. So I could have two Decisions use the same Business Knowledge Model, but it might be evaluating the same logical information using different physical data sources.

So, an alternative way of expressing the Applicant Credit Score Decision would be as follows:

Decision Model and Notation (DMN) alternative view of Decision showing Decision Table as part of the expression

Alternative expression of the Decision, showing the Decision Table as part of the Decision. Note that there is no longer a reference to the table underneath the Decision name.


Business glossary, and data modelling

I haven’t touched on business terms and glossaries in this post. These are still a critical aspect of expressing decisions effectively. In fairness, I’ve adopted a lot of the practices from TDM in naming the Input Expressions (Fact Types in TDM-speak). DMN doesn’t mandate a glossary and I suspect this is because the other OMG spec ‘Semantics of Business Vocabulary and Business Rules’ (SBVR) takes care of it.

In order to come up with the good names for the Input and Output expressions, I did produce a portion of a Concept/Fact model:


The concepts were defined to help guide the naming of the input and output expressions

There would be a few arguments about the name of this type of model but, fundamentally, it helped me in defining the in scope concepts and their relationships between them in order to properly qualify the terms used.


Closing notes

As mentioned at the start, my intention in this post was to provide a view of DMN, not critique it. However, I can’t resist a couple of thoughts:

  • Decision domain view – providing a graphical decision-oriented view of the domain has a huge benefit. Whilst a lot of decisions are executed as part of a process, understanding the full context in which a decision is made is impossible without reference to that process. By providing a DRG and associated DRDs, there is now a dedicated view of decisions that will speak more appropriately to a specific demographic of stakeholders.
  • Decision table flexibility – I like the flexibility of the tables, particularly in terms of the different hit policies for Single-Hit tables and the Aggregator for Multi-Hit tables.
  • Increased complexity
    • Decision tables – whilst the flexibility of the Decision Tables is a plus, it’s also a drawback, particularly to business usability, because the way in which a table is read is now down to people spotting the one-character indicator in the top-left of the table. They’ve also got to know which of the hit types the indicator belongs to, although the aggregator at the bottom of the table should help that. I suspect tool vendors will make their own decisions as to how many types of decision table will be supported. In this post, I’ve only covered Decision Tables that are ‘rules as rows’; it is also possible to have ‘rules as columns’ as well as ‘Cross-tab’.
    • Terminology – ‘invocation’; ‘boxed ‘ will provide a cultural barrier to adoption, like it or not. The terminology is just too techy. TDM excels in its simplicity coupled with its richness of expression, but will always be hamstrung by being proprietary for tooling.
  • Method and style – as described, I learned a lot of the above from the spec, but a big part of doing the decomposition of the decisions was based on what I know from using TDM. The principles that I mentioned right at the start are a key part to actually applying a notation, in the same way that using BPMN is vastly improved by applying any number of approaches available today. You can have a list of ingredients, but the ability to put them together and create actual food is based on approach and experience. The take-up of DMN and its usability with stakeholders will be highly dependent on the ability to apply it well. For example, you’ll see that most of the decision tables I’ve created have about 3 input expressions. However, I could have created monster tables in terms of rows and columns, but this would have left us with inflexible and unmanageable rulesets.

The likelihood is, people will really start getting interested when this standard hits 2.0 – if I think about how BPMN developed between versions 1 and 2, then there will be a lot more work done. One thing is certain: Decision Modelling is a thing – get involved.


Footnote: I do this research and investigation because I enjoy learning new stuff, plain and simple. It’s also because it’s part of my ethos in constantly improving the work that I do in practice. If you find it useful and it helps you in your endeavours, that’s great. All I ask is that, if you make use of any of the information, give credit where it’s due 🙂

10 thoughts on “Going DMN-tal

  1. Nice work Nick,

    some comments:

    * The first decision table: Applicant Demographic Suitability Table
    You call this a Priority table, but you seem to mean a first hit (F) table, where the sequence of the rules determines the priority in decreasing order.Note that first hit tables are hard to validate and sequence dependent. If you exchange rows 1 and 5, the meaning is different.
    A priority table is different. It returns the output with the highest output priority (from the list Suitable, Unsuitable).

    – small detail in this table: I would suggest not to merge the TRUE cells of rows 3 and 4

    * The decision table called: Applicant Student Credit Card Demographic Suitability Table
    This is not an ‘Any’ table because the rules that hit do not return the same conclusion. What you probably mean is a first hit table, or you want “-” to mean: “any type but Student”.
    As you can imagine, I am not a big fan of First hit tables. It is considered poor decision table practice (hard to validate, sequence dependent and therefore error-prone).

    • Thanks for reading it and commenting so quickly, Jan! I’ve made updates – it was my misunderstanding on the Priority one so I have indeed updated it to a First hit policy, although I appreciate (and agree) with your comments around the use of First hit tables.

      With the second, it was sloppy on my part. Rather than making it a First hit, I’ve changed it to ‘Unique’ and updated the expression to Not “Student”.



  2. Pingback: Another DMN Decision Model (executable!) | OpenRules Blog

  3. Applicant Years of Age: years and months duration(Today’s Date, Applicant Date of Birth).years

    You can model Today’s Date as Input Data.

  4. Hi, Nick! First of all, thank you for your work in providing an example. This may help readers understand the spec better. I think the spec is not an easy read for a target audience of business people or business analysts.

    I agree with what you say, specifically:
    1. Business Knowledge Model and Boxed Expressions sound techy
    2. TDM Rule Family can be a BKM
    3, I, too, wonder if FEEL is friendly-enough (and I wonder if we really need it, wait and see).

    I also like a DRD that has only the decision boxes (not the other items) because it is useful as a high-level conceptual starting point – we have done something like that on some projects.

    In all, though, the DRD can get become very “cluttered” very quickly, I fear, if it is to show all DRD elements, even for small TDMs translated into DRDs. I think a subset of DRD for a bigger picture is helpful and then to put the detailed logic connections in a separate diagram (like TDM), but i am biased, of course :-).

    I think you are incorrect that aggregate for multi-hit tables requires more process tasks, i believe we have addressed this using only TDM (list fact type into a RF that aggregates list members). However, aggregates might be nice here.

    I do wonder about the emergence of DMN models in which there are various types of BKMs. Will it be possible to validate them (since BKMs are different style) and to generate test cases for them? Time will tell.

    2014 will be interesting. Thank you for your research into DMN so far.

    • Thanks for your feedback, Barb,

      Yes, I agree that if you were to convert a TDM graphical model to a DRD then you’d have at least twice the number of elements, technically adding no greater expression. But, as I mentioned, that’s always been one of TDM’s great strengths.

      I haven’t seen any evidence of the aggregation, though. Although one would argue that the population of values in a list fact type is the same as a ‘No Order’ multi-hit table with the default ‘Collect’ aggregation, I know from practice that I’ve never been able to do counts or maximums on a list, at least as far as Sapiens’ DECISION goes. Any functions of that nature have always required a Service Task and that was my main motivation for highlighting the benefit in DMN decision tables.

      The various types of BKM also make me think that DMN would accommodate the use of lookup tables, another element that relies on reference to a process model when using TDM at the moment.

      As you say, 2014 will be interesting. I think decision modelling as a concept will start to spread far more rapidly and it will start to garner far greater attention with business analysts.

      However, I do think that will present the biggest challenge to TDM: in response to this post, it’s already generated two executable models through the guys at OpenRules and Liquid Sequence. I’d speculate that’s only been possible through the open nature of the standard. That said, TDM is operating at a large-scale enterprise level and is probably the most mature method in the market at the moment, so two fairly simplistic models does not represent a huge turn in the tide.

      However, its continued adoption, at least at a practitioner level, will be hampered by the lack of availability in current information. What I mean by that is that TDM has advanced significantly since the book but the visibility of that change is non-existent, at least to any formal extent. And I think that’s a real shame. The QWERTY keyboard was never supposed to be the best; Betamax was better than VHS. The best product doesn’t always garner (or maintain) the greatest market share.



  5. Pingback: June-2018 Challenge “Credit Card Application” |

  6. Pingback: Old Decision Model “Credit Card Application” Implemented with New OpenRules-7 | OpenRules Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s