Understanding the business value of microservices architecture for insurers

Publish date:

Insurers today are progressing their core digital transformation journey to leverage the business value of “going digital.”

In fact, more than 35% of insurers said they had upgraded their back-end core systems – such as policy administration and claims – to support digital transformation, according to a survey in the World Insurance Report (WIR) 2018 from Capgemini and Efma. Property and casualty insurers are especially enthusiastic about modernizing their systems.

However, even as some insurers continue to build a robust digital foundation for their systems, customer expectations are growing every day. It has become paramount that insurers be agile in their business and adopt a rapid pace of change. Because slow-moving, monolithic applications can hinder an insurer’s response to dynamic market conditions, some insurers are exploring (and embracing) a microservices architecture.

In order to understand their business value, it’s important to first understand what microservices are and how they differ from what’s been done before.

What are microservices?

Microservices are part of a software development approach that has recently grown more popular. The approach is designed to build single-function modules with well-defined interfaces and operations. These modules are essentially micro-applications that enable a specific granular business function such as payment, issuance of policy documents, or first notice of loss (FNOL) submission. A micro-application can be independently deployed and can communicate with other micro applications serving other business functions. This approach differs from development of monolithic applications – such as policy administration, billing, and claims systems – that tightly aggregate multiple business functions together and are deployed as a large, monolithic unit. It’s useful to note, of course, that the term “monolithic” in insurance systems has historically been used to describe systems that do all of those things (policy, billing, and claims together), while “modular” meant just one of those things. Now, modular isn’t modular enough!

Microservices characteristics:

  • They are granular, independently packaged services.
  • They are function-oriented, with each microservice performing a specific business function.
  • They are designed for continuous delivery and deployment.
  • They communicate with other microservices through common lightweight protocols such as RESTful APIs.
  • They are platform and language-agnostic. Different microservices within an application can be developed within different programming languages or platforms as they have universal standards for communication.

Microservices are usually organized around business capabilities and priorities. Therefore, they can be developed independently or in parallel by cross-functional teams, with each team responsible for a microservice or set of microservices end-to-end. Software built as microservices can be broken into multiple component services, so each can be deployed, tweaked, and then redeployed independently with no compromise to the integrity of an application.

How are microservices related to APIs and web services?

Microservices may be confused with APIs and web services due to some similar characteristics and benefits. While microservices are an approach to designing software applications, APIs and web services enable interoperable communication between different applications or devices. In other words, microservices tend to operate within an application (or in some cases, when properly orchestrated, are the application), while APIs/web services tend to operate between applications – though exceptions in both cases exist.[1]

APIs are a set of tools and standards that typically help two completely different applications communicate with each other. The service provider application exposes its data or functionality through an API to other applications so they can use the specific standards of communication to consume that data or functionality. For example, through Google APIs, Google Maps can be used by other apps such as Uber (and in that example, vice versa!). Web services are a kind of subset of APIs. They perform largely the same function, but web services are a set of standards that enable two applications to communicate specifically over the internet using the HTTP protocol and other specific protocols such as SOAP.

To give an imperfect but simple analogy, a restaurant run by a single person who solely manages the host stand, kitchen, tables, and payments would be the equivalent of the traditional, monolithic application. If the restaurant had a host, waiters, and a kitchen staff, the standards for communication between them (such as the names of dishes, prices, etc.) would be equivalent to the APIs. The kitchen staff wouldn’t need to know who placed the order and the servers wouldn’t need to know the recipe of the dishes, but each of them would communicate through the designated dish names to provide their services. Imagine the chaos if one waiter referred to tables using numbers (such as “Table 13,”) but the host called tables by colors (such as the “Blue Table”) and they didn’t explain to one another what their naming convention was. APIs define the standard language that should be used, solving this problem.

Web services would perform the same functions as the APIs, but each would be for a specific type of communication (e.g., for the orders into the kitchen – whether from the server’s tablets or an online to-go order). A microservices architecture would be even more granular and would provide each waiter, cook, host – and even more granularly, a cashier, a busboy, a dishwasher, etc. – with a common way to communicate with all the others. It would give them all a common language across many areas of the restaurant for even the smallest transactions.

Why are microservices important?

Microservices offer numerous benefits for insurance organizations operating in a dynamic and competitive environment.

Increased agility Legacy systems are one of the key factors holding insurers back from quickly innovating. Surrounding legacy systems with microservices helps address this challenge as required changes need to be made only to the relevant microservices without the entire application broken down to change specific portions. While this is far from a silver bullet, it can alleviate some legacy challenges.

Greater flexibility There are few constraints as to which programming language or platform can be used for individual microservices in an application, so there is greater application development flexibility. The same is true for deployment as individual microservices can be delivered and deployed independently. Of course, best practices dictate that you should try to stick with a common language, but it’s good to have options.

Faster time to market Individual microservices can be developed in parallel by various teams, leading to more rapid application development.

Faster enhancements As the applications are composed of smaller, independent microservices, they can be enhanced easily by simply creating a new microservice for the added functionality.

More robust Applications based on this approach are more robust because issues can be addressed by fixing only the relevant microservices, without affecting the rest of the application components.

Better re-use and customization Individual microservices can be re-used in other applications that require similar functionality, and there is scope for greater customization or configuration of the application for use in different contexts by reconfiguring the composition of microservices used.

How can microservices benefit insurers?

More than 80% of insurers surveyed as part of the WIR 2018 said that evolving customer preferences are driving their need to become digitally agile. Microservices can help insurers bridge the gap while they budget for and implement replacement of core systems such as policy administration and claims to become more adaptive to changing requirements and advances in the market.

Moreover, microservices can help insurers design more flexible offerings that can be easily and quickly enhanced to respond to competitive forces. As insurers go beyond agent-based, pure risk transfer to offer an ecosystem of services and an omnichannel experience, microservices will play an essential role in creating efficient and lean applications.

Insurers can take positive steps forward in their digital transformation journey to become more competitive and dynamic. Visit www.capgemini.com/industry/insurance or reach out to me directly at chad.hersh@capgemini.com or via https://www.linkedin.com/in/chadhersh to discuss in detail.

[1] Opensource.com, “What are microservices?” https://opensource.com/resources/what-are-microservices, Accessed July 2018.

Related Posts

insurance

RegTech solutions can mitigate risk while aiding regulatory compliance

Elias Ghanem
Date icon May 20, 2019

Mounting regulatory oversight and today’s technology-inspired open ecosystem are a formidable...

insurance

There’s no business like the life insurance business!

Aruna Mahesh
Date icon May 20, 2019

We’ve all heard this oft-repeated cliché – life insurance carriers are laggards when it comes...

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information