What Is DMN?

Decision Requirements

There are three basic types of applications for DMN. The first is model-based decision requirements. A decision, as it is commonly understood, can be described as a question and a set of allowed answers. It does not perform any actions; it is simply data-in, data-out. The logic of the decision depends on information passed from a combination of source data and other decisions. Those supporting decisions have similar dependencies. An outline of the overall structure can thus be represented as a Decision Requirements Diagram (DRD) displaying a network of decisions, represented as rectangles, connected to supporting decisions by solid arrows called information requirements, and ultimately to input data, represented as ovals. In this way, the information requirements of a complex decision is decomposed in the diagram into simpler decisions and source data.

The DRD doesn’t tell you how each decision computes its output value from its inputs. That is called decision logic. In legacy business rule management systems (some renamed decision management systems), decision logic has been the exclusive domain of programmers, except for one simple form called a decision table. Each row of a decision table is a rule, and each cell in that row is a condition on the column heading. If the rule “matches”, meaning all cells in the rule evaluate to true, the rule output is selected as the table output. Decision tables have been around for decades, and DMN places certain constraints on the text in each cell and what to do when multiple rules match, called hit policy.

The DMN spec establishes three conformance levels for tools, and Level 1 merely requires support for DRDs and decision tables. I call it DMN Lite. It allows consultants to engage business users in defining requirements that are then handed off to programmers for implementation. But it is not enough to create testable decision logic, or even testable decision requirements. It is a modest improvement over text-based business requirements, but not really in the spirit of a standard. In practice, any sort of diagram with boxes and arrows can advertise itself as a DMN DRD and any sort of decision table, whether it follows DMN’s constraints or not, can advertise itself as DMN as well, so Conformance Level 1 allows legacy tool vendors to assert standards compliance without changing their software very much.

Executable Decision Logic

Conformance Level 2 was a mistake that, for political reasons, still remains in the spec. It simply adds on top of Level 1 support for S-FEEL, a subset of the FEEL expression language that can be used in decision tables. Originally S-FEEL was specified by deleting certain lines of the FEEL grammar, but that didn’t work, and S-FEEL has been deprecated for several years. So just ignore that one.

Conformance Level 3 is Real DMN. It allows non-programmers to create executable decision logic. To do that, it adds two key elements that set DMN apart from traditional decision languages. The first is a set of specific tabular formats called boxed expressions used to define decision logic. Decision table is one type of boxed expression, but there are others: literal expression, invocation, context, and more. The second is FEEL, a business-friendly expression language for the text that goes in the cells of the boxed expressions. An expression language is not a programming language. It does not have program statements that define variables. In DMN, the variables are defined by the names (labels) of the decisions and input data in the DRD. An expression language is simply a formula that computes a value. FEEL is comparable to (and more business-friendly than) Excel Formulas; it is not equivalent to Excel Macros, which are programs.

The combination of DRDs, boxed expressions, and FEEL is what makes executable logic design accessible to non-programmers, but it is also what has made DMN implementation challenging to tool vendors. Remember, in DMN the variable names are the labels of the DRD elements, and as such typically contain spaces and punctuation normally not allowed in executable languages. In fact, this effectively blocked vendor implementation until Red Hat published their open source FEEL parser. Boxed expressions are a challenge as well. Except for decision tables, most are two-column tables, the first column being a variable name and the second column being its value expression. The value expression could simply be a FEEL formula, but it could be a whole boxed expression, a table nested within another table, creating a graphical nightmare for the tool vendor.

For the modeler, however, it means complex logic can be fully defined by creating diagrams and tables – DRDs and boxed expressions – with a bit of FEEL inside. FEEL has built-in functions and operators, and, like Excel Formulas, requires a little bit of learning to master. But it is so much more business-friendly than Javascript or Python or other “simple” programming languages. And here’s why that’s important. It puts subject matter experts in direct control over the logic, as executed. DMN is different from BPMN in one critical aspect: The model has a correct answer! Its logic can be right or wrong, and the subject matter expert, not the programmer, is the one that knows the difference. Thus testing the decision logic is an essential function of a DMN tool. You put in values for the input data, run the model, and check that the decision output values are correct.

Moreover, DMN models can be compiled and deployed as REST services in the cloud. In tools like Trisotech Digital Enterprise Suite, this can be done in a single mouse click. Once deployed the decision service can be invoked by any client app or process able to make a REST call. It can even be deployed as an elastic cloud service using Kubernetes. Low-code does not mean low-performance!

Low-Code Business Logic

Larry Goldberg, author of The Decision Model, a precursor of DMN, liked to call its output not decision logic but business logic. I have only lately begun to appreciate the significance of that distinction. When you see what Real DMN can do through diagrams and tables, you realize it is not restricted to decision logic described as questions and allowed answers. It can be any form of business logic at all! The clearest example of this use case is the Trisotech Digital Enterprise Suite, which borrows FEEL and boxed expressions from DMN and uses it in BPMN as well. That means executable process services can be created by subject matter experts, without queuing up for programmer resources.

I’ve posted recently about client engagement work creating Business Automation components in the form of short-running BPMN services that update database tables in response to business events. In those services, the basic database operations (query, insert) are provided by service tasks using OData or OpenAPI, but the business logic is all DMN. A bit of the DMN is “decision logic” as we commonly know it, but most of it is performing calculations and generating the new table rows using diagrams, boxed expressions, and FEEL. There is no programming required, and like decision services, these Business Automation components can be deployed in one click as scalable REST services in the cloud. These Business Automation projects tend to start with examples defined in Excel tables, in which the job is to generalize the logic and update database tables in response to business events. While I’ve been engaged in creating these models, I insist that clients can (and should) learn to do it themselves. If you can create a complex Excel model, you can certainly learn to create its equivalent Business Automation service model. It’s a new language, but it’s actually simpler than Excel Formulas.