A primary design goal of the DMN standard was accessibility to subject matter experts and other "business users", i.e. non-programmers. DMN promises executable decision logic without programming, and it achieves that through a combination of standard diagrams (DRDs), standard tabular formats (boxed expressions), and a business-friendly expression language (FEEL). Nevertheless, you constantly hear that it's too hard for non-programmers. Absolutely not true, but what is true is that not all business users can do it... as I've learned from doing DMN training for 5 years.

It's not easy to say with any precision who can and who cannot master DMN. I have said in the past that if you can use the Formulas ribbon in Excel you can do it. I've also said that it requires an understanding of basic concepts such as datatypes, expressions, and functions. But that's a little abstract. Here is a short pre-test to see how challenging DMN will be for you. It doesn't require that you already know DMN, just that you can apply a bit of teaching about it, like you might get from my book DMN Method and Style or my DMN training. (Of course, in the training it's reinforced with hands-on exercises, repetition, and quizzes.)

## DRD

A Decision Requirements Diagram defines the logic dependency of a decision on supporting decisions and input data.*Input data*, the ovals in the diagram, are values supplied at the time of logic execution.

*Decisions*, the rectangles in the diagram, contain a

*value expression*that computes an output value based on the values of its inputs. The inputs to a decision are the decisions and input data connected by incoming solid arrows called

*information requirements*. Those inputs are variables in the decision's value expression, which can reference only variables that are direct information requirements. The wavy shape in the DRD, called a

*knowledge source*, represents background information on the decision logic, not an information requirement.

Q1. Based on that explanation, the value expression for *Loan prequalification* in the diagram above may reference which variables?

*Credit score, Affordability category**Credit score, Affordability category, Loan approval guidelines**Credit score, Down payment, Purchase price, Monthly income, Loan rate pct**Credit score, Affordability category, Down payment, Purchase price, Monthly income, Loan rate pct*

## Decision Tables

The most familiar boxed expression type in DMN is a*decision table*, like the one below.

Here is how they work. Columns to the left of the double line are the inputs. Below the input name is its datatype, which may also include constraints on the allowed values, such as a numeric range or enumerated values. The column to the right of the double line is the output. Each numbered row is a *decision rule*. The input cell in a rule represents a test of the input, true or false. For example, for rule 1 column 1, that cell is true if *Credit score* is greater than 720, otherwise false. And for rule 1 column 2, the cell is true if *Affordability category* is either "Affordable" or "Marginal". If *all* condition cells in a rule are true, the rule is said to *match* and the expression in the output column is selected as the decision table output.

If it is possible that for some combination of input values, more than one rule may match, the rules are said to *overlap*. The *hit policy code* in the upper left corner, here A for Any, is used in that situation. Hit policy A means the table may contain overlapping rules if they have the same output value. For example here, the combination *Credit score* 610 and *Affordability category* "Unaffordable" matches both rules 6 and 7, which have the same output value.

A couple other things to mention.

- A numeric range in a condition cell uses the format you see in rules 2-5. A square bracket means include the endpoint; a parenthesis means exclude the endpoint. For example, rule 2 tests the condition greater than 680 and less than or equal to 720.
- A hyphen in a condition cell means the input is irrelevant in this rule; the cell is true by default.

*Loan prequalification*output for

*Credit score*720,

*Affordability category*"Unaffordable"?

- "Likely approved"
- "Possibly approved"
- "Likely disapproved"
- null (no match)

## Functions

A Business Knowledge Model (BKM) is a unit of decision logic formulated as a modeler-defined*function*, meaning its value expression references

*parameters*specified in the BKM definition. In the DRD, a BKM is connected to a decision that invokes it by a dashed arrow called a

*knowledge requirement*. In the invocation, the decision passes values of each parameter, called

*arguments*, to the BKM, which plugs those values into its value expression and returns the result to the decision. In addition, the FEEL expression language also provides a large number of

*built-in functions*, which can be invoked without a knowledge requirement.

The invocation is defined by the decision's value expression, which - as mentioned previously - can reference only information requirements of the decision. In particular, it includes expressions mapping decision inputs to each parameter. BKMs allow modelers to create *reusable decision logic*, since different decisions (typically in different DMN models) can send their own particular argument values to the BKM.

Below you see a BKM called *Loan amortization formula*, giving the monthly payment for a fixed-rate home loan, along with its documentation. In the BKM definition, the parameter names and datatypes are enclosed in parentheses, below which is the BKM's value expression. The second parameter of this BKM is the annual interest rate for the loan expressed as a decimal (not a percent). The formula is just arithmetic, but it is complicated and hard to remember, so perfect for a BKM. If you have the BKM, you don't need to know how to derive it; you just need to understand its parameters.

The DRD showing invocation of BKM *Loan amortization formula* by decision *Monthly payment* is shown below. Input data *Loan rate pct* is the annual loan rate expressed as a percent.

The invocation expression has the format *BKM name(arg1, arg2, arg3)*, where *arg1, arg2, *and *arg3* are expressions for the value of each of the BKM parameters. The order must match the parameter order in the BKM definition.

Q3. What are the BKM's parameters?

*Loan amount, Loan rate pct, Loan term**Loan.amount, Loan.rate pct, Loan.term**p, r, n**principal, rate, number of months*

*Loan amortization formula(Loan amount, Loan rate pct, Loan term)**Monthly payment(p, r, n)**Monthly payment(p, r/100, n)**Loan amortization formula(Loan amount, Loan rate pct/100, Loan term)*

## Answers

Did you write down your answers to the four questions? If not, go back and do that now. Below are the answers.
Q1. The correct answer is a. *Credit score, Affordability category*. A decision's value expression may reference only its direct information requirements, and there are just two of those.

Q2. The correct answer is c. "Likely disapproved". *Credit score* 720 is true for rules 2, 3, and 7. * Affordability category* "Unaffordable" is true for rules 6 and 7. Thus the only matching rule is rule 7, "Likely disapproved".

Q3. The correct answer is c. p, r, n. The BKM's parameters are listed in parentheses in the BKM definition.

Q4. The correct answer is d. *Loan amortization formula(Loan amount, Loan rate pct/100, Loan term)*. The expression starts with the BKM name, not the decision name. Because *Loan rate pct* is a percent, it must be divided by 100 to convert it to a decimal, the format for parameter *r*.

## Are You DMN-Ready?

So how did you do on the four questions? If you got them all, you're definitely ready. If you missed one, but you just overlooked some detail and you understand the explanation, you're also ready. Otherwise, if the Answers above still don't make sense, you might not be a good candidate for DMN. In my DMN training, we go over things multiple times and you are hands-on with the tool, but you need a good grasp of the basic concepts. And yes, there is a little math (but just a little).