Modernization of technology can make a significant impact across many parts of the insurance industry, including underwriting, policy administration, and claims. McKinsey research shows that the potential benefits of modernization include a 40 percent reduction in IT cost, a 40 percent increase in operations productivity, more accurate claims handling, and, in some cases, increased gross written premiums and reduced churn.1
Technology modernization is vital, but—given the significant value at stake and the size of the investment—it should be approached with a healthy dose of caution. Indeed, many insurers miss out on the full benefits of the program for several reasons. First, they don’t have a clear view of what sort of actions are needed or the impact such actions could have, which may lead them to undersell both the business value at stake and what is needed to capture it. Second, many organizations have assumed that a “digital overlay”2 is all that is needed, only to find that some capabilities (such as rapid product configurations) require modernization of core systems. Third, insurers that do embark on modernization may falsely assume that a platform replacement will be a magic bullet that will solve all their efficiency and data-conversion problems.
To help insurers dispel these misconceptions, this article explores the top ten myths of tech modernization that many in the insurance industry believe in and provides guidance on how to successfully navigate them.
Myth versus reality: How to navigate technology modernization
This list is not meant to be exhaustive, as each technology-modernization program will have its own context and trade-offs. However, understanding the thinking behind each of these myths will help business and technology sponsors ask their teams the right questions rather than blindly following the latest “shiny object” trend or allowing suboptimal decisions to be made in business or technology silos.
Myth 1: The business impact of technology modernization is underwhelming
The reality: There are two broad reasons why the business impact of technology modernization may appear insignificant. First, insurers may not aim high enough, embarking on partial or incremental programs that do not tap into the considerable promise of modernization. Consider that numerous duplicate systems within a company’s technology infrastructure are the single biggest source of cost differentials, compared with similar products and operations organizations. In fact, our review of policy and workflow-system consolidations reveals that the operating expenses for companies with many duplicate systems can be three to four times higher than those with just one or two systems. This massive variance is often underestimated in business cases for technology-consolidation programs, which are often approved at a breakeven of five years (the average amount of time that leaders are willing to wait for a positive return on investment).
Second, business growth, retention, and productivity benefits may not be not fully factored into the business case during the planning phases of modernization. This is true even when a primary goal of modernizing systems is to enable a competitive customer experience or target new customers through the use of advanced analytics. Although revenue benefits are harder to quantify than changes in operational costs, even a directional estimate of benefits is useful to build buy-in.
How to navigate: To realize the considerable value at stake, insurers need to recognize—and commit to—a wide and transformative program of technology modernization. To justify the expense at the outset, insurers need to articulate the considerable gains in productivity and business impact that technology modernization programs can offer, and their business case should include an attractive ROI. This sets the right tone for the program and will ultimately yield a program that delivers meaningful impact.
For example, one insurance group used standardized business key performance indicators (KPIs) in the early stages of planning technology-modernization programs in its business units. These metrics outlined the target digital-adoption rate, retention uplift, operations productivity level, number of claims per full-time-equivalent employee, and straight-through processing ratio of applications, allowing the organization to draw up its business case and the predicted impact of achieving those goals. In this case, achieving these KPIs would improve customer retention by 5 percent and realize 20 percent in productivity savings.
Focusing on the outcomes and business value first helps teams plot their transformation path and timetable.
Myth 2: Modernization simply means replacing the core platform with the best-in-class option
The reality: Core-platform replacements often have higher up-front investment costs than in-place IT modernization, as they require both software and hardware, experts’ time, and extensive testing. Furthermore, migrating existing policies and their implicit contracts to a new platform is often expensive—these additional costs need to be factored into any decision—and time consuming.
One big reason for high modernization costs is the age and quality of the policy data and rules—poorly maintained policies are expensive to refresh and modernize to work in a new system. Product types and geographic context are also considerations. For instance, US personal property and casualty (P&C) policies are generally issued annually and thus have up-to-date policy data and rules; this makes migration efforts more straightforward. By contrast, in countries such as Austria or Germany, policies are refreshed annually to adjust premiums for inflation, but policy data, rules, and terms only change when a customer switches to a new policy—which may not happen for many years. Therefore, policy rules need to be carried over to the target system or customers need to switch to a new policy during modernization, rendering it time consuming.
Life insurance policies are issued for longer periods (often decades) and tend to present even greater legacy-data challenges.
How to navigate: To mitigate the risk of disruption, some organizations might choose to take a hybrid approach: issuing new policies on the new core platform while maintaining existing policies on the legacy platform. However, this can create a period of inefficiency as both platforms will need maintenance and training for operations staff. Technology leaders will need to factor this cost bubble (the increased cost of maintaining assets across two platforms) into their business plan and have a set time frame to either migrate, minimize, or off-load the legacy policies.
In many cases, in-place modernization is significantly less risky than a core-platform replacement—and just as powerful. This is particularly true in the many situations in which existing products and policies are not well documented. The existing system can be divided into similar blocks of policies, with each block updated to deliver the most valuable benefits, with much less risk.
For example, one retirement-services player decided to pursue an in-place upgrade of its legacy platform to the latest vendor-supported version. Once the process was in progress, it started issuing new business on the platform and could then migrate existing blocks from the other record-keeping systems. This approach had less risk than a wholesale replacement, given that much of the operations and rules did not need to change right away.
Myth 3: Using a vendor platform will guarantee access to the latest cloud-based technology
The reality: Many vendor platforms are from the prior generation (such as on-premise, monolithic, or two- or three-tiered client-server architectures) and may be outdated by the time they are implemented. Indeed, many industry-leading vendors must satisfy the needs of large customers with custom solutions. Doing so can force these vendors to invest in bespoke platform solutions rather than pursuing the R&D investments that would otherwise allow them to offer innovations to their customers.
How to navigate: Insurers will need to decide if the latest cloud-based technology matters to them. Is access to innovations such as the latest data analytics and AI services the motivating factor, or is it sufficient to be a fast follower—that is, adopt technology once it has been proven, and stay updated on security patches? Once organizations are clear on their own priorities, they will need to understand the strengths of each vendor’s architecture. How, for example, does the vendor handle multitenancy3 and automatic software updates? Can it integrate into the broader ecosystem of traditional and cloud-based services?
Insurers need to understand whether the system was designed for the cloud or whether it was a lift-and-shift approach to an older platform; that is, the platform was moved to a new system without any accommodating redesign or changes. If vendors did use a lift-and-shift strategy, companies will need to ensure that the system will meet their future business requirements. The frequency of new update releases will also give a sense of the pace of innovation.
For instance, insurers may decide to conduct functional proof-of-concept demos and architecture proofs-of-concepts during vendor selection for a core insurance solution. During such a process, insurers could test the integration of a vendor’s application programming interface (API) with the customer front end to ensure feasibility and highlight possible challenges. In cases where complications arise—such as when the integration requires building effort-intensive API translation services in an enterprise service bus (ESB)4—the process can be evaluated and the findings used to develop a much more robust and realistic implementation plan.
Myth 4: A vendor package will give us prescriptive guidance on how to modernize our business processes
The reality: Most vendor platforms use frameworks that suggest best practices for managing products and business processes, but they don’t necessarily deliver a template for a fully configured and coherent business model. These platforms were likely developed for specific customers, and their functionality expanded over time.
How to navigate: The best vendor platforms clearly configure and explain the parameters of their products and workflows rather than customizing their system for every customer. These platforms can accommodate business processes without compromising the insurers’ ability to upgrade their core systems. Furthermore, business users can apply no-code or low-code approaches to directly configure business processes without IT involvement, though these platforms are still relatively immature and should be thoroughly tested to handle realistic production volumes and use cases.5
Insurers could look for vendor platforms that come with level-five specificity for typical business processes. For example, a new system designed to administer policies could define or standardize process steps for common transactions (such as policy issuance, loan approval, and disbursement) and have parameters that allow dynamic adjustment (such as loan interest rates based on market conditions). Existing processes like this can be reverse engineered and tailored to an organization’s needs; processes not already in place should be planned appropriately for the time it will take to configure the system.
Myth 5: A simple one-size-fits-all technology solution to our ‘spaghetti integration’ challenge already exists
The reality: Although it may seem that the latest integration technology can solve the problem of “spaghetti integration,”6 the truth is that there is no silver bullet. The introduction of new integration patterns—from point-to-point integrations to ESBs and now to API-based patterns—should simplify the architecture landscape. Yet doing so is not always straightforward. Many insurers, for example, will implement an ESB to replace the spaghetti mess caused by point-to-point integration. However, an ESB introduces an extra communication layer (the “bus”), which can increase latency and become a single point of failure.
Similarly, some enterprises have recently fragmented their systems into hundreds of reusable microservices,7 but this level of complication can quickly become unmanageable if microservices have overlapping functionality and data.
How to navigate: When modernizing legacy systems with a history of spaghetti integrations, IT organizations will likely need to employ a mix of approaches. ESBs are useful, for example, in situations where a heavyweight solution is needed to connect incompatible legacy systems, such as an enterprise resource planning (ERP) system or a mainframe. These tools are designed to support many data fields and handle complex logic. However, they should be used in conjunction with lighter-weight APIs (particularly those that require fewer information fields and data exchanges compared with a typical API) and through judicious use of point-to-point integrations.
Myth 6: Modern automated tools ensure smooth data conversion
The reality: Insurance data are notoriously messy, as the ways certain data fields are used often change over time. Undocumented data usage can also lead to surprises during the conversion process. A metadata-based conversion tool can partially address these challenges by tailoring the logic of data conversion to factors such as the date the record was created; that said, the conversion process is rarely seamless.
How to navigate: Data profiling is essential to determining how many years of data history should be migrated to the new platform and what can be archived. P&C and retirement lines often renew plans every three years or so, providing a natural cutoff for data conversion.
Automated tools can also help insurers identify which customer segments have enough consistent data to be converted. Still, some data elements will need to be manually converted or refreshed through new or external data. IT leaders should work with the business team to find pragmatic and viable approaches to obtain or clean this data, such as by using low-cost labor.
For instance, one insurer’s new data and analytics team set out to build and populate a data lake (a repository for unstructured data) using historical data but ran into multiple delays due to poor data quality. A second team analyzed the data’s quality prior to converting it, ushering in a much smoother migration. The team determined the specific books and cutoff dates that could be most successfully migrated, and then identified and trained data-domain owners and subject-matter experts to judge whether it was better to manually clean or refresh stale data fields. This approach allowed the insurer to migrate the data to the new platform and provide a better customer experience.
Myth 7: It is always best to use industry-standard data schema
The reality: Decades of policy changes mean that legacy platforms and data are not easily mapped to industry-standard data schema. Either the Financial Services Logical Data Model or ACORD insurance standards can serve as a starting point when defining a data model, but the guidelines will need to be tailored and governed based on an individual insurer’s products, customers, and financial-data domains and definitions.
Some insurers may use the target platform’s data schema instead of an industry standard, as this can simplify and speed up modernization in the short term. This approach can be problematic, however, if the target platform schema is not well suited for integration or uses enterprise-wide standards like data warehouses or lakes.
How to navigate: Insurers should align their target product portfolio with the industry standard schema, extensively profiling legacy data sources to minimize the number of iterations to the final schema.
An alternative approach is to use the target system’s data schema. Although this method has its drawbacks in terms of potential lock-in to a target system (given the schema might be proprietary), it could be a more straightforward option since the schema has already been tested and mapped against the corresponding business processes in the relevant insurance domain.
Myth 8: Going from legacy to cloud-based platforms will reduce IT cost
The reality: Savings often materialize only from app or platform rationalization and not from the cloud-based platform per se. In fact, the cloud can be more expensive. We have observed many situations in which initial excitement over the cloud is replaced by surprise when the monthly bill comes. A lift-and-shift approach to the cloud, for instance, can add more complexity and lead to higher data egress and software-licensing charges, which cancel out any per-unit cost efficiencies on storage and computing. In addition, cloud platforms often come at a higher level of service quality than legacy systems, thus significantly improving IT stability but increasing cost.
A mature cloud-based system provides two fundamental sources of value: instant access to infinite scalability and speed of change through software (for example, quickly releasing new features). Building on these sources of value, we estimate that for every $1 million of IT budget, the total potential value from cloud-based modernization is $250,000, split among business acceleration (about 25 percent), app development and maintenance productivity (about 50 percent), and infrastructure efficiency (about 25 percent).
How to navigate: Insurers need to think comprehensively about the business case of moving to a cloud-based platform. We find that the benefits of business acceleration and development productivity often dwarf the infrastructure cost. Furthermore, the off-book benefits of increased operational stability and reduced risk are often just as important as the cost savings, if not more so. By having a clear, realistic understanding of both the desired outcomes and what a cloud platform can (and cannot) achieve, insurers can make an informed decision about whether to invest in migrating to a public cloud-based platform.
Technology leadership at one insurer decided to update the infrastructure operating model in the company’s on-site data center, postponing a cloud migration to do so. This transformation established a cloud-like operating model (that is, the infrastructure teams engineer highly automated products and services that are consumable by application teams, in the same way that application teams consume public-cloud services) within the existing infrastructure team and realized significant savings without requiring the team to make the much bigger investment of migrating to the cloud.
Myth 9: Getting rid of mainframes will automatically improve productivity
The reality: Mainframes often outperform multitier, modernized applications—their reliability and performance for high-volume transaction processing are best in class. As a result, mainframes are likely to remain a part of the insurance portfolio for decades to come, despite the difficulty in extracting embedded data and rules to use as part of digital services and analytics. Even companies that try to move to the cloud will likely still use mainframes, as the cloud is not yet ready to handle critical workloads. In addition, improving productivity for applications migrated off the mainframe will require updates to both the infrastructure and the operating model.
How to navigate: Insurers should first consider what data need to be extracted to support new-business capabilities and what rules will help focus modernization efforts. For the remaining functions, insurers could concentrate their efforts on modernizing the software running on mainframes, shrinking and exposing APIs, improving million-instructions-per-second (MIPS) consumption, spurring productivity by implementing DevOps techniques on the mainframe, and potentially considering mainframe-as-a-service options. These tasks can be combined with efforts to modernize the mainframe, though they need not be undertaken all at once. Insurers can pick and choose which to start with and work their way through them.
For insurers to realize productivity gains for those modular-application components that do get migrated off the mainframe (such as a business-services component), they will need to update both their IT architecture and their operating model. Modern infrastructure-as-code practices transform “precious pets” into “commodity cows”; instead of building an expensive one-off system that can never go down, such as a mainframe platform, the architecture relies on many interchangeable virtual machines that can quickly spin up if a neighbor fails. This new approach can dramatically decrease the cost and time needed to set up and test new environments. These benefits can only be achieved, however, if the overall operating model shifts to take advantage of the speed and flexibility of developing modular applications.
Myth 10: Microservices will make architecture agile and digitally savvy
The reality: In some cases, such as with core ERP functionality, the scope of an enterprise-wide system or business capability is not easily broken down into microcapabilities. Forcing microservices into these situations may result in increased complexity in an insurer’s architecture as teams create hundreds of overlapping services.
How to navigate: Given that each service needs to own its data and be sufficiently autonomous, insurers will need to carefully evaluate whether re-architecting an existing system into a microservice is feasible. For example, insurance applications such as claims applications can be decomposed into a set of microservices such as “update policy info,” “authenticate customer identity,” “get claims info,” and “auto-adjudicate claims decision”; all of these services should be designed to be interchangeable and autonomous. They can be developed in different languages and interact over lightweight APIs. Dedicated ownership of each microservice by a product team can ensure a “you build it, you own it” mentality, leading to continuous improvement over time. As these new microservices are built, previous integrations are rationalized to simplify the portfolio.
It is a business imperative that insurers get technology modernization right, but both the value at stake and the risk of failure are commonly underappreciated or misunderstood. By understanding these ten myths, insurers can start (or reset) their programs with a solid, realistic understanding of how and where technology can add real value.
