Question

In the readings so far, you have probably seen references to the changes in ASP.NET and other server-side technologies over the past several years. Using external resources, look at the necessity of maintaining legacy systems developed over the past 20 years. Why would stakeholders be invested in maintenance rather than rebuilding or replacing the systems? When responding to peers, look for opportunities to expand on their research with the information you discovered. If they found greater detail, then comment on the new information.

Answer 1

Across the industry, insurers made cutbacks on IT expenditure during the financial and economic crises. Maintenance was mainly limited to modifications necessitated through changes in legislation and regulations. Where possible, significant investments and investments in legacy replacement were cancelled or postponed. Now, if insurers want to participate in a new era, they face an IT landscape that’s in dire need of replacement.

The three most important advantages of a quick legacy systems cleanup are:

1. Improved customer service
2. Risk reduction
3. Cost reduction

Improved customer service

The rise of new technology and services from companies such as Amazon, Coolblue and KLM have set new standards for accessibility, engagement and experience. Mobile, social and 24/7 are no longer factors that make you distinct. In just a short time these have become hygiene factors. When new apps capture the market, customers expect their insurers to market these too. With legacy systems that’s a non-starter. These systems’ time to market and connectivity are hopelessly inadequate for current developments.

Risk reduction

Legacy systems operated almost without problem for years. We’ve already encountered every exception and bug. But the documentation has been neglected over the years and the people with sound knowledge of the system or programming language have often moved on. Necessary modifications end up being expensive and long-term high-risk projects. The age-old solution of ‘adding on’ bits of functionality has resulted in a jumble of systems and considerable risks during big changes. It’s often known as spaghetti architecture. Another risk is scaleability. You can build fantastic things at the front end, but the slowest unit in the chain will determine the response time. And that’s often the legacy system at the end of the chain, something builders of fantastic ‘front ends’ sometimes forget. The ongoing risk is that a great idea will later fail in production.

Cost reduction

Customer service and risk reduction are, of course, reason enough for legacy replacement. But the associated cost reduction isn’t inconsiderable either. Accenture quantifies the savings potential at 20-30 percent(1). Research by McKinsey(2) demonstrates that complex legacy systems lead to unnecessarily high costs and low productivity. The best-performing insurers can perform up to 3 times as well as the poorest performers! Take digital transaction processing, for instance. This will increase considerably in a modern system. Maintenance costs go down with modern development platforms and good documentation. Modifications and further development require much less effort. Finally, numerous systems operate as SaaS solutions, bringing such things as Pay per Performance within reach.

And now?

Once the need for change has finally registered, the question remains: what now? Rebuild with modern software, purchase standard software or develop your own? A question that doesn’t have a simple answer. But those using legacy systems today do need to start considering this, and quickly. The need to address this will only increase.