Every discussion of DMN these days seems to begin with some declaration of what “business users don’t like.” They don’t like FEEL. They don’t like boxed expressions. They don’t like BKMs. They don’t like contexts. They don’t like names with underscores, or, heaven forbid, camel case! They don’t like parentheses to define a numeric interval excluding the endpoints. They don’t like hipsters, Obamacare, or Hillary’s email server.
What they do like about DMN, by universal agreement, is its use in classification decisions. And it’s easy to see why. DMN classification decisions are easy to understand, widely applicable, and quite powerful with the right methodology.
Let’s say your decision model determines approval or rejection of a loan application. That’s a binary outcome, Approved or Declined. Now think about the factors that go into that decision. Those would include information about the borrower, such as age, marital status, income, debt obligations, credit score, and employment history; information about the loan itself, such as the loan amount, down payment amount, and monthly payment; information about the collateral, such as loan-to-value ratio, risk of accidental loss, expected rate of appreciation or depreciation; information about the external credit environment, such as Fed interest rates, ability to sell or securitize the loan, etc. It’s a long list.
The lender may have a few rules that automatically decline the loan based on one of these factors: the borrower’s employment status or credit score, loan to value ratio, etc. But beyond that, all those factors just go into one big stew that is supposed to determine the risk or profitability of the loan. That’s where classification comes in.
Instead of trying to figure out all combinations of these factors that recommend Approve or Decline, instead we combine subsets of them to define several risk categories: the borrower’s credit risk, loan affordability risk, collateral risk, etc. For each of these, the outcome is an enumerated list, such as High, Medium, or Low. Each risk category value is determined by just a subset of the factors in the overall lending decision. In DMN, the risk category is modeled as a decision table with enumerated output values High, Medium, and Low. This is a classification decision.
Classification decisions are easy to understand because the output is not some complicated FEEL expression but just a selection from an enumerated list, High, Medium, or Low. Each column of the decision table represents one of the inputs to that logic, that is, one of the factors affecting that risk category. In this case, the syntax of each decision table cell is simple, as we see in the table above. (Ssshhhh! It’s FEEL, but not too loud, don’t want to freak out the business users.)
The Decision Requirements Diagram (DRD) shows how the input data, the individual risk category decisions, and the overall Approve-Decline decision are related. All the decision nodes enclosed in the red rectangle are classifications. The overall decision, Approved or Declined, is based on the outcomes of the individual risk categories. If they are all Low, or maybe one is Medium, the result is Approved. If any one of them is High, Declined. In between, maybe you want to refer the loan for human adjudication. You can assign unequal weights to the various risk categories using the Category-Score pattern. All that is up to you. The point is, you’ve reduced a complex, nearly intractable decision to a tree of much simpler classification decisions. Each classification decision is not only easy to define and understand, but easier to maintain. Business users can do it themselves. And with DMN, that is the whole point!
The DMN Method, as described in my book DMN Method and Style and associated DMN Method and Style Basics training, provides a systematic approach to decomposing complex end-to-end decisions into such a tree of classification decisions, and the common patterns involved, including the Category-Score pattern. Classification decisions are not the only way to use DMN, but they are the most common.
Best of all, they’re the part that business users like.
Good article as usual, Bruce; one question – I’d be interested in your definition of ‘business user’? I find it to be one of those terms that’s used endlessly to support any number of different positions and you cite the various scenarios in which “business users don’t like ” – but no-one ever says who they are. That might sound like a stupid thing to define because I’ve no doubt that many would think it obvious. However, it feels like a nebulous catch-all that is trotted out whenever convenient (by some, I’m not saying in all cases) and a little like smoke and mirrors.
So who do you class these guys as? Do you include business analysts? Do you exclude anyone? Are business users just classed as those that are reviewing and owning this work? Or those that are doing the modelling? Or both? Are business users just anyone outside of IT?
Thanks
Good point. “Business user” encompasses a reasonably wide range of skills and knowledge. And, of course, the consumer of a model (BPMN or DMN) does not necessarily have the same skill/knowledge requirement as the producer of the model, even though both are (in my terminology) business users. Generally speaking I am just distinguishing business users from developers. The former have domain knowledge concerning the process or decision logic and some amount of computational/logical skill, but are not programmers. So that would include business analysts, business architects, etc. The latter generally have little domain knowledge and create executable code based on “requirements” received from the business, in whatever form. For classification decisions, I think my definition of business user is no different from that used by TDM, which you are familiar with. For full DMN Level 3, which goes beyond pure classifications, the example I use is someone able to use the Excel Formula menu, which is a business-oriented expression language, as opposed to Excel Macros, which use programming languages like javascript.
That’s very useful, thanks Bruce. My previous concerns around FEEL stem from that definition and that mine was a much narrower definition than yours. Having played around with FEEL a lot more now, its power is obvious and it certainly feels (no pun intended) considerably less contentious with your definition.
It’d be interesting how many adoption concerns potentially stem from a simple lack of common understanding of that definition…