Parijat Dutta

Approximately 63% of insurers still rely on legacy systems that are over 20 years old. Outdated technology and related architectures consume up to 75% of IT budget in some companies.

Background

Legacy systems in the insurance industry, particularly those built on mainframe technology, are a significant drain on resources, consuming up to 75%¹ of IT budgets for maintenance alone, as reported by Userlane. For instance, U.S. federal agencies spend an estimated $337 million² annually on maintaining legacy applications. These outdated systems contribute to inefficiencies and increased risk of operational disruptions, security breaches, and non-compliance with modern regulatory standards. Security breaches alone can cost companies an average of $3.86 million³, and the inability to integrate with new technologies hinders scalability and responsiveness to market demands. The insurance sector, heavily reliant on data accuracy and processing speed, suffers from poor user experiences and increased employee turnover due to frustrating software tools, impacting overall productivity and customer satisfaction⁴.

Client Background

The client, a leading player in the insurance sector, faced significant operational challenges due to their distributed product offerings spread across Mainframe, Windows, and Linux systems. Their claim, payment, and billing processes were managed by eight distinct and isolated processing engines, making change management a formidable task. Legacy systems, in particular, posed high inertia and limited resource availability.

Problem Statement

1. Complex Change Management: Managing changes across multiple, disparate systems was challenging. Legacy systems, with their inherent rigidity, further compounded the difficulty.
2. Future Consolidation Plans: There were vague plans to merge all claim and payment systems into a single platform. However, immediate actionable steps were needed to address the pressing inefficiencies.
3. Segregation of Processes: Tightly coupled monolithic adjudication, billing and payment processes were a major hurdle towards change adoption, maintenance and responsiveness.

Proposed Solution Approaches

1. Orchestration Layer: Initially, the idea was to build an orchestration layer over all separate claim engines to enable logic-based routing and invocation of processes. This approach was quickly discarded as it did not address the core issue of change management. The claim engines would still remain monolithic and future technological upgrades would suffer from the same problems.
2. Throttling Approach: Another consideration was to bring each claim platforms up to state-of-the-art technology standards, and systematically drain their previous processes. This approach was also discarded due to the client’s ongoing multi-year contract with a third-party vendor for a consolidated claim payment platform.
3. Microservices Architecture: I proposed externalizing sub-applications common across the various claim engines and invoking them as microservices. This proposal was accepted, and it provided the following benefits:

Existing Challenges	Mitigation through Microservices Solution
Complexity: Monolithic platforms are complex and expensive to change	Modernization of core components with API integrated scalable microservices will loosen the coupling, and will enable componentization and modularization.
Latency: Outdated processes incur delays	Message streaming to microservices, and API enabled components along with queue-based load leveling will allow for real-time and near-real-time processing.
Lethargy: Inefficient change management.	Orchestration and monitoring across microservices improves agility and allow scope for automation. Decentralized and externalized business rules along also foster ease of change management.
Expensive: Obsolete tech are expensive to manage and maintain	Economic cloud based solution ensures high reliability and availability without impacting scalability. Phased migration plans enabled by decoupling of functionalities through microservices allows development of an effective and efficient roadmap.

Tenets of the Solution

1. Refactor identified microservices using strangler pattern from the monolithic legacy claim systems
2. Cloud native
3. Real time communications through API gateway pattern
4. Designed microservices should have single responsibility, interface segregation, loose coupling, circuit breaker, and orchestration principle.

Defining the MVP

I identified 6 features that were common across all the separate claim platforms. My proposal was to decouple and externalize these 6 sub-applications, using common microservices that would be invoked by each of the claim system as needed. The same functionalities within each claim system will be disabled.

I grouped them into 3 triggering events that can execute the microservices; correspondence trigger, disbursement trigger, and calculator trigger. These events, although part of the overall orchestrated process, can exist independently.

I proposed the following phased approach for MVP deployment:

Solution Architecture

The solution was designed leveraging cloud technologies, ensuring scalability, resilience, and high availability:

1. API Gateway: Acted as the entry point for all API calls, providing a unified interface for the microservices.
2. Serverless Container Management: Ensured that microservices could scale independently based on demand.
3. Scalable Database: Provided robust solution to manage the data needs of the microservices.

Additionally, a user-friendly UI was developed to provide business units with the flexibility to manage their processes and configure rules independently. This UI allowed for the addition of new microservices through a configuration table, ensuring future extensibility.

Roadblocks and Resolutions

1. Cloud Data Hesitancy: Initial resistance to migrating data to the cloud was mitigated through comprehensive market research and a thorough review of cloud service provider’s certifications and compliance standards. This reassured stakeholders of the security and reliability of the proposed solution.
2. Data Access Issues: Some business teams were preoccupied with an ongoing merger, limiting their availability. To circumvent this, I utilized online repositories and client’s knowledge banks, delving into production support documents, test cases, and service mappings to gather necessary data. I documented my findings in a new confluence page and periodically sent it to SMEs for validation. This proactive approach significantly accelerated the project timeline.

Quantitative Impact

• Efficiency Gains: The MVP immediately saw an impact on change management overhead, and introduced ~3% efficiency gain in terms of development and testing efforts. Completed strategic overhaul through adoption of microservice-based decoupled solution is estimated to reduce the average change management time and cost by by 35%.
• Cost Savings: By leveraging Cloud service provider’s pay-as-you-go model, the client will projected to save approximately 18% on infrastructure costs compared to their present on-premise setup.
• Scalability: The microservices architecture enabled the client to handle increase in claim volumes during surge periods without performance degradation.

References

1. https://www.userlane.com/blog/enterprise-legacy-systems/ ↩︎
2. https://tblocks.com/articles/uncovering-the-hidden-costs-of-legacy-systems/#:~:text=A%20study%20on%20the%20maintenance,of%20the%20government’s%20legacy%20systems. ↩︎
3. https://www.embroker.com/blog/cost-of-a-data-breach/#:~:text=According%20to%20the%20Ponemon%20Institute’s,2020%20amounted%20to%20%248.64%20million. ↩︎
4. https://www.celent.com/insights/195881499 ↩︎