People who started decision modeling standardization years ago were all agreed that the DMN standard is supposed to be oriented to subject matter experts, should be simple, friendly enough while powerful to cover the common denominator in operational decision modeling. It was a good start for DMN in 2013 and an enthusiastic acceptance since then. However, today DMN is full of complex, programmer-oriented features which seem to get even more complex in new releases. There are plenty examples of unnecessary complexity being proudly promoted for their “elegance”.  Here are a few examples to compare.

From the notorious Challenge Jan-2016 “Vacation Days”:

This is a boxed expression from the DMN’s solution:

The same logic can be presented by a regular multiple-hit decision table:

From a practitioner’s review of the upcoming DMN 1.2:

This is a boxed expression in DMN 1.1:

This is an improved version after the introduction of generalized unary tests with reserved symbol ‘?’ in DMN 1.2:

The same logic can be presented by a regular decision table:

Being a real-world practitioner, Jan Purchase in his review concurs that “in this particular (and rather frequent) use case” the regular decision table is more preferable. He although pointed out that the code like the generalized unary tests may be more flexible overall.

More Complex Logic

Jan provides a more complex example where a FEEL expression with filters looks compact and powerful:

count(persons.experience[years>5])>2

It is used inside the boxed context implemented in DMN 1.1 as follows:

DMN 1.2 will allow a user to “simplify” this code:

count(?[years>5])>2

and even to remove the context converting it to this decision table:

Jan rightfully noted that this “syntax may unnerve some business users“. But can we offer more traditional decision tables to business users that still represent the complex logic that deals with a collection of “Persons” attending a Party? A year ago I proposed how to avoid programming when we deal with collections of objects. Here are my decision tables that implement the same logic as above:

The first decision table initializes several Party’s attributes (explicitly defined decision variables) and executes “ActionIterate” to run the second decision table for every attendee. The third decision table uses the accumulated attributes  to choose the value of the Admission Grade. Certainly these 3 tables are not as compact as the above approach, and they probably are not as “elegant” as the above expressions with filters. However, it is hard to argue that they are easier to understand by business users. So far, my proposal was ignored by DMN 1.2, but hopefully it will be considered by the next DMN release.

DMN 1.2 decided to remove so-called “S-FEEL” from the standard. S-FEEL and the corresponding Compliance Level 2 include only simple arithmetic and logical expressions inside decision table cells and do not include complex boxed expressions with loops, filters, and formal parameters. But our customers actually like the simplicity of S-FEEL formulas that naturally allowed them to use variable names with spaces like in this example:

I’d agree that we don’t need two languages in DMN, but it’s hard to agree with dominating promotion of complex boxed expressions. There should be one FEEL language that concentrates on commonly used decision modeling constructs. I don’t suggest to remove “boxed expressions” from the standard – they should be available as advanced DMN capabilities. There will be always people who would like to use programming constructs in their decision models and in some cases it even may become a necessity. However, I cannot agree with DMN Committee members who put emphasis on boxed expressions and then state that “For the foreseeable future, [executable decision models] will be created by developers and [maybe] more technical business users.” We need to keep the DMN standard oriented to business users. To do that we should concentrate on the traditional decision tables, expand their functionality when necessary, and to promote the use of the most simple while powerful FEEL expressions. We all want DMN to succeed, and I hope the constructive critique with concrete examples and suggestions for improvement will be considered by the future DMN releases.

P.S. You will find many comments to this post at LinkedIn