A teeny-tiny intro into the project for those who skipped the first part
I didn’t really mean – Do whatever you want – of course. There were some specific business requirements.
- This should be software for an insurance agency that would allow centralizing the company's core business logic, which was scattered across many different applications.
- The logic has to be converted into a format of entities that one can use as regular objects in the database (create, edit, delete, view, call).
- The client wanted a system that could interpret these entities.
But in terms of implementing these requirements, we had complete carte blanche.
Ideas would just pop up and we’d present them. We’d get an okay or a no-go from the management. Depending on the answer, we’d adjust our development trajectory. The team grew to include eight people and here’s what we’ve got in a year.
What do we have so far?
The fundamental idea is "Workflow" – a collection of CPP business rules that are somehow linked together. The application's business logic is presented graphically. The parent Workflow is at the top and can contain multiple nested Workflows.
The Workflow can be configured by the user through the UI and then integrated into their own CPP application. Each configured rule has a success or failure execution result. The user — the agent — receives the final result — quote approved or rejected — by aggregating the results of all executed rules.
If you have a sec, have a look at this Insurance BI application. This is another project that we took over from a different team working for this US Insurance Enterprise. The results are stunning!
How exactly can the results be aggregated?
In fact, there is no built-in mechanism for this in MS Rules Engine. There are two ways to handle this. Use whichever matches best your situation.
Option 1 for results aggregation
We’ve implemented an approach with the process handler – it is just a method that is hardcoded within an application and does aggregation on our side.
This issue can be solved by using rule grouping.
For example, there are three rules
- returns eligible
- returns refer
- returns decline
We know that if at least one rule returns decline then the entire flow is decline.
If there is no decline but at least one refer then the entire flow is refer (an agent should refer to the underwriter to proceed with the quote).
When using process handlers we simply hardcode it (create a process handler in the code on our side) and assign this handler to each workflow that operates eligibility. As a result, after executing the main logic in the Rules engine our code for aggregation will be executed.
Option 2 for results aggregation
The second option is to split the rules inside the Rules engine into groups (MS Rules engine supports grouping).
Then we can create groups for each type of the return value.
For example:
- group 1 (all rules that return decline)
- group 2 (all rules that return refer)
The main rule would look like this:
"execute group 1"
onSuccess: return decline
onFailure: execute group 2
This results in a kind of recursion, allowing to group the rules in an infinite set of nested rules. The result of each rule can be the next rule.
What challenges to expect if you decide to go with such a custom insurance software project?
Initially, we didn’t know if it was possible at all to implement a thing like that in our client’s business. It’s a micro low-code platform, you see. We created a system that could be used by other developers, business analysts and business users to write their own logic and execute it. However, we solved this challenge both for us and for you – it’s possible, so let’s keep going.
1. Cross environment implementation and Deployment
We racked our brains a bit on this one.
In the end, we’ve come up with a CI/CD process which allows users to migrate the rules from one environment (Development, UAT, Staging) to another, at this emulating the release process of a standard application.
We’ve also implemented separate access rights in the system. The live environment is protected from unauthorized changes (approval is required from a person who has the approval rights).
By the way, if you’re interested in deeper Insurance Infrastructure insights, here’s the IaC case for the same client.
2. Change history
The rules are created, changed, and at the same time someone uses them. Some third-party services, for example. Every request and every response should be logged somewhere. For this purpose, the Evaluation History portal was created, which you can enter and see who launched which workflow, the payload transmitted, and the response received.
Why is Change history so important?
Why not just store the logs in Splunk, for instance?
- Logging every transaction is quite an expensive operation in terms of memory – a few gigabytes with a relatively small number of requests.
- Security was also an issue. Since we log user input, it may contain data that the company does not want to send to external logging systems.
The availability of this data in OUR storage allows us to
- attach virtually any UI to it
- generate reports on demand or on a schedule
- notify on any errors and more.
|
As for the term micro low-code platform that I’m using here… If you refer to Wikipedia, it says: A low-code development platform (LCDP) provides a development environment used to create application software, generally through a graphical user interface (as opposed to only writing code, though some coding is possible and may be required)...A common benefit is that a wider range of people can contribute to the application's development, not only those with coding skills, but good governance is needed to be able to adhere to common rules and regulations It is impossible to create an application with the Rules engine. But you can
It looks more like some kind of Admin panel for the website content management only for business logic with low code elements. But for the sake of simplicity, let's leave it as it is – a micro low-code platform it is. |
Speaking about low code – if you’re thinking about some low-code/no-code solutions to implement in your next project, here’s a story from our Presales team. Bubble was the client’s first choice, but it didn’t work out as expected…
And our Founder’s take on low code, too!
But let’s see how my story ends now.
What benefits a year of development brought for the client?
Before Rules Engine, all business rules were hard-coded in multiple applications and scattered across dozens of teams. This logic was duplicated in multiple places and sometimes erroneously did not match, while it should have.
- Therefore, the customer needed to make some centralized system, where the main logic would be stored.
- At the same time, the logic could be reused by other teams and
- Have some UI to edit it without changing the code directly.
Thus, the project
- enables business analysts and business users with special training to make changes safely into the business logic on their own and
- centralizes change management and traceability.
And all this for insurance software products that have 1000+ business rules! Ambitious? You bet!
How do you feel about the project? Share your thoughts with us on our page on LinkedIn, or X, or send us an email directly using the form below. We provide honest insights on software solutions for the insurance industry based on our ongoing and completed projects. Experts insights only.
Want to implement this technology for your business? Ask us how.