As the number and maturity of platforms supporting the Decision Model and Notation (DMN) standard continues to grow, it is time to take a look at the third Conformance Level defined in DMN. The Friendly Enough Expression Language (FEEL) is the language used by DMN to formalize decision logic in applicable points of a decision model. Conformance Level 3 supplements the notation and modeling in Conformance Level 1 and the decision table support defined in S-FEEL (simple Friendly Enough Expression Language) of Level 2 with the full FEEL expression language. FEEL provides powerful capabilities to satisfy the needs of DMN:
- Built-in types, functions and operators
- Enables a formal expression that can define every decision in a model
- Formal expressions that may be encapsulated as functions • Supports abstraction, composition, and scalability
With this capability in mind, let’s remind ourselves of the stated goals of DMN:
DMN will provide a common notation that:
- Is understandable by all business users – from requirements through
maintenance o Can be processed by technical developers responsible for
automation - Is manageable by business people who will manage and monitor decisions
- Create a standardized bridge for the gap between the decision design and implementation
- Designed to be useable alongside the standard BPMN business process notation
Paramount throughout these goals is the inclusion of business users. They should be able to model, create, analyze, implement and manage decisions. I think there’s no question that the expressive power of DMN for the first two levels of Conformance satisfies that need.
Nearly all DMN compliant platforms on the market now either have tooling for Conformance Level 1 (decision modeling; often with connectivity to execution engines) or they have modeling along with the capability to create and execute decision tables as defined in Conformance Level 2. Platforms implementing full FEEL are on the way. Having had the opportunity to work with one, I want to share several observations and one primary question: is FEEL too technical for DMN?
I found FEEL to be the proverbial wolf in sheep’s clothing: a very straightforward, understandable Decision Requirements Diagram (DRD) can hide some very detailed, programmatic, non-business friendly details. After I had completed my implementation proof of concept, my first reaction was that I was looking at a programming language. But the more I thought about it I realized I was perfectly fine with that. This is supported by two primary reasons.
First, as I have written previously, I do not believe decision tables alone are sufficient for implementing all decision logic. Period. I believe my exact words were “real world operational decisions are rife with logic that is often unclear and best addressed with a variety of decisioning artifacts and procedural steps.” Legacy business rule management systems provided a plethora of rule metaphors for expressing decision logic for this very reason. In the case of DMN, FEEL gives us this power. Can I ultimately implement everything I would want to in decision tables? Probably. I can also get a board into two pieces using a wrench and hammer but it’s easier, faster and cleaner if I use a saw. For example, I was can implement the capability to generate a monthly loan payment given the loan amount, loan term and interest rate in S-FEEL. It was ugly and it was complicated. The same task was trivial using FEEL and it gave me what I would want: a clear, reusable piece of code.
This example leads me to my second reason for being comfortable with the inclusion of FEEL. It is most often going to be used to implement mechanics or tools that won’t need to be created or managed by business. In the example I just presented, the calculation will never change. It’s written once and used in numerous places. I found my other detailed, technical segments of FEEL included sorting functions, collection functions, and assorted numerical calculations. None would require business intervention except to define where these activities would occur and when they’d be invoked. Conformance Level 1 gives us this and does so in a friendly, intuitive fashion fashion. This satisfies the goals of DMN while giving us all the firepower we need to handle real world operational decisions.
DMN Conformance Level 3 gives us the expressive power needed to completely model decision logic and, while its use and definition may require some technical intervention, it can be done in a way that satisfies the goals of this standard.
