What’s your Legacy plan?

Bring up the topic of legacy systems to just about anyone who works at an insurance company, and the reactions will range from a warm smile to an exasperated sigh (with maybe a grimace in the middle). To some, older legacy systems are the company's bane. To others, they are a blessing. The reality is that, more often than not, legacy is both.

Bane or blessing, for the most part legacy is here to stay. "In 1990, a cover on InformationWeek said the mainframe was dead," says David Holmes, executive vice president at Jacada, an Atlanta-based provider of legacy integration and Web-to-host solutions. "That never happened. And then Y2K came along. If Y2K didn't kill the mainframe, nothing will."

It seems that legacy systems have been blessed with eternal life. Still, many carriers are looking for ways to adapt to business demands both with and without involving their older systems. In short, since legacy systems are as unique as the companies that own them, each system merits its own strategy. In fact, no matter how much a given organization is committed to replacing all legacy systems, most find it nearly impossible.

"Strategies for legacy systems are developed on a case-by-case basis," says Tim Wright, CTO at GEAC (Markham, Ontario), a business performance management solutions provider. "Each customer is unique and has different reasons for replacing or modifying" their legacy systems.

However, no matter how obvious the cost savings are, sometimes reducing redundancy is too expensive. "Running old mainframes is expensive," says Jacada's Holmes. "That said, anybody can replace a mainframe, but you are talking millions of dollars and years of development."

"The cost of replacing a legacy system, or migrating off of a system, is phenomenal," adds Ravi Koka, founder, chairman and chief strategy officer at SEEC Inc., a Pittsburgh-based business process solutions provider. "Most companies look to change their legacy systems incrementally to spread the cost."

Whatever a company's strategy may be, warns Pawel Stefanski, core insurance executive, IBM Global Insurance Industry (Armonk, N.Y.), if the new technology is not applied correctly, the insurer will have problems down the road. "If today's newer technology is not applied correctly, it will become legacy technology in 10 years," Stefanski says.

"If you just put the technology in place without thinking about the architecture, you will end up in the same situation-with outdated systems that have been customized and do not work with each other," Stefanski adds.

David Caddis, vice president, application infrastructure management, Candle Corp., an El Segundo, Calif.-based enterprise infrastructure management provider, agrees. "In many cases, insurers are rolling out systems that can leverage legacy processing power, while at the same time unifying systems to synchronize customer information. Our customers all face unique challenges," he says. "This begs for not just a piecemeal integration approach. Insurance companies need a service-oriented architecture," Caddis adds.

That said, it's really newer technologies that are making it possible for carriers to develop sound architectures to either leverage or migrate off of their legacy systems. "One of the keys is XML" says Larry Fortin, director, insurance practice, Edgewater Technology (Wakefield, Mass.), a strategic consulting and software development firm. "Rules-based technology that leverages XML standards from ACORD is important."

The increasing use of XML standards puts the insurance industry in a unique position to leverage Web services, a much-heralded technology that can make working with business partners much easier. According to Kimberly Harris, research director, insurance, at Gartner (Stamford, Conn.), because of the work that ACORD has done in developing XML standards for insurance transactions, the insurance industry is much farther ahead of other industries when it comes to being able to roll out Web services.

"Insurance companies are definitely looking at Web services, and tools like WebSphere and .NET to help them with their legacy problems," says William Fournell, vice president, financial services consulting group, at Cap Gemini Ernst & Young (CGE&Y, New York). "And they are not just using XML to build front-ends or to screen-scrape. Insurers are building true applications in XML that can leverage some of their existing systems to provide better service."

By leveraging the ACORD XML standards, along with Web services technology and sound internal integration and development practices, insurance companies do have a way to leverage what they have now for future use. However, there is no silver-bullet that will work in every company. As mentioned previously, one IT organization actually may use several different strategies for its various legacy systems. Here are a few examples of ways insurance companies are living with their legacies-in most cases, as a blessing:

A Bit of This, A Bit of That

John Kellington, CTO at Ohio Casualty (OCAS, $4.78 billion in assets, Fairfield, Ohio), knew from his prior experience as a consultant at IBM there is no single answer to the "what-to-do-with-legacy-systems" question. He boils it down to four approaches. The first is the greenfield approach. "You can build a completely new system, or buy it, and move everything...onto it," Kellington says, but it is expensive and risky.

The second approach is component migration, where components of the older system-such as a rating engine-are moved onto a new platform. It takes longer, but the costs are spread out and there is less risk, he says. The third is "data first," where the systems are left alone and all of the data-policy, customer, rating-is moved to a central database Lastly, there is "surround and tackle," he says. "Build new applications around the existing systems and update the older systems in the process."

"When we replace a legacy system, rarely do we use just one strategy," Kellington says. For instance, "we have a personal lines policy admin system that is 3270-based," he says. "Our plan is to move the book of business to a new system, but we needed to extend the older system to our agents in the meantime."

Ohio Casualty decided to build applications, along with SEEC, to represent the 3270 screens through HTML to its agents while the carrier was planning to move the book of business to its in-house-developed Policy Administration Rating and Issuing System (PARIS). "We chose SEEC because we were not looking for more [Java] applets," a functionality that may cause trouble for some field-force agents, Kellington says.

PARIS is based on IBM's IAA (Insurance Application Architecture) and Java functionality, Kellington says. Ohio Casualty's long-term strategy is to move off of its older systems, using a combination of the strategies that Kellington outlined.

Loving Legacy

According to Don Buskard, senior vice president and CTO at AXA Financial, "Our strategy is that we like our legacy, it is a solid asset. We have been grooming our legacy as part of our strategy.

"We have created a technical architecture that sits in front of all of the legacy, and provides all of the communications between the legacy and the front-end systems," Buskard adds. AXA (New York, $480.9 billion in assets under management), along with Candle Corp. and IBM as partners, began developing the architecture as far back as 1989. AXA's strategy leaves the legacy systems virtually untouched, with the architecture handling all communications with new systems, such as AXA's front-end Siebel (San Mateo, Calif.) sales system. The integration architecture currently handles more than 600,000 transactions a day.

"We want to leave our legacy systems untouched," Buskard says. "Nobody wants to replace what is there."

AXA is happy with its strategy because the overlying architecture provides the needed communications at a reasonable price. "We always look at the costs in the organization," Buskard says. "If the legacy systems were redeveloped in a new technology, the maintenance cost would be less. But if we redeveloped the legacy in a newer technology, and you add in the cost of developing and transitioning to a new environment, we don't think you can justify the cost."

To get the company to where it is today, AXA knew it could not tackle everything at once. "If we endeavored at the start of the project to map every single function into the architecture, we would still be mapping today," Buskard says. "Instead, we approached the project and we knew we had three challenges."

The first challenge was to develop a project blueprint. "We knew we had to make the design flexible so we could react as technology changed over time," he says. "Then, rather than just build an architecture, we built an architecture to meet specific business needs. We didn't build the architecture because it is a good idea, we build services on the architecture because there was a business need." The third challenge is testing and scalability. "Every day the activity grows," Buskard says. "It is growing because the services are growing. We have no concerns over scalability."

Buskard says that the architecture has posted some impressive returns. "By having the blueprint and architecture in place for all projects, it makes the reuse of certain components very high," he says. "We have measured a 300 percent rate of return for the 12 years" the architecture has been in place.

Knowing Where You're Going

Sometimes the hardest part of an IT leader's job is not technology, it's people. And when it comes to legacy, the job gets even tougher.

"If something is working, it is very hard to convince the business to invest the time or money" to replace a legacy system, says Lorne Blanche, vice president of information systems at Atlantic Blue Cross Care (ABCC, C$140 million in assets), a Canadian health insurance company headquartered in Moncton, New Brunswick. "We are just beginning to make the business understand that we have to eventually retire our legacy systems. Retiring the legacy is part of our original roadmap and is part of our long-term strategy."

For now, ABCC has chosen to leverage its legacy systems because "you cannot replace the legacy systems in the timeframe that people expect," Blanche says. "Now, anything new that we build, we build it through a Web browser. We are providing new functionality for agents and brokers by interfacing the legacy systems through the Internet."

ABCC's job is a little easier, Blanche says, because as part of the carrier's Y2K strategy everything was ported into a Unix environment. "We still have some restraints, but we are in better shape than we would have been in if everything was running on the older systems. Unix is becoming more disciplined and there are more tools out there [for Unix]."

Central to ABCC's strategy is the use of XML. "We are leveraging XML," he says. "Once you get the legacy transactions into XML, you can make them available to whatever system and whatever format you need," such as making ad hoc reports for agents or providing customer data through a Web browser.

To help the carrier develop XML-based solutions, ABCC didn't have to look far, literally. The company chose XML software and development capabilities from Whitehill Technologies, a Moncton-based provider of business infrastructure software. ABCC purchased Whitehill XML Transport and Whitehill XSL Composer to transform hundreds of existing paper-based reports and documents into online formats in support of ABCC's efforts to improve customer service and efficiencies in its operations.

ABCC's IT executives knew it would be costly to develop similar technology internally. Also, there were already products available on the market that would satisfy ABCC's business requirements. "Every insurer thinks that it does things uniquely, but there are many commonalities in the way business is processed," Blanche says. "The differentiator is customer service, not technology. You don't have to create something from scratch if there is already technology available on the market. Whitehill is based nearby and that is one of the reasons why we gave them attention," adding that with a local supplier a company can sometimes get better service than from a vendor that is hundreds of miles away.

Legacy Remains Untouched

As training costs for its customer-service representatives continued to increase, Indiana Farm Bureau Insurance realized it needed to simplify the interfaces between the front-end and its legacy systems.

"Our legacy systems are decades old," says Goutam Kundu, director of technology infrastructure at Indiana Farm Bureau (Indianapolis, $1.34 billion in assets). "The systems are feature-rich, but in order to get to the data that our customers need, the CSRs had to go to several systems. We wanted to make moving between systems seamless for our agents and CSRs.

"The CSRs wanted to get away from cryptic mainframe codes," Kundu adds. "Our systems were set up to be product-centric, not customer-centric. Training a new CSR was a week-long process."

However, the multi-line carrier was not in a position to immediately move off of its legacy systems because developing a new platform was too expensive and risky, reports Kundu. Instead, "we left the legacy untouched and developed a Web portal front-end with Jacada" for the company's life product lines.

With Jacada, Indiana Farm Bureau decided to extend the legacy system's functionality to CSRs and agents by using XML and Java to automatically capture screens in a rules-based solution. After a successful round of testing in the field, the system was rolled out to all 450 Indiana Farm Bureau agents last year. Within four weeks, the company had 25 screens from CICS applications re-engineered and deployed to its agents with a user-friendly GUI.

On the CSR and agent training front, the time required for a new agent to learn how to use the system went from weeks to a short time for orientation, according to Kundu.

"Jacada enabled us to achieve much better results with less risk, time and money than would have been required to complete this key project manually," according to Greg Clancy, Indiana Farm Bureau's CIO. "We were able to leverage the value we already had in our existing systems while improving them for current and future business needs and objectives."

Eventually, notes Kundu, Indiana Farm Bureau plans to retire some of its 50-plus redundant legacy systems. "Jacada is a short-term solution," he says. "While we evaluate the legacy, we are using Jacada, but we are going to bring down the number of systems we have in the next few years."

Greg MacSweeney is editorial director of InformationWeek Financial Services, whose brands include Wall Street & Technology, Bank Systems & Technology, Advanced Trading, and Insurance & Technology. View Full Bio