Domain-Specific Libraries of Decision Models

Our customers frequently build not one but multiple decision models for their business domains such as property and casualty insurance, loan origination, medical guidelines, etc. After building several decision models, they already have a quite rich glossary and various decision tables that essentially cover their business domain. So, it gives them a good foundation to build a library of relatively small decision models which can be used to assemble more complex decision models. Sometimes they even add domain-specific decision tables and supporting Java classes.

Here is a general architectural schema:

It includes multiple decision models with some of them being deployed as cloud-based decision microservices. It also includes a special Orchestration Decision Model that describes how to orchestrate other decision services.

The OpenRules release include a workspace “LoanOrigination” that implements a library of decision models for the Loan Origination domain using an example from the DMN Section 11. You may freely download it from here:

Extract (unzip) the downloaded files and you will get the folder “LoanOrigination” on your hard-drive. This folder contains several decision models that implement various small sub-goals and two main goals “BureauStrategy” and “Routing” deployed as external decision services:

This library is described in this BBC-2020 presentation: Building, Deploying, and Orchestrating Complex Decision Services.

Rules-Based Service Orchestration. OpenRules provides business users with abilities to build and deploy operational decision microservices. Now we empowered business users with an ability to assemble new decision services by orchestrating existing decision services independently of how they were built and deployed. The service orchestration logic is a business logic too, so it’s only natural to apply the decision modeling approach to orchestration. To orchestrate different decision (and other) services we create a special orchestration decision model that describes under which conditions such services should be invoked and how to react to their execution results.

OpenRules decision tables have special action-columns of the type “ActionExecute” that is usually used to execute other decision tables. To be able that to execute different services upon certain conditions, we expended “ActionExecute” with an ability to execute different external services by their unique names without worrying about their implementation and deployment. To describe such external services OpenRules added a special new table “DecisionService“. In the Loan Origination library the high-level goal “Loan Origination Result” is an example of the orchestration decision models. The orchestration logic here is relatively simple:

Execute decision service “BureauStrategy” that should determine the goal “Bureau Strategy”. If Bureau Strategy is DECLINE, then set Loan Origination Result to DECLINE, and stop. If Bureau Strategy is not DECLINE, then execute decision service “Routing” that will determine the goal “Routing”. If Routing is DECLINE, then set Loan Origination Result to DECLINE. If Routing is REFER, then set Loan Origination Result to REFER. If Routing is ACCEPT, then set Loan Origination Result to ACCEPT.

This logic can be naturally presented in the following table:

Here the third column “ActionExecute” may execute two decision services: “BureauStrategyService” and “RoutingService”. The actual implementation of these services is described in the following table:

The column “Service Type” defines these services as REST web services and provides their endpoints – in this particular case both services were deployed as AWS Lambda functions, the default OpenRules deployment destination (it was done with an instant click). The table “DecisionService” may have the 4th (optional) column

that describes the parameters of each service that correspond to the business concepts defined in eth common Glossary. If the column “Business Objects” is omitted (like in the above table), all business objects will be passed to all decision services even if “BureauStrategyService” doesn’t need BureauData.

Along with REST web services, we support other types of services. For example, you may get essentially faster execution by taking advantage of the fact that your services are deployed as AWS Lambdas by using their ARN addresses as endpoints:

If your decision services are deployed as AWS Lambda functions you even don’t have to provide the complete ARN addresses, and can simply write their names as in the following table:

OpenRules will automatically expand the name like “BureauStrategy” to “arn:aws:lambda:us-east-1:395608014566:function:BureauStrategy”.

Another supported type of services is regular Java classes automatically generated by OpenRules from decision models:

You also may invoke any static Java method, e.g. use Service Type “JavaMethod” and Service Endpoint “loan.origination.EmailService:send” to send an automatically generated email to the Applicant.