A simplified car insurance scenario designed to calculate premium involves the execution of different decisions, such as those shown in the diagram below:


The challenge is in orchestrating the execution of multiple decisions and sharing some state between them. As this model demonstrates, the “High theft probability auto list” is an input to the rating sub-decision.
As you can guess, there are two options for that:

  • Client application (i.e., web application, mobile, etc.) loads the list and passes it across
  • A decision service that hosts the decision retrieves the data and passes it to the decision

In an enterprise, what you really need is to have a way of orchestrating the execution of the whole scenario – something like the decision flow shown below:


And a way to host this Decision as a Service is to allow the whole enterprise (with as many different technologies, devices and platforms as it has) to be able to consume this service and drive the result for calculating the premium. If you can simply host this decision flow and provide a Web API for execution, then no matter what sort of application (i.e., web application, mobile or tablet, Android, iOS, Windows form, Max OS, etc.) you have, they all can consume it as a single source of truth.

Load High-Risk Cars from DB

This first action in the decision flow above is to retrieve data from the database, and in the execution context other Decision Tables can then retrieve the list for high-risk-cars.
The action has a simple implementation, which is to just select cars from the database as shown below:

The next Decision Tables are defined below:

Theft rating

DT-Define potential theft rating

Injury rating

DT-Define potential occupant injury rating

Calculate premiums

DT-Calculate premiums


In an enterprise, you would need to:
1. Have a better way of orchestrating decisions – Flow can get really big and hard to maintain
2. Expose the Decision as a Service with a Web API end point for execution
3. Use different data sources for different environment spaces (i.e., QA, staging, Production, etc.)
4. Manage multiple versions of the decision

In the next post we are going to show how to simplify the flow. Then we will discuss the above requirements (on hosting decisions) and see how you can model and execute this particular example scenario in a better way, and also host it as a service using FlexRule Server , which can fulfill those requirements.

FlexRule Server simply allows hosting decisions as a Web API Service, so that all technologies, devices and platform can execute (and manage) a business decision and business rules.


In the next post, I will show you how to avoid implementing the decisions in a process as a sequential flow. That approach helps you to encapsulate the whole decision making process into a single task, which makes your process much simpler and flexible to change.
Read more at https://www.flexrule.com/archives/execute-decision-model-and-notation-dmn/.

(*) For details of rule implementation please visit our wiki site at https://resource.flexrule.com/knowledge-base/car-insurance/#business-rules

Last updated October 11th, 2019 at 10:26 am, Published April 14th, 2015 at 10:26 am