Six things insurers must get right for platform modernization strategy

If you are responsible for platform modernization strategy for an organization that has been grappling with age-old legacy platforms, then this article is for you.

Why platform modernization strategy is important?

Platform modernization strategy for legacy applications is among the top priorities for insurance carriers.

Insurance IT applications are traditionally run on old legacy platforms which is operationally painful in several ways in the context of a modern competitive market.

Legacy platforms lead to low flexibility and poor agility that impact customer experience.

The rigidity in these platforms results in high IT change management that substantially increases the operational latency and costs.

The knowledge and skills available in the market to run these legacy platforms are receding fast which increases knowledge risk and technology debts.

Also in the context of an enterprise, normally it’s not just one legacy platform but many of them running in silos and carrying duplicate products and processes. Such redundancies multiply these problems many times.

Why all strategies are not suitable for platform modernization?

What’s more, traditionally applications on legacy platforms are complex monolithic systems. Hardcoded business rules pile up over time into a “spaghetti” code without standards or methods in place. This results in monolithic architecture that makes the unwinding of these business rules nearly impossible.

This makes traditional ways of simplifying business applications, like ‘rewriting’ or ‘rearchitecting’, not viable options due to inherent complexity and costs in doing so.

What platform modernization strategy works well?

The above problems led software product vendors to create custom ‘Commercial-off-the-Shelf’ or COTS platforms. These platforms normally address specific business functions like policy administration, claims administration, rating underwriting quote, agents’ compensation, business product management, etc.

The intent is to provide the ability to the carriers to use these COTS platforms AS-IS to a significant extent.

The goal of these COTS platforms is to enable maximum configuration with minimum customizations.

In an ideal world, these platforms should work well on the successful migration of business data from the existing systems to these new platforms. However, that is often far-fetched in reality. We will see why in this paper.

Why is COTS the right platform modernization strategy?

An off-the-shelf platform most likely has already been proven to work, and only requires adaptation to the specific requirements of the carrier in question.  It has best practices built-in that are often learned from other implementations of the platform. This reduces the risk of development in terms of cost, complexity, and duration.

It also enables better customer experience and a superior functional architecture for managing business processes in a better way.

What’s more, most of these platforms are SaaS offerings, in many cases cloud-native. This brings in a lot of advantages in terms of performance, resilience, change management and costs, all out-of-the-box.

What could go wrong in using the COTS strategy and how to solve that?

While COTS platforms sound like a bright idea for a platform modernization strategy there are many reasons why it might fail. Research firms indicate that the success rate of COTS platform implementation is less than 30%.

What this implies is that this strategy is not easy to execute. There are many risks and points of failure that can derail the strategy.

This paper highlights six potential areas that need to be done right for a successful COTS platform implementations to modernize old legacy systems with a reasonable degree of certainty.

1. Involve key stakeholders in the transformation journey

Platform modernization is a large transformation that impacts the whole enterprise both within it and outside. Such a large transformation impacts the existing customer experience, business processes, IT application change management, IT infrastructure, IT architecture, the way the value of data is perceived, and a lot more.

In other words, a new platform that replaces one or more existing legacy systems brings radical changes to the enterprise operating model that impacts all stakeholders, internal and external.

This makes it so vital to involve every key stakeholder to be part of the platform modernization journey and decision-making to make it a successful endeavor.

Failure to have key stakeholders on the bus creates roadblocks that can blow up your platform modernization strategy.

This is where setting up Center-of-Excellence (COE) for transformation is so critical. The transformation COE needs to be comprised of Business leaders, IT leaders, Program Managers, Architects, Developers, Infrastructure and Security engineers, and Customer representatives.

The goal of the COE would be to facilitate the transformation by —

  • Playing change evangelists
  • Educating across ranks and files about the Pros and Cons of the transformation and building organizational confidence
  • Providing leadership
  • Making critical decisions
  • Eliminating roadblocks
  • Approving tools, utilities & enablers
  • Engaging cross-functional teams
  • Managing board-of-directors and external stakeholders

Setting up a successful COE implies that half of the battle is won. It means that the organization is united towards a common goal, ready to make it happen. What can be a better foundation to change!

2. Select the right target platform

The selection of the right COTS platform is potentially the biggest driver to a successful platform modernization.

Alternatively, the selection of a wrong platform is a recipe for disaster.

Here is a list of key criteria that drive the fitment of a COTS platform in the context of an insurance carrier. The COTS platform that makes the right choice must have the following capabilities but not limited to these –

  • Support the administration of business products and processes, as relevant for the carrier
  • Support data models for the lines of business for the carrier
  • Provide APIs and flexible interfaces for seamless integration with other applications
  • Be sufficiently configurable to minimize IT change management
  • Provide self-service and multichannel engagement to external personas (customers and brokers)
  • Support high availability (anytime connectivity), low latency (real-time or near-real-time information) and quicker turnaround of business processes to support superior experience
  • Provide specialized tools and utility to allow easy data migration from existing platforms
  • Support SaaS operations on public clouds and bring all best practices that the cloud platform offers

It is important to remember that what works well for Life insurance will not work exactly the same way for Disability insurance. This is because Life and Disability insurance products and processes are operationally different in more ways than they are common.

It is also important to remember that these COTS platforms on their AS-IS state are highly simplified and generalized. Thus, the platforms may not have all the unique business rules or data entities & attributes that carriers are running in their existing legacy systems. As a result, functional and data gaps are bound to exist.

In a nutshell, it is imperative to test-drive the platform well in the context of the carrier’s business operating model, understand the gaps, and have full clarity on what it takes to fill in those gaps. Your decision and commitments on the platform should be guided by this clarity.

Also research on the vendor well before proceeding too far so you know what are you getting into–

  • Is the vendor credible financially, and technically (ask for case studies, prior implementation experiences, etc.)
  • See if you can get reviews from other carriers who have already adopted the platform and running their business in that platform

3. Keep a solid integration strategy in place

When you introduce a new platform in an existing ecosystem, integration is the key from a business process standpoint.

The new COTS platform needs to be connected to the existing applications in the periphery of the COTS platform within the ecosystem. When looked through a different lens, it means that the COTS platform needs to be integrated with the applications that were peripheral to the existing legacy system.

However, it is simpler said than done.

This is because the number of peripheral applications can be just too many. It’s a messy network of point solutions without a plan or structure ever been followed. That is how most legacy ecosystems are built and look like. The mess did not happen in a day but over decades of an unplanned and tactical approach to application development.

This is a risk, since missing to connect to one of these applications will cause the business process to crumble.

That is why it is super-important to analyze and understand the current ecosystem well, its functional flow paths and the existing integration points. That will help in the adaptation of the new COTS platforms within the existing ecosystem.

You are otherwise likely to burn your hands if you jump onto the implementation of the new platform without understanding how the different application dots are connected in the ecosystem.

4. Design data migration methodology

Data migration is probably the riskiest aspect of COTS implementation. Business data in the context of insurance that need migration would potentially include customers, products, plans, coverages, policies, claims, different reference data, etc.

Data migration needs a solid strategy laid out. If not planned well, results can be disastrous because ‘flawed’ data migrations can impact your customers’ assets. In all respect, data migration should be customer-centric in its fundamental approach.

Here are the guidelines to an effective data migration strategy (but not limited to these)

Migrate data in the context of customers to avoid loss of integrity of customer-centric information. Also, plan to migrate data in logical chunks for better control of customer-centric information during migration.

Strategically make the decision if high-net-worth customers should be migrated to the new platform before other customers.

Remember, migrating high-net-worth customers early in the process may be a risk. This is because your migration methodology may not be fully set up or proven at these early stages which may be risky to migrating high-net-worth customers.

On the flip side, moving high-net-worth customers early to the new platform can be helpful from a customer-experience standpoint. You can start providing these customers with a better more digitalized experience sooner than later. Better experience helps to strengthen the relationship with these high-net-worth customers, which can bolster business opportunities.

Within a customer context, think about strategies to reduce the risk of the potential impact on the customer.

For example, if the customer has policies for a closed block of products then migrate those first. This is because the closed-block of policies is less risk in terms of asset value. Thus migrating the closed block can de-risk the migration of the open block of products that is high-net-worth for the customer in question.

Here is a relevant read about some important considerations in insurance data migration.

Keep your customers in confidence

Lastly, as the good old saying goes, transparency and honesty always pay off. Remain transparent by keeping customers informed of the changes you are making in your systems and processes that can cause them temporary inconveniences.

Educate them on how this change will make things much better for them in the days to come soon.

5. Build the close-out strategy for existing legacy platform

As the new system replaces an older one, the retirement of the old system needs serious thoughts. Running redundant systems with no specific business use case can impact bottom-line, and also defeat the purpose of modernization. Thus, having a sound and risk-free decommissioning strategy in place for the older legacy system is critical.

Below are typical options for closeout of the existing legacy system(s). These options work well either standalone or in combinations depending on the business needs —

  • Coexist with the new platform till data migration is 100% complete
  • Closeout immediately after migration to the new platform is 100% complete to reduce operational overhead of running multiple and parallel systems
  • Co-exist with the new platform for a specific period of time until the stability of the new platform is proven
  • Stay around till all the compliance and regulatory functions and reports are set up in the new platform
  • Stay on to comply with the regulatory need to house specific data on-premise while the new platform runs on a public cloud,

6. Establish an agile program management model

Large platform implementation is tons of IT work that is largely cross-functional in nature. Such cross-functional work needs best-of-breed time management, resource management, and communication strategies. The value generated from the work needs to be communicated and shared with the business regularly and in a timely manner.

Also, we bring new platforms to make the business run more efficiently. Thus it is imperative to show to the business leaders the results of what is being done quicker and on a regular basis to gain their confidence in the program.

This makes “agile” as the preferred style of program management.

Such an approach helps to identify potential risks early and gain stakeholder confidence by meeting expectations well.

What else!

There are yet other aspects that need to be kept in mind too. Think of a highly customized and complex monolithic mainframe system that needs to be replaced by a modern COTS platform.

The biggest barrier to such a modernization approach would be the extraction of business rules that are heavily customized and therefore unique to the given mainframe system.

Why? How do we overcome such a barrier? How do we estimate what it needs to do such work? Read through this for insights on why business rule extraction from legacy systems can be a roadblock to platform modernizations and potential strategies.

Summing it up

The implementation of new platforms to replace existing systems is anything but easy. It has a number of risks from standpoints of costs, business outcome, stakeholder confidence, customer experience, etc. Historically, the success rate of large re-platforming programs is low.

Prior experience in similar engagements can help to remediate some of the risks. What is more important is to leverage this experience in building a solid full-proof execution plan.

The above six points provide foundations for platform modernizations that I learned first-hand through many large complex modernization engagements.

While not addressed in great detail in this paper these points can serve as guidelines to a failure-proof strategy for the platform modernization.

Related articles

Please click on the below links for related articles:

Six pitfalls why strategic enterprise programs fail

Disclaimer

The diagrams used in this paper are for illustrations only and taken from external sources/ 3rd party websites.

Suvo Dutta

I have over 22 years of IT experience in strategy, advisory, innovations, and cloud-based solutions in the Insurance domain. I advise clients in transforming their IT ecosystems to future-ready architectures that can provide exemplary customer experience, improve operating efficiency, enable faster product development and unlock the power of data.

You may also like...