Decision Modeling: Declarative vs Procedural

The ultimate objective of Business Decision Modeling:

A business analyst (subject matter expert) defines a business problem, and a smart decision engine solves the problem by finding the best possible decision.

Declarative decision modeling assumes that a business user specifies WHAT TO DO and a decision engine figures out HOW TO DO it. This is quite opposite to the Procedural approach frequently used in traditional programming.

As a community of BR/DM vendors and practitioners over the last 15 years we made dramatic progress in this direction. Are we happy where we are today? Do our rule and decision engines are smart enough or they still ask too much from our business users? These questions came up several times during DecisionCAMP-2022 which is a part of the larger event symbolically called Declarative AI.

For example, in my presentation, I demonstrated good, bad, and ugly solutions for a real-world problem. But even my “good enough” solution forced a business user to define several nested loops. OK, OpenRules allowed me to present those loops in a nice table format, but it still doesn’t sit well with me. So, I asked the question: Was it really necessary to use these loops? By using similar decision modeling constructs (many of which are included in the DMN standard) we force our users to procedurally specify HOW to find a decision. Contrary to our initial objective.

During the DecisionCAMP-2022’s expert panel, I raised the question: “Are our engines smart enough?” You may watch this discussion and make your judgment about the answers. In general, the experts believe that today we still have plenty of low-hanging fruits for our “smart enough” decision engines. There was even this comment after my presentation: “I don’t really see the problem here. My experience is that people are quite happy to think procedurally. They understand doing the same thing several times in a row.” Probably it was ironic, so was my answer: “People are happy today to drive cars, but in ~20 years kids will ask: Daddy, did you really drive those cars yourselves? Were you crazy?“

I am trying to raise this question for a while – see for instance my post “Model-based vs. Method-based Approaches to Decision Modeling” after DecisionCAMP-2018.

Anyway, after all these discussions, I decided that it is not enough to raise questions or just talk about the future of decision engines. I need to demonstrate their potential capabilities using concrete examples. Below I will describe several of such examples.

Simple Example: Declarative vs Procedural in Java

Let’s consider a very simple arithmetic problem:

There are 3 variables X, Y, and Z that can take values from 1 to 10 (or a larger number). We know that X < Y and X+Y=Z. We need to find their values that maximize the Cost = 4XY – 5Z.

Procedural Solution. Here is the solution written in plain Java:

Procedural Solution

This program is a typical procedural code with nested loops that specifies exactly how to solve the problem. It works but brings immediate questions:

• Can we recognize our business problem by looking at this solution?
• Will we start the 4th loop if we need to add another variable that is in relationship with X, Y, Z, and Cost?
• Would it still perform well for problems of a larger size (e.g. max=10,000)?

Declarative Solution. Now I will show you a declarative representation of the same problem:

Declarative Solution

This declarative solution clearly separates Problem Definition in the method define() and Problem Resolution in the default method maximize() provided by the standard parent class JavaSolver. There are no loops and any code that specifies how to solve the problem. This solution only defines the problem and our decision service solves it! It also provides positive answers to the above questions.

Performance Comparison. Now let’s compare the performance of these two solutions for different sizes of the problem specified by the parameter “max”.

As you can see, the declarative solution was found in 1 second vs 3 minutes for max=10,000 and in 10 seconds vs 27 minutes for max=20,000. It is ~200 times better performance! Thus, the declarative solution is not only user-friendlier but also provides incomparably better performance for problems of large sizes with which we deal in real-world applications.

Note. The provided declarative solution is based on the open-source Java Solver that implements the JSR-331 standard and can be added today for free to any BR/DM tool.

Loan Origination Example: Declarative vs Procedural using Decision Engines

Let’s consider a typical decision model such as the notorious Loan Origination problem described in the DMN Section 11. There are many solutions to this problem implemented using various BR&DM tools, e.g. you can see, download, and run the OpenRules solution. All these solutions assume that a loan request contains the exact numbers for Loan Amount, Loan Term, and probably Loan Rate. If such a request is rejected by the proper rules-based service then a requester will also receive some explanations for the rejection.

However, why not make this decision-making application more flexible by asking a user to enter only preferable ranges on loan amount and loan term? It may be done in the following simple dialog:

When a user clicks on the button “EVALUATE” s/he expects to receive the best possible loan offer or if rejected s/he may expand the requested ranges or remove them at all. In the background, our smart decision service is supposed to find the maximum acceptable loan amount with a corresponding loan term among all acceptable loan offers. If it is impossible to find any acceptable loan for this borrower, the request will be rejected with an explanation.

Note. During DecisionCAMP two presenters mentioned similar business problems concentrating on how to provide explanations for rejected loan requests. Greg Ottosson said it is not acceptable to offer a “try-and-fail” approach to a loan borrower by asking her to manually try different combinations of loan amounts and terms. Alan Fish even said we should be able to support the following conversation:

Thus, we need to find a generic approach that solves similar problems by empowering the proper decision-making applications with smarter decision services.

Can our current rule (decision) engines do it?

Procedural Solution. A trivial solution for the above problem can be implemented using two loops and calling any currently available decision service multiple times. Here is the proper pseudocode:

As you can see, this solution with a nested loop looks very similar to the procedural solution to the arithmetic problem described above with all its cons and pros. It would not be acceptable in many practical cases.

Declarative Solution. What a declarative representation of the same problem should look like? Ideally, it should look very close to any DMN-like representation of the proper decision model with similarly looking decision tables. However, there will be one big difference: the majority of decision variables (except pure input data) should become unknowns defined within some domains. For example, the decision variable Loan Amount can be defined within domain 50000-75000. If we don’t limit our main goal variables then our decision model has to produce a solution or point us to errors in the user request or inside the decision model itself.

Thus, from a user perspective, the decision model will look as friendly as the current DMN-like decision model (preferably without loops and other programming constructs). However, from the implementation perspective, the current sequential rule engines cannot support the required functionality. We need new inferential rule engines! How could they be implemented is a question for each vendor.

There are several possible approaches and even supporting tools that could be utilized to implement a new generation of rule engines. Here I will only list some of them:

1. Constraint-based Approach
   • In 2011 I published the paper “Representing and Solving Rule-Based Decision Models with Constraint Solvers” published at LNCS 7018, pp. 208-221, 2011, Springer-Verlag Berlin Heidelberg 2011. It has 5,000+ reads at Research Gate. It directs us to the practical solution for smarter decision models without forcing a user to describe how to find multiple and optimal decisions. However, in this article and its continuation I also described the limitations of the proposed approach.
   • This approach was implemented as OpenRules Rule Solver which is capable to utilize off-the-shelf constraint solvers compliant with the JSR-331 standard. You may see its live demo online without any installation from http://openjvm.jvmhost.net/WhatIfAnalyzer/. It includes an interactive solution to the Loan Calculation problem similar to the above one.
   • Another implementation of a similar approach was done a few years ago by KU Leuven researchers who suggested a constraint-based extension for the DMN standard called cDMN.
   • In the last few years, similar approaches started to be considered by Red Hat and FICO using their optimization tools.
2. Enhanced RETE
   • It is quite possible that the classical RETE algorithm invented by Dr. Charles Forgy 40 years ago may get a new life by trying to resolve problems similar to the described ones.
3. A New Approach
   • The described business problems are similar but still quite different from typical constraint satisfaction and optimization problems (they usually are much easier). So, I expect that within a few years we will see completely new implementations of much smarter rule/decision engines!