The DMN 1.2 Revision Task Force starts up this week.  I have a number of related items in my wish list.  Before submitting them to the RTF, I’ll use these posts to generate some discussion.  My top ones are these:

Hierarchical DRD

Like a subprocess in BPMN, I’d like a decision node in DRD to be expandable to another DRD, so that a single decision model representing a complex end-to-end business decision may be described as a tree of DRDs.  Typically, in a tool, a decision in a parent-level DRD will be hyperlinked to the child-level DRD.  The benefit, as well established in BPMN, is the ability to provide a single model for complex end-to-end logic that includes both high-level and detailed views.  The alternative, which DMN 1.1 currently supports, is a flat DRD.  It is not required to show all the nodes in the logic, but if you want to show them all, you get only the detailed view not the high-level view.  According to Larry Goldberg of The Decision Model fame, once a DRD gets beyond 30 nodes it becomes unmanageable in practice.

Consistency places certain constraints on the child-level diagram.  Its “inputs” and “outputs” must match those of the parent-level decision.  I suggest that the information requirements of the parent-level decision become the input data elements of the child-level DRD, and that the child-level DRD has a single top-level decision node identical in name and output components to the parent-level decision.  Like a subprocess in BPMN, a decision node that contains a child-level DRD requires some distinctive marking, such as a

[+] symbol in the bottom center.

You might argue that we already have something like this in a decision service.  Possibly this element could be modified to support this idea, but as currently defined it does not.  First, a decision service is an overlay on the decision logic, not a compositional element of it.  A single decision node may belong to multiple decision services.  Second, a decision service has no “collapsed” representation in the DRD.

Alternative BKM Representation in DRD

I have been really surprised to discover the breadth of displeasure among DMN tool vendors with business knowledge models.  Some object to the basic notion of decision logic formulated as parameterized functions, but to me this is fundamental to reusability.  Tool vendors are free to present a more business-friendly design surface, but underneath the covers the reusable logic must be loosely coupled to the models that reuse it, so the names of the reusable inputs (parameters) must be independent of the variable names in the calling model.  So I for one am completely in favor of having BKMs.  What I (and almost every tool vendor I’ve talked to) don’t like is how they are represented in the DRD.  In DMN today, when a decision calls a BKM, both the decision and the BKM are drawn in the diagram, connected by a dashed like connector representing some mapping to the parameters and return of the output value.  Again referencing BPMN, it is as if a Call Activity and the called process must be drawn in the same diagram with some arrow between them.  It just clutters up the diagram and adds no value.

A better way to do it is via a linked diagram that exposes rather than hides the parameter mapping.  The calling DRD becomes much easier to look at, without sacrificing any detail.  A decision node invoking a DRD should have some distinctive marking, such as a thick border style.  The decision logic for such a node then includes both the invocation parameter mapping, a boxed expression, and the BKM logic.

DRD Representation of a Context

This item is related to the previous two.  The Context expression type allows the decision logic of a single decision node to be modeled as a sequence of context entries, reducing the number of decision nodes required in the DRD.  It is always possible, however, to create a “sub-DRD” equivalent to that Context, in which every decision node is a literal expression, decision table, or invocation.  (The algorithm for creating such a sub-DRD requires parsing the expression language of the context entries to discover the implicit information requirements of the local variables defined within the Context.)  The advantage of such a DRD-like representation of a Context is DRDs are believed to be more “business-friendly” than boxed contexts.

Ideally the DMN metamodel should recognize the equivalence of a Context to such a sub-DRD.  I believe that this would allow tools to express the decision logic in either form and even toggle between them, depending on user preference.  A decision node whose logic is modeled as such a Context/sub-DRD is an example of the first item in my wish list, the Hierarchical DRD.  It also helps resolve another issue in DMN 1.1, which is that a BKM must be a single value expression not a sub-DRD.

Multi-Instance Decision

In DMN 1.1 with FEEL, iteration over a list or rows in a table requires using the for..in..return operator.  For example, if an Order contains a list of Items, each with a Description, UnitPrice, and Quantity, the decision TotalPrice is expressed as follows:

TotalPrice = sum(for i in Order return i.Quantity*i.UnitPrice)

The dummy variable i stands for a row in the table Order, i.e. an Item.  The for..in..return operator iterates Quantity*UnitPrice for each Item in the Order, and the sum() function adds those to get the total.  Technical folks used to XPATH or XQuery might find this syntax straightforward, but it is not the most business-friendly.  I propose the following equivalent notation using a new decision node type called a Multi-Instance Decision, or MID:

  1. The MID is a decision that is described by a sub-DRD (equivalent to a Context), as discussed above, with a special icon or marker to indicate it is an iteration.
  2. The MID may be displayed either collapsed (with [+] bottom center) or expanded, containing the sub-DRD inside it.
  3. At least one information requirement of the MID must be a list or relation.
  4. The iterator (equivalent to i in the for..return expression) is an item in the above list or relation.  It is represented graphically in the MID as an oval shape, similar to input data.  The iterator provides information requirements to decision nodes in the sub-DRD representing the MID.  Other non-iterated elements in theDRD may supply additional information requirements to decision nodes in the MID.
  5. The semantics of a MID is to iterate the decision logic over each item in the list.  Possibly the MID may define aggregation options, such as Collect, Sum, Max, etc.

Here is what Signavio’s implementation of such a MID looks like:

MID

Indirect Invocation

I believe this feature was intended to be put into DMN 1.1 at the last minute, but it was kind of botched.  In the DMN 1.1 spec, a decision invoking a BKM identifies the BKM to be invoked not by its static id but by an expression – any expression type, even a decision table – that outputs the BKM name.  This is not consistent with anything else in DMN, but its advocates (whom I will not name) touted the benefit of such an dynamic invocation, so that depending on the inputs, the decision could invoke BKM1, BKM2, or BKM3.  And there is indeed some benefit to that!  So what is the problem?  The problem is that the target BKM is also identified by a knowledgeRequirement connector, which points to a BKM by id.  And the decision’s invocation logic uses static names for the BKM parameters, which only works if BKM1, BKM2, and BKM3 all share the same parameter names.

So this is basically a bug fix.  Either make invocation dynamic, and allow knowledgeRequirements and parameter bindings to be dynamic as well, or go back to the simpler static invocation.  What we have now is neither fish nor fowl.

 

Like any of these?  Hate them?  I’m interested in feedback.