How we apply API-led connectivity & OutSystems for CPP modernization at an Insurance Giant

Let's start with the functional part and then switch to the development story.

This is a brand new insurance product related to a bunch of a similar group of projects.

The Restaurant bundle includes 4 quote types: Commercial Auto, Worker Compensation, Business Owner's Policy, Cyber.

These pages are for the info input – address, contact information, class code, etc. So, the application is quite straightforward and is mainly about forms filling. The user fills in the data, clicks on “save and continue” or “next”, moves on, and in the end, gets a fully filled-in quote. Then the user binds the quote to the policy and moves on to another application where he/she can proceed with the insurance policy. So, it’s some sort of a CRM for insurers.

First, we create all these fields to be filled in – the UI part – according to the mockups of the client’s designers.

Second, we do the initial validation and upload all entered data correctly for further processing and instant quote verification.

When a user enters, changes, or adds data, we need to collect this data for validation, save it to the local application cache to move ahead with the next page. Some minimum validation is done on the UI side – so that a letter is not entered where we expect a number and vice versa. We extract all the endpoint information and send it for deeper validations. Those deeper validation procedures are done via several services connected to Restaurant Insurance Soft (more on that later).

If data is valid, the user moves ahead. The page makes a request so that the entered data is saved. The user goes to the next page, and the saved data necessary to continue with the quote is automatically uploaded for this page. The process continues until the user – the agent – binds the quote to the policy.

We are doing a bunch of similar applications for this particular client. They aren’t really that complex in the UI part – be it software for health insurance companies, life insurance software or p&c insurance software. However, it’s the backend, data processing, project workflows and timelines that can be stressful. But more on that later.

We joined the project a month after it started, when there were only the designs and authorization ready. In fact, it was just a bare skeleton with a couple of functionalities working and only one developer from the customer’s side on the project. The two of us joined, and a really hot time started – we needed to go into production within two months.

A few days for onboarding and off we go working two shifts with our US-based colleague. But soon after that, he takes paternity leave for six weeks… The situation had changed for us.

In a few weeks we did go into production. Roughly 75% of the first product version that went into production was done by us.

We worked late. Me and Gleb are both based in Poland and there were a lot of details we had to figure out with the US management.

What’s more, when in production, the application needs constant support. Something is failing all the time. So we get into the logs, search for the root cause of the problem, either fix it on the UI side, or transfer the detailed description of the error to other teams on the projects that we’re closely connected to. It’s kind of a ping-pong game, if you have some dependencies, and in insurance you have a lot of them.

By the way, Gleb has been successfully splitting his capacity between this quote management software and a lightweight document management system -- another project for the same insurance client. This is Part I of the story and this is Part II told by Dmitry, Delivery Manager who works with Gleb on the document management project. Take a minute to look it through, if you've been thinking about using OutSystems for insurance software development.

As for Restaurant Insurance Soft, there are two key dependencies and several of secondary nature. I’ll focus only on the key ones here for the sake of clarity.

Our team works with the UI part using OutSystems. The UI part of multiple customer’s applications is made on OutSystems, a low-code platform.

Vertical Integration project is in charge of the business logic for Restaurant Insurance Soft, and is a purely backend project. It:

1. receives input data from the UI-part of Restaurant Insurance Soft
2. aggregates the data
3. refers it to another service/database
4. gets data from there, transforms it somehow, and then gives it to us. 

Let's call it a backend for frontend – an aggregator that goes to other applications/services, aggregates data, and then sends it to Restaurant Insurance Soft in an aggregated form.

So Restaurant Insurance Soft, a project on the low-code OutSystems, is connected to Vertical Integration project in everything concerning data uploading and sending. This is clear for now.

Vertical Integration project aggregates the data and sends it further down the pipeline.

In Restaurant Insurance Soft’s case data is sent to Rules Engine. Rules Engine – centralized business rules storage for multiple similar applications – runs the data through the business rules, and checks whether it is possible to continue with this quote, since the data entered might be invalid or violate the insurance rules. 

• The address might not exist or
• The data entered does not allow an insurance policy – the insurance limit has been exceeded, the building is too old, etc. 

That is, the non-qualifying quote will be declined at the stage of quote filling.

Restaurant Insurance Soft sends a request to the Vertical Integration project, and the Vertical Integration project sends it to Rules Engine. Rules Engine finds out if everything is okay and if we can continue. If a quote is not eligible, the agent receives a declination message – the error is displayed in the UI so that the user can understand what needs to be corrected. The user can make the following corrections:

– change the address

– reduce the insurance payout limit

– change the year of construction, etc.

and proceed further, if the initial data was simply put wrong and no insurance rules were violated, in fact.

Since our insurance customer has 

1. Legacy core systems
2. a lot of projects very similar in nature to one another

an architecture called API-led Connectivity is a great fit. This is something akin to microservices.

There are many reusable and purposeful APIs which are developed to play a specific role: unlocking data from systems, composing data into processes, or delivering an experience. If I need this functionality, I reach out to a specific service and get the job done. Instead of reinventing the wheel, I use this tiny functionality common for multiple projects to 

• get the data or
• process it in some way or
• make it look pretty or 
• fix the message so that it becomes more detailed, etc.

In fact, we have a bunch of APIs, which communicate with each other through API requests – GET, POST, PUT, PATCH.

And we have a single database at the core of all our activities. I mentioned microservices before – the idea is very similar. But for each microservices, there is its own database. Here, we have a huge database – the legacy we all need to access. But not all services need direct access to the legacy database. Tiered API-led connectivity allows for a safe connection to the legacy database and reliable data interchange and processing. Therefore the division.

There are lower level services that can handle the database. There are those in charge of the business rules. There are top-layer applications, like our back-end for frontend which does not directly access the database. If it is necessary to put or get something from the database, they will contact the appropriate service.

That is, API-led connectivity looks like this, if put simply.

1. Experience APIs: A top-level Backend for Frontend. For each UI app there is is own little project, which would aggregate the data.
2. Process APIs: An intermediate level, where business logic concentrates. In our case, this is Rules Engine that will handle the requests from one or multiple applications.
3. System APIs: The lower layer that can be either a data provider or a database (in our case).

Therefore, Restaurant Insurance Soft is a GUI application and more effort goes into UI work. Vertical Integration project application acts as an aggregator, which collects data. Rules Engine provides deep data validation. Together, these three projects allow the agents to automatically create, fill in and validate the quotes in a matter of minutes.

1. Active development phase is continuing. New features are being actively implemented, we’re far from reaching the support phase.
2. Some unobvious bugs show up that we need to take care of.
3. Things became less trivial. We implement more UI validations. In other words, why send out delirious data if we can cut it on our side somehow?!
4. Dev Research. For each new task we give our conclusion for the BAs and PMs what resources the task will require, what’s ready and what’s not to start with the task, which team takes the task (Restaurant Insurance Soft, Vertical Integration project or Rules Engine) or how many teams are going to be involved at all.

As for the dev research, Symfa is one of the few insurance software companies where developers are super versatile and can cover for QA, BAs or PMs, if the project requires our extra commitment. The client not for once recognized our dedication which – as they thought – was unthinkable from an outsourced vendor.

As soon as we go live, we get immediate feedback. The manager approaches us directly and says, "Well, the agents feel like they need some extra functionality.” And we start fixing straight away.

For example, here’s the page with yes or no questions. Instead of clicking with the mouse, the agents want to switch between questions using the Tab key. It’s all about CX, so we’ll have a task for that.

Business analysts have their own vision of the task, but a technical assessment must also be provided.

We now have 15-min calls after or before the daily meetup with the management to discuss the tasks. Before, we had a textual description of the task and usually it required tons of comments that would spread for several weeks, or even months sometimes! So, it’s not really the development effort that only matters, but the effective processes, too. Sometimes the job can be done in a week and sometimes in a month, while the reason for this gap would be miscommunication and bureaucracy.

The first stable version of the application for production was released by Symfa, with all the acknowledgement of our customer’s contribution. We started with 6 states, now there are 37 states and the product is delivering value for the insurer every day.

The team's proactive approach is appreciated and acknowledged. Now it's a bit easier, because we have to take care of the project only during our working hours. If it's 10 pm in Poland, the US-based developer catches up, and we can relax a bit. Which is somewhat a luxury for us now, to be honest, ‘cause we’ve been through some seriously hot seasons!

A couple of weeks ago, Director IT sent us his words of gratitude through the Account manager at Symfa. Sounds like a happy ending, huh? But we’re nowhere near the end, as this digital transformation journey for our client has spread across 40 projects and about 20 teams at Symfa. 

Have a look at this BI and ETL development project to get the scale of the initiatives we’ve been undertaking together.

Come back for more true enterprise development stories. We post regularly about property and casualty insurance software, insurance rating software, etc. and how it’s built. Follow us on LinkedIn  and X to be the first to know about our recent projects!