If DMN just wanted to be a requirements-gathering notation along the lines of BPMN 1.x, DRDs and decision tables would be enough. (And unfortunately, to many decision management vendors and consultants, those are enough!) But DMN has higher aspirations. Like BPMN 2.0, it seeks to unify modeling and execution in a single language, accessible to business people but powerful enough to handle real-world decision logic. In the end, DMN had to invent that language, called FEEL. Having used it a bit, I can say that it accomplishes those goals. It is reasonably business-friendly and at the same time, quite powerful. Now the only challenge is to get DMN vendors to support it.
FEEL is not a programming language, just an expression language. The best explanation of what that means comes from Michael Kay writing about XPATH 2.0, a similar expression language:
Every expression takes one or more values as its inputs, and produces a value as its output…. One of the things an expression language tries to achieve is that wherever you can use a value, you can replace it with an expression that is evaluated to produce that value…. This property is called composability: expressions can be used anywhere that values are permitted.
A FEEL expression is a formula that produces a value. FEEL expressions can reference variables, but unlike a programming language, FEEL cannot create variables. It is like the language used in Excel formulas, which is a far simpler thing than javascript or VBA, which are used in Excel macros. For that reason, I say it is indeed business-accessible.
FEEL defines just a few datatypes: string, boolean, number, and a few date, time, and duration types. These types can be restricted to enumerated values or ranges, and can be combined to form complex data structures. FEEL variables may include lists and tables, as well. FEEL provides a large number of built-in functions and operators. For example,
Order.Item[price >= 10]means from a table Order, select all rows (Item) with a price greater than or equal to 10. In addition to table queries and joins, FEEL expressions can do iteration, datatype validation, list sorting, and lots of other powerful things. FEEL expressions can invoke reusable functions, like
paymentAmt(principalAmt, ratePct, termMonths).What that means is that instead of handing off iteration to BPMN and handing off queries to SQL, DMN logic can do the end-to-end decision logic itself. So why aren’t DMN vendors rushing to support it?
Basically, it’s too much work. No Java or javascript libraries for it exist yet, so the vendors would have to parse the FEEL expressions and do the translation themselves. Better to wait for someone else to do it. Naturally, they say, “Our customers aren’t asking for it.” AS IF!!! It’s not like the expression languages used in first-generation DMN tools are more powerful than FEEL. In fact, just the opposite.
Eventually it will happen.
Hi Bruce,
For me, FEEL is one of the things that I think could be the real barrier to business adoption, so I was wondering if you could further qualify ‘It is reasonably business-friendly and at the same time, quite powerful’? I firmly agree that a standardised way of expressing things is key – the graphical diagrams in DMN have nothing like the same power as those in BPMN – the actual logic, the stuff people care about, is in the tables and expressions. Maybe it’s from trying to learn FEEL from the spec (hopefully the book will really make it accessible) and maybe it’s because we are still at 1.x, but I do believe there will be challenges with the use of FEEL.
For me, the detail is in the definition of ‘business’ – making something business-friendly is a term that has been used an awful lot to underpin the purpose and benefits of DMN, both in the LinkedIn discussions and the spec. In addition, saying that something is business-friendly, doesn’t require programmers etc etc, is the way in which the sales people will make their money, otherwise no client will ever invest in the tooling or, ironically, the services and training proffered by consultants and tool vendors to support this supposedly easier way of doing things.
Is FEEL really ‘friendly enough’?. Friendly enough once people have got to grips with it, perhaps, but that immediately reduces the pool of people that will genuinely do decision modelling, and thus ‘business-friendly’ becomes something much more specific.
So do you see this as ‘friendly enough for business analysts’, or ‘friendly enough for all business users (irrespective of skillset)’, or something that has to be defined per client?
The key risk, from my experience, is this: decision modelling is a skill (which is why there is training required and I genuinely hope yours develops into the excellent standards set by your BPMN training). But the upper echelons of management that I’ve seen so far have bought into decision modelling because of a misguided belief that ‘anyone can do it’. Not only does that entirely devalue it, it immediately creates an environment where bad practices develop from the off, the time and money is NOT invested in working out what is actually required to do it well and the whole thing unravels.
So bringing that back to the question of FEEL, I think there is also an element that tool vendors are not supporting it because it limits their initial offering – they’d have to understand it (your point about too much work) and they’d have to be able to sell it and without the former they can’t do the latter. But I suspect the former is down to the fact that there is a genuine question around whether it is genuinely ‘friendly enough’.
I welcome your thoughts
Nick
Nick, I can’t do justice to this in a comment thread. It needs a separate post, which I will do this week. Instead of saying FEEL reduces the pool of people that can do decision modeling, I would say that if a business person cannot use a particular expression or function, that reduces the richness of decision logic that person can model. In that case we’re limiting it to decision tables. If you just use decision tables for everything, then S-FEEL (the subset of FEEL used in decision tables) is as simple as anything else you might imagine. But table queries, iteration, data validation… they go beyond decision tables. So you need a language. The problem isn’t that other languages do those with simpler syntax. The syntax is just as “complicated” and it’s tool-specific.