Decision Modeling notations 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.

Over the past eight years, Decision Modeling has been 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 and documented in books by James Taylor and Jan Purchase and Bruce Silver. Both standards are in use and continue to evolve.

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? What can newcomers to Decision Modelling and DMN learn from the earlier standard?

In short, a great deal.

We believe that new, and even experienced, Decision Modeling practitioners can benefit significantly from background knowledge of TDM. This article explains why and what these benefits are.

Key Similarities and Differences Between TDM and DMN

About Versions

As both TDM and DMN are evovling, it’s important to be clear about which versions we are talking about.

After TDM was originally documented in The Decision Model, between 2009 and 2012, a number of white paper extensions were produced. It is this public version of TDM that is the focus of this article. TDM has continued to evolve as part of the Sapiens’ DECISION tool but this extended approach is not yet a matter of public record and we don’t discuss the innovations made, or being made to this version of TDM. Regarding DMN, we are specifically referring to version 1.1 of the standard.

How They Compare

Their relationship between the public version of TDM and DMN is summarized visually in the diagram below.

As the figure shows, the DMN notation is broadly a superset of that provided by TDM. Because DMN is just a notation not an approach, it lacks TDM’s method and best practices. There is no doubt that many of these methodological elements are of huge benefit to decision modelers. Although DMN does not define a methodology for decision modeling, as the position of the text in the figure shows, it does offer some support for the structural, declarative and integrity principles of TDM. 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.
• Show the data on which decisions depend.
• 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.
• Distinguish between a diagram and the underlying decision repository. Every diagram depicts a view or subset of a model.

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.

They also clearly have different strengths:

• Whereas TDM defines a framework for decision modeling: a notation, a method and a set of rigorous principles, DMN only provides a standard notation.
• DMN’s notation is more extensive 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—these authorities are vital for traceability;
  • Business Knowledge Models support the parameterized reuse of decision logic, which is difficult to achieve in the public version of TDM.
• TDM has the concept of a ‘View’ of a Decision Model or Rule Family. TDM uses views to show an alternative, context-specific definitions of the logic hierarchy (e.g., flavours of the decision logic to address jurisdictional, product or customer oriented specifics). This is useful for compactly representing a set of logical variations of a single decision. DMN lacks this facility.
• TDM has the concept of ‘Community’ that DMN lacks. In TDM this represents a federated and hierarchical subset of a decision repository aligned to a specific purpose or audience. This is used to support larger team collaboration in decision modeling. DMN has the concept of multiple views (Decision Requirements Diagrams) of a underlying network of decisions (The Decison Requirement Graph) but this is much less well developed.
• TDM has the concept of an underlying glossary which is not addressed by DMN. In TDM provision of a glossary is essential for all decision models. DMN’s scope does not include this vital concept.
• Whereas TDM focuses on Decision Tables, DMN can additionally represent logic definitions using analytics, text, boxed expressions and other representations outside the standard.
• 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).
• TDM Decision Tables have conditions that test collection inputs directly. Although DMN supports collections, its Decision Tables cannot used them as direct inputs (e.g., it has no equivalent of the TDM operator ‘contains any’).
• DMN has a graphically richer version of the Decision Service construct supported by TDM. Whereas TDM defines all details of the interface using a Decision View, DMN allows the full interface of the Decision Service, including public and private sections, to be shown graphically.
• 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.
• DMN does not support the TDM notion of rule pattern (a key denoting a unique pattern of inputs used in the condition of each row in a Decision Table).
• DMN is an open standard ratified by the Object Management Group (OMG) whereas TDM is owned by Sapiens Inc.

Many of these differences stem from the fact that DMN is only a notation and does not address method or best practice as TDM does. It is clear, however, 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. The declarative and integrity principles represent an approach to modeling which exceeds the scope of a notation definition like DMN but can still be very useful when applying DMN.

Structural Principles

TDM’s structural principles (1-7), which concern the representation of tabular logic, are mostly preserved by DMN (except for principle 5, see below). 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 allows one or more messages to be specified as auxiliary outputs of a Rule Family, but these are for debugging, explanation, conclusion metadata and traceability purposes and are not meant as additional conclusions.
• TDM’s first normal form is part of principle 5 that demands that no row in a Decision Table should be capable of being refactored into more than one row. One can break it by using the First hit policy to implement ‘else’ and ‘otherwise’ rules. This principle should be upheld in DMN by avoiding these practices except when clarity of expression demands it. 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’) requires that all the conditions in a rule need to be satisfied in order to yield the accompanying outcome and stipulates how rule patterns are used. DMN supports the former, but does not have rule patterns.
• TDM’s second normal form, part of principle 6 that ensures that all stipulated conditions in each row are relevant to the conclusion, should be a best practice when using DMN but not officially required. Conditions in a DMN Decision Table that are redundant and have no role in determine the conclusion should be removed.

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’) respectively forbid the order of condition columns and rules in Rule Families (Decision Tables), and decision dependencies in Decision Views (DRDs),  to impact the meaning and behavior of Decision Tables. Principles 8 and 10 are neither explicitly mentioned nor contradicted by DMN’s definition of Decision Requirements or Decision Tables. Both should be considered a best practice: neither column, rule or dependency ordering should have any impact on the meaning of a model, all else being equal. Principle 9 is upheld by the DMN Decision Table definition when using the Unique, Any, Priority, Output 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’) ensures that no condition in a Rule Family depends on any other. It includes the third normal form which forbids the appearance of conditions that can clearly be derived from others. The derivation of these derived conclusions should be addressed explicitly in another Decision Table;
• Principle 12 (‘rule family consistency’) demands that there are no overlaps in the logic of the rules in a Rule Family. This is the best practice for Unique and Any hit policies. It also asserts that  at least one conclusion value must result for any set of valid input values. This is the equivalent of the (obsolete) DMN concept of completeness.
• Principle 14 (‘inferential integrity’) which enforces the following restrictions on any sub-decision that yields (provides) a conclusion that is used (consumed) as a condition in a dependent decision:  all the potential values provided are covered by the conditions of the consumer and all the conditions in the consumer represent values that can be provided.

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. This is considered to be poor factoring of business logic and is likely to foster some repetition in the Rule Families. In our experience this restriction is sometimes impractical and we would suggest that it be upheld as an ideal, not as a best practice.

Conclusion

Prior experience with TDM is a huge benefit for any decision modeler. The best practices and principles that TDM provides are effective pre-requisites for rigorous and accomplished decision modeling and TDM will provide modelers with a solid foundation for building valuable decision models.

TDM has many best practices that can be reused in DMN with some minor adjustments, however modelers with TDM experience should consider the differences between them 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 DMN training courses can help those with TDM experience who need to master DMN quickly. A more in depth comparison between the features of TDM and DMN is included in appendix D of our book.

Our thanks to Sapiens for all their feedback and help in producing the materials on which this article was based.