4 motivations for using Decision Models and DMN

I have trained a lot of practitioners in the Decision Model and Notation (DMN) – I am closing in on 1,000 decision modeling trainees now – and one of the interesting questions is always their motivation for using decision models. As I look back across all the folks I have trained, four motivations seem to bubble to the top:

1. Too many analytic projects go awry and they need a way to frame requirements for analytic projects to tie analytics to business outcomes
2. They struggle with a “big bucket of rules” in their Business Rules Management System (BRMS) and need a better way to capture, manage and structure those rules
3. They need clarity and consistency in how they make (or want to make) decisions that are likely to be only partially automated
4. They need an executable representation of decision-making

These motivations have three things in common:

1. They need to visually communicate their intent to a wide group of stakeholders, some of whom did not build the model
2. They need a broad group of people – business experts, business analysts, data scientists, programmers and others – to be able to collaborate on the model
3. They have tried using documents (requirements, lists of rules, spreadsheets) before but have found them inadequate

Decision models built using the DMN notation and a decent approach (such as the one Jan and I describe in Real-World Decision Modeling with DMN) deliver. DMN Decision Requirements models are easy for a wide group of people to collaborate on and clearly communicate the structure of decision-making. Combined with either DMN Decision Logic models or executable rule artifacts in a BRMS, they manage decision logic effectively and are an executable representation of your decision-making.

Now, there are those that feel like the motivation for decision models is almost always a desire for an executable representation – that only a decision model that is complete and executable is really useful. While this may be true of BPMN tool vendors – who need executable DMN to make their process models go – it is far from true among decision modelers more generally. In fact in our training and consulting projects we see more projects where a decision requirements model alone is tremendously useful than anything else.

Among those who want execution there is a split also: Some want the model to be 100% executable – to be able to generate code from it. Others prefer (as I do personally) to link a business friendly logical model to executable elements in a more loosely coupled way. This allows the business to keep things in the requirements model that are not executable (such as how people should decide to consume the result or characterize an input) while IT can make some performance or platform-specific tweaks that don’t have to show up in the logical model. The cores are linked (most decisions in the model have an executable representation in a BRMS that is editable by the same people who edit the model) but not everything has to be.

Whether you like the “press the big red button” approach that generates code from a DMN model or a blended DMN + BRMS model for execution, never forget all the other use cases where clarity, collaboration, consistency and structure matter even though execution doesn’t. There is a wide range of valuable use cases for DMN – it’s not just about executable models.

Prompted by an interesting post by Bruce Silver called DMN and BPMN: Common Motivation, Different Outcome?