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?
Read all about it in my colleague's originally published blog. I have also given links above to related blogs that might interest you
Originally published at https://www.simplesolve.com on December 28, 2021.
