On June 30 I will present “Developing Decision Optimization Microservices for Real-World Decision-Making Applications” at DecisionCAMP-2020. Preparing my presentation, I thought about the major points I want to make. Of course, first of all, I want to demonstrate how to develop optimization services, but I also want to stress how the proposed approach helps to bring already great optimization tools into the everyday reality of business application development.

Over the years, I wrote about decision optimization many times – just click on the menu-item “Optimization” on this blog or read this quite popular paper. Yes, it is a good practical approach to split a business problem in two sub-problems and use off-the-shelf tools to represent and solve them:

• Business Sub-Problem – use any off-the-shelf BR tools (rule engines)
• Optimization Sub-Problem – use any off-the-shelf Constraint or Linear/MIP solvers.

So, first I will do a live demo of a simple business problem with an optimization component to show how it can be done using this implementation schema:

Business people are still frequently scare of Optimization in general, so I tried to demystify it by explaining that nowadays it is relatively simple to represent and solve optimization problems using modern off-the-shelf constraint/linear solvers. I even used DMN-like tables in Excel to do it with Rule Solver. In my DecisionCAMP’s presentation I will be using JavaSolver to define and solve a minimization problem, and then I will show a very important advantage of JavaSolver: an ability to switch between different constraint/linear solvers without any changes in the model itself! So, I plan to demonstrate how it can be done by only changing a solver name in the “pom.xml” file.

However, there is another, even more important point, I want to make. Look at this architectural schema with 4 major steps for development of operational decision models:

[1]<=>[2]. As it is already quite common for decision modeling, we start will Problem Description in plain English following by creation of the Business Glossary and Test Cases with examples of inputs and expected results. After several iterations and gaining a good understanding of the business problem, we start adding business logic in the form of rules, decision tables, and/or programming constructs. Our objective at this point is to develop an executable Decision Model capable to produce the expected results.

[2]<=>[3]. This is also an iterative process – see how beautifully Carole-Ann Berlioz recently demonstrated this approach in her video. The Decision Model can cover different types of logic based on expert knowledge (Business Rules), historical data (Machine Learning), or mathematical models (Optimization). Correspondingly, the decision model can utilize off-the-shelf rule engines, rule learners, and constraint or linear solvers.

Based on the requires skills, the steps 1, 2, and 3 can be done by Business Analysts or, if necessary, they can involve software developers to code some parts of the decision model using standard APIs such as JavaSolver. At the heart of the proposed approach is incorporation of optimization code into business decision models! For example, I will define a Business Sub-Problem in Excel tables and a Optimization Sub-Problem in Java. However, the Java code will be incorporated into a larger business decision model using the following Excel-based table of the type “Code”:

[4]. This approach not only allows the optimization model to be tested using already developed test cases. It also helps to utilize the existing deployment mechanisms. For examples, in my previously published examples, I demonstrated how OpenRules Decision Manager supports instant deployment of optimization services as AWS Lambdas or RESTful web-services. Even when a decision model is a pure optimization model, it still makes sense to wrap it into a business model “dress” like I did in the recently created Worker Scheduler.

People who implement decision optimization services can choose from a rich set of underlying Constraint or Linear/MIP solvers, and with the proposed approach they do not have to commit to any of them. They may concentrate on the representation of their optimization model as a component of a larger business (!) decision model with clearly specified input and output, test cases, and the invocation mechanism common for all other decision services (e.g. JSON). I believe such approach helps to bring already great optimization tools to the real-world of business application development.