Decision Modelling
Decision modelling shows how repeatable business decisions get made: the ones that recur, that follow rules and that apply to the same set of data. A decision model combines three elements, the decision itself, the information it consumes and the knowledge, meaning the business rules that govern it. A simple decision is captured by a single table or a single tree; a complex decision breaks down into linked sub-decisions, each described separately, which is what a decision requirements diagram carries. Decisions are rarely made in isolation and modelling them serves as much to make a decision explicit and maintainable as to frame, upstream, the ones that warrant analysis. Decision modelling therefore comes in three representations and the choice between them turns on the shape of the decision: a decision table and a decision tree describe a single decision, a decision requirements diagram structures a network of linked decisions.
Goal
Decision modelling makes explicit how a repeatable business decision is made, separating the decision logic, the rules and the data they query from the process that invokes the decision. The deliverable is a model of the decision, drawn to the chosen level of detail, that a stakeholder can read, that lends itself to impact analysis and that outlives the person who makes the decision from memory today. It answers a precise question: how is this decision made, from which inputs, under which rules and on whose authority.
The BABOK frames every approach to decision modelling around three elements. The decision is the question to settle and its answer. The information is the set of data the decision consumes as input. The knowledge is the body of business rules that, applied to the information, produces the answer. These rules are of two kinds: a definitional rule fixes what is true by construction, for example that a tax is calculated correctly; a behavioural rule constrains what must happen, for example that a billing address matches the credit card presented. This shared vocabulary is what the three representations have in common, whatever their form.
A single model serves several uses. It documents a decision made by hand, it feeds a rules-based automation and it frames, upstream, a piece of data-mining or predictive-analytics work. Decisions are rarely made in isolation: many sit in a chain where each conditions the next, so modelling them also serves to spot the ones that warrant analysis and to check that they align with strategy, before committing the data. At the scale of the organisation, a comprehensive decision model ties these decisions to processes, to performance measures and to the units that own their rules.
When to choose which technique
A single question separates the three representations: does the decision fit in one representation or must it be broken down into a network? A decision made in one step is captured by a decision table or a decision tree. A complex decision, one that can be split into sub-decisions that depend on one another, is structured by a decision requirements diagram, where each sub-decision is described separately and linked to those it depends on.
When the decision is a single one, the choice turns on the shape of its logic and settles between the decision table and the decision tree. The BABOK notes that trees are in common use in some sectors but markedly less widespread than tables and that they are particularly effective for certain kinds of rule, segmentation rules first among them.
The decision requirements diagram operates at a different level. A table and a tree say how a given decision is made; the diagram shows how several decisions hold together, which one feeds another and where the authority for their rules comes from. That is its distinctive contribution: where the table and the tree stay at the scale of one atomic decision, the diagram frames the whole and makes visible the dependencies that link the decisions. Its elements pick up one by one the three elements of any decision model, the decision, the information it consumes and the knowledge that governs it, plus the source of that knowledge. This is why a decision requirements diagram frequently houses tables and trees at the point where it refers to the logic of each decision.
| Representation | Choose it when | Shape of the decision |
|---|---|---|
| Decision table | An atomic decision governed by many combinations of conditions over the same set of data, to be covered exhaustively and verifiably. | One decision, many rules, tabular form. |
| Decision tree | A decision whose rules share conditions and read as a chain of branches, typically a customer segmentation. | One decision, shared conditions, branching form. |
| Decision requirements diagram | A complex decision to break down into interdependent sub-decisions, showing the information and knowledge each one depends on. | Several linked decisions, network form. |
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17 Decision Modelling.
- IIBA, Guide to Business Data Analytics, §3.8 Decision Modelling and Analysis: the perspective that places a decision within a chain of decisions at enterprise scale.
- OMG, Decision Model and Notation (DMN): the industry-standard notation behind the decision requirements diagram and decision modelling in general.