While James Taylor and I were collaborating on our Decision Modelling book and discussing our experiences of using DMN with clients, the question “what additional features should be adopted in the next major release?” frequently arose. We found that our respective wish lists had a lot in common, reflecting our views on decision modeling best practice. We decided to describe these proposed new features in a series of posts and encourage readers to give their own opinions.
We’ve already explained our wishes for the decision logic level of the standard. Here we consider the requirements level, mainly the Decision Requirements Diagram (DRD). As with the previous article in this series, wish items were constrained to new or amended notation, not method or approach.
Given this, do you agree with our items? What features would you like to see included in the decision requirements level of the standard?
Decision Requirements Level Wish List
One of the key aspects of DMN is the Decision Requirements Graph (DRG): a network of decision model components (decisions, Input Data, Knowledge Sources and Business Knowledge Models) connected by requirement dependencies which represent the structure of a decision model. All, or part of, a DRG can be visually represented using a Decision Requirement Diagram (DRD). Typically there are many DRDs each illustrating some aspect of the model. We believe the DRD notation, as currently defined by DMN, omits some important details of a decision model.
Decision Data Cardinality (Decision Iteration)
A key DRD dependency is the Information Requirement which depicts that a decision requires data, either from a sub-decision or an Input Data component.
One drawback of the DRD defined by DMN is its inability to express the cardinality of this dependency. In other words to represent cases where:
- multiple instances of a decision are required to handle a single, composite element of data (i.e., a collection Input Data or a collection yielded by a sub-decision) by iteration (fan-out) or
- a single instance of a decision must aggregate multiple items of data (fan-in).
We propose an additional DRD notation to represent ‘fan in’ and ‘fan out’ of information
requirements borrowing BPMN’s ‘multi instance’ marker. In the first example DRD on the right, a decision Eligible Products (note the convention that a plural name denotes the outcome of an homogeneous collection of data items) yields a single collection of products each of which must be separately considered by the Cost Product decision. Therefore multiple instances of this decision will be needed—one per item. This is achieved in the logic definition with a decision that depends on a collection of inputs and iterates through each member processing it independently. The example DRD notation is enriched by the ability to show this one-to-many cardinality.
Conversely DRDs cannot show that multiple elements of data are aggregated into a single result by a decision. The DMN logic level can support this (with an aggregation function or aggregating hit policy), how should a DRD represent it? It is an important aspect of the dependency between decision components. One possible method is shown on the right, again using the multi-instance marker. Here the decision Cart Price aggregates the many outputs of the Discount Item Price decision, a single instance of which is triggered for each Item.
Supplementary Information Marker (Ellipsis)
Each Decision Requirement Diagram (DRD) shows a subset of the components and dependencies of the DRG—it is a visual view of part of the DRG. Given this, it would be useful to depict visually that a component shown in a DRD is involved in other dependencies that are not shown on this DRD. Consider an example of four separate DRDs in the diagram below. DRD ‘A’ represents the entire DRG, whereas DRDs ‘B’, ‘C’ and ‘D’ are subsets of the DRG and the ellipses signify the elided child and parent nodes respectively. The DMN standard refers to the concept of this ellipsis but does not nominate a specific visual representation like the own shown—we think it should.
An even simpler alternative is not to distinguish between missing parent and child components and to show a single ellipsis marker if any attached nodes are elided from the DRD in question. This requires tool support and could be done in a number of ways but we feel there is value in highlighting ‘hidden’ content on a DRD.
Decisions and Business Knowledge Models
A Business Knowledge Model (BKM) is a reusable element of business logic invoked by a decision. BKMs support the parametrized reuse of decisions. BKMs have their own symbol, dependency relationship and invocation rules but are very close to decisions in many other respects. The trouble is, in the interest of supporting potential reuse, many decision models become a sea of decision/BKM pairs, doubling the size of the DRD. We think the concepts of decision and BKM should be combined and represented as a single symbol in a DRD. Surely any decision should be subject to parameterized invocation and that the distinction between decision and BKM is currently too fine to be useful. Use the decision symbol to represent both concepts and retain the knowledge requirement relation to denote invocation only when needed.
We hope you found these interesting and that you had a chance to read our wishes for additional features in the Decision Logic level of the DMN. Meanwhile, we would be interested to hear your views: what additional features would you like to see in DMN?