Legacy Technology Spawns Crisis In Human Support

While the debate continues regarding the choice between tried-and-true legacy systems versus the promising Web services technologies, a far greater issue is looming on the horizon.

Like the proverbial frog in a pot that is slowly brought to a boil and dies while continuously spurning opportunities to escape, a crisis in legacy system support human skill sets is steadily developing, making the legacy predicament a critical human resource issue.

Its no longer just about the virtues and limitations of the existing legacy technologies, but includes taking stock of the legacy-savvy baby boomer workforce required to maintain these warhorse systems. Over the next decade, many of the baby boomer generation will retire. Unless companies begin to plan for the replacement of their legacy systems, they will be caught in boiling water with no easy escape.

During the 60s and 70s most large insurance companies laid down their systems foundations with mainframe computers using Assembler and COBOL programming languages, while smaller companies often wrote or bought core systems languages like RPG. Next came online capabilities like CICS, allowing terminal screen update and access rather than using punch cards and printers.

In the 80s, a number of 4th generation language solutions were the first attempts to displace the legacy environment. Later, client/server technologies were introduced, but also failed to fully displace the core legacy systems, especially in the larger insurance organizations. A rich interface layer was often added, resulting in increased operational complexity.

The late 90s brought the emergence of 2nd & 3rd generation Web applications along with a huge demand to integrate and externalize systems, providing true transaction processing to intermediaries and clients. A new layer of technology and middleware was added to the already strained legacy environment. In many cases, this was only partially successful due to the inherent limitations of some of the old legacy technologies, in addition to the business users frustration and growing need for more functionality and easier accessibility.

The years of “band aid” approaches, piecemeal technology implementation and exception programming have left todays typical insurance CIO with a logistical nightmare. A significant portion of todays insurance IT spending is poured into maintenance and support of the legacy environment, rather than the preferred investment in new technologies, capabilities and product development.

Lets consider the hypothetical example of a multinational, multi-line life insurer with its core systems running as COBOL mainframe applications with a portfolio of approximately 50,000 programs and 20 million lines of code written over 25 years. Like most well-established life companies, they would be required to drag along the past hundred years of history, with the oldest policies dating back to pre-World War I. Periodic mergers and acquisitions add more complexity.

For closed blocks of business, they might try system consolidation in an attempt to create a generic product chassis to simplify administration. However, the generic product chassis approach is flawed. Unless volumes are low, many options will be discounted as too expensive from a reserving and profitability perspective, and sometimes legal and contractual obligations prevent substitution with other products. While this example is that of a life insurer, p-c insurance can be equally complex when supporting many lines of business, especially in commercial surplus and excess markets.

Aside from the technology challenges, lurking in the shadows of the legacy technology question is an even bigger problem. IT resources with the skills required to maintain the aging application portfolio are quickly dwindling in numbers. The teaching of Assembler, RPG or COBOL programming languages has been abandoned by virtually all schools. And young programmers perceive no benefits in gaining these dated skills.

Over the next decade, most legacy language programmers will retire, leaving insurance organizations an extremely difficult and costly environment to maintain with no viable skill sets in sight. Recruitment drives at the local “Shady Pines Retirement” complex is hardly a sustainable strategy. And, for many mid-size companies who have depended on their limited, yet seasoned IT staff, the loss of just a few key individuals could prove fatal.

The question at this technology crossroads is not if the legacy needs to be replaced, but rather: “What do we use to replace the aging legacy?” Is there really a viable technology alternative that is robust enough and has the longevity to provide the next generation of back-office solutions?

The choice is boiling down to two distinct options–the .NET specification from Microsoft or the Java Enterprise Edition 2 (J2EE) specification developed by Sun and now adopted by many large software vendors, including IBM, Oracle and HP.

The .NET option enables language independence, but requires a commitment to the Microsoft operating system. On the other hand, J2EE offers platform independence, but a commitment to the JAVA programming language environment.

J2EE may be attractive to large insurers requiring the unparalleled security, dependability and high volume capabilities found with the traditional mainframe. Many mid-size companies night prefer UNIX and OS/400 operating systems for exactly the same reasons.

However, .NET is also a viable alternative that can offer large throughput and robust processing capabilities. In my experience, larger insurers are adopting J2EE as their core strategic direction, while smaller operations are opting for Microsoft .NET.

To develop a coherent strategy to replace legacy systems, start with a capability evaluation of the entire systems portfolio, taking all business drivers and key indicators of performance into consideration. Reviewing the current state and performing a gap analysis will determine the major pain points. The result will be a prioritized road map to tackle the project from both business and technology perspectives.

The only viable way to sell a Herculean legacy replacement project is to convince the organizations executives of the potential new business capability with manageable risk. Robust, on-demand Web applications will offer huge organizational cost saving opportunities when displacing in-house work. Add in the advantages of self-service and instant gratification for channel partners and customers, and the ROI for Web applications is a winner.

Where possible, first focus on legacy replacement for the functional area with the highest ROI. As the overall decommissioning savings come largely at the end of the full replacement cycle, defer the lowest ROI phases to the back end. Continually demonstrating attractive ROI through all phases of this multiyear project will help sustain critical executive sponsorship.

Only a brave and well-prepared CIO can successfully approach the board of directors and request five years and multiple millions of dollars to support a project the scope and size of legacy replacement. Showing a steady stream of financial returns over the entire period makes the decision more palatable and minimizes the risk.

While the CIO needs to be one of the key evangelists for the legacy transition, the ROI expectation will only be realized with the complete commitment of the business units.

Companies that get moving now and complete this legacy replacement challenge will undoubtedly be the winners in the future insurance market race. Those who ignore the challenge of the rapidly retiring baby boomers may end up like the unfortunate frog that ignored the rising temperature.

Rodney Griffin is director of product management for Emeryville, Calif.-based WorldGroup (www.wgcusa.com). He can be reached at rodney_griffin@wgcusa.com.


Reproduced from National Underwriter Property & Casualty/Risk & Benefits Management Edition, October 17, 2003. Copyright 2003 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.