Microservices: It's not just Integration

Microservices architectures continue to receive significant attention for their ability to provide very fine granularity integrations across systems.  However, many of these conversations have been limited to the Enterprise Architecture domain as most people assume this is just a progression from the existing Services Oriented Architectures (SOA) of the past. 

In this article, I will discuss why Microservices architectures are much broader than integrations, and will challenge Insurers to think differently about how they execute their core transformations in the future. Is the role of a Commercial off the Shelf (COTS) product back in question?

Market Trends

Interest by Insurance CIO’s of pursuing a Microservices strategy continues to grow, with Celent noting over 1/3rd of leaders interested in the pattern. This is noteworthy not simply due to the figure, but because they also expressed interest in combining both a Microservices integration pattern to a bespoke insurance platform. 

As you will see, Microservices architectures not only shift the integration design equation, but also reimagines what to expect from a COTS package in the future.

Architecture Impacts

So what does this mean? In the traditional COTS + SOA model, a project implements software which manages the full lifecycle of the core capability. For example, a PAS system would be expected to manage the full quoting, issuance and policy management functions, with specific integrations interacting to consume / pass relevant data to complete the lifecycle. While not exactly black box, the architectural pattern is essentially 1) pass data to the PAS and 2) PAS performs a function. 

This model suits the COTS buyer well, since the engineering of the core product is performed by the software vendor and remains the ownership of their product. This model also simplifies the number of integrations across the enterprise (assuming good SOA practices) as services are course grained and re-used. 

A New Paradigm

Nearly all software vendors are accelerating a microservices re-platforming of their products. Whether this makes sense from a software vendor perspective is somewhat irrelevant, as there is a fear of missing out which will drive the major vendors to at least offer this alternative. Compounding matters, SaaS start-ups such as Instanda and Socotra already offer these patterns while leveraging complementary SaaS architectures such as Docker Containers. 

Looking at Figure 3, I illustrate how to view the COTS offering within the context of a Microservices architecture. We no longer have to assume the COTS product will manage the full lifecycle (although we can keep it there). This means we can re-imagine the quote journey and use parts of the COTS product, integrate with other platforms on a best-of-breed basis and create a custom combination of integrations and system ownership to meet the project’s specific needs.

This is obviously very powerful for the project, but poses significant challenges when attempting a wholesale core transformation. For example, the project team will be to answer three key questions by transaction:

• Should this lifecycle transaction remain as-is in the COTS product?
• Is there an equivalent function we can leverage via a Microservice?
• Do we implement a hybrid pattern and “stitch” the transaction together?

Even if a project team decided to break the quote transaction into a combination of Microservices between the PAS, an InsurTech product and 3rd party data providers, there still remains the issue of who manages the transaction and its corresponding data. This is where the complication of a Microservices strategy becomes apparent.

The Renaissance of Solution Architecture

While large projects are only starting to investigate these patterns at scale, I believe many will quickly realize that assumptions in the COTS + SOA model no longer hold true. With the increased design flexibility Microservices patterns offer, project teams will need a strong Solution Architecture domain coupled with their Enterprise Architects to envision an end-to-end design up front.

There is a very real possibility that a project will simply miss a key feature (e.g. delinquency) since the complexity and optionality of this approach means it will be easy to assume one system performs a function, while another team makes a different assumption. Coupled with Agile and CI/CD techniques this can result in a nightmarish scenario for project managers and their sponsors. 

Ironically, this places a stronger demand on defining the up-front application and feature ownership at the beginning of the project, bringing us back to a Waterfall-like design phase preceding development.

Conclusion

Some industry commentators believe Microservices will make legacy COTS vendors obsolete, however, like all things I believe the reality will be more nuanced. For most new projects, it will make sense to continue to leverage the vast majority of lifecycle management within a vendor solution while integrating best-of-breed features through a sub-set of Microservices (think 95%). 

This broadly aligns with the state of InsurTech as I see it, since many of the emerging leaders in the space are offering solutions to a specific portion of the value chain. This allows projects to not only integrate with a combination of providers, but create a unique technology stack that aligns with their customer proposition - and isn’t that the purpose of our projects anyway?