What is a Decision Graph and why is it needed?

In our last post, we discussed why you should model and manage business decisions explicitly. Simply put, it's because they are the most valuable entity in your organization. Now, the next question is how to model business decisions. Some techniques allow you to model decisions, but in principle, and at its core, you need to be able to:

  • Represent multi-step decisions
  • Specify relations and dependencies
  • Decompose a complex decision
  • Incorporate predictive, rule-base, data-driven, and multiple other techniques in a model
  • Execute a model to create outcomes

Different techniques such as Influence Diagrams, Decision Trees, Decision Requirements Diagram, Bayesian Networks, and Ishikawa Diagrams can either:

  • Be too specific for a very narrow problem space, and cannot be used in every decision-making scenario (such as Ishikawa Diagrams) or ;
  • Allow generic ways of modeling decisions that become too hard to understand for a complex decision-making scenario (such as Influence Diagrams) or;
  • Oversimplify the decisioning scenario too much and not cover the whole picture, and if you force it to, it becomes too big and complex too soon, or you need to leave out certain aspects of the decision such as Decision Requirements Diagram or DRD).

In addition, neither can support all of the five core principles you need to model a complete decision-making scenario. This is why people fall back into other modeling techniques such as process, flowchart, etc.

We created a modeling technique called “Decision Graph” to address these challenges. This technique lets you model complex decision-making scenarios covering the five core principles. Additionally, it is generic enough to be applied in every type of decision and supports multiple decision layers to avoid building up complexity in modeling.

How do you model Business Decisions using a Decision Graph?

In short, modeling a decision, or framing business decisions, as it's called, allows you to decompose a complex decision. That is, a technique to break a complex decision into smaller, more manageable units of decision-making. In doing that, you will specify the relationships between those units, their PKI, and their data requirements and circumstances around each of them.

Frame the Business Decision

In this step, you decompose and define the relation between the decision units. We have already covered the main part of decomposition techniques in our Time for Framing Decisions Systematically article.

Decision Graph of a Rapid Dispute Recovery

Decision Graph that integrates multiple decision logic as well as a Sub-Graph

Once you have completed the Decision Graph model, you must consider the decision unit types. Based on the nature of each specific unit, you can use different decisioning models such as rule-based, optimization (CP, MIP, etc.), Machine Learning (ML), decision-making workflows, and so on.

Define Data Requirements

As part of the Decision Graph, each decision unit may need some form of input and supporting reference data.

The structure of the required data – either input or supporting reference data – should be modeled and, potentially, validated before calling to a Decision Graph. You can specify the required data using Fact Concept modeling. Once the data structure is defined, they can receive and collect data.

Fact Concept Diagram, which can be used to model business decisions

In the Decision Requirements Diagram of DMN, input data can be received by defining Input Data elements.

Input Data is a good way to collect the actor's input (user, system, etc.); however, DMN and DRD have no options for supporting data references. Yes, you can define it as Data Input, but that means you need to load all the potentially required data upfront and pass it around in the network to decision services whether they are used or not.

More importantly, the consumer of the decision (or decision service) may not have access to the supporting data. Supporting data comes from internal systems and processes that are not visible to and accessible by the consumer of a service.

Define Circumstances

Decisions (i.e., the decision graph and its units) don't execute in a vacuum. All decision nodes in a decision graph may not need to be executed – it depends on their defined circumstances.

The Decision Requirements Diagram of DMN is very limited in these aspects, not allowing specifying the circumstances. Hence, all the decisions are executed. The best way to define them is by using conditions in rules at the implementation level in DMN, which means decision nodes on DRD will be executed anyway.

What if a dependent decision changes the circumstances, and you don't need to execute a decision node anyway? Well, that's not possible in DMN!

Using a Decision Graph, you can specify circumstances to control when and why a decision unit should be executed.

Book a Custom Demo

First or last name is too short

Identify and Define KPIs

One of the significant differences between business rules and business decisions is that KPIs for rules are irrelevant, and therefore have no context. But business decisions do, and they should define the expectation of the decision and the success (or failure) metrics around them. In layman's terms, what is a good or bad outcome of a decision in that context? This leads to the need to specify metrics around units of a Decision Graph.


There are many ways to model business decisions using different techniques, but each lacks one or more parts of how organizations must define and manage business decisions successfully.

For this reason, we created a modeling technique inspired by other approaches to frame business decisions. We did so from scratch as improving existing approaches produced sub-optimal outcomes.

A Decision Graph ensures there is no lack of critical components for capturing the efficiency and effectiveness of business decisions and their execution at scale.

Last updated June 6th, 2024 at 02:37 pm Published February 15th, 2024 at 12:23 pm