DMN Business Knowledge Models - Love 'em or Hate 'em?

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.DRD

But here's the thing: Unless you want to expose that bit of decision logic for reuse, BKMs are unnecessary. And 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...