How We’ve Built a Micro Low-Code Platform to Help Insurance Business Users Change Business Logic Fast and Easy. Part II

Three years ago, the client tried to create a Rules engine for their multiple similar-looking user-facing insurance software applications. They failed back then but succeeded now, after Symfa joined.

undefined
9 min read
Client stories
Digital Transformation
Enterprise
Insurance

Three years ago, the client already made some attempts to create a Rules engine, but it didn’t work out. So, a year ago they gave it another go.

It was just the two of us at the start, me and Alex (the customer’s developer). We were given full creative freedom.

“Do whatever you want. We’ll get on a call every two weeks and you’ll show us what you’ve come up with,”  – the management told us. And that’s basically what we did. 

Hi, I’m Dmitry Denisko, Sr. Software Engineer at Symfa, and this is Part II of our Rules Engine story. Here we’ll talk more about the project challenges that I skipped in the first part of the story. I’ll also add a bit more tech details on how we’ve implemented the MS Rules Engine for a US-based Insurance Major. When you think of the insurance agency software, this system that we developed together with our client would hardly come to your mind first. But – boy – it is a real life savior for our insurance client which has to provide software for insurance agents.

Table of Contents

  • A teeny-tiny intro into the project for those who skipped the first part
  • What do we have so far?
  • How exactly can the results be aggregated?
    • Option 1 for results aggregation
    • Option 2 for results aggregation
  • What challenges to expect if you decide to go with such a custom insurance software project?
  • What benefits a year of development brought for the client?

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.

  1. 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.
  2. 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).
  3. 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.

How we improved business rules management for our insurance client

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.

What is a Workflow for Insurance Application?

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

  1. returns eligible
  2. returns refer
  3. 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?

  1. Logging every transaction is quite an expensive operation in terms of memory – a few gigabytes with a relatively small number of requests.
  2. 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

  • take some business rules out of working applications
  • put them into a database
  • call & use them and reuse them in other applications
  • modify them as needed without changing the main code.

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. 

  1. Therefore, the customer needed to make some centralized system, where the main logic would be stored.
  2. At the same time, the logic could be reused by other teams and 
  3. 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 custom software agency helps the insurance business

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.

Credits

Dmitry Denisko
Dmitry Denisko

Sr. Software Engineer

Dmitry's goal as a professional is to build highly performed, clean, and readable code along with designing scalable and maintainable solutions.

Self-motivated , result-oriented, with great respect for company values, Dmitry easily grasps new concepts, is studying new areas all the time, and raising his professional level.

Technology stack: C# .NET core, ASP.NET core web API, REST API, MS SQL, Redis, Microservices, RabbitMQ, gRPC, Docker, k8s, jaeger, prometheus, grafana

Dmitry's goal as a professional is to build highly performed, clean, and readable code along with designing scalable and maintainable solutions.

Self-motivated , result-oriented, with great respect for company values, Dmitry easily grasps new concepts, is studying new areas all the time, and raising his professional level.

Technology stack: C# .NET core, ASP.NET core web API, REST API, MS SQL, Redis, Microservices, RabbitMQ, gRPC, Docker, k8s, jaeger, prometheus, grafana

More Like This

BACK TO BLOG

Contact us

Our team will get back to you promptly to discuss the next steps