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

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

So right off the bat, youre going to go down what is really one road. 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 to create a flexible infrastructure that can bring new systems into the fold.

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

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

TD: Then how should insurers evaluate each of those scenarios?

Johnston: Probably the second is the toughest one, because the CIO is saying, I know were OK today, but well be in serious trouble in three years. But thats one of the jobs of the CIO, to maintain the 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 the system, it still takes us three months to bring a product to market and we need it in three weeks. Another [reason] may be that, even if the system is running fine internally, can you maintain an organization to support these [systems]? Do you even have staff on board anymore who know the architecture?

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

Johnston: Where the system doesnt meet the future needs, thats where wrappering is most amenable to success. It definitively doesnt help you when youre worried about being able to maintain the environment. 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 the core calculations and wrapper it. That can breathe new life into the system. [In any scenario], the places where wrappering works best is where they can tap the original architect of the system.

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

Johnston: We see a stratification based on size. If youre a [larger insurer], you tend to operate in an IBM-centric environment, which is now JavaBeans or J2EE, and that implies CORBA is under the covers. A small multi-line insurer may be totally Microsoft-centric. They may never have bought a mainframe. Perhaps theyre running Allenbrook on a NT server, Microsoft Exchange on another NT server, and some applications on a SQL server. Youll find them programming in DCOM and moving to a .NET environment. Some [larger companies] have linked administration to agency systems using XML, but youre just really starting to see that standard have an impact on the industry in terms of externalization.

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 business face. Theyre not saying, You have to be a C++ object oriented programmer who plans everything in UML [unified modeling language] to interact with me. Now Im going to start presenting business services.

IBM is taking it even further with its MQ series, saying, Were going to help you wrapper your system [but] it can still work the way it always has. If you get 100 insurance companies together and ask 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 the interface so you dont compromise the integrity of the system, which requires 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-time option, people are used to taking these systems offline for maintenance. And the reason they want to do a legacy extension is [to provide] 24/7, international rolling-with-the-sun processing.

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

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

TD: How do you think the software industry is positioned for integration 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 to 20 years. So given that, youre seeing a lot of what youd call legacy extensions, and some of the large vendors are beginning to recognize that and embrace ittheyre trying to say to people who are going out and doing these extension projects, Maybe we dont have everything you need right now, but well give you a good interface to allow you to interact with our system on a fairly high level. Theyre beginning to realize that they need to position their systems as good citizens in a larger ecosystem thats going to involve CRM, portals, new business underwriting systems, and financial management systemsin contrast to a world where everything is a nice, clean steel cylinder, and everything evolves in that system.

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

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

Marx: Weve seen four different approaches. One would be a wrap approach: using a middleware layerto put in some basic product and processing rules logic. The second would be to replace, either building or buying a new set of integrated packages. Another is renovationbasically using new tools available in the market to regenerate legacy code into a more modern format and language from both the database and programming standpoint. And the fourth would be to outsource it.

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

TD: How do insurers evaluate which approach is best for them?

Marx: There are a few key decisions. What business does the insurer want to be in? Is it a wealth manager, a product manufacturer, 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 when the current systems provide adequate functionality and the organization wants to add capabilities in a more flexible and cost-effective manner.

The renovation approach is usually required when systems lack documentation and run on technologies that are outdated and expensive to maintain. There are a handful of tools that will interrogate the program code and database structures and convert them to a modern program language and database format. [Y]ou can pick up a lot of business rules, perhaps 80-90 percent, and it also creates reasonably robust documentation when, in most instances, none exists.

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

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

Jackowski: The first is scope containment. [Second], carriers traditionally underestimate the complexity, and what they think is a simple replacement turns into a five-year activity. [They also fail to] understand from a technology perspective what the touch points are. How do data feed between the systems? How do you keep things in sync? What technologies are just a new veneer?

When you look at the underpinnings of a CICS application, the better systems will have a client server or a three-tier or n-tier design: a well encapsulated display layer versus a data access layer versus a business object layer. But there are very few systems that are designed that way. When you take systems that were poorly designed and try to extend them to the Web, or put a GUI front end on them, theres a lot of trouble because IT cant get their hands around the code.

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

TD: Then how can insurers avoid those types of disappointments?

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

Lastly, [insurers need] to set a direction that has a lot of flexibility. No two legacy systems look the same, even if their core roots are the same product. Theyve been modified, tweaked to death, and very few people may understand them. A key element is to bring in a technology that has a lot of flexibility in terms of how the core transaction engine can be extended to integrate [with other systems]. Our approach has been to bundle not just software assets and services, but also provide the source code and development environment to allow carriers to have the flexibility of a custom solution.

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

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

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

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

Schreiber: You need to establish an architecture before you choose your tools, otherwise you have a lot of tools in the basket and no way to use them. If you come from a tool view out, theres too much overlap. Weve found the folks who are doing well are going with the open standards[theyre] J2EE compliant. Then you pick the tools that are in those spaces. From there, you play the vendors off 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 you a good candidate to explain what youve done with your legacy systems without endorsing or criticizing a particular vendor. Why has this been your model in IT?

Salzmann: Do you want to have an outside consultant build your system? 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 documenting those systems, boy, you deserve what you get.

So you get a system that is built by people who arent going to be maintaining it, thats horrifically documented and built under pressure [to meet a] a guaranteed delivery date, and then you hand it over to your programmers who didnt learn the new technologytheyre working Cobol, theyre given Javaand you expect it to work? Compound that with the fact that either the consultant doesnt know insurance or if they know insurance, they dont know your business.

We will [only] use consultants when we go into [a new technology]. When we started Java we brought in experts to train us on Java, not to build our systems. The only thing we dont build is general ledger, payroll, and permutations of operating system software, such as security and firewalls.

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

Salzmann: Whenever youre talking about extending the life of the legacy system, the defining principle is that you should only be extending its life as a database server. You make an error if you start adding functionality. If you say, Im going to make this application work longer, so I need to build better screens and a better 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 file maintenance and the data storage. Then you start migrating your old legacy system to more of a true repository of information, a true database, perhaps moving it to Oracle or DB2, perhaps using business objects and user-friendly query tools to get more things out of it. Pretty soon your legacy system is something that you primarily use to get back-end information out of, and the front-end transactional processing is Web-enabled with the functionality necessary to process your transactions in that new architecture.

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

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

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

Ruffalo: Weve extended our mainframe legacy systems to live in a PC-based client/server environment and to support a 24/7 claims call center, an expert underwriting system in personal lines, paperless processing in all lines of business, and a Web-based front end. [Its] built in Java and XML, and provides our agents real-time quotes and application upload in both personal and commercial 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 policyholder information, the user interface bolts directly into the legacy environment. Theres no reason to have a middle tier to hold a subset of data; you only need a communications link to get that information from an IP protocol to the enterprise server and then back down again.

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

Theres a third flavor we occasionally deploy for heavily accessed systems where we create a mirrored copy of data in the mid-tier so we can gain the efficiencies of having that access being local.

Who Dat?

The folks who opined for this article know a thing or two; each has at least 10 years of experience with insurance administration systems.

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

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