The Decision Model and Notation (DMN) standard from the Object Management Group (OMG) defines a language for decision models. A decision model describes graphically – through diagrams and tables – both the logical structure of a business decision, called decision requirements, and the rules and formulas for each logic element. That makes the decision logic transparent and maintainable by business.
DMN decision models are meant to be created by business, not IT. The diagrams are easy to draw and understand. Unlike the text-based requirements documents of traditional business rules projects, they engage subject matter experts, help them understand the bigger picture, and make them not only willing but eager to participate in the project.
DMN is a powerful language. While it is possible to use DMN only to create decision requirements handed off to IT for implementation in a traditional rule language, DMN is capable of defining the complete decision logic itself, down to the finest details.
What’s more, DMN models are directly executable on a native automation engine. If the model is complete, there is no need to hand it off to programmers for interpretation and translation into the language of a business rule engine. And as an industry standard, DMN’s notation, syntax, and operational semantics are defined in an open specification, so it works the same in any tool. Models may even be interchanged between tools using a standard XML format.
Unification of decision modeling and execution is a big deal. With DMN, the decision model is both the requirements and the implementation. That means one language, one repository, one source of truth. Thus, DMN breaks down the barriers between business and IT that have long hampered business rules projects, fostering a closer, more agile collaboration between those groups.
I need to say something here about the importance of executability. You might hear some people insist that business users should go nowhere near executable decision logic. That’s just nonsense. I’m not saying business users are going to create models and deploy them into production on their own with zero IT involvement. You’re still going to need IT for testing, staging, deployment, all that DevOps stuff. But if you want business users to specify decision logic that actually works, they need to be able to test it themselves, to see that the results, upon execution, make sense. In the end, a DMN tool that cannot do that doesn’t realize the true promise.
Many of these characteristics of DMN, while they seem obvious today, were not apparent to me in 2016 when I published the first edition of DMN Method and Style. At that time, version 1.1 of the standard had just been finalized and was being readied for public release. The basic features of the language – the graphical notation, the FEEL expression language – were little changed from DMN 1.0, but bugs in the original metamodel and schema had until that point made executable implementation impossible.
The field was now wide open for implementation and for explanation to the world. The DMN specification was dense and near impenetrable, but as a member of the DMN task force in OMG I had a good understanding of it, and there were no serious DMN books yet available. It seemed like a good time to write one.
But in reality, it was not. It’s one thing for a standard to be implementable and quite another to have tools that implement it properly. The best tools at that time didn’t follow the spec. They omitted important elements of the Decision Requirements Diagram (DRD), used their own syntax for decision tables, and ignored the FEEL expression language entirely. Worse, they couldn’t execute what they modeled. The examples in the book suffered mightily as a result.
And I can’t even blame it all on the tools. My own experience in decision modeling at that time was too limited to provide practical advice. My main business is actually training in process and decision modeling, and since that time I’ve learned a lot more about DMN: what works, what doesn’t, what business users can handle.
One thing that became apparent is that while DMN can create and execute complex and powerful decision logic using low-code graphical tools, today few “business rules people” are prepared to do that. It’s not really programming, and business analysts, business architects, and plain old business users can learn to do it, but in the near term, most models that fully exploit the power of DMN and FEEL will likely be created by technical modelers and programmers. As a consequence, earlier this year, Edson Tirelli and I wrote the DMN Cookbook[1] aimed at those users, a compendium of DMN recipes and tricks to do just about anything you’d want to tackle in decision logic. Edson is the Drools project lead, creator of the runtime used in DMN software from Trisotech, Red Hat, and other vendors as well.
But DMN’s target user population is not technical modelers and programmers. It’s business users, and I needed to make good on what I tried to do the first time with DMN Method and Style. The second edition is a complete rewrite. It is based on DMN 1.2, just finalized and being prepped now for public release. Fortunately, this time the tool I’m using – Trisotech Decision Modeler[2] – incorporates all the latest features, including decision services, model import, enhanced iteration, new FEEL functions, and generalized unary tests – and can execute everything it can model. That’s a wonderful thing.
DMN Method and Style 2nd Edition bears little resemblance to the original. It actually follows the outline and many of the examples of my DMN Method and Style training[3]. If you’re someone who can learn from books, there’s no need for you to take the training. It’s all in the book.
Most folks can’t do that, however, so the training adds things they need to become competent at DMN: hands-on exercises using a DMN tool, a quiz at the end of each section, and post-class certification. Certification is based on an online exam and a mail-in exercise reviewed by me, which students must iterate until it is perfect. I’ve trained over 4000 students in process and decision modeling since 2007, and post-class certification is the one thing proven to let the training “sink in.” The training is available both web/on-demand and live/onsite. For more details, go to methodandstyle.com.
Even if you’re not ready for training, I strongly urge you to get a good DMN tool and try your hand at decision modeling. You can get a free 7-day trial of the Trisotech tool by going to www.trisotech.com/methodandstyletrial.
Outline of the Book
The first ten chapters roughly follow the outline of the DMN Method and Style Basics training. Subsequent chapters follow the outline of DMN Method and Style Advanced.
Chapter 1 explains the concepts and objectives of business decision management, the business value of decision modeling, and the evolution from traditional business rules to DMN and machine learning.
Chapter 2 explains the basic elements of DMN, including the decision requirements diagram (DRD), decision tables and other boxed expressions, and DMN’s standard expression language FEEL.
Chapter 3 drills into the DRD and the mechanics of modeling decision requirements.
Chapter 4 discusses modeling decision logic with an emphasis on decision tables, and briefly outlines DMN’s other expression types, including literal expressions and invocation.
Chapter 5 shows how to improve BPMN process models by converting a chain of gateways to a decision task and linking that to a DMN decision model.
Chapter 6 discusses decision table hit policy, which specifies how to select the decision table output value when multiple rules match.
Chapter 7 discusses elements of decision table “style” – completeness, consistency, maximum contraction, etc. – and how to use Decision Table Analysis to find style errors in your model.
Chapter 8 discusses data modeling and logic reuse, including the importance of creating and assigning item definitions (named datatypes) to decisions and input data, and documenting variables and types in a business glossary for standardization and reuse.
Chapter 9 discusses the benefits and techniques of classification decisions, which play a major role in decision modeling.
Chapter 10 highlights a new feature of DMN 1.2, decision services, with emphasis on three important usage patterns.
Chapter 11 begins the “advanced” content, with emphasis on FEEL and additional boxed expressions.
Chapter 12 covers literal expressions, including FEEL string and number functions.
Chapter 13 discusses contexts, a boxed expression type that lets you simplify decision logic without proliferating DRD elements.
Chapter 14 covers dates, times, and calendar arithmetic.
Chapter 15 covers handling lists and tables, a key strength of FEEL.
Acknowledgments
This book would not have been possible without the efforts of Trisotech and Red Hat to create a tool that is not only faithful to the DMN standard but makes it easy to use through a great user interface and additional whole product features. To Denis Gagne, Simon Ringuette, Melanie Gauthier, and the rest of the Trisotech team, thank you. I could not have wished for better partners. The same goes for Edson Tirelli, Matteo Mortari, and the rest of the Red Hat team. Your software just plain works!
I also must acknowledge other members of the DMN task force in OMG, including Gary Hallmark, Alan Fish, James Taylor, and Falko Menge, whose efforts continue to improve the standard, as well as the tremendous accomplishment of Keith Swenson in establishing the DMN TCK and making its work the gold standard in assuring DMN conformance.
Thanks also to Carol Leyba for cover design and other assistance.
Bruce Silver
Pasadena, CA, September 2018
[1] Silver and Tirelli, DMN Cookbook (Altadena: Cody-Cassidy Press 2018), https://www.amazon.com/ dp/0982368186
[2] www.trisotech.com
[3] https://methodandstyle.com/training/dmn-training/