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
Injury rating
Calculate premiums
Conclusion
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.
Next…
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
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.
Hi Arash – I’m having trouble understanding what you mean here. You talk about exposing “the decision” as a service, but you have four decisions in your DRD. Does the service encapsulate all four (plus the BKMs)? If so, what orchestration do you need, other than providing the necessary data to the service? Perhaps your orchestration represents what happens inside the service, but it is odd anyway because the two BKMs are functionals, and would be called by the Determine Rating decision, yet you seem to have them orchestrated as separate tasks. Perhaps all will become clear in your next post 🙂
Hi Alan,
Thanks for the comment.
That is correct and good you point it out. Those KBMs are functional. There are two reasons for the orchestration in this article:
1. As datasources are external to DMN, we needed that orchestration to allow the data for “High theft probability auto list” be retrieved from database. (first task in the flow)
2. Show how the execution would happen, if you don’t use a DMN to deign the decision graph. In next one we replace the separate tasks of Decision Tables with the DRD.
Sorry for the confusion.
[…] In the last post, we discussed how to use different isolated decision tables in an orchestration as a decision flow. In this post what we do is using the same bases on the implemented decision tables, but this time we link them to a DMN model and we execute a DMN model. […]
[…] couple of previous post, we discussed how to orchestrate and link multiple decision table in a flow, and then how to model and execute decisions using DMN (Decision Model and Notation) approach. Now […]
[…] have shown previously use of a Decision Table modeling to model this set of logic. Now let’s see how we can model it in a Natural Language DSL using set of […]
[…] answer the business question, one or usually multiple business logic are involved. For example, the decision for calculation of an annual premium of a car which that has to answer two questions: How much are the Base Premium and Auto Premium of a […]