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:

**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.

- In 2011 I published the paper “
**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.

**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!