Next stop, [DMN/TDM] Interchange

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:

  • Rows-as-rules
  • 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.

Feature DMN TDM
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
Output Single value
  • Decision Table must have a ‘single-hit’ policy
Single value
  • Requires a ‘regular’ Fact Type as the conclusion
  • Each row must produce the same value
Multiple values
  • Decision Table must have a ‘multi-hit’ policy.
  • Aggregator is built into the table – default is ‘collect’, collating the outputs as they are produced. Other aggregators include ‘max’, ‘sum’.
Multiple values
  • Requires a ‘list’ Fact Type as the conclusion
  • Each row may result in a different value
  • List is unsorted
  • Aggregating the list output requires another RFV


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:

Side-by-side comparison of the rule articulated using a single-hit DMN Decision Table and a TDM Rule Family View. Note that the colour choice is arbitrary

Side-by-side comparison of the rule articulated using a single-hit DMN Decision Table and a TDM Rule Family View. Note that the colour choice is arbitrary

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:

Side-by-side comparison of the two graphical notations, showing the various options available in DMN

Side-by-side comparison of the two graphical notations, showing the various options available in DMN

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:

Side-by-side comparison of the rule articulated using a multi-hit DMN Decision Table and a TDM RFV that utilises a List Fact Type

Side-by-side comparison of the rule articulated using a multi-hit DMN Decision Table and a TDM RFV that utilises a List Fact Type

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:

TDM RFV that is an ‘unconditional computation’

TDM RFV that is an ‘unconditional computation’

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….


Why so [controversial], son?

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.

But there.


Further reading

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:


2 thoughts on “Next stop, [DMN/TDM] Interchange

  1. Hi Nick,

    1. Your post on DMN/TDM interchange was really inspiring. It helped me a great deal. (I came to decision modeling through TDM, but I’m now asked to get acquainted with DMN 1.0).

    It also inspired me to do a comparison between DMN and SBVR. Of course, this is a completely different subject: DMN and SBVR are much farther apart than DMN and TDM. But I still used the same example (excellent in its simplicity) that you started your post with: see:

    I remodelled the example a little, in order to get what (to my mind) seems a more realistic use of persistent data. But (as you point out) this tends to also depend on the analysis phase you are in. I am not as experienced in decision modelling as yourself. So, if you have any comments, I would be very interested.

    2. Your section “Why so controversial, son?” If the parallel is too far-fetched, then sorry, but this really reminded me of some bloody fights over BPMN that I had with colleagues working on a process engine. At first I could not see the advantage of having BPMN Sub-Processes as opposed to BPMN Call Activities. That is, I just could not understand why anybody would want to model a subroutine as part of some embedding higher-level process, without leaving the possibility open to call that same subroutine from some different higher-level process later.

    My colleagues (sort of) brought me round to their point of view… Obviously, building an implementation becomes much easier when you know beforehand that you don’t have to cater for potential later re-use in a different context. But it still feels like a practical vs. a more fundamental concern. What they are dealing with, very practically, is the problem of BPMN diagrams becoming too unwieldy too soon. A very real problem, I know, so, fair enough. My point is semantic: if you can THINK OF a subroutine as being modular, then why not make it re-usable?

    Is there any parallel between this stuff and your TDM issue with Interim Fact Types?

  2. Hi Rob, sorry it’s taken so long to response to your comments.

    First off, thank you for your thoughts and I’m delighted that my post triggered your own analysis; thanks also for crediting me in your post, it’s really appreciated 🙂

    In terms of your main question regarding reuse: what you’ve mentioned there in terms of your BPMN discussions is not quite the same thing I was getting at in this post, but you can certainly draw parallels.

    TDM Supporting Rule Families can be reused across different decisions; just because a fact type is interim, doesn’t mean that it can’t also be interim in another decision. I’ve reused Supporting RFVs in a number of different projects; so to that end it is more like a call activity than it is an embedded sub-process. My main challenge has always been around exposing the use of that interim fact type as a persistent piece of data, which is not possible unless that RFV becomes a decision in its own right. So the point I was driving at was the equivalency between diagrams – I don’t see a Supporting Rule Family View as the equivalent of a decision – I see it as the equivalent of a business knowledge model.

    To draw further parallels with your colleagues view, it depends how much you know about the domain in which you’re modelling (be that process or decision) at the time you start modelling. So there are some obvious things that are key outputs and so you’d identify decisions to support the production of those outputs. The less obvious things are those piece of logic that start to crop up in lots of places; at a certain point it’s going to be easier to define it once then reuse it. In that instance you would probably create a decision and then use the output as a persistent fact type everywhere else. Then you’re only ever making the changes in one place. But if you start out with everything as its own decision, then it would certainly make things unwieldy very fast. Personally, I always see it as easier to split things than consolidate them; it’s harder to spot consistency in disparate threads.

    I hope that answers your question; when I get more time, I’ll take a detailed look through your post.

    Thanks again for commenting!


Leave a Reply

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

You are commenting using your 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