Business Rules and Decision Management movement always had this ultimate objective:

A business analyst (subject matter expert) defines a business problem and a smart decision engine solves the problem by finding the proper 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 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 the just finished DecisionCAMP.

For example, during 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’s expert panel, I raised the question “Are our engines smart enough?”: you may watch this discussion and make your conclusions about the answers. In general, the experts believe that today we have enough 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?“

Anyway, after 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 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 solution written in plain Java:

Procedural Solution

This program is a typical procedural code with 3 nested loops that specifies exactly how to solve the problem.

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!

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

Thus, the declarative solution is not only user-friendlier but it also provides incomparably better performance for problems of larger sizes with which we really deals 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 used today for free by any tool.

Loan Origination Example: Declarative vs Procedural in Java

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 expect that a loan request contains the exact numbers for the requested Loan Amount, Loan Term and probably Loan Rate. If such a request is rejected by the proper rules-based service a requester will also receive the explanations for the rejection.

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

In this case, our decision service is supposed to be smart enough to offer a user the maximum acceptable loan amount with a corresponding loan term. If it is impossible to find any acceptable loan within these ranges, the request still will be requested with an explanation.

Note. During DecisionCAMP two presenters considered the similar business problem discussing how to provide explanations for why a loan request was rejected. Greg Ottosson said it is not acceptable to offer a user (such as a loan borrower) the “try-and-fail” asking him/her to try different combinations of loan amounts and terms. Alan Fish even offered to implement the following conversation:

The described approach solves similar problems by empowering the proper decision-making application with smarter decision services.

Can our current rule (decision) engine to do it?

Procedural Solution. A trivial solution can be implemented using two loops as in the following 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.

Declarative Solution. How 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 of pure input data) should become unknowns defined in 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 have to produce a solution because otherwise it will point us to errors inside the decision model itself.

Thus, from a user perspective the decision model will look as friendly as the current DMN-like decision model. 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 to each vendor.

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

1. 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.
2. In 2011 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 try it 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.
3. 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.
4. In the last few years similar approaches started to be considered by Red Had and FICO using their optimization tools.
5. 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 the problems similar to the described ones.
6. 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 soon we will see completely new implementations of much smarter rule/decision engines!