Is FEEL a Barrier to DMN Adoption?

In his comment on a recent post, Nick Broom questions my embrace of FEEL, in particular my claim that it is reasonably business-friendly. He worries that in fact that FEEL will prove a barrier to DMN adoption, especially since decision management tools are being sold on the premise that "anyone can do it." A lot to unpack there, but let me try.

First, almost no one has any idea of what FEEL is. Their only source of information about it is the FEEL spec, which is chapter 10 of the DMN spec. It is totally impenetrable, I readily admit. I have come to understand it only after months of tutoring and repeated corrections by its author, Gary Hallmark, chair of the DMN RTF. Standards organizations like to say their specs are written for implementers not end users, but in reality much of it is written by PhDs in computer science for other PhDs in computer science. That is especially true for language specs. W3C's XPATH 2.0 spec is even more impenetrable to me, and that is a language I already know. So to learn what FEEL is, you need a book.

Then there is the question of what is a business user and what kind of decision modeling can a business user do. In my book I say that if you can use Excel formulas you can use FEEL. Now that's not all business users. Some can barely use Excel, period. I'm talking about the formulas tab, below.


I am told that the Excel formula syntax was considered as the DMN expression language before they settled on FEEL. FEEL syntax is actually more business-friendly, in my view. Consider this decision rule in "natural language" for the value of LoanStatus based on inputs Risk (allowed values Low, Medium, High) and PTI (payment to income ratio):

If Risk="Low" or "Medium" and PTI<0.3 then "Approved" else "Declined"
Here it is in Excel formula syntax:
Here it is in FEEL:
if Risk in ["Low", "Medium"] and PTI <0.3 then "Approved" else "Declined"
OK, which is more business-friendly?

Nick speculates that the reason why DMN vendors have not implemented FEEL is that it will scare away customers with the sense that DMN is "too hard." OK, so let's look at how the tool I am using in my DMN training models this decision rule. Oh wait, it doesn't support FEEL, cannot do if..then..else literal expressions at all. We can always use a decision table for that, right? Decision tables in DMN use a dirt-simple subset of FEEL called S-FEEL. S-FEEL expressions are limited to arithmetic and simple Boolean comparisons (e.g., Age>18), and in decision table cells (input entries) limited to a value, a range of values, or a list of same, possibly enclosed by "not()".

Here is how the decision rule above is supposed to look in a decision table (Rule 1) using S-FEEL:


Here is how it looks in my tool:


Yes, it's pretty close. But not exactly: the Risk input entries are not S-FEEL syntax. Is that to make them more understandable to business users? Please. It's to make it easier to implement using the libraries available to that tool vendor. I don't want to make a big deal of this tiny syntax difference. But think about it. This is in the simplest decision table imaginable. And decision tables can handle only a limited range of decision logic. Iteration, table query, data validation, and other common patterns require literal expressions and tables of literal expressions, called contexts. Once you get into literal expressions, every DMN tool has its own language. In that case, do you really even have a standard?

To say yes to that, you have to accept that the object is not really to make the decision logic executable. It's just to collect business requirements in a structured, validatable form - complete and consistent - that can be translated to a different business rule language for execution. That's kind of the state of the market right now. Decision Management Solutions is feeding requirements to ODM, Signavio to Drools, FICO to Blaze. That's why I say that even though DMN 1.0/1.1 adopted the mission statement of BPMN 2.0 - unifying modeling and execution - in practice it's more like BPMN 1.2, model-based requirements needing translation into some other execution language.