DMN Business Knowledge Models – Love ’em or Hate ’em?
Blog: Method & Style (Bruce Silver)
If you’re like most people trying to find out about DMN by reading the spec, you focus on the diagrams and examples. And you probably come away thinking, Yikes, what a mess! The thing that elicits this response from most people is the proliferation of business knowledge models (BKMs), those rectangles with clipped corners that seem to be stuffed in every nook and cranny of the DRD.
But here’s the thing: Unless you want to represent a reusable bit of decision logic, BKMs are optional. You don’t have to use them!
DRD and BKMs come from the same place, a FICO methodology called Decision Requirements Analysis. It’s described in Alan Fish’s book, Knowledge Automation. Alan also wrote the Lending example chapter of the DMN spec, which explains their proliferation there. In Alan’s methodology, BKMs represent distinct aspects of “knowledge” assigned to different subject matter experts. There is a certain reasonableness to that, but in DMN the BKM models that knowledge as a function with defined parameters. A decision node – the rectangle in DRD – incorporates that knowledge by “invoking” the BKM, passing values to its parameters. Alan calls it knowledge, but a BKM is really just a decision table or literal expression, same as a decision. So you could either put that decision table in the original decision (one step), or put it in a BKM that the decision invokes (two steps).
Why would anyone do in two steps (plus an extra shape and connector in the diagram) what you could just as well do in one? Alan likes showing the distinct aspects of knowledge in the diagram. Mmmm, ok, but that’s not compelling to me. The DRD is crowded enough as it is! For me, the reason for BKMs is reuse. In the DMN training I just put together, I must have entered the formula for amortized payments 50 times:
Payment = (LoanAmt * Rate/12)/(1 - (1+Rate/12)**-termMonths)
Yeah, that formula. Who wants to memorize something like that? Better to make it a BKM Payment(p, r, n), where the principal p is the loan amount, r is the interest rate, and n is the term in months. Then you define it once, and then call it from any decision that needs that formula by passing values for the three parameters. And that’s just a simple literal expression. Imagine some more complex reused logic that requires a decision table with 4 inputs and 10 rules. You really don’t want to have to type that in time after time. Perfect for a BKM. You can even save those BKMs in a special model used as a function library. Your real decision models then import the library and invoke the BKMs.
Well, that’s how it is supposed to work, if DMN tools actually supported BKMs and model import. From what I can see, first-generation DMN tools are trying to avoid BKMs altogether. You could re-do the spec Lending example without using them at all – my book has an example of that – and the DRD is a lot easier to make sense of.
But that doesn’t mean BKMs are useless. Reusable decision logic needs them. Iteration needs them. DMN needs them. In moderation…
The post DMN Business Knowledge Models – Love ’em or Hate ’em? appeared first on Method and Style.
Comments (1)
Leave a Comment
You must be logged in to post a comment.
What is missing from these methodologies and the discussions of them is a recognition that all of the items depicted on a DRD are usefully seen as decision-data pairs. The values of the parameters “LoanAmt” “Rate” and “termMonths” are data resulting from decisions and so is the formula (knowledge?) that is used to calculate “Payment.” Every data element value is the result of a decision. The decision that produces a value for the data element “Payment” is a decision that can be automated using the knowledge that “Payment = (LoanAmt * Rate/12)/(1 – (1+Rate/12)**-termMonths).” With less well understood decision situations we may not know of a formula or decision table that produces adequate results. In such instances, until we know of such a formula or decision table someone will make the decision based upon knowledge that will be at least partly tacit.
While it is useful to see data and decisions as decision-data pairs, I have yet to find any utility in or basis for distinguishing between knowledge and data. Nor do I see any need to do so.
This understanding produces a DRD in which every node is a decision and it’s resultant data—considerably simpler than one with any one of three different entries at the nodes. Nevertheless, most applications are sufficiently complex that a DRD is only helpful in depicting small portions of the network.