Preface

Decisions are so pervasive and deeply woven into the fabric of business that we often take them for granted:

• What is the total price – including applicable discounts, surcharges, taxes, and shipping – for this order?
• Is the information on this form complete and valid?
• What upsell offer should be made to this customer?

These decisions are more than arbitrary human judgment.  They are based on some defined business logic.  Optimizing operational performance, risk, and compliance in the face of a complex and ever-changing business environment requires the logic of these decisions to be determined and maintained by the business, not delegated to programmers.  In the past that has not been easy.  But things are changing.

Here we are talking not about strategic decisions – Should we acquire company XYZ? – but the operational decisions that occur every day.  They perform calculations and approvals, check compliance, and suggest next-best actions… all based on some defined decision logic applied repeatedly in the course of business.  The logic of operational decisions is fundamentally based on business – not technical – considerations.  If you tried to explain it to someone outside your organization, you’d probably begin by saying, “Well, it depends on a number of factors…”

To explain the decision logic in complete detail, you’d have to list all of those factors, enumerate their possible values, and then specify all the rules that determine the decision result for any possible set of factor values.  For years, organizations have tried to do this in lengthy “business requirements” documents handed off to programmers for implementation, either in a business application or a dedicated Business Rule Engine.

In applications such as underwriting, benefits administration, and risk management, companies have long relied on Business Rule Engine (BRE) technology to automate the decision logic.  So-called Business Rule Management Systems (BRMS) surround the BRE with a proprietary rule language, a repository for ruleset versioning and test, and a governance/change control framework.  While those systems were intended to give control over business logic to business analysts, in practice such control frequently remained a prerogative of software developers.  Historically, the business stakeholders’ role has been to try to specify the requirements for that decision logic, typically in spreadsheets and text-based requirements documents, which are then interpreted by technical architects and programmers (as best they can) and then translated into executable code.  But that handoff is not an efficient or effective way of defining decision logic that is continually changing.  Because decision logic is business logic, business people should be able to define and maintain it themselves.

Now, for the first time, we have an industry standard executable decision modeling language – Decision Model and Notation (DMN  – designed for business users.  DMN allows business analysts, business architects, and regular business people themselves to model and maintain the decision logic that impacts their daily operations, rather than simply write business requirements for programmers.

A decision model is not the same as a text-based requirements document.  A decision model communicates through structured diagrams and tables, not unstructured text.  Unlike text-based requirements, diagrams and tables can be reviewed simultaneously by all stakeholders.  Moreover, since the model conforms to a defined structure and rules, it can define decision requirements more precisely, completely, and consistently than a business requirements document ever could.  A DMN model can even be directly executed on a decision engine without requiring translation into the rule language of a proprietary BRE.

DMN is an industry standard, maintained by the Object Management Group (OMG).

Following the Path of BPMN

We have a recent precedent for this in the case of business process modeling.   Ten to fifteen years ago, in order to bring automation to a business process, business requirements were captured either in text-based requirements documents handed off to programmers or in modeling tools embedded within a proprietary Business Process Management Suite (BPMS).  In other words, to do any business process modeling you had to buy a runtime system first.

The emergence of the BPMN standard in 2003-2005 revolutionized business process management.  All of a sudden you could describe any business process – manual or automated – as a set of diagrams with precise meaning defined by an industry standard, not by a proprietary tool.  Because it was business-friendly, BPMN 1.x was rapidly adopted by business and technical users alike, and proprietary process modeling tools quickly died out.  The shift to model-based requirements based on standards led to radically new BPM project methodologies in which business users collaborated with developers directly in the implementation phase.

Although BPMN 1.x was not executable, it was believed at the time that mapping BPMN to a similar process execution language standard called BPEL would suffice, since many of the leading process automation suites, like IBM, Oracle, and SAP, already supported BPEL.  But in the end, business users rejected that idea.  There were BPMN diagrams that BPEL could not execute without redrawing them in a way that looked completely unfamiliar to the original modelers.

Consequently, in 2008-2009 those same BPEL vendors led the development of BPMN 2.0, which made BPMN both a diagramming language and a process execution language.  Not only was modeling standardized, but much of the automation runtime was standardized as well.  This led to a significant transformation of the BPM technology landscape, with an explosion of new tools, lower costs, open source software, and all the rest.  It was nothing short of a revolution.

Make Way for DMN

Decision management is embarking now on that same path (Figure 1).  With DMN we now have standards-based decision modeling geared to business analysts and ordinary business users.  Instantly, that moves us past the problems of text-based decision requirements documents.  In the longer run, it promises to make model-based decision execution pervasive in business systems.

DMN’s two most prominent features are:

• Decision requirements diagrams (DRD), able to depict complex end-to-end business decisions as a hierarchy of decision nodes, supporting decisions, and input data, annotated with links to policies, business rules, and analytics models that provide an authoritative basis for the decision logic.[3]
• Decision tables, tabular specifications of the logic of an individual decision node in a DRD. Decision tables have been in use for decades, but DMN specifies a standard syntax and formats for them.

Unlike the first generation of BPMN, DMN already defines an executable expression language called FEEL, so DMN models, at least in principle, can be executed.  I say “in principle” because, as of this writing, few FEEL-based DMN tools are available.  So far, most have been substituting their own tool-specific expression languages with FEEL-like capabilities.  In fact, several first generation DMN tools are content to serve as a modeling front end to commercial BREs such as IBM, FICO, and RedHat, requiring translation of DMN into a different rule language.  But the arc of BPMN’s history suggests that this is a temporary state of the market.  Ultimately DMN/FEEL engines will exist with production-level performance and reliability, and the decision management revolution will be fully realized.

Why I Wrote This Book

When the DMN 1.0 specification was finalized in November 2014, I had been doing BPMN training for almost eight years.  My book BPMN Method and Style[4] was in its second edition, translated into German, Japanese, and Spanish.  Through all that experience I had learned the difference between an OMG specification and its effective use, which requires firm guidelines.  My guidelines, based on the “Method and Style approach,” is founded on a few basic principles:

1. What counts in the model is what you can see in the diagrams, not details buried in the nether reaches of a tool.
2. Modeling is fundamentally a disciplined exercise not a creative one. Creativity is critical to designing better processes or betterdecisions, but translating some given logic into a model should be as “mechanical” as possible.
3. While the spec may allow many different ways to model the same bit of logic, differing in compactness, ease of understanding and analysis, ease of change, and other factors, it’s best for everyone to standardize on one way to model a particular type of scenario.

On reading the DMN spec, I saw immediately that several factors that had made my previous BPMN work successful were in place again with DMN:

• The opportunity to transform an undisciplined text-oriented practice of specifying decision requirements into a disciplined model-driven effort. There is a widely held belief that business users cannot “follow the rules,” but my BPMN experience had proven that to be false.  You just need to show them how to do it.
• A specification extremely difficult to decipher, even upon close and extensive rereading. OMG specifications make no attempt to be “teaching” documents, and the DMN spec is no exception.  Moreover, the diagrams and examples in the spec are often more confusing than clarifying.
• The complete absence in the specification of any methodology or practical guidance for how to use DMN’s many features.

I had previously done an engagement or two with Larry Goldberg of KPI,[5] co-author with Barb von Halle of The Decision Model[6] (TDM), that showed the client how to apply decision modeling and process modeling in tandem based on a business-oriented methodology.  TDM was, I believe, the first serious effort to make decision modeling a true business-oriented discipline, and a number of TDM ideas are incorporated in DMN.  My original thought for the book was to take the DMN standard, which differs from TDM in several significant ways, and apply much of the TDM methodology and “style rules” to it.

But that is not the book I ended up writing.

As I was rereading the DMN spec for the umpteenth time, certain sections remained unclear or contradicted other sections.  The only real example in the spec, a Lending decision, seemed to omit critical features of the standard.  For example, all decision tables referenced only literal values, but the spec says they could reference variables, as well.  That’s a pretty big omission!  Some chapters of the spec, like the one on FEEL, remained impenetrable after multiple attempts.  The purpose of the “boxed expression” format was never really explained.  To top it off, the XML schema – the key deliverable for DMN implementers – contained critical bugs.

I began firing off questions to the DMN LinkedIn group.[7]  I quickly became such a pest that Gary Hallmark, a contributor to the group and co-chair of the DMN 1.1 Revision Task Force (RTF) in OMG, invited me to join the RTF.  The main purpose of a “minor revision” RTF is to clarify the standard and fix bugs, so I was happy to do it.  That turned out to be a transformative experience, as it gradually became clear, after six months of weekly teleconferences, what the spec was struggling to say.[8]  In time I discovered aspects of the standard that even its original authors failed to appreciate.  For example, I saw how a prominent feature of the standard, the Decision Requirements Diagram(DRD), makes DMN fundamentally different from TDM, and suggests not only a very different methodology but a relationship between DMN and BPMN that is different from the one discussed in the spec.

The DMN 1.1 RTF completed its work in November 2015.  Official publication is in the hands of the editors at OMG.  The bugs in the schema have been fixed and some vague passages in the spec text have been cleaned up.  For example, it’s clear now that decision table cells may reference variables!  But while the interior plumbing has changed completely from DMN 1.0, the features modelers are most interested in, decision tables and DRDs, still look the same as they did in the original version.  On the downside, the DMN 1.1 spec text still tends to obfuscate more than enlighten.  The FEEL chapter is as impenetrable as ever, and the Lending example decision table cells still contain only literal values.  It was impossible to fix those things by the DMN 1.1 deadline, and to be honest, some RTF members like them just as they are.  So to dig beneath the surface of DMN, you’ll just have to read this book.

Those endless re-readings of the spec text, edits to the metamodel and schema, and vigorous debates in the RTF meetings also produced an unexpected bonus, a much deeper understanding of what DMN can be when it is fully implemented by tool vendors.  As of this writing, DMN tools have implemented only a portion of the specification.  Full implementation should include two key features inadequately explained in the spec: FEEL and boxed expressions.  I believe these hold the key to advancing, in the terms of Figure 1, from BPMN 1.x-like decision models to BPMN 2-like decision models: a unified language supporting both modeling and execution.

While boxed expressions and FEEL are critical to the long-term success of DMN as a standard, the world doesn’t really know about them yet.  And so, in addition to my original objective of teaching modelers how to use DMN effectively, the book has the additional goal of encouraging those modelers to demand that tool vendors fully implement these features of the spec.

What Makes a Decision Model “Good”?

DMN Method and Style is aimed at creating decision models that not only are “valid” according to the DMN specification, but that could be called “good DMN,” models that communicate the decision logic clearly, completely, and consistently through printed diagrams and tables.  But what makes a decision model “good”?

There is a substantial literature describing what makes a good decision table, including publications (all predating DMN) by Vanthienen,[9] Ross,[10] and von Halle and Goldberg.[11]  There is general agreement among these authors that a well-designed decision table should be complete (cover all possible combinations of input values), consistent (provide a single conclusion value for any particular combination of input values), and as compact as possible (within the defined table format).  Also, there is some consensus that the table should be organized to facilitate analysis of completeness and consistency by visual inspection.  The specific recommendations of these authors differ, of course, and they must be adapted to the decision table structure defined by DMN.  DMN style applies those principles with specific recommendations applicable to DMN decision tables, and adds others – for example, concerning naming of decisions and input data – that attempt to communicate more meaning through the printed diagrams.

However, the literature provides little guidance on how best to decompose a complex operational decision into a DRD.  This is the DMN Method, and it represents a new and original approach.  The Method begins by understanding the business decision as a whole and places it at the top of the Decision Requirements Diagram.  That might sound obvious, but actually the concept or term “business decision as a whole” is never mentioned in the DMN specification.  Nor is it mentioned or used in the methodologies of Alan Fish’s Knowledge Automation,[12] the source of the DRD idea, or The Decision Model.  Instead, all of those sources describe the business decision as a whole as a business process defined by a companion BPMN model.  In fact, the DMN spec explicitly describes the DRD as the link between decisions in a decision model and activities in a business process model.

But that interpretation actually sells the DRD short, because DRD is able to capture, in a single diagram, a high-level view of the entire end-to-end decision logic, even when that logic is executed in multiple steps separated in time.  In addition to decision services that execute model-defined decision logic, the DRD may include human decisions and external decisions, in which the decision logic is not defined in the model.  In the Method, the DRD describes, on its own, the decision logic of the business decision as a whole.

This use of DRD is consistent with DMN concepts and rules, but it leads to a different model structure and a different methodology than one that relies on a BPMN process model to communicate the end-to-end decision logic.  The DMN Method starts with the business decision as a whole and the available input data elements.  The top decision node in the DRD represents the end-to-end business decision: Is the insurance application accepted, and what is the price?  The Method then guides the modeler in the top-down decomposition of that decision node into a hierarchy of supporting decisions, and ultimately down to the input data.  To aid in that decomposition, the Method also provides a set of common decision logic patterns useful for modeling specific scenarios.

Objectives

The goals of this book, then, are threefold:

1. To clarify for modelers the concepts, formats, and standard expression language of DMN, as defined in the DMN 1.1 specification.
2. To define the characteristics of “good DMN” – models that succeed in fulfilling that essential mission of precise, clear, and complete communication of the decision logic – along with a methodology and modeling style elements designed to achieve them. Method and Style is layered on top of the DMN spec but is not the official specification.  The book will be careful to distinguish the requirements of the specification from those of Method and Style.
3. To explain to implementers the technical aspects of the standard: the metamodel and schema, FEEL, and the boxed expression format, with the goal of encouraging tool providers to incorporate all the major features of the standard, not just a few.

Just as there are for BPMN, there will be a wide assortment of DMN books available, and I expect this one will include more technical detail than most.  But, like DMN itself, the book is primarily intended for business users, not developers.  And just as with BPMN, there may be some who say that by venturing beyond DRDs and simple decision tables, I am making DMN “too hard for business people.”  But after nine years of BPMN Method and Style training for thousands of business people and business analysts, I know this is not the case.  Non-technical practitioners of decision modeling can learn DMN, even the advanced Level 3 patterns, and apply it well in their daily work.

Let me say it again:  DMN was created for business users not programmers.  But like BPMN, using it well requires a disciplined approach, lots of examples, and a clear methodology.  Presenting that is the real objective of the book.

Organization of the Book

The book is organized into three parts, covering Business Decision Management, the DMN Standard, and DMN Method and Style.

Chapter 1 explains the concepts and objectives of Business Decision Management, the background and business value of decision modeling, and its application to risk and compliance, predictive analytics, and the Internet of Things.

Chapters 2-7 explain the DMN 1.1 standard, as described in the specification.

• Chapter 2 presents basic decision modeling concepts, the origins of the DMN standard, and an overview of DMN’s five key components.
• Chapter 3 explains the elements of the Decision Requirements Diagram. DRDs provide a high-level view of end-to-end decision logic understandable to any business user.
• Chapter 4 discusses decision logic at Conformance Levels 1 and 2, with a focus on DMN decision tables. Conformance Level 2 is DMN’s baseline for executable decision logic, based on a simple business-oriented expression language called S-FEEL.
• Chapter 5 discusses decision logic at Conformance Level 3, including a comprehensive explanation of the FEEL language and boxed expressions.
• Chapter 6 presents a step-by-step walkthrough of the Lending decision example from the DMN specification, illustrating the various decision table formats and the linkage between the DRD and detailed decision logic. DMN is best learned by studying examples, and this one shows how all the pieces fit together in a basic end-to-end decision model.  Chapter 12 later presents an alternative model for the same decision logic, but following Method and Style.
• Chapter 7, aimed at DMN implementers, explains the DMN 1.1 metamodel and schema, significantly changed from DMN 1.0.

Chapters 8-17 explain DMN Method and Style.

• Chapter 8 summarizes the literature on what makes a good decision table, as background to DMN Style.
• Chapter 9 presents DMN Style, a set of recommendations for modelers, with emphasis on element naming and decision tables.
• Chapter 10 reviews the literature on decision modeling methodology, and then presents an overview of the DMN Method.
• Chapter 11 discusses common patterns used in DMN decision logic, including arithmetic computation, classification patterns, iteration patterns, table lookup and query patterns, sorting and optimization patterns, action subtable patterns, and validation patterns.
• Chapter 12 explains top-down decomposition of the DRD using the DMN Method, illustrated by restructuring the Lending decision discussed in Chapter 6.
• Chapter 13 discusses data modeling for DMN and elements of a Business Glossary.
• Chapters 14 and 15 present detailed examples of advanced decision logic modeled using DMN Method and Style and the patterns of Chapter 12. The first determines approval and annual premium for auto insurance, requiring iteration over cars and drivers on the application.  The second is a mortgage product recommendation, involving iteration and table query patterns.  While the logic of these examples may seem daunting at first glance, taking the time to work through them in detail lets you appreciate the expressive power of DMN.  You don’t need to be a programmer to understand them.  If you can use the Formulas menu of Excel, you can learn to create DMN models like these.
• Chapter 16 discusses decision analysis and testing, a capability of decision modeling tools that is not part of the DMN specification but is a critical element of any decision modeling project. The chapter discusses completeness checking, consistency checking, decision simulation and analysis, using examples from the Signavio tool.
• Chapter 17 summarizes what is important about DMN, what to look for in a DMN tool, and the path to improving the standard.
• Appendix A is a very brief tutorial on BPMN.
• Appendix B provides a real-world example of business decision management in global banking today.

Acknowledgments

In the course of preparing this book, I have requested and received a great wealth of explanation, background information, opinion, encouragement, and reviewer comments from many people, and I would like here to thank those who gave it so generously.

Larry Goldberg of KPI (now Sapiens DECISION) first introduced me to decision modeling and encouraged me to think more seriously about the relationship between decisions and process modeling.  His book The Decision Model announced to the BDM community the message I have long preached in the BPMN world: Business users, you can do disciplined modeling yourselves!

Gary Hallmark of Oracle not only invited me to join the DMN 1.1 RTF but took extra time to help me understand FEEL, boxed expressions, and other “hidden gems” of DMN.  It’s why the book I ended up writing is so different from the book I started out to write.  We battled at times over the metamodel and schema, but in the end, together we made it a lot better!

James Taylor of Decision Management Solutions, author of the Decision Management Manifesto and the original evangelist of BDM, has helped me understand the decision management market and its forerunners, and has provided valuable comments and advice.

Alan Fish of FICO, inventor of the DRD, also helped me with valuable clarifications, a great methodological starting point, and a well-written book, Knowledge Automation.  His comments on an early draft of the book have been extremely valuable.

Gil Ronen of Sapiens DECISION provided not only the basics of the Mortgage Recommender example of Chapter 15 but many valuable comments on the draft.

Amid all the conflicting opinions about what makes a decision table “good,” Jan Vanthienen of KU Leuven was the one who convinced me why Unique decision tables are the right way to go, even when they are not the most compact.  He also provided me many examples from the academic literature that demonstrate that while the DMN standard may be new, many of its ideas are not.

Gero Decker and Bastian Steinert of Signavio not only offered me use of their DMN tool for examples in the book but added features in the tool to assist my purpose.  Now that is a responsive partner!  Also, Gero was the one who suggested using patterns as an organizing principle for decision logic, and that became a cornerstone of the Method.

Jacob Feldman of Open Rules not only provided detailed comments on the draft, but as overseer of the DMCommunity website,[13] he continues to provide the most interesting publicly available examples of decision models.

Aaron Sayles, a Senior Financial Implementation Consultant with extensive implementation experience in risk and regulatory reporting, contributed Appendix B, a compelling here-and-now example of the need for business decision management in the new regulatory compliance regime affecting banks around the world.

I also would like to acknowledge most helpful interactions with Nick Broom, Falko Menge, Will Thomas, Ron Ross, Denis Gagne, and Carol Leyba.  Thanks to all of you.

A Final Word

Finally, let me say that many of the reviewer comments took issue with certain details of the DMN standard itself.  I myself do not agree with everything in the spec, nor, I am quite sure, does anyone else on the drafting committee.  The standard is based on compromise, give and take among many intelligent and strong-willed individuals.  But I have tried in the book to present DMN as it actually is specified, not as I wish it were specified.  Even the Method and Style recommendations are intended to be layered on top of the rules of the specification, not calls to disregard or rewrite parts of the spec.  DMN will surely evolve, and OMG provides an open process for all to participate in that evolution.

Bruce Silver

Pasadena, CA, January, 2016

[1] http://www.omg.org

[2] A  Live Catalog of DMN Supporting Tools may be found at  http://openjvm.jvmhost.net/DMNtools/

[3] DRD comes from a FICO methodology called Decision Requirements Analysis, detailed by Alan Fish in his book Knowledge Automation.  Fish is co-chair of the DMN task force in OMG.

[4] Bruce Silver, BPMN Method and Style 2nd edition (Aptos: Cody-Cassidy Press, 2011), http://www.amazon.com/dp/0982368119/

[5] Now Sapiens DECISION

[6] Barbara von Halle and Larry Goldberg, The Decision Model (Boca Raton: Taylor and Francis, 2010), http://www.amazon.com/dp/1420082817/

[7] https://www.linkedin.com/groups/4225568

[8] I’m not the only one who was confused.  Most first-generation tools also omit the ability to reference variables in decision table cells, and they ignore boxed expressions, which I have come to understand as an essential part of the DMN “notation.”

[9] http://www.brcommunity.com/b618.php

[10] http://www.brsolutions.com/downloads/TableSpeak%20Primer.pdf

[11] von Halle and Goldberg, The Decision Model

[12] Alan Fish, Knowledge Automation: How to Implement Decision Management in Business Processes (Wiley Corporate F&A, Kindle Edition, 2012)

[13] https://dmcommunity.wordpress.com/