DMN Demystified, Part 2. Key Element 1: Decision Requirements Diagram
Blog: Method & Style (Bruce Silver)
The one part of the spec that every DMN tool supports is the Decision Requirements Diagram, or DRD. It provides a business-friendly picture of the dependencies of a high-level business decision on supporting information. Rectangles in the diagram represent decision nodes. A decision has a name (the label in the rectangle) and a value determined by the node’s decision logic, or value expression, such as a decision table.
In a DRD, the solid arrows into each decision represent its information requirements, either a supporting decision or an input data element, the oval shape. Only data referenced by an information requirement may be referenced by a decision’s value expression. So you can think of DRD as a decomposition of a complex business decision into a network of simpler supporting decisions.
The decisions, input data elements, and information requirements together define the overall decision logic structure. So what is all that other stuff?
The rectangles with the clipped corners are called business knowledge models, or BKMs. They have two purposes, one generally accepted, the other controversial. The generally accepted use of a BKM is as a reusable bit of decision logic, modeled as a function of one or more parameters. It can be invoked by multiple decisions that map their own inputs to the BKM parameters. Reusable logic is good, and everyone is happy with that. The controversial use is as a “domain of knowledge,” a bit of FICO methodology that snuck into the DMN spec by way of a detailed Lending decision example, from which this diagram is taken. Some folks love it, but most think it adds a lot of unnecessary complexity to the logic and clutter to the diagram. The tool I am using in my DMN training doesn’t even support BKMs.
The shapes with the wavy bottoms are knowledge sources. These are effectively annotations of the diagram, linking a decision or BKM to some authority: a policy document, analytics model, or named expert, whatever. It’s background info for the decision logic.
A DRD may also depict a decision service as a rounded rectangle enclosing a group of decision nodes intended to be executed as an atomic unit. Decision services are not compositional elements in the DRD, but overlays that reveal an implementation of the logic.
What makes DRDs different from, say, a Rule Family in The Decision Model by von Halle and Goldberg, is that a DRD extends beyond a single decision service. It can represent an extended business decision executed in multiple steps separated in time. It may even include human decisions and external decisions (i.e., logic defined and executed outside of the decision model).
Thus, a DRD is capable of representing the business decision as a whole. The DMN spec and its examples do not exploit this capability, but it is a critical underpinning of DMN Method and Style.
The post DMN Demystified, Part 2. Key Element 1: Decision Requirements Diagram appeared first on Method and Style.
Leave a Comment
You must be logged in to post a comment.
