Ten years ago, we were reading articles about why insurersshould migrate from mainframe to client/server architecture. Today,we still are.
The arguments for migration have, however, changed. Before, someselling points were GUIs and more flexible front-end toolsyou know,touchy-feely stuff. But over time, better analytic applicationshave become available for mainframe systems, and presentationlayers have been offered to dress up even the ugliest green-screensystem.
Todays discussions about replacement of insurers legacy systemsbothmainframe and first-generation client/serverhave distilled to moreobjective analyses. Of course, the best reason for replacementstill is It doesnt run any more, something we didnt think wed hearso soon after completing Y2K-driven remediation efforts ondecades-old systems.
Most of these [legacy] systems are patchwork quiltsislandsjerry-rigged together, said Cal Braunstein, chairman/CEO andexecutive director of research of the Robert Frances Group. Headded that this trend was, in some cases, exacerbated by companieswho rushed to install some first-generation client/server systemsas point departmental or line-of-business solutions. You needtofind an architecture that can meet future business needs.
Meeting those needs was the motivation that started the current andongoing migration at Anthem Blue Cross and Blue Shields MidwestDivision. Mergers, acquisitions, and technology components spreadacross three states had resulted in nine different core processingsystems servicing the Midwest Divisions business. This hodgepodgeseriously restricted its ability to provide effective multi-stateservice, create new products, and distribute workloads amongstaff.
Anthem first looked at choosing one of its several mainframesystems to handle the entire business load, but decided none wassuitable. Some were beginning to fail, others didnt have thefunctionality we needed to deliver across the three states, andothers werent scalable, said Shirlee Cassidy, vice president ofAnthem Midwests business and information systems.
Anthem selected Facets by Erisco (now TriZetto), and beganimplementation in 1999. The two-tiered client/server system runs ona series of RS/6000 boxes. To date, Anthem has completed themigration of one million members to the new platform, has retiredmainframes in Kentucky, will soon complete migration in Indiana,and recently began the process in Ohio.
A patchwork can affect viability of systems beyond the pureoperational level as well. At another level, working better withagents, having better information about the client, being able toservice them betterthose are really the key issues, said ChristineIngold, vice president of global financial service at PeopleSoft.How to bring customer information forward so insurers have acomplete view of the customer and understand the relationshipsamong the different channels, is a challenge for carriers facedwith systems with a transactional focus or with individual systemssupporting different customer touchpoints.

Finding Your Center
Insurers are looking to their IT departments to develop systems andstrategies that develop customer-centric packages, and thats nothow they were developed; they were line-of-business packages,Braunstein said. And the problems with bringing siloed systemstogether to develop any sort of three-dimensional customer view aremany. There are different databases with different field names ofdifferent lengths, as well as combinations of relational databases,hierarchical databases, and flat-file formats that may maintain keyinformation in miscellaneous fields.
[This] becomes very frustrating to an IT executive who said, Ivegot all the damn data, lets bring it together and use it, and IT issaying, You cant, Braunstein said. And you dont want to startcreating other shadow databases and synchronizing them on anongoing basis. These are problems that make somebody finally turnaround and say, I need [a new] architectureIve had my fill ofthis.
Thats exactly what happened at Grange Insurance, headquartered inSeattle. The company had been using TFG from the Freedom Group andEncore from the (now-defunct) Heritage Computer Corporation on IBM390 architecture, running VM and VSE.
We need to be able to generate reports quickly, to slice and dicethe data, and take different views and assess where the business isgoing, said Ralph Carlile, Granges vice president of informationtechnology. For the mainframe, there are some tools that allow someacceleration, but theyre expensive, and the mainframe environmentis just too difficult.
The other driver was, as we develop and procure applications, wewant to have standardized interfaces, being able to revolve aroundstandard data schema like XML. In a mainframe environment, no oneseems to be able to master how to standardize interfaces for acomplete range of technologies, said Carlile.
For other insurers, the key motivator behind migration toclient/server is the inability of their legacy mainframe system toquickly respond to new marketing opportunities and to expand tomeet the growth goals of the enterprise. Denver-based COPICInsurance was faced with those issues in its homegrownadministration systems that resided on their HP3000.
We dominate the Colorado medical malpractice marketso our intentionis to expand into other states and broaden our product line, saidBill Donohue, COPICs CIO and vice president of informationtechnology. Additionally, The support for the operating system wasbeing withdrawn by HP, so we would have had to do a migration atsome point, probably this year.
COPIC completed its migration to Delphi Technologys Oasis system inDecember 2001. Oasis handles policy, claims, financial, and riskmanagement for COPIC, runs on Sun Solaris servers, and leveragesthe insurers existing database investments in and experience withOracle.

We Can Always Throw Iron at It
Regardless of where insurers fall on the spectrum of reasons forlegacy system replacementfrom the necessary to the purelydesirableeach faces tremendous risks in the migration process. Thegreatest risk is putting in systems that dont work, or at leastdont work as well as those being replaced.
Thats one reason why some insurers, such as Prudential, aremaintaining functioning legacy systems for existing business, whilebringing in client/server systems only for new business. Adegradation of performance that follows the replacement of existingsystems is the biggest fear of Ron Belmont, vice president ofinformation systems in Prudentials life insurance division. Notnecessarily in response time, because we can always throw iron atit, but in terms of work we get done for each technology dollarspent. What is my run rate? Thats our biggest technologychallenge.
Prudential is therefore maintaining its homegrown mainframeapplication for its pre-demutualization book of traditional andvariable life as well as a Vantage mainframe system by CSC for anynew variable life. However, for its post-demutualization book ofnew business term life, the company uses LifePro by ProfessionalData Management Again, which it installed about eighteen months agoon an IBM system running AIX.
Our investment has been in building what we call goal-orientedtransactions, which is a layer above the admin engines to makebusiness-oriented transactions look the same regardless of whatplatform you are accessing our services from, Belmont said.Essentially [its] a surround strategy. That benefits our customerservice people, and as we push out self-service to the Web, itallows us to port those functions to the Web space. Thats wherewere making our most significant investment in client/server as itrelates to the admin platforms.
In deciding what to do with their mainframe systems, life insurancecompanies are also limitedor, perhaps, aidedby the nature of theirbusiness. A policy sold in 1958 stays the same between 1958 and2001, said Bill Ball, vice president of information technologyservices at John Hancock. In property/casualty, the policy renewsevery year, so you can have a conversion strategy where you putrenewing policies on a new system.
Like Prudential, John Hancock is retaining its in-house developedmainframe-based systems, and is not converting the data on them. Itdid convert a legacy client/server application from Trimark toMcCamish Systems VPAS. Additionally, it installed PolicyLink, aclient/server system from Leverage (now CSC) in 1998.
Conversion is costly and difficult to make a strong compellingbusiness case, particularly when the systems we have runs prettywell, Ball explained. And if youre saying, Im not putting any moreproduct on them, Im just going to enhance the functionality, itbecomes a less expensive alternative to investing $5 million toconvert them to another platform.
Balls energies are therefore focused on front-end technologies toprovide access and operational efficiencies. Your high-volume,call-center-type transactions, those are the ones you want to frontend, he said. You want people to be able to process the most commonand least complex transactions quickly. Unlike property/casualty,were not worried as much about the efficiency of claims systems inlife. Instead, he explained, Hancock is using Internet technologiesto build the front end, eliminating multi-system issues from theperspective of the end users, distributors, and customers.
The other reported problem for insurers the size of John Hancockand Prudential is a dearth of systems and vendors on the marketwith the power to support their operations. Particularly with anexisting customer base like Prudential has, there arent that manyproducts out there that are built to accommodate us, Belmont said.Were the 800-pound gorilla. There are specific volume concerns thatare not shared by all our competitors.
Insurers of any size face other, well-documented risks involved inany system migration: data quality issues, cost overruns anddelays, inability of the vendor to deliver. And particularly whenit comes to core administration systems, the typical length of theproject itself poses its own problem.
The thing to be leery of with anything that represents a multi-yearproject is not to create a single multi-year project, said RFGsBraunstein. The longer the project, the greater the risk offailure. The other piece is [that] technology will change as youwork your way through the process, so youve got to try to look atwhere it will be in a few years, and to make sure that what youreputting in wont be obsolete.
The means to mitigate migration problems arent revolutionary.Provide intermittent deliverables. Vet the vendor. Cleanse thedata. The more cleaning you can do before youre trying to migrate,the better youll be, said Chris Mears, vice president ofdevelopment at Delphi Technology. If you try to clean when youmigrate, you cant tell if the problem is in the migration, if thenew system has a bug, or whatever.

Reality Checklist
But how should insurers turn these system-integration truisms intoreal-world solutions? Consider the actual problems faced by theinsurers whove 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. Imnot a genius, but Ive been doing this for 30-some-odd years, so Iwas able to anticipate most of the potential problems, saidDonohue. But [choosing] a small vendor was a risk.
At the time COPIC was evaluating Delphi Technology, the vendor hada track record of successful installations at other medicalmalpractice insurers who had similar needs for multi-state,multi-line capability. COPIC negotiated penalties and bonuses thatwere tied to the delivery date of the software; that addressed onelevel of concern. But another issue COPIC identified and confirmedvia references was the high level of configuration that would berequired to make the system match its existing businessrules.
Although there are plenty of advantages of working with a smallertechnology company, there are some disadvantages as well, Donohuesaid. [The software] is not plug and play, so youre dependent to alarge extent on the vendor.
In Donohues case, his staff had to do a lot of customization to theoff-the-shelf product, so to help ensure successful configurationaswell as address user concernsCOPICs IT department turned to itsbusiness unit for high-level support. We were also able to get thebusiness to give us a full-time, management-level person for twelvemonths of the project, Donohue said. We never let the business[people] go away for more than three weeks before we brought themback for some purpose, whether it be training or testing. Thatsimportant because people in the business forget quickly whatproject problems are all about, because they have their ownday-to-day business to deal with.
Secondly, the insurer also invested heavily in in-house testing ofsoftware and kept their on-staff Oracle guru happy by putting himin control of the conversion planning. (Normally, the vendor wouldhave been responsible for that conversion, Donohueexplained.)
Donohue is pleased with the results. Maybe Im still stuck in theeuphoria of having installed a system in just thirteen and a halfmonths, but from a strategic perspective and in giving the businessownership of the project, it was a home run.
Grange identified two key areas of risk: cultural, involvingtraining IT staff in new skills and users in new workflows andprocesses; and technological, involving moving, cleansing, andreformatting data. The first area is being addressed via regularassessment of the Diamond project among Carlile, his staff, and theusers. The foundation for addressing data issues began when Grangeinstalled a SQL2000 enterprise database that serves as the mainstorage point for all data in the enterprise as the insurermigrates from the mainframe to the new client/server system.
Diamond replicates its information back into the database as itsdata changes. The information thats still on the mainframe is movedinto the enterprise database at some replication frequency. Thatswhy we put that [database] in place; its the hub of the wheel. Andthese different systems that provide updated information and data,due to their transactions, were going to synchronize or replicateon a regular basis, said Carlile. Grange hopes this strategy willaddress the impending difficulty of generating reports frommultiple data sources. That was a primary concern, and [theenterprise database] starts to simplify the reporting process andhopefully over time will minimize the effort in this transitionfrom a data point of view.
Finally, at Anthem, technology challenges have been minor comparedto the business issues addressed before and during the migration.We made the decision that we wanted to consolidate our businessmodel at the same time we were migrating our platform, so thatmeant we need to reach agreement on a number of tri-state issuesthat were all handled differently, Cassidy explained. Having aprocess whereby associates can work through those issues andanalyze potential impact has been important. Weve done that throughmultiple levels of oversight and governance.

Some would say that, in the end, the biggest risk for insurersis staying with a legacy system that meets short-term needs, butwhich is inadequate to support the future of the business. The moredata you put into an older system, the harder it will be to convertthem, said Jon A. Loveless, director of sales support at DelphiTechnology.
But perhaps the most direct advice for insurers looking to approachclient/server installation or migration comes from John HancocksBill Ball: Spend less time getting it right and more time gettingit. We spend a lot of time making sure its the right choice, butnone of them are really right. Theyre all ugly, all complex. Sopick one, and start solving the problems associated withimplementing it. Have some organizational stomach for the conceptof Were just doing this. Nothing is infallible. The only thingthats guaranteed is that somebody will screw something upsomewhere.

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

The ubiquity and flexibility of PCs drive many insurers to aclient/server architecturenot only for their administrationsystems, but even in the systems that touch only limited points inthe enterprise. Yet one of the concepts of old mainframeapplicationsperforming all the processing on the serveris part ofthe theory behind the newest Web-native applications.
While insurers are reluctant to turn over their core administrationfunctions to a Web-based outsourcer, solution providers are bettingthat this model will take off for non-mission-critical functionssuch as CRM, illustration, and analytics.
Consider an insurer still using dumb terminals to access multiplesystems in the background, said Christine Ingold, vice president ofglobal financial service at PeopleSoft. Using a Web-nativeapplication should really be an easy migration, because all thatterminal needs is a Web browser. Theres no processing that needs totake place on the client, and nothing to be installed. A cheap PCwith a browser for the Web-based system and a terminal emulator forthe mainframe back-end would do the trick.
But how to first connect the back-end systems at the insurer tothese Web-native applications? PeopleSoft pushes a portal strategywith pre-architected models to minimize conversion issues and with,as Ingold said, the connectors to plug into insurers systemswithout having to convert their technology.
Will it and other vendors deliver on that promise, or will thechallenge of exposing components and applying wrappers fall oninsurers IT departments? Well see. MPV

Mainframe Redux?

In 2001, IBMs mainframe business grew for the first time since1989, while slow PC sales helped contribute to an overall revenuedecline.
(Source: IBM press release, January 17, 2002)

clickhere

Anthem Blue Cross and Blue Shield: www.anthem.com
John Hancock: www.johnhancock.com
McCamish Systems: www.mccamish.com
COPIC Insurance: www.copic.com
Grange Insurance: www.grange.com
Prudential: www.prudential.com

Computer Science Corporation: www.csc.com
Delphi Technology: www.delphi-tech.com
The Freedom Group: www.freedomgroup.com
IBM: www.ibm.com
PeopleSoft: www.peoplesoft.com
Professional Data Management Again:
www.pdmagain.com
Robert Frances Group: www.rfgonline.com
TriZetto: www.trizetto.com