What’s Behind Vendor Resistance to FEEL?
Blog: Method & Style (Bruce Silver)
I read with mixed feelings Larry Goldberg’s post “Just Not FEELin It“. Larry is the one who introduced me to decision management a decade ago. He was the first to promote a strict methodology for business users creating model-driven decision requirements, which is essential. So he is a very smart guy, and I respect his opinion. That is why his blanket dismissal of DMN’s key features – FEEL (and, by implication, boxed expressions) – was so disappointing. On the other hand, his two proffered alternatives, the Excel formula language and AI-based tools to convert legacy code to Sapiens’ rule language, just cannot stand up to a fair comparison with DMN, so I am eager to join the battle.
Before doing so, I need to make note of the key difference between DMN and traditional decision management products. DMN, from the beginning, had the goal of marrying two seemingly incompatible characteristics – accessibility to non-programmers and executability on a runtime engine. And it accomplished that, at least for vendors that fully implement the standard. But to get through the standards committee, DMN allows partial implementation as “conformant”. Many vendors who wrap themselves in the mantle of the DMN standard implement only the decision requirements portion, not the executable logic portion, FEEL and boxed expressions. I call them DMN Lite. Decision Requirements Diagrams (DRDs) depict the dependency of a complex decision on a network of simpler supporting decisions and input data. A fully fleshed out DRD creates fairly complete logic requirements by specifying the inputs and outputs of each supporting decision, without specifying the internal logic of each decision that actually transforms the inputs to the outputs. In DMN Lite, that would be handed off to programmers.
To me, that’s not really business empowerment. It’s just business engagement in a programmer-driven project. DMN’s real breakthrough was business-enabling the decision logic itself, using FEEL and boxed expressions. FEEL is not a programming language. It does not have program statements that create variables. It is simply an expression language, returning output values for a given set of input values, just like the Excel formula language. The variables are defined by the DRD. They are the decisions and input data in the diagram! And this creates problem number one: The variable names are the modeler-entered labels of those boxes and ovals in the diagram, so they can contain spaces and punctuation not allowed in variable names by most executable languages. It makes parsing the model for execution too hard. As Denis Gagne of Trisotech likes to say, making it easier for non-programmers made it harder for tool vendors. Maybe that was a reasonable excuse for vendors not to implement FEEL back in 2017, but Red Hat’s FEEL parser/compiler has been open source for several years now. So vendors cannot stand on that today.
Larry rightfully points out the impediments caused by the resulting profusion of decision languages employed by the DMN Lite vendors. I agree that this has hurt DMN adoption. But it’s not for lack of trying. FEEL at least has several implementers. I would ask Sapiens, IBM, FICO, Sparkling Logic, and the rest: What other tool vendor is using your language?
Larry’s proposed FEEL alternative is the Excel formula language. It’s true that Excel formulas, in their simplest form, are widely used. But for decision logic, comparing FEEL to the Excel formula language in terms of business-friendliness is a no-contest win for FEEL. It’s not even close. There are two main reasons for this. The first is the lack of operators in the Excel language. The only operators they support are arithmetic (like +, -, etc.), comparison (like =, >, etc.), and string concatenation (&). Those are the ones used in Excel 99% of the time. Everything else is a built-in function, and so even modestly complex logic is constructed as functions nested within functions nested within other functions. The second reason is the inability to break a complex value expression into a set of simpler expressions without dropping back into a programming language. DMN solves that problem with boxed expressions. DMN Lite vendors who get the vapors over DMN contexts apparently think nothing of an Excel formula with functions nested 10-deep.
Here is an example of the nested function issue. Earlier this year, in an article promoting the wonders of Power FX – the new name for the Excel formula language – Microsoft’s key example demonstrates how to extract the last word – text following the last space – in the string Input.Text. Here is Microsoft’s formula:
Right(Input.Text, Len(Input.Text) - Find("|", Substitute(Input.Text, " ", "|", Len(Input.Text)
- Len(Substitute(Input.Text, " ", "")))))
Here it is in FEEL:
split(Input string, " ")[-1]
This example uses the FEEL filter operator [-1], which extracts the last item in the list created by the FEEL function split using the delimiter ” “. It’s true, the modeler would need to learn the FEEL function split and the filter operator. But that’s easy compared to unwrapping the Power FX solution, with functions nested five levels deep… for something so simple!
In real business logic – and here I have to give Larry credit; the Decision Model (and DMN) are about creating all kinds of business logic, not just what we think of as “decisions” – we are more often dealing with lists and tables than extracting the last word of a string. The Excel Formulas ribbon boasts a long list of built-in functions to choose from.
The following example from the Power FX documentation is a fair illustration of the difference in style from DMN and FEEL. Suppose we have input data Products, a table containing columns Product, Quantity Requested, and Quantity Available, and we want to generate a new table Replenish with columns Product and Quantity to Order, when the Quantity Requested exceeds the Quantity Available. The Power FX solution is a single expression with doubly-nested functions:
ShowColumns( AddColumns( Filter( Products, 'Quantity Requested' > 'Quantity Available' ),
"Quantity To Order", 'Quantity Requested' - 'Quantity Available' ), "Product", "Quantity To Order" )
From Microsoft’s documentation:
Note that in the above, we used double quotes (“) in some places and single quotes (‘) in other places. Single quotes are required when referencing the value of an object, such as a field or table, in which the name of the object contains a space. Double quotes are used when we are not referencing the value of an object but instead talking about it, especially in situations in which the object does not yet exist, as in the case of AddColumns.
Sure, that’s business-friendly! DMN instead takes a more graphical approach.
The decision Replenish uses the FEEL iteration operator for..in..return on the Products table filtered by the condition Quantity Requested > Quantity Available. Each iteration calls the BKM Replenish item, which uses a context to create one row of the resulting table.
Some folks might favor the Power FX approach, even though some arguments are enclosed in single quotes and others in double quotes, and it requires two levels of nesting. There is no doubt the DMN style is different, more graphical and less ad-hoc. For example, creating a table almost always uses iteration on a context BKM, one context entry per output table column. Modelers just learn that pattern, used all the time. Both approaches require the modeler to learn something new. The notion that an Excel user already knows the ins and outs of Power FX formulas is absurd. I would argue that with an equivalent amount of education or training, the DMN approach is easier to grasp. It is more standardized, more graphical, breaks complex logic into smaller pieces, with less reliance on deeply nested functions.
Larry’s second suggestion, using AI to extract logic from legacy code and map it to his own proprietary rule language, is not a bad idea, but it has nothing to do with business empowerment. The sad truth is that most DMN Lite vendors don’t want business users anywhere near the decision logic. Just give us the requirements, please, and we’ll take it from there. That’s the old way, and still the predominant way… but it is not what DMN set out originally to do!
Often lost in the discussion is the important role of boxed expressions, such as the context Replenish item above. Most boxed expression types are two columns, variable name in the first, its value expression in the second. In combination with FEEL, boxed expressions are absolutely the key to Low-Code business automation! Trisotech, for example, uses them to make executable BPMN accessible to non-programmers. Like FEEL’s names with spaces, boxed expressions present an implementation challenge for tool vendors, because the value expression could be another boxed expression – tables nested within tables, so few vendors offer them. But boxed expressions are absolutely essential to turning complex expressions into a set of simpler ones.
Having said all this, there remains no doubt that vendor resistance to FEEL has caused DMN adoption to suffer in the marketplace. I am not opposed to including support for other expression languages. For example, I would welcome a tool that offered Power FX in combination with DMN boxed expressions. It would reduce the deep function nesting, which is Power FX’s biggest drawback. But the effort to restrict business users to requirements specification only is not the best path forward.
Leave a Comment
You must be logged in to post a comment.
