Our DMN 2.0 Wish List II: Decision Requirements
Blog: Lux Magi - Decision Management for Finance
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?” was a common subject of conversation. We found that our respective wish lists had a lot in common, reflecting our views on decision modeling best practice, so we elected to describe these proposed new features in our book and summarize some of them here.
We’ve already explained our wishes for the decision logic level of the standard. Here we consider the requirements level.
DMN (The Decision Model and Notation) is a way of representing Decision Models using diagrams and text, it does not address issues such as method or approach, therefore wishes must be constrained to notational items. 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
One of the key aspects of DMN is Decision Requirement Diagram (DRD) which represents dependencies between the components of a decision model: decisions, Input Data, Knowledge Sources and Business Knowledge Models.
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 Input Data.
One drawback of the DRD defined by DMN is its inability to express the cardinality of this dependency. In other words to depict that multiple instances of a decision may be required to handle a single, composite element of data (i.e., a collection Input Data or a decision that yields a collection) or vice versa. We propose an additional DRD notation to represent ‘fan in’ and ‘fan out’ of information
requirements using BPMN’s ‘multi instance’ marker. In the example DRD below, a decision Eligible Products (note the convention that a plural name denotes the outcome of an homogeneous collection of data items) yields a collection of products each of which must be separately considered by the Cost Product decision. Therefore multiple instances of this decision will be needed.We term this fan-out (see example diagram).
Conversely DRDs cannot show that multiple elements of data are aggregated into a single result by a decision. A simple example of this is the notation of an iterative decision that depends on a collection of inputs and iterates through each member. The DMN logic level can support this (with an aggregation function or aggregating hit policy), how should a DRD represent it? One possible method is shown below, again using the multi-instance marker.
Supplementary Information Marker (Ellipsis)
An important part of a decision model is a network of decision components connected by dependencies: a Decision Requirements Graph (DRG). Each Decision Requirement Diagram (DRD) shows (a potentially overlapping) subset of these dependencies—a visual view of part of a decision model. Given this, it would be useful to depict visually that a component is involved in dependencies that are not shown on a specific DRD. Consider an example of a Decision Requirements Graph (‘A’) and three separate DRDs in the diagram below. DRDs ‘B’, ‘C’ and ‘D’ are subsets of the DRG and the ellipses signify the missing child and parent nodes respectively. The standard refers to the concept of this ellipsis but does not nominate a visual representation—we think it should.
An even similar 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 ‘missing’ 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 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 potential reuse, many decision models become a sea of decision/BKM pairs, doubling the model size. We would like to see the concept of decision and BKM combined—we think any decision should be subject to parameterized invocation and that the distinction between decision and BKM is currently too fine to be useful.
Conclusion
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?
Leave a Comment
You must be logged in to post a comment.
