In my DMN 1.2 Wishlist post, one of the key items is the ability to represent a single decision node having complex decision logic with a “sub-DRD” equivalent to the boxed context representation allowed under DMN 1.1.  In his comment, James Taylor sighs loudly and adds that if I understood the spec better I would realize that what I want can be done already in DMN 1.1.  I don’t see that, but a picture here is worth 1000 words.

UServ detail

Here is a DRD of the UServ auto insurance example taken from Chapter 14 of my DMN Method and Style book and slightly modified.  It has only 20 decision nodes – far less than Larry Goldberg’s manageability limit of 30, but still a bit hard to take in with its mess of crossing lines.

Here is a simpler high-level view of the same business decision, much easier to understand and probably how I would begin to decompose the logic in top-down fashion:

UServ hiLevel

What I want is that this simpler DRD, adorned with suitable symbols and border styles, is a valid representation of the same end-to-end decision logic described in the detailed DRD.  James says this is already possible under DMN 1.1, it’s just a tooling issue.  But is it?

The simpler DRD has 6 decision nodes, here colored green in the detailed DRD:

UServ detail2

In the high-level DRD, for example, the decision logic of AutoEligibility Score depends only on the variables car and HighTheftList, both input data elements.  But in the detailed DRD, it depends on the variables PotentialTheft Category and PotentialOccupantInjury Category, both decisions and not the same thing at all.  Unless you say, “Well, of course, the decision logic of the node has to change if you change the DRD representation,” I don’t see how the diagrams are equivalent under DMN 1.1.  To make them equivalent, you need to encapsulate the supporting decisions of AutoEligiblity Score inside that single decision node.  And you can do that today already with a context, a boxed expression that using FEEL looks like this:

UServ AutoEligibilityScore context

This context is equivalent to the tree of supporting decisions of AutoEligibility Score in the detailed DRD, and it is true that if you make this context the decision logic of that node in the high-level DRD, the high-level and detailed logic for this decision are the same.  The problem with boxed context is that almost no tools support it, saying that business users won’t like it.  Maybe that is the case, maybe not, but what is clear is that there is a “sub-DRD” representation of this context (and those of the other decision nodes in the high-level DRD) that makes the high-level DRD exactly equivalent to the detailed DRD, but much easier to visually understand.  My proposal is that the sub-DRD is displayed as a separate diagram hyperlinked to the decision node in the high-level DRD, much like a child-level BPMN diagram is hyperlinked to a subprocess in the parent-level diagram.

This sub-DRD notion is related to other items on my wishlist as well.  Actually, the diagrams above only work for an insurance policy with one driver and one car.  The UServ scenario specified multiple cars and multiple drivers on a single policy.  You can do this in DMN 1.1 today, but to iterate a decision requires a BKM and a for..in..return expression.  Thus in addition to (not instead of) the decision nodes you need to draw BKM nodes, with their own arrow connectors – more clutter – and if you think the boxed context above is not business-friendly, you’re really going to hate for..in.return.

UServ proposal

The wishlist proposals say instead of drawing the BKMs in the main diagram, use a thick border on the decision node to indicate a “call” to a reusable function, i.e., BKM.  In the tool, such a node would typically be hyperlinked to diagrams representing the parameter mapping and the BKM logic.  And the 3-bar symbol indicates that the called function is “multi-instance,” iterated over a repeating input element.  (Here the input data elements car and driver are tables, one row per car or driver.)  In the wishlist post, such a multi-instance decision was shown expanded, as it is currently implemented in Signavio.  In the diagram above, it is shown collapsed.