With DMN (the OMG Decision Model and Notation standard) reaching finalization, it is good to examine and highlight the purpose and contribution of DMN.  Is it a standard notation, is it a methodology, is it a graphical model, is it an implementation standard, or what is it?

This article identifies the position of DMN, the reasoning behind it, and its relation to other modeling techniques.

What are the issues DMN attempts to solve?

1. Separating decisions and processes.  It is commonly known that mixing decision logic with business process paths is not very flexible and leads to complex process models.  Separating decisions and their logic from the process is better, but there was no standard modeling notation for that.


2. Decision table types.  Most people know what decision tables are:  a number of rows or columns containing decision rules about combinations of condition expressions with their respective outcome.  But many did not realize how the decision table concept has been refined throughout the years into a strict and powerful modeling technique (based on consistency by construction, normalization, correctness, …).  Different forms, with different names and different semantics, are still used sometimes, and DMN allows us to recognize, and unambiguously understand and exchange, these various forms.


3. Decision modeling methodology.  Decision table methodology is not new.  Methodologies, both to design single tables and to design a network of decision tables (where the outcome of one table is used as a condition in another table), have existed for years, allowing the expression of a model of related decisions.  But as other methodologies have appeared, containing undefined types of tables (whatever they are called), it is important to keep the insights of the past and avoid confusion.


4. Separating decision structure and decision logic.  Decision logic can be expressed in many forms.  Sometimes (related) tables are perfect, but in many other cases, other forms will do better (mathematical functions, neural networks, …).  DMN, by separating the decision and the decision logic, allows us to model decision relations, even if not all logic is expressed in tables.


5. Standard notation for exchange and implementation.  If the concept of the decision table has been well defined for many years, a strict notation (about what goes in which cell) is useful to allow automatic implementation.  By its simple expression language, DMN allows model-driven design, such that business people can truly model and maintain decision logic without worrying about implementation.

The following sections elaborate on each of these issues.

1)  Separating decisions and processes

Most processes and business process models incorporate decisions of some kind.  Decisions are typically based on a number of business (decision) rules that describe the premises and possible outcomes of a specific situation.  Decisions influence the activities and workflows of process stakeholders.  Business decisions are important but are often hidden in process flows, process activities, or in the heads of employees (tacit knowledge).  Moreover, in a large number of cases, a particular business process does not just contain decisions, but the entire process may be about making a decision.

It is not considered good practice to model the detailed decision paths in the business process model.  Separating rules and decisions from the process simplifies the process model (separation of concerns) and makes it more flexible.  It also allows the management of rules and decisions next to the processes.

2)  Decision table types

Decision tables look straightforward:  a number of rows or columns containing decision rules about combinations of condition expressions with their respective outcomes.  The reason for their success is simply that every column (if the rules are in rows), or every row (if the rules are in columns), or every dimension (if the rules are as a crosstab), is about one specific condition.  This fixed order of conditions allows a complete and consistent overview of decision rules for a specific decision, which is important for the business.

But many people do not realize how the decision table concept has evolved over the years.  Not every table of rules is considered a good decision table (no matter what it is called).  Because different forms, with different names and semantics, are still sometimes used, DMN allows us to recognize and unambiguously understand them.  DMN does not prescribe a specific form (although there is a default), but it at least makes sure there is no ambiguity.  The default decision table is the preferred unique hit table, which is consistent by construction, because there are no overlapping rules and no redundancies.^[1] [2]

3)  Decision modeling methodology

The format of decision tables, however, is only part of the story.  When the CODASYL Decision Table Task Group produced their report A Modern Appraisal of Decision Tables^[3] it not only contained an overview, notation, theory, and algorithms but also a development methodology.  This development methodology (Chapter 5) covers such aspects as:

• a set of guidelines for composing effective decision tables (form, structure, meaning, …).
• the development of a hierarchical structure of tables that serves as a functional solution to the problem.
• the definition of a working subset of decision tables (completeness, no inconsistencies, no redundancies, no overlapping rules, no ELSE-rule, …).
• a simple 8-step method to construct good decision tables.
• a transition from the specification to design, implementation, and maintenance.

After the CODASYL report, the development methodology has been further refined and explained, e.g., as presented at the Business Rules Forum since 2004 (see, for example, [4], [5]).

DMN is not a methodology, but it fits perfectly with the decision table methodology and allows exchange with other approaches.

4)  Separating decision structure and decision logic

DMN provides constructs for both decision requirements and decision logic modeling.  For decision requirements, it defines the concept of a Decision Requirements Graph (DRG) and a corresponding notation:  the Decision Requirements Diagram (DRD).  The requirements level allows for modeling and managing linked decisions, abstracting from the detailed logic of each decision.

Decision logic modeling can take many forms, depending on the decision at hand:  it can be decision tables, calculations, if/then/else logic, externally-defined logic in a piece of code, the result of a predictive analytics model, etc.  This is because not all decisions or rules can be expressed in tables.  But once tables are used, DMN-conformant models ensure they are properly-defined decision tables, easy to recognize and interpret unambiguously.

The two levels are not isolated from each other.  Decision table theory (for example) shows how factoring and normalization of decision tables reveals structural relationships between connected decisions.^[2]

5)  Standard notation for exchange and implementation

The primary goal of DMN is to provide a common model and notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements, and then to the more-detailed decision logic models (e.g., in the context of business processes), and to the developers responsible for implementing the decisions, and, finally, to the business people who will manage and monitor those decisions.  DMN creates a standardized bridge for the gap between the business decision design and decision implementation.  DMN notation is also designed to be useable alongside the standard BPMN business process notation.

To this end, a simple but strict notation and expression language is useful to allow automatic implementation.  DMN includes a simple language called FEEL (Friendly Enough Expression Language), such that business people can truly model and maintain decision logic without having to worry about implementation; but it is strict enough to allow straightforward and automatic implementation.  Another goal of DMN is to ensure that decision models are interchangeable across organizations and tools.

So how does DMN fit in?

DMN is about indicating the importance of modeling and managing decisions, not only processes.  DMN also provides a standard notation for representing the dependencies between decisions as well as for representing the logic of a single decision (e.g., in the form of a decision table).  DMN itself is not a methodology, or the standardization of an existing methodology, but it does fit well with a decision table development methodology by allowing us to recognize, exchange, and unambiguously understand decision modeling artifacts, whatever the underlying methodology (or lack thereof).  That is important for business.

At the same time, DMN attempts to produce executable specifications (in different levels of conformance).  Therefore, it is important to clearly identify the syntax and semantics of decision requirements, common table types, (friendly enough) business expressions, etc.

DMN does not replace other methods or standards.  It does not replace business rules, of course — it just represents some of the structural, decision rules.  It does not replace SBVR (and can perfectly refer to it).  And it links well to BPMN by more clearly separating decisions and processes.

So DMN is an excellent start.  It will allow us to harmonize and clarify the decision management and decision table message.  It does not replace the good old (but modern) decision table methodology, and it makes business users and implementers aware of the need for clear decision specifications, both outside and inside the context of business processes.

References

[1]  J. Vanthienen and E. Dries, Decision Tables:  Refining the Concept and a Proposed Standard, 13 pp, www.econ.kuleuven.be/prologa/refsdtpubs/DTDevACM.pdf  

[2]  J. Vanthienen and M. Snoeck, "Knowledge Factoring Using Normalization Theory," International Symposium on the Management of Industrial and Corporate Knowledge (ISMICK'93), Compiègne (FR) (October 27-28, 1993), pp. 97-106,  www.econ.kuleuven.be/prologa/refsdtpubs/NORM4WIN.pdf  

[3]  CODASYL Decision Table Task Group, "A Modern Appraisal of Decision Tables," Report of The Decision Table Task Group, ACM, New York (1982), 322 pp.  

[4]  J. Vanthienen, "Quality by Design:  Using Decision Tables in Business Rules," Business Rules Journal, Vol. 5, No. 2 (Feb 2004), www.BRCommunity.com/n008.php  

[5]  J. Vanthienen, "The History of Modeling Decisions using Tables (Part 3):  Standardizing Decision Table Modeling (16 guidelines)," Business Rules Journal, Vol. 13, No. 5 (May 2012), www.BRCommunity.com/a2012/b652.html  

# # #