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.
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.
- 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.
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:
The business rule tasks (small table marker in top-left corner of the activity) denote that decisions are required at those points.
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:
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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:
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:
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.
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 🙂