Call us at 650-400-3029 (PST)

Using TDM Principles in DMN

Decision Model and Notation (DMN) is an open industry standard, designed to be a common and standard bridge between what you need a business decision to do and the decision implementation for how it actually happens.  The Decision Model (TDM) is a proprietary approach to representing business logic established by Barbara von Halle and Larry Goldberg in 2009 and documented in their book The Decision Model[1].   Both DMN and TDM are based on a decision requirements model which is represented in a series of diagrams with decision requirements notation showing how decisions are decomposed into their sub decisions and data dependencies along with the tabular structure for defining decision logic. TDM defines a set of 15 principles for decision modeling, many of which can be applied using Decision Model and Notation (DMN)[2].

Structural Principles

TDM’s structural principles (1-7) are around the representation of tabular logic.  Principle 1 (Tabular) and Principle 4 (Row) establish a way to use a decision table to represent business logic.  Principle 7 (Connection) establishes dependency relationships between decisions so that the outcome of one decision can be used as the inputs of dependents.  These three structural principles are directly supported by the requirements relationships in DMN.  Principle 2 (Heading) defines the meaning of table headers which in TDM is constrained to only information inputs while DMN headings allow for expressions.  Principle 3 (Cell) allows for operators and operand expressions while in DMN any specific operand expressions – like a cell calculation, would be pulled out into their own decision for output to allow for comparisons with a single operator.  Principle 5 (Conclusion) allows for only one conclusion in TDM, while DMN relaxes this constraint to allow flexibility to have multiple conclusions for strong relationships that are cohesive, share dependencies and are mutually independent.  Lastly, Principle 6 (Conditions) requires that all conditions in a rule are satisfied in order to yield the outcome with rule patterns.  While DMN mostly supports this, it does not explicitly support rule patterns.

Declarative Principles

TDM’s declarative principles (8-10) refer to the ordering of condition columns, rule rows, and ordering of decisions in decisions views.  DMN addresses these principles as decision table design best practices.  Principle 8 (Declarative Heading) and Principle 9 (Declarative Body) forbid any implied meaning for the ordering of condition columns and rule rows in the tabular decision logic known as rule families.  DMN assigns no significance to the order in which inputs appear in a decision table and there is no concept of condition evaluation order in the decision table.  Similarly, Principle 10 (Declarative Inferential Relationship) forbids any implicit semantics for the top-to-bottom or left-to-right ordering of decisions in decision views ensuring that any sequencing is eliminated with an important best practice of DMN decision model that requirements are modeled and not sequenced.  Principle 9 is upheld in DMN by the specific decision table definitions of Unique, Any, or Collect hit policies with the rule order irrelevant to the behavior of the decision table.  The First hit policy violates this principle and should be avoided in DMN as best practice.

 Integrity Principles

TDM’s integrity principles (11-15) align with DMN as best practices, with the exception of Principle 13 (Rule Family Transitive) which ensures that two direct sub-decisions of a specific decision should not have dependencies between them.  While this is good practice, it is often impractical in real engagements to adhere to this requiring lengthy refactor work to result in new decisions making that are often less intuitive for business owners.  The consequences are minimal for this rule family transitive principle, so it should be upheld as an ideal but not a best practice.  Principle 11 (Rule Pattern Transitive Conditions) ensures that no condition in a rule family depends on any other which remains a best practice, while not directly supported by DMN, in that any dependencies of conditions would be pulled out into their own decision table within DMN. Principle 12 (Consistency) ensures there are no overlaps in rules in a rule family.  In DMN this is maintained as a best practice for decision logic hit policies and completeness in that a decision table conclusion will cover every possible combination of input values.  Principle 14 (Inferential Integrity) enforces restrictions on sub decisions that the values of the outcomes are consistent with the conditions imposed.  This general best practice in DMN maintains the integrity of information requirements to ensure that the type and range of an information item which a decision uses as an input must match the type and union of the ranges of all providers.  Principle 15 (Business Alignment) is directly supported in DMN as a business context best practice aligning both to the goals and KPIs for a decision as well as capturing the decision properties such as the business meaning, connections with business entities, statistics, process context, governance, and data context.

[1] The Decision Model: A Business Logic Framework Linking Business and Technology (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis, LLC

[2] Real-World Decision Modeling with DMN (Taylor & Purchase) © 2016 Meghan-Kiffer Press