feature story

Leaving Your Legacy

With chip prices falling, desktops more powerful than ever, and new systems taking advantage of technology inconceivable in the 1970s, the days of the mainframe may be numbered. Are you ready to move on?

Ten years ago, we were reading articles about why insurers should migrate from mainframe to client/server architecture. Today, we still are.

The arguments for migration have, however, changed. Before, some selling points were GUIs and more flexible front-end tools—you know, touchy-feely stuff. But over time, better analytic applications have become available for mainframe systems, and presentation layers have been offered to dress up even the ugliest green-screen system.

Today’s discussions about replacement of insurers’ legacy systems—both mainframe and first-generation client/server—have distilled to more objective analyses. Of course, the best reason for replacement still is “It doesn’t run any more,” something we didn’t think we’d hear so soon after completing Y2K-driven remediation efforts on decades-old systems.

“Most of these [legacy] systems are patchwork quilts—islands jerry-rigged together,” said Cal Braunstein, chairman/CEO and executive director of research of the Robert Frances Group. He added that this trend was, in some cases, exacerbated by companies who rushed to install some first-generation client/server systems as point departmental or line-of-business solutions. “You need…to find an architecture that can meet future business needs.”

Meeting those needs was the motivation that started the current and ongoing migration at Anthem Blue Cross and Blue Shield’s Midwest Division. Mergers, acquisitions, and technology components spread across three states had resulted in nine different core processing systems servicing the Midwest Division’s business. This hodgepodge seriously restricted its ability to provide effective multi-state service, create new products, and distribute workloads among staff.

Anthem first looked at choosing one of its several mainframe systems to handle the entire business load, but decided none was suitable. “Some were beginning to fail, others didn’t have the functionality we needed to deliver across the three states, and others weren’t scalable,” said Shirlee Cassidy, vice president of Anthem Midwest’s business and information systems.

Anthem selected Facets by Erisco (now TriZetto), and began implementation in 1999. The two-tiered client/server system runs on a series of RS/6000 boxes. To date, Anthem has completed the migration of one million members to the new platform, has retired mainframes in Kentucky, will soon complete migration in Indiana, and recently began the process in Ohio.

A patchwork can affect viability of systems beyond the pure operational level as well. “At another level, working better with agents, having better information about the client, being able to service them better—those are really the key issues,” said Christine Ingold, vice president of global financial service at PeopleSoft. “How to bring customer information forward so insurers have a complete view of the customer and understand the relationships among the different channels,” is a challenge for carriers faced with systems with a transactional focus or with individual systems supporting different customer touchpoints.

Finding Your Center

Insurers are looking to their IT departments to “develop systems and strategies that develop customer-centric packages, and that’s not how they were developed; they were line-of-business packages,” Braunstein said. And the problems with bringing siloed systems together to develop any sort of three-dimensional customer view are many. There are different databases with different field names of different lengths, as well as combinations of relational databases, hierarchical databases, and flat-file formats that may maintain key information in miscellaneous fields.

“[This] becomes very frustrating to an IT executive who said, ‘I’ve got all the damn data, let’s bring it together and use it,’ and IT is saying, ‘You can’t,’” Braunstein said. “And you don’t want to start creating other shadow databases and synchronizing them on an ongoing basis. These are problems that make somebody finally turn around and say, I need [a new] architecture—I’ve had my fill of this.”

That’s exactly what happened at Grange Insurance, headquartered in Seattle. The company had been using TFG from the Freedom Group and Encore from the (now-defunct) Heritage Computer Corporation on IBM 390 architecture, running VM and VSE.

“We need to be able to generate reports quickly, to slice and dice the data, and take different views and assess where the business is going,” said Ralph Carlile, Grange’s vice president of information technology. For the mainframe, there are some tools that allow some acceleration, but they’re expensive, and the mainframe environment is just too difficult.”

“The other driver was, as we develop and procure applications, we want to have standardized interfaces, being able to revolve around standard data schema like XML.” In a mainframe environment, “no one seems to be able to master how to standardize interfaces for a complete range of technologies,” said Carlile.

For other insurers, the key motivator behind migration to client/server is the inability of their legacy mainframe system to quickly respond to new marketing opportunities and to expand to meet the growth goals of the enterprise. Denver-based COPIC Insurance was faced with those issues in its homegrown administration systems that resided on their HP3000.

“We dominate the Colorado medical malpractice market…so our intention is to expand into other states and broaden our product line,” said Bill Donohue, COPIC’s CIO and vice president of information technology. Additionally, “The support for the operating system was being withdrawn by HP, so we would have had to do a migration at some point, probably this year.”

COPIC completed its migration to Delphi Technology’s Oasis system in December 2001. Oasis handles policy, claims, financial, and risk management for COPIC, runs on Sun Solaris servers, and leverages the insurer’s existing database investments in and experience with Oracle.

“We Can Always Throw Iron at It”

Regardless of where insurers fall on the spectrum of reasons for legacy system replacement—from the necessary to the purely desirable—each faces tremendous risks in the migration process. The greatest risk is putting in systems that don’t work, or at least don’t work as well as those being replaced.

That’s one reason why some insurers, such as Prudential, are maintaining functioning legacy systems for existing business, while bringing in client/server systems only for new business. A degradation of performance that follows the replacement of existing systems is the biggest fear of Ron Belmont, vice president of information systems in Prudential’s life insurance division. “Not necessarily in response time, because we can always throw iron at it, but in terms of work we get done for each technology dollar spent. What is my run rate? That’s our biggest technology challenge.”

Prudential is therefore maintaining its homegrown mainframe application for its pre-demutualization book of traditional and variable life as well as a Vantage mainframe system by CSC for any new variable life. However, for its post-demutualization book of new business term life, the company uses LifePro by Professional Data Management Again, which it installed about eighteen months ago on an IBM system running AIX.

“Our investment has been in building what we call goal-oriented transactions, which is a layer above the admin engines to make business-oriented transactions look the same regardless of what platform you are accessing our services from,” Belmont said. “Essentially [it’s] a ‘surround’ strategy. That benefits our customer service people, and as we push out self-service to the Web, it allows us to port those functions to the Web space. That’s where we’re making our most significant investment in client/server as it relates to the admin platforms.”

In deciding what to do with their mainframe systems, life insurance companies are also limited—or, perhaps, aided—by the nature of their business. “A policy sold in 1958 stays the same between 1958 and 2001,” said Bill Ball, vice president of information technology services at John Hancock. “In property/casualty, the policy renews every year, so you can have a conversion strategy where you put renewing policies on a new system.”

Like Prudential, John Hancock is retaining its in-house developed mainframe-based systems, and is not converting the data on them. It did convert a legacy client/server application from Trimark to McCamish Systems’ VPAS. Additionally, it installed PolicyLink, a client/server system from Leverage (now CSC) in 1998.

“Conversion is costly and difficult to make a strong compelling business case, particularly when the systems we have runs pretty well,” Ball explained. “And if you’re saying, ‘I’m not putting any more product on them, I’m just going to enhance the functionality,’ it becomes a less expensive alternative to investing $5 million to convert them to another platform.”

Ball’s energies are therefore focused on front-end technologies to provide access and operational efficiencies. “Your high-volume, call-center-type transactions, those are the ones you want to front end,” he said. “You want people to be able to process the most common and least complex transactions quickly. Unlike property/casualty, we’re not worried as much about the efficiency of claims systems in life.” Instead, he explained, Hancock is using Internet technologies to build the front end, eliminating multi-system issues from the perspective of the end users, distributors, and customers.

The other reported problem for insurers the size of John Hancock and Prudential is a dearth of systems and vendors on the market with the power to support their operations. “Particularly with an existing customer base like Prudential has, there aren’t that many products out there that are built to accommodate us,” Belmont said. “We’re the 800-pound gorilla. There are specific volume concerns that are not shared by all our competitors.”

Insurers of any size face other, well-documented risks involved in any system migration: data quality issues, cost overruns and delays, inability of the vendor to deliver. And particularly when it comes to core administration systems, the typical length of the project itself poses its own problem.

“The thing to be leery of with anything that represents a multi-year project is not to create a single multi-year project,” said RFG’s Braunstein. “The longer the project, the greater the risk of failure. The other piece is [that] technology will change as you work your way through the process, so you’ve got to try to look at where it will be in a few years, and to make sure that what you’re putting in won’t be obsolete.”

The means to mitigate migration problems aren’t revolutionary. Provide intermittent deliverables. Vet the vendor. Cleanse the data. “The more cleaning you can do before you’re trying to migrate, the better you’ll be,” said Chris Mears, vice president of development at Delphi Technology. “If you try to clean when you migrate, you can’t tell if the problem is in the migration, if the new system has a bug, or whatever.”

Reality Checklist

But how should insurers turn these system-integration truisms into real-world solutions? Consider the actual problems faced by the insurers who’ve undertaken the migration process.

Among the many risks that COPIC identified for their installation, the two that stood out were vendor stability and user buy-in. “I’m not a genius, but I’ve been doing this for 30-some-odd years, so I was able to anticipate most of the potential problems,” said Donohue. “But [choosing] a small vendor was a risk.”

At the time COPIC was evaluating Delphi Technology, the vendor had a track record of successful installations at other medical malpractice insurers who had similar needs for multi-state, multi-line capability. COPIC negotiated penalties and bonuses that were tied to the delivery date of the software; that addressed one level of concern. But another issue COPIC identified and confirmed via references was the high level of configuration that would be required to make the system match its existing business rules.

Although there are plenty of advantages of working with a smaller technology company, there are some disadvantages as well, Donohue said. “[The software] is not plug and play, so you’re dependent to a large extent on the vendor.”

In Donohue’s case, his staff had to do a lot of customization to the off-the-shelf product, so to help ensure successful configuration—as well as address user concerns—COPIC’s IT department turned to its business unit for high-level support. “We were also able to get the business to give us a full-time, management-level person for twelve months of the project,” Donohue said. “We never let the business [people] go away for more than three weeks before we brought them back for some purpose, whether it be training or testing. That’s important because people in the business forget quickly what project problems are all about, because they have their own day-to-day business to deal with.”

Secondly, the insurer also invested heavily in in-house testing of software and kept their on-staff “Oracle guru” happy by putting him in control of the conversion planning. (Normally, the vendor would have been responsible for that conversion, Donohue explained.)

Donohue is pleased with the results. “Maybe I’m still stuck in the euphoria of having installed a system in just thirteen and a half months, but from a strategic perspective and in giving the business ownership of the project, it was a home run.”

Grange identified two key areas of risk: cultural, involving training IT staff in new skills and users in new workflows and processes; and technological, involving moving, cleansing, and reformatting data. The first area is being addressed via regular assessment of the Diamond project among Carlile, his staff, and the users. The foundation for addressing data issues began when Grange installed a SQL2000 enterprise database that serves as the main storage point for all data in the enterprise as the insurer migrates from the mainframe to the new client/server system.

“Diamond replicates its information back into the database as its data changes. The information that’s still on the mainframe is moved into the enterprise database at some replication frequency. That’s why we put that [database] in place; it’s the hub of the wheel. And these different systems that provide updated information and data, due to their transactions, we’re going to synchronize or replicate on a regular basis,” said Carlile. Grange hopes this strategy will address the impending difficulty of generating reports from multiple data sources. “That was a primary concern, and [the enterprise database] starts to simplify the reporting process and hopefully over time will minimize the effort in this transition from a data point of view.”

Finally, at Anthem, technology challenges have been minor compared to the business issues addressed before and during the migration. “We made the decision that we wanted to consolidate our business model at the same time we were migrating our platform, so that meant we need to reach agreement on a number of tri-state issues that were all handled differently,” Cassidy explained. “Having a process whereby associates can work through those issues and analyze potential impact has been important. We’ve done that through multiple levels of oversight and governance.”

Some would say that, in the end, the biggest risk for insurers is staying with a legacy system that meets short-term needs, but which is inadequate to support the future of the business. “The more data you put into an older system, the harder it will be to convert them,” said Jon A. Loveless, director of sales support at Delphi Technology.

But perhaps the most direct advice for insurers looking to approach client/server installation or migration comes from John Hancock’s Bill Ball: “Spend less time getting it right and more time getting it. We spend a lot of time making sure it’s the right choice, but none of them are really right. They’re all ugly, all complex. So pick one, and start solving the problems associated with implementing it. Have some organizational stomach for the concept of ‘We’re just doing this.’ Nothing is infallible. The only thing that’s guaranteed is that somebody will screw something up somewhere.”

Web-Native: Return of the (Ultra) Thin Client

The ubiquity and flexibility of PCs drive many insurers to a client/server architecture—not only for their administration systems, but even in the systems that touch only limited points in the enterprise. Yet one of the concepts of “old” mainframe applications—performing all the processing on the server—is part of the theory behind the newest Web-native applications.

While insurers are reluctant to turn over their core administration functions to a Web-based outsourcer, solution providers are betting that this model will take off for non-mission-critical functions such as CRM, illustration, and analytics.

“Consider an insurer still using dumb terminals to access multiple systems in the background,” said Christine Ingold, vice president of global financial service at PeopleSoft. Using a Web-native application “should really be an easy migration, because all that terminal needs is a Web browser. There’s no processing that needs to take place on the client, and nothing to be installed.” A cheap PC with a browser for the Web-based system and a terminal emulator for the mainframe back-end would do the trick.

But how to first connect the back-end systems at the insurer to these Web-native applications? PeopleSoft pushes a portal strategy with pre-architected models to minimize conversion issues and with, as Ingold said, “the connectors to plug into insurers’ systems without having to convert their technology.”

Will it and other vendors deliver on that promise, or will the challenge of exposing components and applying wrappers fall on insurers’ IT departments? We’ll see. —MPV

Mainframe Redux?

In 2001, IBM’s mainframe business grew for the first time since 1989, while “slow PC sales” helped contribute to an “overall revenue decline.”

(Source: IBM press release, January 17, 2002)

Links

Anthem Blue Cross and Blue Shield
John Hancock
McCamish Systems
COPIC Insurance
Grange Insurance
Prudential
Computer Science Corporation
Delphi Technology
The Freedom Group
IBM
PeopleSoft
Professional Data Management Again
Robert Frances Group
TriZetto

***

For more information about McCamish Systems, please contact our Sales & Marketing group at Solutions@McCamish.com or call 800.366.0819.

©2007, McCamish Systems, L.L.C. All rights reserved.