Architecture

OpenRules Decision Manager helps enterprises develop operational decision services for their decision-making business applications. The top-level architecture is shown on the above picture where a stateful decision-making application invokes stateless operational decision services. These services are based on business decision models usually created and maintained by business analysts in the Rules Repository using only familiar tools such as Excel (or Google Sheets) and a file manager. Tested decision models can be deployed on-premise or on cloud using the standard frameworks provided by major vendors.

Technical Architecture

The following architectural diagram explains how OpenRules Decision Manager helps users to design, deploy, and execute Operational Decision Services:

Implementation Steps. Business analysts (subject matter experts with no programming experience) use OpenRules to create, test, and maintain business decision models. They use their favorite tool (Excel or Google Sheets) as a  rule editor to represent business logic in decision tables placed in Excel files distributed between different folders – see examples of business decision models here. They create test cases directly in Excel to make sure that their decision models are always operational.  When business analysts click on the provided batch file “test.bat”, OpenRules internally converts an Excel-based model into highly efficient Java code and applies a highly powerful Decision Engine to execute it against the provided test cases. It produces decisions with detailed explanations.

The development of operational decision models usually  goes through 4 major steps presented on the picture above:

Steps . You start will a 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, you gain a good understanding of the business problem and move to the Step 3.

Steps  – . You start adding business logic in the form of rules, decision tables, and/or programming constructs, which with the Glossary and Test cases will comprise your Decision Model. This is an iterative process: as you implement a new piece of decision logic (e.g. add a new decision table), you execute your model against your test cases to make sure that it works and produces the expected results.

Usually business analysts implement business logic in Excel tables and execute this logic using the standard Rule Engine.
If some business rules should be automatically discovered based on your historical data, your decision model may also utilize Machine Learning components provided by Rule Learner.
If your model needs to solve optimization sub-problems, you may takes advantage of Rule Solver. Both Rule Learner and Rule Solver are naturally integrated into the Decision Manager and work together with its Rule Engine.

Thus, OpenRules-based Decision Models 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 Java APIs supported by Rule Learner and Rule Solver.

Step . Tested business decision models can be easily integrated in any Java application using a simple Java API, or used on any server like Apache Tomcat and IBM WebSphere, or being deployed on cloud as a decision microservice utilizing any serverless architecture provided by  major cloud vendors such as Amazon, Google, Microsoft, or IBM. Different deployment options are presented on the following diagram and described in more details here.

DevelopDeployExecute

Serverless Architecture with Decision Microservices

Decision Microservices and Serverless Architecture quickly become the de-facto approach for many modern decision-making applications. OpenRules support the development of domain-specific microservices as described on the following diagram:

It includes rules-based service orchestration with an ability to assemble new decision services by orchestrating existing decision services.

To “choreographing” decision services with event streams you may use rules-based state machines.

A detailed diagram for the OpenRules AWS Tracker can be found here.