When James Taylor and I began our collaboration on our new book ‘Real World Decision Modeling with DMN’ it begged the question: ‘Why is a book on DMN necessary? After all there is a well-documented specification.’
The Decision Model and Notation (DMN) standard—a document defined and published by the Object Management Group (OMG)—does define the notation, so why is a book on Decision Modeling, and specifically DMN, needed? What can it do that the specification cannot? What should users of DMN be aware of that the specification cannot tell them?
What’s Wrong with the DMN Spec?
Actually, very little; the specification is, as standards go, an articulate, easy to reference and well-structured document. It should be—The OMG is an international, technology standards consortium specializing in the development and custodianship of standard notations used by businesses in over twenty market verticals. The vendor team behind the DMN specification includes Decision Management Solutions, Fair Isaac Corporation (FICO), IBM, Knowledge Partners International, Oracle and TIBCO Software Inc. This represents an enormous amount of collective experience in Decision Modeling.
In fact the specification acquits itself admirably, it:
- Is precise. The specification document makes frequent use of formal (and unavoidably technical) terms to describe the concepts of decision modeling concisely. It has many meta-models to accurately define the relationships between these concepts. Its contents are laid out in dependency order, introducing underlying technical concepts and normative references before considering the notation and expression grammar in detail.
- Provides a focused definition, relevant to its audience. The specification defines the standard, the criteria for measuring conformance to that standard and its data interchange formats chiefly for the benefit of tool vendors. It defines the form of decision models in great detail, but has little to say about their application.
- Is a professional reference work, not an introduction. The specification assumes the reader has some technical knowledge (exposure to UML, language grammar and the fundamentals of data structures) and provides little introduction to decision modeling. It does not consider the rationale and origin of decision modeling or justify DMN’s features. Although some examples are provided, these are just big enough to illustrate notational concepts and not the practical ramifications of using DMN at scale.
In short the specification serves its purpose well. The brevity and technical focus of effective standards’ documentation is essential if they are to be of use to their intended audience and provide a lean definition. However, this focus can mean that such documents are intimidating for some end users of the specification—notably: business analysts, subject matter experts and stakeholders.
Why Write a Book?
A book on applying decision modeling using DMN can supplement a standard by:
- Providing a user oriented view. By tailoring the text of the book to a business audience, removing the tool implementation detail and technical focus of the standard, a book can make DMN much more accessible and valuable to business subject matter experts and policy owners—DMN’s core users. Omitting IT centric detail avoids alienating business audiences and leaves more room to present issues of importance to them and provide realistic examples to illustrate these points.
- Explaining what it is why it should be used. By means of a business-oriented discussion of the definition and business case for decision modeling in general and DMN in particular it can provide informed incentive to apply DMN.
- Explaining when to use it. By detailing the key indicators that reveal when DMN is best used and how to recognize those situations when it should be avoided, a book can help ensure that the technique is applied judiciously.
- Explaining how to use it. A notation is of little use without some guidelines describing how it should be applied. These can be: descriptions of appropriate methods for decision discovery and analysis; details of DMN patterns—combinations of techniques for solving frequently occurring problems—and tips for integrating DMN with other modeling standards (e.g., UML, BPMN and ArchiMate). Such advice can help practitioners to maximize the benefit of using the standard and avoid common pitfalls.
- Providing an experienced viewpoint. By bringing additional, pragmatic knowledge of how to scale the use of DMN in larger projects and illustrating this with realistically sized examples a book can describe how DMN works in practice. Perhaps the most effective advice that can be provided is a series of decision modeling best practices garnered from years of applying the standard.
- Supplying additional insight. By describing decision modeling features that are not supported by the standard, but which have contributed significantly to projects, a book can prepare DMN users for more advanced challenges they are likely to face. In addition, this insight can instruct users on which of DMN’s features to use sparingly—a few have adverse effects in certain circumstances.
- Advising on adoption. By making specific recommendations on how to build practitioner teams within a company and how to select the most appropriate toolset, a book can facilitate a rapid and successful enterprise adoption of the standard.
James and I have included all of this in our book and we hope that our experience of using DMN can benefit others. Little of this content is appropriate for inclusion in a standards document of course, but all of it is important to help business users to understand, become proficient in and get the most from decision modeling.
A good book, with the content described above, should virtually replace the standard specification document for business users: becoming the dominant reference work for all but the most specific and technical inquiries. Equally important it should encourage wide spread use of the standard so that many organisations can benefit from explicit management of their decision assets.