Just Not FEELing it

In a recent DecisionCAMP conference, in the “ask a vendor” free-for-all, I – once again – voiced my concerns about the inclusion of FEEL (Fairly Easy Expression Language) in the DMN (Decision Model and Notation) specification. This is an issue that I raised at the outset of my involvement with the working group, and continue to raise, as I do now.

To the extent that an expression language is a necessity – and of course it is – FEEL is not the solution. FEEL creates a barrier to entry by requiring the initiate to learn yet another language, when there is at our disposal a perfectly acceptable expression language, originated in Excel, now used by many spreadsheet clones, and clearly a global standard as it is used by hundreds of millions of practitioners. It just so happens that the most effective users of Excel are the key users of decision management tools – business analysts.

The resort to FEEL in many cases is an attempt to overcome what is a lack of capability in the model notation. Some practitioners even regard the modeling notation as just a way to “sketch” the models by the business analysts, so that they, the practitioners, may then “perfect” the models in FEEL language! In other cases, FEEL is used to implement procedural functions, negating the declarative intent of the model.

These examples of the use of FEEL defeat what I consider to be the principal reasons for DMN – to enable businesspeople to express AND MANAGE business logic. The abstraction of that logic out of language formalism into a visually descriptive but accurate and rigorous notation is key to achieving that goal.

I am not alone in this. Carlos Serrano-Morales of Sparkling Logic opined in the discussion that in practice the use of FEEL leads to models that defeat the purpose of interoperability. Called on to defend FEEL, Gary Hallmark of Oracle – one of the original – and principal advocate – of FEEL in the original DMN working group – made the acute observation that while he believed there was still a place for organizations like OMG, that in large measure it was the Open-Source community that was propagating modern day “standards”, suggesting to me that Gary’s views on FEEL have evolved. The glacial rate of evolution of DMN, compared to the dynamic demands of the decision modeling community, lead to the vendor work arounds, and constantly create customized evolutions of DMN/FEEL to meet client needs.

Over the last year or so, I have become acutely aware of the Babel of different scripting, expression and programming languages in the marketplace. This is due to my work on the ALE (Automated Language Extraction) product we, Sapiens Decision, are introducing to market. ALE uses Machine Learning and other methods to extract business logic from programming languages – and potentially natural language – and render that logic into normalized decision models, to be managed in a decision management tool.

We believed that the hundreds of billions of lines of code in COBOL legacy solutions were obvious targets for ALE to extract the business logic, and then manage as decision models in Sapiens Decision. Turns out that the real problem is the logic embedded in any/all computer language(s), even in the most modern of systems!

One representative, but striking, use case I will cite is a super-regional insurance company that recently implemented Sapiens Decision. This company is five years into a strategic re-organization that involved the implementation of a new, enterprise-wide, Policy Administration System (PAS), a classic step in modernization of a legacy insurance company. The CIO recently made the statement to a user group forum at Sapiens Decision that had they implemented decision management at the outset of their journey, they would have “saved tens of millions of dollars.” The reasons for the savings are multi-fold, a contributing factor being the proprietary language used by the PAS in implementing customized business logic. This leads to a combination of issues:

  • The need for a group of specialized (read: highly paid) developers with the knowledge of the unique language used by the PAS to perform customizations (of which there are – of necessity – a great many.
  • A classic combination of business analyst working with developers to implement the solution, leading to lengthy (and costly) implementation and change process.
  • Lengthy – and expensive processes to upgrade the PAS system as it progresses through its life cycle of version following version.

By removing the custom logic (and even a significant portion of the native logic) from the PAS, and having it rendered in decision models, the PAS is made “lightweight”. The decisions are exposed to the PAS as an API. The PAS becomes capable of being upgraded in compressed cycles, and able to be supported by a significantly smaller developer team. Business analysts become more effective, able to author and test their requirements directly; even more importantly they can manage the full scope of the business logic, and isolate change opportunities and process improvements without the deep archeological dives into the code previously necessary.

Given this great use case for decision management, the problem remains that the client has the very large body of existing code to be converted to decision models. Of course, we could manually extract the logic, but cost and time to value are dramatically collapsed using ALE.

This is one example of the use of ALE. To date we have faced client requirements to extract the business logic from an extraordinary variety of rule platforms and languages. The list (not exhaustive) includes COBOL, of course, but also Java, Python, and proprietary languages in several different enterprise systems, ETL tools, and business rule languages (an aside – yes, rule languages are about as bad as programming languages in terms of their proprietary nature, highly specialized technical staffs, the difficulty of traceability, and the entropy in the structure of rules in the rule repository over time.)

Clearly, the last thing the client seeks to do is re-embed any part of the logic, once it Is ultimately freed of language dependency, into yet another language, most particularly one supported by a relative handful of practitioners.

If anything, in this second decade of decision management, I am even more passionate in the belief that a declarative, visual representation of even the most complex business logic is the holy grail. I would be the first to admit that our current tools are far from sufficient to achieve this objective. In the next post I will provide – in the spirit of Open Source – my thoughts on the problems to be tackled together with ideas for solutions.

2 thoughts on “Just Not FEELing it

  1. Fred Lyne

    Thanks for this summary of this issue and your ideas to solve the problem. Agree with you 100% that a “declarative, visual representation” of a company’s business logic is the best way to manage policy and lower costs by putting this ability to change policy in the hands of the business people without the constant need to spend IT dollars to change it. Adding another layer of code is not the answer.

Comments are closed.