In my book DMN Method and Style I find some fault with both The Decision Model (TDM) and the Lending example in the DMN 1.1 spec for delegating definition of a multi-step business decision to a BPMN process model instead of to where it rightfully belongs, a DMN decision model. To me, determining something like Is the loan approved or declined? is a single business decision, whether implemented as a single decision service or split into multiple steps. However, the notion of such a “business decision as a whole” appears not once in either the TDM book or the DMN spec. In the DMN Method, the business decision as a whole is represented by a single DRD with one top-level decision node representing the final outcome, in this case approved or declined. It can always be modeled that way, even if – as in the spec example – it is implemented as up to three steps:
- A prequalification step, without credit score, ruling out certain applicants
- An automated decision step, including the credit score, that approves or declines the majority of applicants
- A human adjudication step to decide on the borderline cases
The DMN Method provides a systematic approach to decomposing any business decision into a DRD and then defining the logic of each decision node. While a multi-step implementation of the decision as a whole affects the decomposition of the DRD, it does not change the fact that the DRD must have a single top-level decision node representing whether the loan is approved or declined. In the spec example – and I presume this would be TDM’s preference as well – there is no single decision for that, just a BPMN process with Approved and Declined end states and a variety of paths to reach them. In those methodologies, all three decisions are effectively “routing decisions.” Their purpose is to determine the paths out of gateways in the BPMN model, which is the “real” end-to-end decision logic.
In the book I am generally dismissive of the idea that DMN’s main purpose is routing decisions, but in the course of DMN training and consulting I have discovered that there are occasions where there is no business decision as a whole, but instead a business process in which DMN plays a key role in defining the gateway logic. This is the use case, often cited, in which the BPMN contains endless chains of gateways, effectively decision trees embedded in the process logic. These can be improved by replacing each of those chains with a decision task followed by a single gateway. The result is a process model that is simpler to define, easier to understand, and more easily maintained. Such routing decisions indeed must be considered by the DMN Method.
In those cases, the routing decision becomes the decision as a whole. It is represented by a DRD in which the top-level decision node is the routing decision. In the associated BPMN model, it is represented by a decision task followed by a single gateway. Each gate on that gateway leads to a different next activity or end state. N possible next steps corresponds to N gates on the gateway, and N possible values of the routing decision. The enumerated values of the top-level decision in the DRD should be easily related to the gate labels in the BPMN. The chain of gateways, or embedded decision tree, in the original BPMN defines the logic of the routing decision, typically modeled as a decision table. The input data of the routing decision represent elements that must be obtained by process activities prior to executing the routing decision task. Often the weak link in the process is getting that input data and possibly mapping it to a form used in the decision logic. In that way, using DMN Method to model routing decisions can go a long way in making your process models better.
For more information on the DMN Method, check out DMN Method and Style and our Signavio-based DMN training and certification. We have a public live-online class March 29-31, with a special 30% discount. Check it out!