How DMN Is Different

In my BPMN classes I start by highlighting the ways in which it is different from traditional swimlane flowcharts. While the outward similarities ease business user adoption by presenting a familiar appearance, the reasons why BPMN has succeeded as a standard actually stem from all the ways in which it is different from (i.e., better than) flowcharting. And so it is with the Decision Model and Notation, or DMN. The similarities with earlier approaches center mostly around decision tables, a business-familiar tabular format for if-then decision logic that has been around for decades. And maybe we should also throw in DRDs as well, since they are quite similar to the Rule Family Views of The Decision Model (TDM). Those features of DMN are intended to make the notation outwardly familiar to business users, and thus more approachable.

But what makes DMN important are all the ways in which it is different: different from traditional decision tables, different from TDM, and - most important - different from the rule languages of commercial business rule engines.

DMN stands alone in its combination of these key attributes:

  1. Designed for business users, not programmers. The logic is described entirely using diagrams and tables.
  2. Rich enough to handle real-world decision logic. Not a toy.
  3. Decision logic is verifiable and executable. What you draw is what you execute.
  4. Standardized. It works the same in any tool.

Designed for Business Users

As we did with BPMN 2.0, we sometimes hear from the proprietary decision management tool vendors and their consultant ecosystem, "DMN is too hard for business users." A self-serving smokescreen, of course. So why do I say DMN is designed for business users? The main reason, as I said earlier, is that the decision logic - both end-to-end and in fine detail - is defined through diagrams and tables, not program code. The end-to-end logic is described by a Decision Requirements Diagram, or DRD. It shows the dependencies of any decision node in the diagram on specific supporting decisions and input data elements.

drd2

The internal logic of any decision node in the DRD is defined by a tabular format called a boxed expression. DMN defines several types of value expressions, and each has a well-defined boxed expression format. The most familiar one is the decision table, shown below. All boxed expressions show the name of the DRD element - here the decision Approval Status - in a tab at the top.

simpleatable

Here is the boxed expression format for a literal expression for an amortized payment:

literalexp

Even though your decision models might use that formula frequently, it's a lot to remember. So you could define a parameterized version of it in a business knowledge model, or BKM, and reuse it by invoking it from various decisions. The DRD here shows invocation of the BKM PMT. The boxed expression for PMT, with parameters p, r, and n, is shown next. The boxed expression for the invocation of PMT is last, mapping the inputs of payment to the parameters of PMT.

drd3 bkmlx invocation

How all this hangs together to create executable decision logic is not a program. The meaning is inherent in the diagrams and tables. So, yes, it's a new language that you have to learn, but it's entirely visual. In addition to decision table, literal expression, and invocation, DMN in similar fashion defines boxed expressions called context, relation, and a couple more.

The second way DMN tries to be business friendly is by allowing spaces in the names of decisions, input data elements, and built-in functions. Members of the standards committee are adamant that business users absolutely HATE decision names like CustomerStatus or Customer_Status. They want Customer Status. Seems childish to me but OK, that's what we have. To the geeks out there, it means that the grammar for DMN's standard expression language FEEL is not context-free. Translation: It is a bit harder to implement, but not impossible.

Rich Enough for Real-World Decision Logic

As in BPMN, there is inherent tension between business user-friendliness and the richness of the language. And that's ok. Using DMN for simple decision logic is simple; using it for more complex decision logic is more complex. But it is not programming.

DMN's richness is embodied in its expression language FEEL. FEEL is not a programming language, just an expression language. FEEL expressions are formulas that produce a value. In Excel terms, FEEL is not Macros - that's programming. It is like using the Formulas menu.

excelformulas

Take a look at Excel Formulas if you haven't done so in a while. Sure, using it might be beyond the ability of some business users, but it is explicitly intended for non-programmers. Actually the DMN language is far simpler than Excel Formula syntax. Consider this if-then-else expression for ApprovalStatus:

If Risk is "Low" or "Medium" and PTI<0.3 then "Approved" else "Declined"
Here it is in Excel formula syntax:
=IF(AND(OR(Risk="Medium",Risk="Low"),PTI<0.3),"Approved","Declined")
Here it is in FEEL syntax:
if Risk in ["Low", "Medium"] and PTI <0.3 then "Approved" else "Declined"
Now you tell me, which one is more business friendly?

As you can see, FEEL can be used in arithmetic expressions like the amortization formula, if-then-else expressions, and a lot more, including calendar arithmetic, table queries and joins, iteration, and sorting. For some of it you may need to brush up on your 9th grade algebra, but it's really not harder than that.

Executable: The Heart of the Matter

Even though the decision logic is fully described through diagrams and tables, and even though the variables used in the expression language contain spaces and other things that freak out most programmers, DMN models are executable. Provide the model with valid input data values, and it can produce the proper output value. DMN is not a requirements definition language, intended to produce specifications for programmers working in some other rule language. Sure, you can use it that way, and certain vendors hope that's all you ever do. But that's not really what DMN is. DMN models are not simply requirements for creating executable decision logic; they ARE the executable decision logic.

We saw how this played out a decade ago with BPMN. At first, BPMN was just a modeling notation, not an execution language. The idea was your BPMN diagrams would be translated by programmers into a different language called BPEL for execution. BPMN and BPEL were similar but they were not the same. There were things you could model in BPMN that had to be done quite differently in BPEL, and vice versa. And business users totally rejected that. Soon the BPEL vendors were racing to create BPMN 2.0, which unified the modeling language and the execution language. What you model is what you execute!

And that is what DMN really is: unification of decision modeling and execution, in a common business-friendly language.

Standardized: Works the Same in Any Tool

The three attributes described above are impressive on their own. Still, users of a language like TDM could credibly say, "We do that, too!" Ah, but you can't say this: "Our language is a standard. The IP is freely available. And it works the same in any tool conforming to the spec." Standardization ultimately means lower cost of software, support, and education, and a wider choice of tools. It's why standards usually win over proprietary tools in the end.

Fully implementing DMN means supporting boxed expressions and FEEL. Period. Any other format or expression language is not the real thing. It might "work" but it's not the standard.

So What's the Problem?

The picture I've just painted seems a compelling value proposition. But, to be honest, so far DMN has been all smoke and no fire. Why is that? The answer is simple: There are no tools out there that fully implement DMN, that do all those things. None. Zero. It's hard to get users fired up about something that just exists on paper.

But tools that fully implement the standard are coming.

Implementing DMN is hard. Simply drawing the boxed expressions is hard. I didn't show it here, but most cells in a boxed expression can nest another complete boxed expression, such as a decision table or invocation. In theory there is no limit to the levels of nesting, although as a practical matter most tools will have a limit. And executing FEEL is also hard.

Trisotech's DMN Modeler can draw all the boxed expressions, including nested ones. It's expression editor supports FEEL, including names with spaces and all its built-in functions and operators. It's probably the ONLY DMN tool that can say either of those things.

The issue is execution. Currently, the tool can execute only DRDs containing decision tables, not literal expressions, invocations, or contexts. I'm working to change that. Watch this space.

In the meantime, for many decision modelers, DRDs containing only decision tables are all that is needed, and for those the Trisotech tool is complete and standards-compliant. There is a lot to learn just with that, and if that interests you, check out my DMN Method and Style Basics training, web/on-demand, including 60-day use of Trisotech and post-class certification. More info on that is here.