Rewriting History - Legacy Transformation in the Insurance Sector

Abstract

How can insurance providers’ best leverage their legacy investments and continue to be flexible, competitive, and achieve their business goals? One of the earliest adopters of technology and automation, insurance companies have become heavily dependent on indigenous systems that are based on dated development standards with limited functionality and usability, are deeply fragmented and complex. It is imperative, now more than ever, to consolidate and develop an effective legacy system management and transformation strategy that not just lends competitive advantage, but also minimizes transformational cost, disruption and risk, and has the ability to take the organization to the next level.

The Story So Far—Analyzing the Need for Legacy Transformation

The past decade has seen the insurance industry undergo a phenomenal transformation as a result of globalization, economic upheavals, deregulation, tighter governance and compliance laws, and increased competition. This highly dynamic environment has led to a sluggishness of top line growth that is steering the industry towards newer business models and requisite technologies to support them. Time-to-market, though a perpetual need, has today become a real imperative for businesses to break through this stagnation

With customers at the core of all business decisions, providing facilities to easily access information, transact, and ensuring continual commitment from distributors, and ensuring a premium customer experience are some of the key growth factors that drive this industry. To complement this business change, the underlying IT landscape is also undergoing a rapid transformation. The legacy landscape, in particular, is rapidly changing as these platforms are inherently constrained and unable to support business simplification and enterprise-wide data interpretation.

In an industry where almost all the participants offer identical products, providing better customer service is undoubtedly one of the most important differentiating factors to gain competitive advantage. Given this, insurance companies have typically been among the pioneers of process automation adoption. IT capabilities, be it mainframes, client-server, multi-tier or other emerging technologies, have automated all insurance processes and made information available at

finger tips. In this race towards automation, insurance carriers have become heavily dependent on proprietary, homegrown systems. Traditionally, applications were developed around specific lines of business, leading to incredibly fractured systems and processes.

Large scale consolidation within the industry has further complicated the issue, with a large number of disparate systems invariably performing the same task. Besides, most of these legacy systems are poorly documented and irregularly updated, and are often unable to cater to the needs of emerging business models.

Evolving business models decrease the distance between customers and providers. As the need for direct and easy communication and transparency between the two increases, products silos are curtailed. The insurance industry is struggling with a multitude of applications that require extensive maintenance and have mediocre capabilities.

This white paper aims at helping organizations understand the issues involved in effective management of the existing legacy systems—how to create an environment that supports legacy transformation, and how to move forward without abandoning systems that work.

Issues Associated with Legacy Systems Management

A legacy system is a method, technology, computer system, or application program that is out of date and needs replacement, but continues to be used even though newer technologies or more efficient methods of performing the task are available. This is typically because the system still caters to the users' needs, has become extremely large, cumbersome and complex, has poor documentation, and transition or modernization would require substantial budgets.

Key challenges faced by organizations using legacy systems include:

• Legacy systems that have been developed in the past using older technologies do not just include the software and the hardware but also processes and procedures (policy-centric and customer-centric, bureaucratic, fast and easy to use) that are difficult to change
• These systems become repositories of business knowledge that is not available anywhere else
• These systems are business-critical and are maintained not only because of the information repository but also because it is too risky to remove them

A typical legacy set-up is characterized by these distinct or identifiable features:

• Mainframe- or midframe-based hardware
• Application software written in obsolete programming languages
• Application data with large instances of redundant, incomplete, and inconsistent data
• Software structure and functionality may not support business process enhancements/ changes
• Business rules may be implicit and embedded in the system software
• Software maintained in-house may be poorly supported as suppliers may no longer be in business, or may not support the system anymore
• The resources/ users who were associated with the system may no longer be working with the organization constraining the knowledge about such systems

Such inefficiencies have made it critical for insurance players to clearly define and implement legacy transformation strategies.

Most legacy systems are written in COBOL (code), and nobody teaches in COBOL anymore. The maintenance of legacy systems is going to get tougher as the generation that knew the language retires. There is significant risk in the older systems, as the employees that maintained them retired or moved on, taking their operational knowledge with them. Companies with larger systems eventually is required to do something with them.  

Getting Future Ready: Developing a Legacy Transformation Roadmap

Legacy transformation is the process of bridging the gap between legacy and modern, strategic architectures that are cost-effective, time-efficient and risk averse. The transformation process consists of understanding and documenting the existing system; decomposing the application into data; presentation and processing logic; creating and extracting reusable components; and if desired, converting the legacy code into Web-compatible languages.

Advantages of Legacy Transformation

Transforming a legacy system offers a number of distinct advantages including:

• Reduced operational cost
• Adoption of current business processes and modern technology
• Reduced dependency on resources associated with legacy systems
• Comprehensive documentation of the system with complete knowledge of processes
• Ease in deployment and enhancement of functionality

Cracking the Code: Legacy Transformation Made Easy

One of the key challenges in legacy transformation is the lack of a well-defined data and business rules management strategy. Both involve significant participation of resources managing the data and the code, in-depth understanding of the processes along with the rules that govern them and the associated data. Only then synchronous and seamless transfer of data and rules to the end state system(s) is ensured. While it may be relatively easy to access data, getting access to system specific knowledge like the embedded business logic, and the associated rules is the real challenge. In fact, even with respect to data, comprehending system specific knowledge is a major task.

Comprehensive and Channelized Documentation is Critical: Most legacy applications in the insurance industry have substantial data-related issues like inaccurate, incomplete, or redundant information. Information pertaining to business rules and logic defining the processes and data is generally available either in the form of documents or through the users’ expertise. A typical scenario that legacy transformation programs confront is non-existent or minimal documentation and the inability to access or translate system experts’ knowledge into actionable insights. Company exits (retirement/ or churn), inefficient communication, or lack of cooperation by subject matter experts who may feel threatened by the transformation program, are some of the challenges with respect to knowledge documentation.

Thus, for the success of any transformation, it is imperative to have a robust knowledge management and code comprehension framework. The transformation team needs tools to extract system knowledge from the code, structure to ensure effective knowledge transfer from the experts, templates to record the extracted information and transferred knowledge, and a learning plan to ensure that all the system knowledge is imbibed by them.

Most transformation programs last for a period of two-three years. During transformation, an organization may face lack of knowledge continuity due to changing organizational priorities. Knowledge institutionalization, through a resilient knowledge management framework, plays a significant role in reducing dependency on the knowledge repositories by transporting an expert’s knowledge into it. This repository, supported by a strong competency-building framework, can ensure that the new set of resources become productive quickly, thereby reducing the impact of reallocation or attrition.

Follow an Iterative Approach to Data Transformation: Another challenging area in insurance legacy transformation is the data itself. As mentioned earlier, insurance data on old legacy systems is infested with inaccuracy, insufficiency, and redundancy issues. Understanding and then transforming this data clearly into the new system is a transformation team’s nightmare. Even though all organizations face the same challenges, they tend to throw different sets of data transformation issues.

An iterative approach to data transfer can play a pivotal role in ensuring that the lessons learnt from resolving issues in earlier iterations can be effectively utilized in subsequent iterations. Also, since the amount of data to be converted is huge, the usage of tools that enable the process of transformation is extremely important. Typically, a large number of off-the-shelf Extract Transform Load (ETL) tools have been positioned to address the same. In this case, the transformation rules are complex, since these tools have been built with data warehouse as their final destination.

In case of data migration, the rules need not be complex, as transformation is aimed at cleaning the data and not transforming and drawing business intelligence out of it. Thus, it is usually preferred that simpler data conversion tools are used for this purpose.

Another recommended method for data conversion is “Policy Life Cycle Mirroring”. In this method, based on the history of all transactions in the source system, a new policy is processed in the target system if it allows backdating of transactions.

Unlocking Value of a Comprehensive Transformation Strategy

Any development in legacy transformation tools and techniques is an opportunity for businesses to review their legacy portfolio. When the requirement is to transform a single legacy application, the choice of direction is decided by the quality of the application and the availability of off-the-shelf products to replace it. Generally, one (or more) of the following four alternatives can be used by insurance companies to deal with legacy transformation.

• Leave the Application as is: There are some cases where there is no requirement to change the existing application. For instance: The insurance company might no longer offer a particular product and the preexisting policies being serviced may all be near maturity. In such cases, it will make better business sense to continue with the existing application without investing more on these lines of business or the systems handling them. Thus
• Modify or Upgrade the Application: Depending on the need and the extent of the change desired, the organization can either modify the features of the existing application or upgrade it to newer technologies for better services. Some initiatives that an insurance company can take include:
  • Web Enabling Services: This activity involves re-engineering the interfaces and screen components without disturbing the existing legacy database (non-invasive). This is usually a preferred alternative if the organization has budgetary constraints and yet intends to appeal to a wider audience and enhance service levels.
  • Componentization and Integration: In this process the existing application remains untouched. However, the business rules and the processes are converted into Component Object Model (COM) objects with better functionalities and on premise deployment with a straightforward integration into existing applications. This is generally adopted by insurance companies that are in a rapid, inorganic expansion mode, through mergers and acquisitions.
• Replace Existing Application: Evolving regulatory requirements, products terms and condition updates often make it necessary to change insurance applications. Existing applications may not be in a position to handle all such changes and hence require a replacement, either through a bespoke development or through an off-the-shelf product.
  
  

  Also, if there has been a merger or an acquisition where the businesses being serviced are the same, the insurance player(s) may embark upon consolidating the two businesses and thus the underlying applications as well. In such business consolidation scenarios, the organization may decide either to transport the requisite functionality of one (or more) application(s) to the other or replace one (or more) application(s) with a new functionally and technically richer application.

• Retire (decommission) an Application: This option is chosen when the company decides to exit a line of business and all the associated policies have matured. For instance, certain policies that were specifically designed for a specific purpose/ business segment may no longer be sold or serviced (World War II soldiers) and hence they are no longer needed. Or a company may decide not to offer a product specifically designed for a state/ target segment that it no longer wants to service. Maintaining these applications is an unnecessary cost and effort.

Retiring an application is perhaps one of the most difficult options to exercise considering its impact. Multiple processes (to access the application) have to be redesigned, certain data may have to be preserved for as long as the company exists, and then there are regulatory needs that mandate some reports. It is also a future step for option one (where the legacy application is supporting a closed book of business and is being maintained as it is till the last policy matures) and last step for option three (where one or more applications are getting replaced). Once an application is shut down, it is decommissioned and all its requisite repositories (business rules and/or data) are transferred either to another application(s) or to an archival system.

All the above options lead to consolidation and/ or decommissioning of some or all of the legacy applications.

Decommissioning is the practice of removing a service (application/ database/ platform) while retaining access to the business-critical data stored within the system. Post decommissioning, a legacy system is deemed unfit for performing the regular operations. The data residing in the decommissioned system may or may not be migrated to the target system. In either case, continued access to the data is very critical. By decommissioning redundant, unnecessary or technologically obsolete systems, companies achieve tangible benefits. At the same time, there are certain issues such as:

• Companies typically decommission systems or applications to reduce the infrastructure costs and mitigate operational risks. Some scenarios where decommissioning has been frequently recommended is when a business is considering selling/ exiting a division or line of business
• Mergers and acquisitions bring with them older/ redundant systems
• Inability of existing systems to accommodate newer technological demands
• Scarcity of resources having knowledge of legacy systems

Consolidation: Adopting the Middle Path

Often businesses find it less cumbersome to identify similar processes in disparate systems and integrate them into a process that represents almost all the features in multiple systems. This consolidation reduces duplication and results in generating a powerful set of tools and features that enable users to have a unified view of information stored in multiple systems and locations. Consolidation also enables insurers to evolve new systems to provide scalable, consistent, and reformed data that can be used by enterprise applications and business processes across various administration systems. Typically, consolidation involves decommissioning of one or more system(s).

Based on the client’s requirements, an appropriate strategy to transform legacy applications must be devised. These strategies depend on issues like transfer of assets with/ without data, database and interface compatibility, transition support, and post transition training. Certain specific needs an organization may have, to transform legacy applications, have been listed below:

• Replacement of the legacy system with a new system
• Enhancement of existing functionalities
• Decommissioning of the system

However, the core elements of strategies are components of data and business rules. If the data is relatively clean and policy history is not maintained as live data, “point in time” data migration is recommended. However, if the data is plagued with inconsistencies, redundancies and the system allows backdating, “recreate from issue” or “policy lifecycle mirroring” (wherein all the transactions from policy issue to date are recreated through an alternate source of input), it is more suitable for active policy conversions.

‘Rewriting History’

The only thing constant is change! This age-old adage holds greater meaning when it comes to transformation of legacy systems. Several global insurance companies still bank on legacy systems to handle key processes like claims and policy administration. These applications, while reliable and capable of delivering what they were originally designed to deliver, are fraught with several critical limitations like (a) poor technical support, (b) inflexible business rules, (c) over-burdened databases, (d) hard-to-learn interfaces, (e) difficulty in integration and, (f) high maintenance costs. Despite these drawbacks, insurance companies have been apprehensive about replacing their legacy systems due to the high costs and risks involved.

However, the evolving business ecosystem, increasing competition and customer expectations, as well as changing regulatory mandates have prompted many players to consider transforming their legacy applications

Legacy transformation usually takes two standard modes—consolidation and/ or decommissioning. It would not be an exaggeration to state that a successful legacy transformation is all about successful data and business rules migration from original/ source system(s) to new/ target system(s), ensuring that the interests of all concerned parties (users and managers of old and new systems) are addressed. The key ingredients to achieve this objective are knowledge acquisition from the system using tools and templates; knowledge acquisition from experts using knowledge transfer structures and templates; knowledge institutionalization; and iterative data transfers using appropriate tools or methodologies