The insurance industry has (for the most part) mitigated its concerns about Software-as-a-Service (SaaS) and the cloud for core systems. Several years ago, Novarica predicted that by 2020 more than half of new core system implementations would be vendor-managed on the cloud. While we aren’t there yet, a big push in this direction by most major core system vendors makes this prediction likely to bear out over time.
However, when it comes to the insurance core systems of policy, billing, and claims, “SaaS” does not always mean the same thing that it does when referring to ancillary systems like CRM or self-service portals. (Novarica has discussed this divergence in
SaaS core systems are often a kind of “managed hosting plus,” i.e., a server in the public cloud that the vendor manages for the insurer. The vendor may aspire to provide a single codebase for all insurer clients, but the vendor rolls out that codebase on an irregular schedule and each insurer determines their tolerance for testing and upgrades. The reason for this practice is that insurers, despite growing comfort with cloud, have yet to accept multi-tenancy for their core systems.
Multi-tenancy is an architecture where a single application server and/or data server (or a single pool of servers) houses the system and data for multiple customers. This architecture differs from single-tenant where the system and data are in the cloud but each virtual server is still dedicated to one—and only one—insurer.
Insurers have already embraced a multi-tenant approach for sensitive customer data—perhaps without realizing it—if they are a Salesforce customer; this hasn’t translated to a similar acceptance for multi-tenancy in policy, billing, and claims.
But why isn’t single-tenant SaaS enough?
Single-tenant SaaS has the same long-term scaling problem as on-premise deployments: every client’s system running on a slightly different branch of the codebase. This forces vendors to implement and roll out bug fixes for both the old and new codebase; it requires they expend effort monitoring and managing separate installations; and it means the vendor tasks teams of people with chasing down clients to move forward with their upgrades.
As much as 50% of policy admin vendor development budgets can go toward supporting old code branches and patching bugs. While the ratio varies, any effort that goes into supporting old code detracts from efforts to improve the system, derailing focus from new features and capabilities.
Multi-tenant SaaS guarantees a single codebase. Every bug fix and feature rolls out to all insurer clients at the same time. Client testing is likely built into the schedule, but it’s timeboxed to the vendor’s releases rather than to multiple insurers’ legacy deployment plans. The system stays up-to-date, aligns with all clients, avoids technical debt, and eliminates a costly upgrade cycle. Multi-tenant SaaS eliminates per-client customization not just by design but also by architectural necessity—an enforced best practice.
Most importantly, all of the vendor’s development budget goes to improving the system that insurers use.
Incumbent insurers now exist in a world where InsureTech startups are implementing modern DevOps with continuous deployment and with new features going into production on a rolling basis. The speed at which technology evolves continues to increase. Insurers should learn to embrace multi-tenant SaaS for core systems so they can partner with vendors who will keep modern systems from becoming legacy.
This blog entry has been reprinted with permission
