Why Insurance Carriers are Choosing to Migrate to Microservices

It is like a world of Goliaths into which David came in quietly and shook up the norm. That happened almost 10 years ago when microservices made their debut with Amazon and Netflix. Insurance for long has been a stronghold for monolithic systems and all was good. There was no pressing need to break down these single-tiered monolithic applications into smaller chunks. Now though, many insurers are looking at long and short-term plans for digital transformation and the architecture to underpin this journey becomes vital. But is it right to say that monolithic systems are on their way out?

The evolution from mainframes to monolithic to microservices

Since the early days of software development in the 1950s, systems were deployed as a single process. These legacy mainframe monoliths written in COBOL were replaced later by core insurance systems written in new languages like Java. These systems combined all core functionality like claims, policy, and billing processes into one monolithic system, provided by a single vendor and this made it easier to maintain.

Then came the best of breed systems that broke down the core insurance systems to separate products for each process - policy, claims and finance. However, these ‘modern’ core insurance platforms were still built tightly within each module and had a relational database that was extremely complex and posed a number of hurdles in scalability.

This was the advent for more loosely coupled systems and the decomposing of this ‘one-piece’ into smaller chunks - and microservice architecture was born. It is quite apparent then that insurance technology has always been evolving, unlike the widely held belief that insurance is late to the party.

Are monolith platforms slowly but steadily getting phased out?

A monolithic architecture has been around for a long enough time to be established, understood, as well as trusted. Once this behemoth is in place it is quite scary to consider picking it apart. Having one entity has its benefits but the downside is that if there is a breakdown, the whole system has to be taken offline to discover the cause and fix the issue. And the complexity means that new IT resources taking over are going to find it near impossible to know the system back to front. This is the reason for carriers facing escalating technical costs because fixes are often like a bandaid on a gaping wound. 

A distributed system like that of the microservices with multiple modules that communicate with each other through APIs is replacing legacy applications. Further, each module in this open insurance system has its own database. If new functionality has to be added, only that small “chunk” of the module needs to be scaled up. That is the advantage of building microservices, the flexibility to take new features to market at a fast clip to keep in synch with the fast-changing insurance landscape.

The downside of the microservice architecture is that it requires multiple highly specialized internal IT teams or third-party expertise not just to develop and deploy but also in the maintenance and testing of the different microservices. That is why many insurance carriers opt for a single vendor, like SimpleSolve, that themselves take advantage of the services of other vendors in the ecosystem. The carriers themselves don’t have to manage this.  

Why traditional insurers are looking at change

Monolithic applications are finding it difficult to keep up with new demands on technology. It is like being trapped inside a bubble while the world outside is rapidly changing. Digital insurance companies like Lemonade, Root and Metromile are relative newcomers to the insurance industry but are breaking new ground through innovative use of technology. McKinsey calls the new digital insurance services “digital attackers” who operate differently from traditional insurers, taking away a share of customers from the incumbents through digital acquisition. These attackers often use external third-party data to develop a competitive pricing model. 

The more traditional insurance companies in the US have often tried to reuse their existing architecture in the new digital business model. The problem though is that a massive burden is being placed on legacy infrastructure that was never meant to support it. The digital attackers meanwhile have more modern flexible solutions. 

The best route to follow when migrating from Monolithic to Microservices 

Although breaking down the existing monolithic applications might seem an uphill battle there are certain ways to make the difficult possible during application modernization.

1. Stop adding new features to the monolithic platform and only fix what is broken

2. Look for components that can be easily pulled out and moved into a microservices platform.

3. Evaluate new requirements coming in and build them as microservices.

4. Slowly chip away at the monolithic framework by beginning on components that are of high value to the business. For example, if usage-based insurance is an important advancement then move the components necessary to support it.

The application programming interface (API) will be the mechanism through which all data will flow to the underlying services. As components are migrated, the monolithic architecture will also need to be modified so that an API proxy will be able to communicate with the monolithic system so that it can continue to perform the services that have not yet been migrated.

At the end of the day, digital transformation requires the creation of microservices to develop great products. And while microservices mean more granularity and hence more moving parts,  they are important for creating amazing digital experiences, think IoT for example.  Interested in knowing how SimpleSolve can help your organization migrate from a monolithic architecture? Let’s talk.