Following on from the post I did working through a modelling example using the new OMG Decision Model and Notation (DMN) standard, I decided to round things out by providing my view on how you would interchange between that notation and its Decision Tables to Sapiens’ The Decision Model (TDM) (previously referenced in my posts as KPI, but they are now part of Sapiens), and its Rule Family Views (RFVs).
Article complexity: 4 out of 5
What’s this? Just some notional rating to help you folks work out how much knowledge I’m going to assume you have about decision modelling. I’m not going to introduce any of the basics; reason being that, in providing a succinct overview of interchange, I’m going to need to throw around some of the terminology with reckless abandon. There’s plenty of stuff around that will provide that introduction and I’ve put some references at the bottom of the page.
Fundamentally, I believe the interchange between the two notations, at least from a Business Analyst’s viewpoint, to be fairly trivial. That’s good news, both for those using DMN that may want to convert their models to TDM and vice-versa.
To all intents and purposes, a RFV in TDM can be seen as a type of Decision Table; I’d go one further and say that RFVs are already types of Decision Table supported within DMN (some will no doubt disagree).
TDM RFV vs DMN Decision Table
In comparing a TDM RFV with a DMN Decision Table, I need to put some constraints on DMN, mainly because there are a number of variants and, for the sake of the simplest interchange, I only need to look at a subset. So the table below looks at DMN Decision Tables that have:
- A single-hit policy of ‘Any’
- A multi-hit policy of ‘No Order’
What I’m shooting for in doing this comparison is the simplest form of interchange. So what might be handled one way in TDM could be handled entirely differently in DMN given the range of options, but that’s not my focus. My focus is on quick translation from one to the other.
|Columns||Uses Input expressions (conditions) and Output expressions (conclusion)||Uses Fact Types|
|Table cell||Operator and operand in a single cell||Split cell, one containing the operator (for example, “is”) and the other containing the operand (for example, “eligible”)|
|Condition values||‘Unimportant’ conditions (that is, the value of that condition doesn’t matter for the rule) shown with dashes (-) in the cell||‘Unimportant’ conditions are shown as blank cells|
|Evaluation order||Any order, top-to-bottom, left-to-right (within the constraints noted above for the purposes of comparison)||Any order, top-to-bottom, left-to-right|
A simple comparison
By way of a trivial example, I’m going to take the rule, “A student can enrol for a course if the maximum number of students has not yet been exceeded and they are not already taking more than 4 courses”. I’m going to assume that if any of those things are not true, then they can’t enrol. So, pretty simple stuff; let’s see how the two compare:
At first glance, there may appear to be a fair few differences, but on closer examination, the main structural differences are down to the split cell versus single cell convention for the operator and operand.
They both have three rows; they both have the same number of conditions and they both test exactly the same values and arrive at exactly the same conclusions, as you might expect. So let’s look at the difference in graphical notation:
So there looks to be a few more differences here, but that’s mainly because DMN supports a number of different options. I touch on both options 1A and 1B in the post I referenced at the beginning, but I’ll explain in brief each notation shown above:
To keep the comparison between the two as close as possible, I’ve decided to model the Input Data at its most granular level, that is, at the level of the Input Expression shown in the Decision Table. If you’re at an early stage in your project, you’re more likely to model this at a conceptual level.
- Option 1A – Decision with separate Input Data – Decision Table as part of the Decision: the Decision Table shown in Figure 1 is part of the Decision itself, so it is not represented separately in the graphical model (referred to as the Decision Requirements Diagram (DRD)). Input data is modelled as separate elements required by the Decision.
- Option 1B – Decision with separate Input Data – Decision Table as invoked Business Knowledge Model: the Decision Table is a separate Business Knowledge Model; a Knowledge Requirement of the Decision.
- Option 2A – Decision with Listed Input Data – Decision Table as part of the Decision: as Option 1A, but the Input Data is listed in the Decision element.
- Option 2B – Decision with Listed Input Data – Decision Table as invoked Business Knowledge Model: as Option 1B, but the Input Data is listed in the Decision element.
One option for display: persistent Fact Types (same as the Input Data in DMN) are shown below the dashed line in the RFV element. As this RFV is linked directly to the Decision element, this RFV is referred to as the Decision Rule Family View; any RFVs inferentially linked to this one are referred to as Supporting Rule Family Views.
Graphical notation comparison observations
The only real difference is that DMN uses a wider palette to describe its elements. That can be an advantage or disadvantage depending on your context. In TDM, some people can consider the dashed/solid line as an indication to distinguish interim from persistent to lack clarity. Conversely, having more symbols to learn in DMN takes getting used to and is more to learn, but the palette is hardly unwieldy. DMN also allows you to include things like Knowledge Sources, so your diagram can make it clear what the source of a particular piece of information or business knowledge is.
Now, what has always proved to be a controversial observation on my part is that I consider Option 2B to be DMN’s closest comparison to the TDM view. However, that’s been shouted down so often, that I’m not going to labour the point – everyone else has said that 2A is where it’s at – the decomposition of logic into other decisions is seen to be the same as decomposing a Decision RFV into Supporting RFVs; I’ve provided my view at the bottom of the article.
Multi-hit Decision Tables and List Fact Types
Back at the start, I made a comparison between DMN and TDM key features; the example of the student course enrolment dealt with the single value output, but what of multiple value outputs?
This time, I’ve picked the rather contentious topic of benefits entitlement. Benefits are clearly quite a complicated topic, so the example below is drastically simplified and utterly fictional. But the idea is to give you a view on how multiple items are collated into an output. It’s not as straightforward to write the rule in natural language, so instead I’ll use an example set of input data:
If the applicant has 3 dependents, has earned £4,000 in the current tax year, is employed part-time and is not seeking work, then they are entitled to both ‘Employment and Support Allowance’, and ‘Income Support’.
That would look as follows:
As a disclaimer, I’ve not validated that all possible rules have been articulated in the tables above. There is a completeness indicator that exists for DMN tables that identify whether that is the case, but it is expected that it will be down to chosen tooling to do that completeness determination.
As with the first comparison, there’s little to separate the two other than the typographic conventions. I’ve not repeated those differences that are already shown in the first example.
For the DMN table, there are two key things different from the first example:
- Hit-policy – every Decision Table has a hit-policy but those policies apply to a single type of table. So (N)o Order is one of the hit-policies for the multi-hit table, meaning that multiple outputs are returned, but in no particular order. Other hit-policies, such as (R)ule Order produce the outputs in the order that the rules were executed.
- Aggregator – the aggregator can be shown at the bottom of the table, but this example has left it off because it uses the default ‘Collect’. The aggregator does what it says on the tin – it tells you how the output of the list is to be aggregated. There are 5 other aggregators: sum; min; max; mean; count.
For the TDM RFV, there are also two key differences:
- Conclusion column header – the Fact Type is a list, rather than a ‘regular’ Fact Type and this is denoted next to the Fact Type name.
- Conclusion cell operator – this changes to ‘is appended with’ to denote that the Fact Type has the conclusion value added to its output
I’m actually not going to do the notation comparison, because it’s almost identical to the first one with one exception: the TDM Conclusion Fact Type is as an ‘L’ put in front of it.
A further look at aggregation
By default, the output of a TDM RFV using a List Fact Type is also a collection. It is possible to perform the kind of aggregation that the DMN table does, but it requires an additional RFV to do it. If for some reason I wanted to count the number of benefits instead of just collect them, then I could change the aggregation indicator on the DMN table to ‘Count’ instead.
To do the same in TDM, I’d need to have a RFV that sat above the current one, where the output was a function that counted the contents of the list.
Simplistically that would mean this kind of thing:
You can see that ‘Benefits Applicant Entitled Benefits’ is underlined, meaning it is a Supporting RFV, which is the one shown in Figure 3. The list would be produced, collecting the benefits and then its output would act as an Interim Fact Type for the RFV in Figure 4, in which the count is performed.
So, there are nuances between the two, but not huge differences (within the constraints that I’ve applied). To re-emphasise, I’ve gone for the most like-for-like comparison I can make and I’ve picked scenarios that make the switch very simple.
The range of Decision Tables (and other types of expression that can be used to model decisions) in DMN means that there is far more to thoroughly understanding the notation than what I’ve tried to illustrate here. Equally, the principles of TDM and learning how to model ‘properly’ are hugely important to readability, scalability, and maintenance of decision models.
But in learning the differences between the two, hopefully this post illustrates that there are easy ways to start understanding how to get from one to the other; the rest is up to you….
As I say, I have a view on what makes a decision a decision in terms of the two notations, but there are far more experienced practitioners in the field that have unanimously disagreed with me. So I reckon I must be being thick somewhere along the line, so what follows is purely my opinion based on the practical experience of having to break down TDM decisions into separate decisions in the event that an Interim Fact Type is actually required as an output – please refer to discussions in both the DMN and TDM LinkedIn groups to see where I’ve raised this and the corresponding counter-arguments.
In TDM a decision reaches a single conclusion, which is represented by the decision octagon; that conclusion is provided through the Decision RFV attached to the decision. Supporting RFVs provide a method for decomposing logic for that decision into more manageable pieces and those pieces are reusable in other decisions. However, the conclusions of each of those Supporting RFVs are called ‘Interim’ Fact Types, meaning they don’t persist as outputs from the decision.
Whilst DMN does not mandate that the output of each decision in a DRD be made available for use by a process engine, they certainly can be. In TDM, the only way the output of a Supporting RFV can be accessed is by making that RFV a decision in its own right, which would give it its own decision octagon.
My observation is that the decision octagon in TDM is the equivalent of a decision within DMN; the Decision Class Diagram shown in Figure 17 of the spec shows that a decision is a decision is a decision. There’s no hierarchy of decision types and this is evidenced by the fact that the Decision element is associated to an AuthorityRequirement, which in turn is associated back to a Decision with a ‘requiredDecision’ role. So there is no parent decision and sub-decision (or supporting decision), just decisions requiring other decisions. In other words, all decisions are created equal.
Converting a Supporting RFV to a DMN Decision, to my mind, changes the potential emphasis of the model. One of the purposes of the RFV is reusability, which is also the point of a Business Knowledge Model in DMN. So I’ve always looked at it as Supporting RFVs being linked Business Knowledge Models, with the initial Decision Table referenced by the Decision in the DRD.
I said I’d throw some terminology around, so if you want some basics on decision modelling, you can either refer to some of my other posts (I’m a big fan of “I, Process, take thee, decision”; it’s short and introduces the key concepts of why process modelling and decision modelling go hand-in-hand) or any of the following:
- The history of modelling decisions using tables – first part in a three-part series by Professor Jan Vanthienen from the University of Leuven.
- List of publications on Decision Tables, Tabular Decision Models, and Business Rules, again by Professor Jan Vanthienen.
- 3 reasons why decision modelling with DMN makes for better Business Analysis – slideshare presentation from James Taylor providing a great introduction for Business Analysts and why modelling decisions is important.
- Understanding business data using The Decision Model – a slideshare presentation by Nick Broom (yes, that’s me that is) on Sapiens’ ‘The Decision Model’, showing the different concepts used in the model and its application in practical scenarios.
- The MicroGuide to Process and Decision Modelling in BPMN/DMN – new book from James Taylor and Tom Debevoise, which is the first to incorporate concepts from both standards. Link is to amazon.com.
- DMN LinkedIn forum – many of the early discussions were held on this forum and it is a great resource for getting in touch with the DMN submitters, and learning more about the standard.
- TDM LinkedIn forum – a well established forum discussing The Decision Model.