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:

How does TDM experience inform good practice in DMN?
Can TDM experience encourage inappropriate modeling practices in DMN?

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.

DMN vs TDM — 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:

Provide notations for representing business decision requirements as a hierarchical dependency (TDM’s Decision Model Diagram and DMN’s Decision Requirements Diagram, DRD): showing graphically how decisions rely on sub-decisions and how they can be dissected into ever smaller components of decision-making.
Support a logic definition notation in which decision logic can be represented in a tabular form (TDM’s Rule Family and DMN’s Decision Table).
Define an integration between decision models and business processes represented in BPMN.

They also clearly have different strengths:

DMN is just a standard notation, whereas TDM defines a framework for decision modeling: a notation, a method and a set of rigorous principles.
DMN’s notation is richer than TDM’s and it introduces some new concepts to decision requirements documentation:
- Knowledge Sources allow modelers to explicitly connect decisions to the local expertise and external laws/regulations that authorize or constrain their definition—this is vital for traceability;
- Input Data components support the documentation of the information sources that decisions need and
- Business Knowledge Models support the parameterized reuse of decision logic, which is difficult to achieve in TDM.
DMN has a more flexible notation for representing Decision Tables which supports many features (e.g., hit policies, default values and aggregation) and table layouts (e.g., ‘rules as columns’, ‘crosstab’) unseen in TDM (see here for more details).
Unlike TDM, DMN is underpinned by a rigorously defined expression language—FEEL. This provides a more formal basis for expressions in Decision Tables and a precise textual medium for defining logic in other ways.
Whereas TDM focuses on Decision Tables, DMN can additionally represent logic definitions using analytics, text, boxed expressions and other representations outside the standard.
DMN is an open standard ratified by the Object Management Group (OMG) whereas TDM is owned by Sapiens Inc.

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:

Principle 2 (‘heading’) dictates the contents and form of a Decision Table header. It is not fully supported because DMN allows Decision Table condition headings to be expressions, not just Information Items (Fact Types) as in TDM.
Principle 3 (‘cells’) determines the content of condition cells in TDM Decision Tables (Input Entries in DMN). This is not completely upheld as DMN allows only equalities and inequalities with literals or variables in its condition cells (what the DMN grammar calls Unary Tests)–not operators and operand expressions as TDM does. For example the condition ‘< Persons Salary *4.0’ is legal in TDM but not in DMN.
Principle 5 (‘conclusion’) allows TDM Decision Tables to have only one conclusion. This constraint is relaxed in DMN although there are many good reasons for upholding TDM’s restriction and using this freedom sparingly.
TDM’s first normal form (part of principle 5 that demands that no row in a Decision Table should be capable of being refactored into more than one row) should still be upheld in DMN as a best practice, albeit one that can be relaxed in rare circumstances. The strict application of this principle forbids implicit ORs in conditions but these can be useful, for example: a condition on currency like:
- ‘USD, EUR, GBP’ (DMN)
- ‘is in {USD, EUR, GBP}’ (TDM).
Principle 6 (‘condition’) sets restrictions on the relationship between rule patterns and conclusions. It is not upheld as DMN does not explicitly support rule patterns.
TDM’s second normal form (part of principle 6 that ensures all conditions are relevant to the conclusion) is not explicitly enforced but is a best practice for modelers using DMN.

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:

Principle 11 (‘rule pattern transitive conditions’) which includes third normal form (ensuring that no condition depends on, or is derivative of, any other);
Principle 12 (‘rule family consistency’) demands that there are no overlaps in the logic of a rule family (best practice for Decision Tables using the Unique hit policy) and that at least one conclusion value must result for any set of valid input values (i.e., completeness—there must be no gaps in the logic of a rule family)
Principle 14 (‘inferential integrity’) which enforces the following restrictions on any sub-decision that provides a conclusion that is used as a condition in a dependent decision: that the values of the conclusion are consistent with the conditions imposed and the range of possible values the conclusion can hold are all handled by the dependent decision.
Illustration of TDM principle 13

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

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 decision model shows the information and knowledge dependencies of decisions, the hierarchy of their structure and definition of declarative logic, whereas
The process model shows the sequence of activity, marshaling of data required, any hiatus demanded by the process, the choreography of the entities involved and the automation boundary.

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.

Conclusion

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.