Blog Posts Decision / Rules Management DMN

DMN: What Every TDM User Needs to Know

Blog: Lux Magi - Decision Management for Finance

Decision modeling is dominated by two standards: The Decision Model (TDM), defined by Sapiens Inc, established in 2009 and documented superbly in The Decision Model book by Larry Goldberg and Barbara von Halle and The Decision Model and Notation (DMN) an open standard first defined by the Object Management Group (OMG) in 2013.

While James Taylor and I were collaborating on our Decision Modelling book, and discussing our experiences of using DMN after using TDM, we wondered:

We think the answer to both is yes. How easy is it to migrate from TDM to DMN? We believe it’s less easy than it might first appear and we explain why here. What has your experience been? What advice would you give to TDM modelers adopting DMN?

Key Similarities and Differences Between TDM and DMN

TDM and DMN are both decision modeling notations that have been adopted by companies to improve the integrity, transparency and agility of their important business decisions. They facilitate the management of business decisions as a vital business asset. Their relationship is summarized visually in the diagram below.

Comparison of TDM and DMN Features

The two have a great deal of overlap which makes adopting DMN easier for someone with TDM experience. For example both:

They also clearly have different strengths:

Where they overlap TDM and DMN are very similar and have broadly similar aims. It’s apparent that TDM has directly influenced DMN and the two have common notational roots. Although DMN does not address method or best practice, it is clear that much of TDM’s wisdom can be applied using DMN.

Using TDM Principles in DMN

TDM defines a set of 15 principles for decision modeling many of which can be applied using DMN.

Structural Principles

TDM’s structural principles (1-7), which concern the representation of tabular logic, are mostly preserved by DMN. Principle 1 (‘tabular’) and principle 4 (‘row’) establish a means of using Decision Tables to express logic that are compatible with DMN. Principle 7 (‘connection’) establishes dependency relationships between logic definitions so that the outcomes of one decision can be used in the conditions of its dependents—this is directly applicable in DMN. However, some of the other principles have minor differences:

Declarative Principles

DMN does not explicitly address TDM’s declarative principles (8-10). Principle 8 (‘declarative heading’), principle 9 (‘declarative body’) and principle 10 (‘declarative inferential relationship’) forbid the order of condition columns, rules and decision dependencies (respectively) to impact the meaning and behavior of Decision Tables. Principles 8 and 10 are not contravened by DMN’s definition of Decision Tables. Principle 9 is upheld by the DMN Decision Table definition when using the Unique, Any or Collect hit policies; rule order is significant for other hit policies.

Integrity Principles

DMN does not explicitly address TDM’s integrity principles (11-15) except principle 15 (‘business alignment’) which is directly supported by object and process metadata in decisions (supportedObjective, usingTasks and usingProcesses). The following TDM integrity principles should become best practices when using DMN:

TDM integrity principle 13 (‘rule family transitive’) states that two direct sub-decisions of a specified decision should have no dependencies between them, see the diagram below for an example. In our experience this restriction is often impractical and we would suggest that it be upheld as an ideal, not a best practice.

Pitfalls of Moving to DMN

The wealth of good practice that TDM’s principles convey, most of which are directly applicable to DMN, and the superficial similarity of their notations leads some to believe that adopting DMN after experiencing TDM is just a mechanistic change. However this is misleading.

When adopting DMN, experienced TDM practitioners should be wary of the following pitfalls:

Forgetting to use new DMN concepts

There is a tendency to omit Knowledge Sources and Business Knowledge Models when first creating decision models in DMN because these are entirely new concepts in DMN.

Knowledge Sources are most often neglected because they are not related to implementation effort. They document the origin of local expertise, policies or externally enforced constraints imposed by laws, regulations and mandates and are useful means of making models more traceable to requirements.

Business Knowledge Models allow parameterized logic expressed once to be reused in many contexts for difference purposes. This is an idiom which is new to many TDM users. Oddly, newcomers to DMN without TDM experience  tend to overuse Business Knowledge Models.

Creation of narrowly scoped decision models subordinate to a process

DMN and TDM have a different relationship with BPMN business process model as the diagram below shows. In TDM, the business process represents an overall context in which individual decision tasks can invoke specific decisions (by nominating their subject decision—the decision rule family), see the left hand diagram. Although an individual rule family can be reused in multiple decision model diagrams, each decision model diagram has a subordinate scope dictated by the business process model—that of the individual decision task invoking it (as reflected by the green boxes we have added to the diagram). As a result a TDM decision model is a collection of many small decision model diagrams depicting each decision task. A DMN decision model is not like this.

Differing Relations between BPMN and (Left) TDM, (right) DMN
Differing Relations between BPMN and (Left) TDM, (right) DMN

In DMN, although individual DRD views may depict an isolated decision invoked from a business process, the decision model encompasses an entire decision which can span many DRDs. A business process model and a business decision model represent two views with the same, end-to-end scope: delivery of an ultimate business outcome, as reflected by the boxes on the right of the diagram above. These views have different goals:

The whole end-to-end business scope is the same, but individual decision tasks in a process model can invoke decisions at any level in the DMN DRD hierarchy.

Failing to consider logic representations other than Decision Tables

Unlike TDM, DMN decision logic can be described using text, example rules, decision trees, analytic models or even left undefined. There is no imperative to define the logic of every decision and no requirement to define every decision using a Decision Table. Newcomers to DMN that have TDM experience sometimes feel compelled to define every decision with a Decision Table.

Excessive drill down

When building a TDM decision model it can be challenging to know when to stop ‘drilling down’ in the decision model diagram, to realise when a Decision Model Diagram represents a sufficient level of detail without requiring further decomposition. Typically the experienced modeler drills down enough to ensure that rule families are cohesive but not so much that they become trite.

In the equivalent DMN Decision Requirements Diagram, drill down is not driven exclusively by the need to define every decision as a Decision Table. Although DMN has no method, good practice typically dictates that drill down ceases when the sub-decisions that would result from any further drill down have no business question or requirement (i.e., Input Data, Knowledge Source or Business Knowledge Model) that would differentiate them from their dependents (i.e., their ‘parents’).

Decision models overwhelmed with Data Inputs

TDM depicts the data (as opposed to sub-decision) dependencies of rule families (decisions) by listing them on the bottom compartment of the rule family ‘tombstone’ symbol. This list consists of fact types (information items) which correspond to individual data attributes required to reach a decision. In DMN, decisions’ data dependencies are denoted as Input Data symbols (the rounded rectangles shown in the diagram above). Although these can represent individual data attributes, they more commonly represent data entities each of which have many attributes. Modelers with TDM experience tend to represent every individual data attribute with an Input Data symbol and this can  quickly overload real DRDs and compromise their clarity.


TDM has many best practices that can be reused in DMN with some minor adjustments, but modelers with TDM experience should consider these differences carefully before producing real-world decision models using DMN. Do not infer from the absence of a standard method for DMN that the TDM approach can be directly substituted.

Lux Magi’s TDM/DMN cross training courses can help those who need to master DMN quickly.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples