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
Possible notation for DMN fan out
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.
DMN possible notation for fan-in
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.
DMN ellipsis notation
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.
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?
I agree strongly with the spirit of the suggestions: more info visible in the DRD rather than hidden inside the value expressions. Re the fan-in and fan-out, I think the ideas there are iteration and aggregation. I think putting the MI symbol inside the decision suggests iteration more clearly. For aggregation, maybe better to reuse the hit policy aggregation symbols, like + for sum, etc., and put that in top left corner. Then you could have a single decision that iterates then aggregates the result.
Bruce, thanks very much for the feedback. I agree that the DRD is currently leaving out a lot of interesting and relevant detail which creates a certain ambiguity in the decision model requirements level. The odd thing was this become apparent to me and my co-workers with a few weeks of starting with DMN and has generated issues on many of the projects we’ve worked on with hierarchical data (i.e., most financial projects). I’ve been heartened by your posts in this area.
In answer to your observations: I didn’t place the symbols inside the decision as this can cause confusion if a single decision that produces a collection provides an information requirement to two consumer decisions—one of which exhibits fan-in (consumer aggregates) and the other fan-out (the consumer iterates). A similar argument exists for decisions with information requirements on data inputs—some may be consumed individually, others iterated and others aggregated. The quality seems to be a property of the information relationship between one component and another—rather than a set property of any component. Rather like cardinality of a class relationship in UML is seen as a property of the relationship not either class.
I was also reluctant to use the FEEL aggregate symbols because there are so few and they don’t cover all of the possibilities. For now I thought it sufficient to suggest aggregation and leave the mechanism of that aggregation to the Decision Logic Level.
I think the decision that iterates through one input and aggregates the result could be represented by a fan out on the inbound relationship and a fan-in on the outbound. The convention that any decision that produces a collection uses a plural name also clarifies matters.
I’ll try out some of the ideas you’ve proposed to see how they compare to the above approach on projects where we used it.