When I bought my home 10 years ago, it met my needs well. Butover time, circumstances change. Growing family? Need anotherbathroom. New home office? Gotta have more outlets.
But each new project smacked headfirst into common old-home issues.Could the utility infrastructure support the new load? Whatstructural changes were needed to access core components of thesesystems? Should I simply upgrade to a new home?

Think of insurers legacy systems as old houses, supported notonly by old infrastructure but replete with long-forgotten nooksand crannies and hidden architectural components known only to thebuilders. And now you understand the problem: Whenand howshouldinsurers extend legacy systems, and when should they pull theplug?

To find out, we talked to expertsanalysts, consultants, andinsurers who have first-hand experience at extending the lives oflegacy systems. (Who, you ask? See the sidebar Who Dat?) While wedont expect you to start tearing down wallsliterally orfigurativelybased on this or any other article alone, we expectyoull be able to gain some insight into the issues at hand.

The Analyst
CHARLES JOHNSTON,
THE META GROUP

Technology Decisions: What are the core issues for insurersfaced with aging legacy systems and modern business needs?

Johnston: If youre making a decision to make an investment inmiddleware, it still has to work with a system thats beingmaintained and updated for products and features in the legacyenvironment. If you spend money on the front-end systems andprocesses, youre still making an implicit decision that youre goingto continue to invest in the ability to modify and upgrade thelegacy systems, because a lot of the product changes you need tomake are in the legacy environment.

So right off the bat, youre going to go down what is really oneroad. The other road is to rip it out and replace it.

[Also] recognize that legacy extension is not a onetime process.There will be mergers, acquisitions, and the ultimate goal is tocreate a flexible infrastructure that can bring new systems intothe fold.

TD: So when should insurers just cut bait and throw out thelegacy system altogether?

Johnston: The three reasons why you move away from a system are1) It doesnt cut it from a business futures perspective, 2) The CIOsays the risk of maintaining it is too high, or 3) It cant supportthe current business or perform its current functions anymore.

TD: Then how should insurers evaluate each of thosescenarios?

Johnston: Probably the second is the toughest one, because theCIO is saying, I know were OK today, but well be in serious troublein three years. But thats one of the jobs of the CIO, to maintainthe current and future integrity of the technical architecture.

Its an exercise in risk management and [evaluation of the]business model. You may say: No matter how much we wrapper thesystem, it still takes us three months to bring a product to marketand we need it in three weeks. Another [reason] may be that, evenif the system is running fine internally, can you maintain anorganization to support these [systems]? Do you even have staff onboard anymore who know the architecture?

TD: But if replacement isnt an option despite the analysis, towhat extent can wrapperingencapsulating legacy data orcomponentspresent a solution for current and future problems?

Johnston: Where the system doesnt meet the future needs, thatswhere wrappering is most amenable to success. It definitivelydoesnt help you when youre worried about being able to maintain theenvironment. And it usually doesnt work when the system is broken,although I have seen some companies who have said, We like a lot of[our system] but its not cutting it any more, so well pull off thecore calculations and wrapper it. That can breathe new life intothe system. [In any scenario], the places where wrappering worksbest is where they can tap the original architect of thesystem.

TD: In the library of wrapper acronymsCORBA, COM, SOAP/ XMLwhatare insurers successfully using?

Johnston: We see a stratification based on size. If youre a[larger insurer], you tend to operate in an IBM-centricenvironment, which is now JavaBeans or J2EE, and that implies CORBAis under the covers. A small multi-line insurer may be totallyMicrosoft-centric. They may never have bought a mainframe. Perhapstheyre running Allenbrook on a NT server, Microsoft Exchange onanother NT server, and some applications on a SQL server. Youllfind them programming in DCOM and moving to a .NET environment.Some [larger companies] have linked administration to agencysystems using XML, but youre just really starting to see thatstandard have an impact on the industry in terms ofexternalization.

TD: Who stands out in the middleware space?
Johnston: Youre starting to see a new layer of vendorsthe Vitrias,the Tibcos, the STCsthat are beginning to put on more of a businessface. Theyre not saying, You have to be a C++ object orientedprogrammer who plans everything in UML [unified modeling language]to interact with me. Now Im going to start presenting businessservices.

IBM is taking it even further with its MQ series, saying, Weregoing to help you wrapper your system [but] it can still work theway it always has. If you get 100 insurance companies together andask whos your vendor for infrastructure, they say IBM. Given that,you see an awful lot of MQ series and its derivatives.

TD: What are some key design issues?

Johnston: One of the most difficult parts is designing theinterface so you dont compromise the integrity of the system, whichrequires you to have people who truly understand the architecture.A lot of times those people have been promoted or have retired.

The other issue you run into is cycle time. Most of the [legacy]systems are batch oriented. Even if the system has a real-timeoption, people are used to taking these systems offline formaintenance. And the reason they want to do a legacy extension is[to provide] 24/7, international rolling-with-the-sunprocessing.

The third [issue] is understanding that youre not just slappinga patch on a system. You need to evaluate your infrastructure andarchitecture to create an adaptable environment that allows you toencapsulate the next system and integrate it into the newenvironment. Its not just getting five years out of it, because youdont need all this fancy stuff to do that.

And another big gotchaif you wrapper, you still need to havepeople around who understand the wrapper.

TD: How do you think the software industry is positioned forintegration and extension going forward?

Johnston: There arent a lot of great packages out there today,something somebodys going to want to install and maintain for 10 to20 years. So given that, youre seeing a lot of what youd calllegacy extensions, and some of the large vendors are beginning torecognize that and embrace ittheyre trying to say to people who aregoing out and doing these extension projects, Maybe we dont haveeverything you need right now, but well give you a good interfaceto allow you to interact with our system on a fairly high level.Theyre beginning to realize that they need to position theirsystems as good citizens in a larger ecosystem thats going toinvolve CRM, portals, new business underwriting systems, andfinancial management systemsin contrast to a world where everythingis a nice, clean steel cylinder, and everything evolves in thatsystem.

The Consultants
MICHAEL A. JACKOWSKI, ACCENTURERICHARD MARX AND RUSSELL SCHREIBER,CAP GEMINI ERNST & YOUNG

TD: What approaches to extending lives of legacy systems haveyou seen companies successfully take?

Marx: Weve seen four different approaches. One would be a wrapapproach: using a middleware layerto put in some basic product andprocessing rules logic. The second would be to replace, eitherbuilding or buying a new set of integrated packages. Another isrenovationbasically using new tools available in the market toregenerate legacy code into a more modern format and language fromboth the database and programming standpoint. And the fourth wouldbe to outsource it.

If I look at those four options, the one that we see the mostinterest in today is using an XML-based integration wrapper.

TD: How do insurers evaluate which approach is best forthem?

Marx: There are a few key decisions. What business does theinsurer want to be in? Is it a wealth manager, a productmanufacturer, or a service organization?

If the companys focus is on product development and not service,outsourcing is a good option. The wrap approach is appropriate whenthe current systems provide adequate functionality and theorganization wants to add capabilities in a more flexible andcost-effective manner.

The renovation approach is usually required when systems lackdocumentation and run on technologies that are outdated andexpensive to maintain. There are a handful of tools that willinterrogate the program code and database structures and convertthem to a modern program language and database format. [Y]ou canpick up a lot of business rules, perhaps 80-90 percent, and it alsocreates reasonably robust documentation when, in most instances,none exists.

Schreiber: Renovation tools will create a data model and anobject model, and document the source code to the extent that acomputer generated code can. At least, it will tell you whatmodules call other modules.

TD: What are some of the mistakes youve seen carriers make inefforts to extend their legacy systems?

Jackowski: The first is scope containment. [Second], carrierstraditionally underestimate the complexity, and what they think isa simple replacement turns into a five-year activity. [They alsofail to] understand from a technology perspective what the touchpoints are. How do data feed between the systems? How do you keepthings in sync? What technologies are just a new veneer?

When you look at the underpinnings of a CICS application, thebetter systems will have a client server or a three-tier or n-tierdesign: a well encapsulated display layer versus a data accesslayer versus a business object layer. But there are very fewsystems that are designed that way. When you take systems that werepoorly designed and try to extend them to the Web, or put a GUIfront end on them, theres a lot of trouble because IT cant gettheir hands around the code.

Failures tend to be in the area where carriers feel they can puta wrapper around something that wasnt designed to be wrapped. Thetechnology issues are really around how well the system is designedand whether they can get their hands around the components. Its notjust a pipes and plumbing issue.

TD: Then how can insurers avoid those types ofdisappointments?

Jackowski: Carriers need to understand what their blueprintslook like. What components can be brought in and [installed] out ofthe gates, and what components can be replaced over time? Also,what areas are of high-business impact? Get away from the IT-drivenapproach of replacing legacy applications just because you can.

Lastly, [insurers need] to set a direction that has a lot offlexibility. No two legacy systems look the same, even if theircore roots are the same product. Theyve been modified, tweaked todeath, and very few people may understand them. A key element is tobring in a technology that has a lot of flexibility in terms of howthe core transaction engine can be extended to integrate [withother systems]. Our approach has been to bundle not just softwareassets and services, but also provide the source code anddevelopment environment to allow carriers to have the flexibilityof a custom solution.

TD: Having assessed design issues, what should insurers do next?What extending technologies fit best, and what has beensuccessful?

Jackowski: A lot of systems arent architected in a manner where[any] wrapper on top of IMS or legacy transactions will provide theright capability. There are detailed issues in terms of transactiongranularity, record locking, and concurrency that a lot of thelegacy applications dont understand. The best approach has been toput a new [application] in front of the legacy, where the user doesthe crux of the front office work, and then to push data back onvery discreet transaction boundaries to the legacy system.

Now when we talk to the legacy on the back end, we use a wholeplethora of approaches, but typically MQ Series is used to talk tothe legacy and hook up there. Well even make a run through DB2store procedures to invoke other procedures depending upon what thedata architecture is. But when you use those technologies to hookup to third parties, its a common mistake; the legacy wasntdesigned to be the transaction engine behind those exchanges.

[Carriers need] to put something more robust on the front end toallow the users to save time and focus on the business case, [andto provide] core transaction capabilities to some of thesenew-world technologies such as Web services.

Schreiber: You need to establish an architecture before youchoose your tools, otherwise you have a lot of tools in the basketand no way to use them. If you come from a tool view out, therestoo much overlap. Weve found the folks who are doing well are goingwith the open standards[theyre] J2EE compliant. Then you pick thetools that are in those spaces. From there, you play the vendorsoff each other in terms of function and stability.

The Insurer
NEAL RUFFALO AND
BEN SALZMANN, ACUITY

TD: Youve chosen to go the roll your own route, which makes youa good candidate to explain what youve done with your legacysystems without endorsing or criticizing a particular vendor. Whyhas this been your model in IT?

Salzmann: Do you want to have an outside consultant build yoursystem? Congratulations. Your systems built, but who maintains it?Your own staff doesnt know those systems, they didnt build them.And if you think your outside consultant did a good job documentingthose systems, boy, you deserve what you get.

So you get a system that is built by people who arent going tobe maintaining it, thats horrifically documented and built underpressure [to meet a] a guaranteed delivery date, and then you handit over to your programmers who didnt learn the newtechnologytheyre working Cobol, theyre given Javaand you expect itto work? Compound that with the fact that either the consultantdoesnt know insurance or if they know insurance, they dont knowyour business.

We will [only] use consultants when we go into [a newtechnology]. When we started Java we brought in experts to train uson Java, not to build our systems. The only thing we dont build isgeneral ledger, payroll, and permutations of operating systemsoftware, such as security and firewalls.

TD: How has Acuity worked to extend its legacy systems?

Salzmann: Whenever youre talking about extending the life of thelegacy system, the defining principle is that you should only beextending its life as a database server. You make an error if youstart adding functionality. If you say, Im going to make thisapplication work longer, so I need to build better screens and abetter interface, Im going to add features, thats a mistake.

For example, say youre going to build a Web-enabled front end.New functionality goes on the front end, and you strip[functionality] out of the legacy system, keeping only the filemaintenance and the data storage. Then you start migrating your oldlegacy system to more of a true repository of information, a truedatabase, perhaps moving it to Oracle or DB2, perhaps usingbusiness objects and user-friendly query tools to get more thingsout of it. Pretty soon your legacy system is something that youprimarily use to get back-end information out of, and the front-endtransactional processing is Web-enabled with the functionalitynecessary to process your transactions in that newarchitecture.

One of the things that helps you [in this migration] is thatprocesses change, but the core data themselves dont, or at leastthey change very slowly. If you were to take program data filelayouts from 50 years ago for insurance, theyre amazingly similarto what they are today, which is why it works using your back-endsystem as a database server.

And once you articulate that, its so simple that people say ofcourse. But yet some people still try to Web-enable the legacysystem itself. They put lipstick on a pig.

TD: What are some of examples of processes youve been able tosupport?

Ruffalo: Weve extended our mainframe legacy systems to live in aPC-based client/server environment and to support a 24/7 claimscall center, an expert underwriting system in personal lines,paperless processing in all lines of business, and a Web-basedfront end. [Its] built in Java and XML, and provides our agentsreal-time quotes and application upload in both personal andcommercial lines.

TD: As youve stripped functionality out of legacy applications,has it always been replaced solely on the front end?

Ruffalo: If its inquiry-based, like Web-based policyholderinformation, the user interface bolts directly into the legacyenvironment. Theres no reason to have a middle tier to hold asubset of data; you only need a communications link to get thatinformation from an IP protocol to the enterprise server and thenback down again.

With a more robust system, such as Web-based quoting andapplication, the front end is the presentation layer; the interfacethat the user sees. But there is a mid-tier that holds data,objects, and components that are created [and that] connects to theback end only when necessary. For instance, a quote in process isnot stored in the legacy system, its stored on the mid-tier. Whenthe mid-tier does need to interface with the enterprise (legacy)server, it extracts what it needs, processes it, stores it, andpasses it to the presentation layer.

Theres a third flavor we occasionally deploy for heavilyaccessed systems where we create a mirrored copy of data in themid-tier so we can gain the efficiencies of having that accessbeing local.

Who Dat?

The folks who opined for this article know a thing or two; eachhas at least 10 years of experience with insurance administrationsystems.

Assessing the industry as a whole is Charles Johnston, vicepresident and director of insurance information strategies at theMeta Group. Offering the consultants perspectives are Michael A.Jackowski, partner, Accenture Claims Solution Group; and from CapGemini Ernst & Young, Richard Marx, vice president in themanagement consulting practice; and Russell Schreiber, vicepresident and project director.

Finally, giving a carriers point of view are Ben Salzmann,AcuitysCIO-turned-CEO and member of ACORDs board of directors, andNeal Ruffalo, Acuitys current vice president and CIO.