DMN Method & Style

9th of June 2021

The Decision Modeling Notation (DMN) is an industry standard (OMG) that was developed agnostic of existing and/or technologies. It defines a decision as “the act of determining an output value from a number of input values, using logic defining how the output is determined from the inputs”. This is a convoluted way of explaining that DMN is about the logic modeled as a set of decision rules, and not the specific outcome of any one rule. A DMN decision model will render the output value for any allowed combination of input values. It also isn’t influenced by any action that might flow from such an outcome.

The standard allows for any vendor to adapt his product to adhere to this standard without restrictions, and serves as an executable syntax that can be easily integrated in BPMN and CMMN models in order to enrich them. Although these decisions could be modeled using elements from these respective notations, there are good reasons to separate the decision logic into its proper design:

  • It reduces the complexity of the process/case that is being modeled.
  • It renders the process/case less prone to change, as decisions usually have a different change frequency from the processes/cases in which they are present.
  • Decision logic is typically not sequential and thus contrasts processes that are procedural in nature.
  • It improves the clarity and readability of the processes/cases, as well as of the decisions themselves.

Similar to his earlier work for BPMN, Bruce Silver published this book in 2016 to give DMN the same treatment: Explaining the different components that make up the notation, as well as showcase how to design different scenarios in a proper manner. As he exclaimed about BPMN Method &Style: “It’s not because you know all the words of a language that you can write a proper sentence”. Since then, a second edition was already released. But this review is still about the first edition. In addition Bruce Silver has published a lot of insights on how to work with the DMN specification on his blog Method & Style.

DMN takes its cue from Business Decision Management (BDM) which is both a management discipline and a technology stack to support this discipline. Thus decisions are rooted in business considerations, not technical ones. However, after they are written down in business requirements documents, they are to be handed over to the implementation team who proceeds to code the resulting rules or input them in a Business Rules Engine (BRE) or other technology. In summary, as taken from the lips of James Taylor, BDM’s most recognizable evangelist, and writer of the Decision Management Manifesto: BDM is an approach aimed at optimizing day to day operations. It enables an increase business agility and adaptability by rendering components easier to monitor and change, using Big Data to improve effectiveness and profitability of each action.

The main focus for DMN is not to model strategic decisions (such as for example innovation management approaches), but rather the decisions (calculations, approvals, compliance checks…) that happen every day within the operational scope of an organization. These operational decisions have a common denominator in that they can all be formulated as questions containing data items for which the response is itself a data item. Data items always fall within a domain of possible values (such as a list of constants or a number range). This is sometimes referred to in other decision modeling as a facts model.

Facts Model

The DMN specification is summed up by a number of key elements:

  • Metamodel and Schema: A metamodel describing the names and relationships of the different components in the other key elements.
  • Decision Tables (DT): Tabular representations of logic that make up a decision rule.
  • Decision Requirement Diagrams (DRD): Hierarchical ordering of multiple business rules to represent an end-to-end business decision.
  • Friendly Enough Expression Language (FEEL): A pseudo-code expression language allowing for the introduction of functions (similar to those in for example Microsoft Excel).
  • Boxed Expressions: a tabular notation for data and decision logic.

Although ideally the entire specification should be executable, there are variations based on the implementation of the specification, that could limit what is executable and what is only descriptive. The specification itself also proposes guidelines on this by employing conformance levels, and which elements can be used at each conformance level. I will not list them out, but here is an overview of all levels:

  • Conformance Level 1: not considered executable, so no constraints on content, format, or completeness.
  • Conformance Level 2: Baseline for executable models. The DMN metamodel is respected, and thus models are semantically precise. The subset of FEEL that is usable at this level is called S-FEEL.
  • Conformance Level 3: The full set of DMN elements and diagrams. As this encompasses for example the full list of FEEL functions and operators, this is not considered executable, unless supported by the component in which it executes.

When implementing TableSpeak, another standard for decision modeling, Ron Ross, co-founder of Business Rule Solutions, offered guidelines about anomalies to be avoided. These anomalies can give us insight on how to model in DMN in a proper fashion:

  • Redundancy: Some inputs may match multiple rules, which none the less have the same outcome. For clarity’s sake, these should be avoided. However, DMN does off the Any Hit Policy to capture this.
  • Multiple Outcomes: Some inputs may match multiple rules which have different outcome. Again, clarity is not served by such rules. However, DMN has single-hit policies First and Priority, as well as multi-hit policies allowing this.
  • Conflict: Some inputs may match multiple rules with exclusive outcomes. This is to be avoided at all costs.
  • Omission: Some inputs may not match any rules. For completeness this should not occur.
  • Subsumable Rules: Multiple rules could be combined into a single rule without change in outcome. This is preferred for clarity’s sake as well as make the rules less fragile when they are changed.

These anomalies should drive the testing effort of any DMN modeling with the following checks incorporated:

  • Completeness check: Verify that all possible incomes and outcomes are taken care of.
  • Consistency Check: Verify that no overlapping rules exist with different outcomes unless this is specifically desired (such as with multi-hit policies).
  • Decision Analysis: Verify that all business decisions as a whole provide sensible results.

Metamodel and Schema

Every single element used in the DMN specification is mapped out with its definition, attributes, and relations to other elements. This encompasses numerous UML diagrams which I will not repeat in this article, but as illustration of their relative complexity, the following diagram shows the metamodel for the Decision element:

DMN Meta Model for Decision

Metamodels serve to define not only the behavior and characteristics of the individual elements of the specification, but also to arrive at a sort of ubiquitous language, where whenever a term is used, everyone at the table understands it in the same way.

The term “decision” can easily be misunderstood to mean very different things:

  1. The business decision as a whole: It is an important concept in DMN, but is never mentioned in the specification. Normally we assume one or more DRD will describe such business decision.
  2. A business service or a unit of decision execution: In the DMN specification, this is represented by one or more decision nodes (represented in the DRD by a rounded rectangle overlay encompassing these decision nodes).
  3. A single decision node: The rectangle shape in the DRD, corresponding to the DMN “Decision” as described in the metamodel.

Decision Tables

A strong selling point for decision tables are their readability. The logic that will be applies is very straightforward: IF [set of inputs]THEN [output]. Anyone can look at the table and derive how a specific output is achieved. This logical transparency translates into the following characteristics of a DMN decision table:

  • Rules are understandable to business users.
  • Input conditions are verifiable for completeness.
  • Rules are verifiable for self-consistency.

Based on the work professor Jan Vanthienen (K.U. Leuven) did around decision tables, the author distilled a list of commandments that can be followed to construct proper decision tables. Some of these are self-evident, and I will not list them, but others are practical guidelines to making sure your decision table does what it needs to do. Some of these are covered by the specification, others are best practices for decision table design:

  1. Decision tables should be complete and consistent. As stated above, these are the characteristics that the DMN specification tries to make happen. All possible inputs (or input combinations) should be addressed to give an outcome.
  2. Input entries should be designable as any type, and even be complex types (for example a JSON object). This also applies to designing output values.
  3. Single-hit tables (read: non-iterative) should adhere to the Unique hit policy of DMN to avoid omissions, redundancies or subsumptions.
  4. A horizontal layout (rules-as-rows) is readable if the number of inputs and outputs are relatively low. With a large number of inputs and/or outputs, a vertical layout gives a better overview.
  5. Rules should be ordered in the decision table in a natural way. This will help with the completeness verification.
  6. The order of the inputs should always try to minimize the number of rules in the table.

DMN Decision Table Structure

Most of the elements in the decision table shown here are easily understood based on their name. The only one that deserves a bit more explanation is the hit indicator or hit policy. This determines how the different rules are approached when the evaluation is made. The following hit policies (taken from Bruce Silver’s Blog) are possible in DMN:

  • Unique (U): Only one rule may match. Overlapping rules represent an error.
  • Any (A): Rules may overlap, but only if their output values are the same. Overlapping rules with different output values mean the table is inconsistent, an error.
  • Priority (P): Overlapping rules may have different output values. The hit policy selects the one with the highest priority, which is determined by the order of allowed values in the table output column heading. A P table that omits allowed output values is an error.
  • First (F): Overlapping rules may have different output values. The hit policy selects the first matching rule. Many experts deprecate F tables because they violate the principle that the order of rules in a table should not affect the result. Anything you can do with F tables you can do with P tables instead.
  • Collect with aggregation (C+, C>, C<, C#): Except for C#, the rules must have numeric output values. Hit policy C means collect the values of all matching rules; the aggregation code tells you how to combine them. C+ means take their sum, C> means select the maximum value, C< means the minimum value, and C# means report the count of matching rules.

Decision Requirement Diagrams (DRD)

Example Decision Requirement Diagram
Example Decision Requirement Diagram

The main idea behind the DRD is to describe the “business decision as a whole”. In other words, this is the end-to-end overview of the decision with all of it human decisions, external decisions and the relationships (without stipulating an order of execution) between these decisions to form a final evaluation. This is enhanced with knowledge business models, input models and sources. These elements can be seen in the diagram above:

  • Decisions: logic, either directly stated or referenced, to evaluate a set of inputs.
  • Input Data: literal data values coming from business systems or external sources.
  • Business Knowledge Models (BKM): reusable decision logic represented by a function definition with a set of parameters.
  • Knowledge Sources: these are the authorities for a decision logic set, the source from which the authenticity of the rules are drawn.
  • Connectors to connect each of these elements together based on the element that is being linked to the decisions.

Friendly Enough Expression Language (FEEL)

Literal expressions, decision tables, and many other DMN elements rely on textual expressions (such as for example functions) to describe a complexity needed to achieve proper decisions. The FEEL (Friendly Enough Expression Language) is a readable pseudo-language for programmers and business analysts of which as mentioned earlier a subset is even executable (S-FEEL). The language follows a set of principles that are fairly common in programming languages:

  • Side-effect free
  • Simple data model with numbers, dates, strings, lists, and contexts
  • Simple syntax designed for a broad audience
  • Three-valued logic (true, false, null)

The language can be split up in several different types of statements, that can feel very similar to the macro coding of for example a Microsoft Excel:

  • Conditional Statements: A standard IF <x> THEN <y> ELSE <z>.
  • Loop Statements: Used to transform and/or verify lists.
  • Range Statements: Used to check whether or not certain values are in a given interval.
  • String Functions: Used to transform string values. Examples are length(), upper case(), lower case()…
  • Number Functions: Used to transform numbers with a mathematical operation. Examples are abs(), sqrt()…
  • Date/Time Functions: Used to transform the outlook of dates/timestamps.
  • List Functions: Transformation functions for lists. Examples are concatenate(), count(), distinct values()…

Boxed Expressions

DMN offers a way to graphically represent functions and variables, called boxed expressions. This is shown as a two-column table with the first column being the name of what the boxed expression is visualizing, and the second column being how to determine its value, either as a constant, or a FEEL expression.

These could for example be used to model BKM elements, as is shown in the example below:

Example Boxed Expression

These could also be used to model a data element, as shown in the example below:

Example Boxed Expression

Take heed that every variable used n a DMN expression, either as part of another boxed expression or in a FEEL statement or rule should be a corresponding typeRef defining its type, which can either be one of the base types (such as a string or an integer), or a custom type described by a boxed expression, a reference (namespace-qualified name), or an imported XSD. An example of this can be seen below:

Example Boxed Expression

Decision Analysis

The DMN specification allows for the formalization of decision logic within an organization and subsequently supports the execution of this formalization. However, to come to a proper set of decisions and rules, the author suggests a process titled the DMN Method. It outlines the different phases and steps to go through in order to successfully implement decision logic:

  1. Decision Discovery Workshops with business and subject matter experts to determine the key decision model elements:
    1. The end-to-end business decision (names, possible outcomes)
    2. The input data elements
    3. The process logic of the as-is situation
  2. Top-Down Decomposition of the DRD:
    1. Starting at the top: Modeling the business decision as a whole with an overall question you want to answer. This should be represented by a single decision node at the top of the DRD.
    2. Identify considerations about the top-level decision, splitting it in logically independent categories, each defining a separate branch of the DRD.
    3. Detail each consideration with underlying considerations that could affect the outcome of the decision.
    4. For each detail consideration, determine input data and their source.
    5. For each input data element, determine its usage for every detail decision, allowing for the simplification of certain considerations.
  3. Decision Logic Detailing for each decision node.
  4. A Business Glossary and Data Model diagrams.
  5. Testing and analysis (verification and validation) of the decision model.

These steps are based on other standards about decision modeling available. Decision Requirements Analysis (DRA) will guide us from identifying decision points to defining top-level decisions for each decision point to decomposing each of these top-level decisions to describing in detail all decision nodes to finally defining the rule service boundaries.

Similarly, the STEP methodology (Separate/Trace/Express/Position) follows the following five step process:

  1. Listing all decisions and the sources of their requirements
  2. Documenting the business process and underlying use cases, and determining where the decisions figure in this process
  3. Building a business glossary with links to existing data models
  4. Building a decision model for each of the decisions
  5. Analyzing and optimizing the decision models

Pitfalls of a Modern Organization

The books references an insightful article of Signavio on why we would want to employ a standards-based decision modeling and management approach. The business value of tackling business decisions with such a framework are the following:

  • Meeting the time pressure of ever-changing regulation.
  • Being able to model the needed level of business decision complexity.
  • Avoiding lossy translation of requirements so that no detail or exception case goes forgotten.
  • Detecting faulty requirements that do not cover all permutations of the business decision.
  • Reducing the impact of continual change.
  • Creating a consistency across the entire organization (or even beyond its borders).
  • Making business decisions auditable.
  • Increasing the data quality of information assets used in the decisions.
  • Rendering business decisions testable and executable.

Review BPM ACM Comment