DMN: Something's Different Now...

Recently I posted about the looming New Era of decision management. Some will say, "Yes, we know. You've been touting DMN for a year now." That is true. But this week something changed.

What changed is the release of the first complete implementation of the standard, from Trisotech. Their crack marketing staff assigned it version number 5.1.10, like it's nothing much. But trust me, it's a big deal. Let me explain why.

DMN is a business-oriented, tool-independent, executable decision language. Those aren't just buzzwords. They are what makes fully implementing DMN so difficult, and why it's taken a full year since finalization of the DMN1.1 spec to see software that actually fulfills the promise.

Start with "business-oriented." That mostly comes down to two things: First, there is no programming language, no program statements that create and update variables. Creating and updating variables is done graphically, through diagrams and tables. The diagrams, called DRDs, show the dependencies of any decision on other decisions and input data. The tables provide the logic of each decision in the DRD. Everyone knows about decision tables, but they are just one of several types of "boxed expressions," strictly defined tabular formats for any kind of decision logic. They are just as much part of the language as DRDs and decision tables. Most boxed expressions are two-column tables, with a variable name on the left, and its value expression on the right. That doesn't seem so hard, except that the value expression may be another boxed expression - a table inside a table - and there is no limit to the level of nesting. Oooh! That's number one.

Second, the variables in executable DMN are the names of the decisions and input data, and the standards committee is convinced that unless DMN names may contain spaces, symbols, and punctuation absolutely forbidden in any normal execution language, business users will never adopt it. That makes parsing the expressions inside the tables difficult. Not impossible, but more work than most vendors want to do.

Next, "tool-independent." That means tools can't adopt DRDs but ignore boxed expressions and DMN's standard expression language, FEEL. Well, they can and they do, but that's no longer tool-independent. If each tool makes up its own graphical notation and expression language... hey, we've had that for twenty years! OMG technically endorses this kind of fakery, but honestly, shame on them.

FEEL support is critical. It's just an expression language. FEEL expressions simply calculate a value. Remember it's the DRD and boxed expressions, the diagrams and tables, that define variables and assign their values. FEEL is not a toy language. It can do serious things. It has built-in functions and operators for manipulating numbers, strings, and lists. It can do iteration, validation, sorting, table queries and joins... yes even with those damn names with spaces. Some tool vendors don't want to implement a new expression language when they've already got their own proprietary language, or can use some Java-based expression language instead. But the former is not tool-independent, and the latter is not business-oriented. Full DMN implementation includes FEEL.

Tool independence also implies models should be interchangeable between tools. The spec provides an XML format just for this purpose. Full implementation of DMN means a tool can export and import models serialized in this format. It's what we expect from the word "tool-independent".

And third, "executable." What you model is what you execute. No, DMN is not a requirements language. DMN models are not just suggestions handed off to programmers using some foreign execution language. They are the real thing. Plug in values for the input data, click Run, and out pop values for all the decisions in the DRD. That's the only way you can verify the decision logic, not only that it is complete and syntactically correct, but that the computed output values make sense. That's got to be inside the tool, one click.

But design-time execution isn't enough. To make a real difference, DMN requires a high-performance native runtime. This is where the traditional rule engine vendors are praying for DMN to fail. But this is what has suddenly changed. That's now in place. RedHat's Drools 7.0 native DMN engine is embedded in the Trisotech tool and production cloud service. That changes the game.

So let's put it all together. In addition to DRDs and decision tables, real DMN - business-oriented, tool-independent, executable - actually requires these things:

  • FEEL (all of it)
  • Boxed expressions (all of them)
  • XML interchange (export and import)
  • Execution (in the tool, and in a production engine)
This is what Trisotech DMN Modeler v5.1.10, released this week, now provides. That's what is different now.

Want to take it for a test ride? Click here.