One of the characteristics of the Decision Model and Notion (DMN) standard, is the use of Information Requirements links – solid arrows – linking Input Data and Decisions to Decisions. These Information Requirement links show dependency – the Decision at the pointy end depends on the information at the blunt end, whether that is Input Data or data produced by making another Decision.

We often talk about these requirements in terms of inputs or data flows – the data from the Input Data flows into the Decision that needs it or the output of a Sub-Decision flows into another Decision. Because of this, and because these links look so much like the arrows in a process or workflow, some modelers think of them as a way of ordering decisions – sequence.

It’s important to stay focused on dependency, not sequence, when building decision models. Just because Decision B is made after Decision A, does not mean that Decision B depends on Decision A. A dependency in DMN means that the way the Decision B is made DEPENDS ON that that information – it is REQUIRED because it changes the outcome of the decision. It is not enough that the Decision A is generally, typically or even always made first – there must be something about the Decision B that works differently based on the output of the first decision.

The problem comes up when eliciting models, or extracting them from documentation, decisions are often described sequentially. A document must sequence the pieces of the decision so they can be described and subject matter experts must do their work in some order. As a result, there’s an implicit sequence.

For instance, an SME describing how to calculate a Driver Eligibility Score for car insurance might say “I take the driver information from the application. First I figure out the age category they are in, then I categorize their driving record and then see what training certification they have. Based on those, I figure out their eligibility rating and finally their eligibility score.

This then gets modeled, incorrectly, like in Figure 01.

If the analyst pushes back, however, they will likely find that the dependencies are different. The SME may acknowledge that the first three steps are all made directly from the driver details.

Furthermore, driver eligibility relies on the intersection of age categories and training certification. As a result, a model like this one based on dependence and not sequence is much more appropriate (Figure 02).

Why is this so important. Sticking to dependencies has a number of advantages:

You maximize reuse by minimizing dependencies – you want as few as possible but no fewer. If a decision can be made with a small set of data, then it should be. Linking it to information it does not need reduces the circumstances in which it can be made and means it can only be reused in a context where that additional data is available. You might, for instance, have a situation where you need to determine only a driver’s driving record category. Having to calculate their age category first, as the initial model implied, adds unnecessary complexity as it can be determined solely from driver information.

Focusing on dependencies keeps the model declarative. This example decision can be made for any driver at any time. When a policy is being applied for, it might be made several times because there are multiple drivers on the policy. However, these are independent decisions and should be managed as such.

If sequence matters, that should be managed somewhere else such as in a process model. It’s common to expose multiple decision services for use at different points in a process so that, for instance, a decision of loan eligibility is called early in a process while the larger decision to underwrite (which includes eligibility as well as other elements) is only called later. This allows, for instance, expensive data such as a credit report not to be purchased for those who are clearly ineligible.

By limiting the dependencies for a decision you allow it to be executed in the widest set of circumstances. Running all the decisions you can creates a richer set of log data. For instance, running all the eligibility sub-decisions might find multiple problems with a profile while running them in sequence stops at the first one.

When building decision models, only model dependency not sequence.