Book Review: Real World Decision Modeling With DMN By James Taylor & Jan Purchase

Real World Decision Modeling As many readers will know, business rules are playing a growing role in the analysis of processes and in the development of automated business applications. To facilitate this, the Object Management Group (OMG) has recently released a Decision Modeling Notation (DMN). To help practitioners understand the uses and implications of this new modeling notation, James Taylor and Jan Purchase, two leaders in the field of business decision analysis and design have published a new book, Real-World Decision Modeling with DMN. I saw an early copy at the recent BBC Conference in Las Vegas, and wanted to do a review. Given the season, time was short so the authors and I agreed on a unique approach – I would ask questions and they would provide short answers. Here are my questions and answers by Taylor and Purchase.

What is Decision Modeling?

A decision is a determination made during business operations, often many times a day. Some examples are: “what up-sell products can I offer this customer?”, “which sidebar content should we display to an old client who is returning to our website?”, “Should we fast-track or reject this insurance claim?” or “can we rent a car to this client?”. These decisions address a single question and provide a definitive answer. They are repeatable and directly impact customers or business participants. They can be made by humans or be automated.

Decision modeling involves expressing these decisions in an accurate, transparent, unambiguous and (potentially) executable format. It involves decomposing a decision into its component pieces or sub-decisions and then modeling the requirements for each such decision in terms of the information that must be available to make the decision and the knowledge required to do so. Because decision-making is part of the core of an organization's business operations, it also involves modeling the business context for a decision. This is important because, like processes, decisions should be managed as a corporate asset.

What’s the bottom line value of modeling a decision?
When is it useful?

Modeling decisions, whether they are automated or manual, allows them to be understood, simplified, standardized and improved. It ensures correct and rapid understanding of data requirements so that required input data (and only required data) can be provisioned. It reveals and documents the way decision-making depends on regulations, expertise and policies while allowing internal and external constraints to be understood and explicitly represented. Most importantly it ensures that the approach taken to decision-making is transparent and easily understood by everyone in an organization.

When automation of decision-making is being considered, modeling the decision eliminates error-prone translation to code and shows clearly where the automation boundary should be. Because it promotes reuse and simplicity in implementation, it improves consistency across process and between business channels. A decision model is also an effective means of integrating business rules, analytics, optimization and cognitive technology into an effective whole.

Decision modeling is most effective when decisions have: high frequency (e.g., high transaction volume, a need for real-time response), significant business value (e.g., they govern customer treatment or manage risks) and the need for transparency (e.g., they are highly complex, change frequently or need to comply to critical regulations).

What’s the difference between decisions and rules?

We get asked this a lot. Because business rules are sometimes used to define decisions these terms are often confused. The two concepts are quite different, though, and it's important for organizations to realize the distinction between them. Decisions are high profile—they produce a significant outcome or event that steers and controls a system or business process and can be encapsulated effectively as decision services. Decisions are self-contained—answering a question while resolving or managing any abnormal circumstances and exceptions internally. In contrast, rules lack visibility of 'the whole question', rarely have an individual impact, cannot handle abnormal scenarios and do not represent a deployable unit. Decisions also have business objectives and key performance indicators that they are designed to improve so their effectiveness can be measured and improved. Rules are often too small to have their effectiveness measured in this way.

In our experience, projects that focus on decisions first, taking a decision-centric approach to requirements capture and delivery, are always more successful than those that focus primarily on business rules.

How does Decision Modeling with DMN help projects?
Which of your experiences of applying decision modeling stands out most in your minds?

(Jan) I was working on a coordinated set of financial compliance projects, involving teams from four sites. One of the initiatives involved replacing a central legacy application that provided data to a large number of client applications. Decision Modeling allowed us to get to market much more quickly as it let us build an executable (and therefore testable) version of the core decision within two weeks of obtaining the specification. It also exposed errors in that specification that could be referred to the regulator. Exposing these errors and misunderstandings reduced development costs while a rigorous model of the dependencies of the decision enabled very effective impact assessment and supported rapid evolution of the solution, even as requirements changed. Most importantly, decision modeling drove business engagement because the decision model resonated with the subject matter experts in a way that business rules did not.

(James) I was working with a group of heart surgeons on a clinical decision support system. This group was able to immediately focus on and develop a decision model, taking best practice documents and guidelines that largely sat on the shelf and turning them into something actionable. The decision model let this group focus on a real business (or medical) decision, break it down without reference to technical concepts and then identify the right pieces of the decision to automate. It clarified the data they needed, showed where a medical professional was essential, and revealed much about the recommended approach that had previously been opaque.

So there is value in applying Decision modeling on its own, but what other models do decision models link with? (BPMN)?

Decisions rarely stand alone. They are often triggered by a process, motivated by specific business goals and always informed by business data. Decision models can have a stronger organizational foundations and context if there are data models to explain the information used to make decisions, process models to show when decisions are made and how their outcomes steer a business process and business motivation models to explain the performance indicators that measure decision effectiveness and who will benefit. DMN models can collaborate with UML, BPMN and business motivation models very effectively and this is described in the book.

DMN's collaboration with the Business Process and Notation (BPMN) is especially powerful. Decision models define the structure, requirements and logic of decisions and their potential outcomes. Process models describe if and when decisions are made, show how the outcome of a decision can 'steer' a business process and describe how the decision's input data is orchestrated. Decision models inject intelligence into a process model while process models provide context.

Can you sketch your method for applying DMN?

The first step is to identify the decisions that are the focus of the project. Then we strongly recommend a highly iterative approach – either within a single requirements phase or as part of an overall agile development approach. Within this iterative approach, each decision is first described with a question and allowed answers and its business and operational context is documented. An initial set of input data required by the decision and a set of knowledge sources (describing how to make the decision) are then documented. The decisions are then refined, decomposing them to identify their sub-decisions as well as new or reused input data and knowledge sources. Each new decision identified is then described, its requirements are modeled and it too is decomposed. As the model evolves, outline decision logic or examples may be documented for key decisions. The core modeling steps in this process— describing decisions, specifying their requirements, refining and iterating—repeat until the model is fit for purpose. At this point, the model can then be extended to specify complete decision logic for execution, to document detailed manual decision- making approaches or to link to other implementations.

Who is this book aimed at?

The book intends to help people in both the business and IT communities including:

  • Business analysts or subject matter experts who need to describe or review how decisions are made
  • Program or project managers responsible for efforts to automate and improve decisions
  • Architects or developers working to implement decision-making systems
  • Business strategist looking to innovate decision-making for competitive advantage

Really, anyone who needs to accurately describe decision making.

Would you give us an outline of what the book contains?

The book is designed to be really comprehensive so it provides a complete explanation of decision modeling and how it aligns with Decision Management and Digital Transformation. It describes the DMN standard focusing on the business benefits of using it. The book includes a detailed method for applying decision modeling in your organization and advice on how to select tools and start a pilot project. It contains:

  • Over 220 practical illustrations
  • 47 best practices
  • 13 common misconceptions to avoid
  • 12 patterns and approaches
  • 3 worked examples

I understand the book has 47 best practices? Which are your favorites (/most important)?

(James) When it comes to building good decision models I think the most important are always to document really specific questions for each decision you identify and to use multiple diagrams to show the different perspectives people have of decision- making. It's also really important to seek out and manage reuse as decision models have a lot of reuse.

(Jan) Decision modeling is about clear communication and my favorite best practices support this in ways that even experienced practitioners can sometimes forget. One example is the correct use of Knowledge Sources to document the connection between decisions and the externally-defined expertise and regulations that influence them. Another pivotal best practice is selecting the best means to represent a given decision: Decision Table, analytic model, optimization model, examples or some other format. It surprises many that it is not always necessary, desirable or even possible to document decision logic for all decisions.

I understand the book contains patterns? What are they, could you give an example?

Some problems and solutions recur over and over in decision modeling. The patterns chapter tries to describe some patterns seen regularly in good decision models (and some anti-patterns) and provide some “packaged” approaches for revising decision models to make them more effective. The patterns are like templates, something an experience modeler can use to improve many models in different domains when they exhibit familiar problems.

One illustration of this is the “Divide and Conquer” pattern which describes how to recognize if a single decision should be split into separate, but cooperating, parts and explains how to do this. This is a common challenge in complex decision models when individual decisions try to answer multiple questions simultaneously and become very complex as a result—so called “Swiss Army Knife” decisions. The pattern explains how to split these decisions into their components parts and how the decision becomes easier to understand, more agile and more reusable as a result.

What would be your best advice to companies exploring this technique for the first time? How should they get started?

There's an entire chapter on this in the book. You need to win business backing for decision modeling as quickly as possible. IT backing is necessary but not sufficient as business subject matter experts have to engage completely. A high level business sponsor will be needed to ensure this. The best approach is to select a pilot project that is visible, important and not obscured by risks. The business area should be well understood (using BPMN process models for instance) or have a heavy focus on automation. It should contain decisions that are repeatable, need to be applied consistently, have business value, change frequently, and are currently expensive to make or have a high cost of error. These decisions get the best results from decision modeling.

Once the pilot has demonstrated the power of the technique, the organization should build a decision modeling practice. This team should be rooted in real projects, rather than 'ivory tower' pontification. It should cut across organizational boundaries, offering help to any projects that would benefit from the technique. Decision modeling is broadly applicable and the value it brings expands greatly as it is applied to larger, interdepartmental challenges.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at

Speak Your Mind