Humans seem to have an insatiable urge to put things together.Sure, inventing the wheel was great, but putting two of them on anaxle was even better. Add another pair and a frame, and youve gotyourself a wagon. Put it with a combustion engine, and youve gotyourself an SUV.

Likewise, insurers for years have been finding ways to connectthe various different applications that support their business intosystems that are more than the sum of their parts (see TheEvolution of EAI, p. 25). However, they found the ensuingproliferation of middleware wrappers to legacy systems created itsown problem: a complex web of connections.

Additionally, in a development hardly unique to the realm ofintegration technology, insurers IT organizations sometimes foundachieving EAI was a more difficult proposition than they originallyhad been sold. We all heard the claims that a particular product,once installed, would immediately provide full integration with allthe data in your back-end systems, says Don Buskard, senior vicepresident and CTO of AXA Financial.

The practicality is, of course, that all these back-end systems,as well as the EAI suites, are large and complex, he continues. Youhave older technology on the legacy systems youre trying tointegrate, and youve got business processes youre looking tointegrate within the middleware structure you put in place. Itrequires a lot of analytical work before you bring the product inand a lot of testing after.

Therefore today, with their appetite for large and complex(read: expensive) projects diminished, and with the technology fortechnologys sake paradigm discarded, insurers are demanding to seethe business objective in EAI projects. Just as the goal ofintegrating, if you will, the different components that make up anautomobile were cleartravel farther, fasterthe goal of pursuing anytechnology integration project, enterprise or otherwise, must beevident to insurers before budgets will be approved. As a result,EAI has changed from a technology-centric to a process-centricinitiative, and insurers should be looking at EAI as a way tobetter manage their business processes. Most applications arewritten to support specific business functions, yet carriers needto service multiple product lines, distribution channels, andprocesses that span any single function, says Cindy Maike,insurance market segment manager for WebSphere business integrationworldwide. Making sure there are seamless business processesregardless of the channel the user is coming from, and doing thatcost effectively, should be the underlying fundamental goal ofapplication integration.

This refocusing on business objectives is both desirable andnecessary, according to Ilidio Ferreira, senior analyst in thee-infrastructure group at London-headquartered analyst andconsulting company Ovum. A few years ago, insurers spent theirresources on solutions that seemed to be the best thing to buy forspecific problems. Theyve fattened up, and now they need to go on adiet.

[Insurers] have all these system investments over years andyears, so the real value proposition of EAI is to allow them tomake the most of them, he continues. But in order to do that, theyneed to step back and see what the business really needs, and theymay realize to meet those needs, they may very well need to buyeven more EAI software. Its hard to impress people who have alreadyspent a lot on technology to buy something new.

To convince them and, more important, address business needs,insurers must begin by asking the single critical question, WhyEAI? The following companies have answered that question anddeveloped technology strategies to support business objectives.

Trustmark Insurance
(LAKE FOREST, ILL.):
To respond to a regulatory-driven business need with a solutionthat can extend to other enterprise objectives.

Trustmark Insurance, like all health insurers, has to contendwith transaction compliance deadlines for the Health InsurancePortability and Accounting Act (HIPAA). This business realityatechnology challenge for carriersactually was seen as anopportunity by Nasser Farimani, Trustmarks vice president ofinformation systems technology.

It became immediately apparent HIPAA is an integrationchallenge, he says, one measured by regulatory necessity, ratherthan ROI. It made sense to consolidate our efforts by putting in aplatform that was not just a remediation approach to comply withHIPAA, but that will help us address other business needs.

HIPAA, in fact, added momentum to Trustmarks enterprisearchitecture project, which had begun as the result of a globalbusiness analysis the carrier conducted about two years ago. Webrought in a consultant, talked to the business departmentsheadsand users and determined what they wanted to do, Farimani explains.We determined [our integration efforts] had done well to date, andwe have a stable infrastructure, but the train is moving. We needto renew our technology base, and we need to move toward the Weband be competitive in that space as well.

As a result, Trustmark decided on WebSphere as its integrationplatform, primarily due to its current investment in IBMtechnology. The insurer uses WebSpheres application server as wellas its MQ integrator. The key vision we had was to bring theback-end data forward in a consistent fashion, rather than grabbingdata, cleaning it up, and duplicating it in another database. Wewanted to get away from data redundancy, which is a particularproblem as an organization grows and acquires different systemsthrough various means, as we have, Farimani says.

Additionally, while Trustmark was able to integrate applicationseffectively in the past, the company expects greater advantage froma homogenous EAI platform. The connections weve made to the varioussystems have caused, as is typical, a lot of maintenance. Ourvision was to create an architecture where applications wereloosely coupled, requiring less maintenance and allowing us to plugand unplug applications as needed, Farimani says

On top of that, while our Web technology is working, we knewColdFusion was not the direction going forward, he adds. We wantedto standardize on a Web platform based on open technologies thatwould give us the opportunity to grow when the business needarises.

Specifically to address HIPAA transactions, Trustmark deployediWAYs XML Transformation Engine and its HIPAA adapter to generateHIPAA-compliant code. The system receives standard ANSI X12 HIPAAtransactions, validates the transaction, transforms it to itsequivalent XML format, maps the data to internal data elements,builds and executes queries to retrieve data from Trustmarks VSAMand DB2 databases, and then generates a response, if and whenrequired.

One of the biggest reasons we decided to go with iWAY is itsrich set of adapters that are prebuilt to both WebSphere andTrustmarks legacy systems, Farimani says. These include VSAM andDB2 read-write adapters that provide a relational view of the dataTrustmark could not achieve as easily before. Also, because we hadstandardized on WebSphere, it made sense to select a tool thatcomplemented that platform, Farimani says.

Trustmark will be building its architecture on a going-forwardbasis. In addition to HIPAA compliance, several processes have beenidentified as immediate targets of the new platform. For example,Trustmark replaced a legacy rating engine with a new Web-basedsystem, which generates real-time proposals by communicating with adocument management system through the new platform.

Our vision was to start ourselves on a path; to create ahub-and-spoke architecture, Farimani says. We wont be revamping thewhole portfolio of applications, but where it makes business senseto enhance an application or to communicate with other applicationsthrough the integration platform, that platform is now in place inpart due to the need to meet HIPAA requirements.

Jefferson Pilot Financial
(OMAHA, NEB.):
To manage a growing business and enhance customer self-servicewithout adding staff.

Jefferson Pilot Financials Benefit Partners division has beenable to handle double-digit growth in its group life, disability,and dental business over the past three years with minimal increasein head count. According to William Hanby, the carriers vicepresident of information technology, this has been directlyattributable to integration efforts designed to reduce data entryinto its variety of in-house-developed systems and operate moreefficiently.

There is a significant cost savings to your operations if youhave a common set of data connected; not necessarily a datawarehouse, but a means of accurately populating the various systemsthat come into play. It also creates the perception of a singlesystem to the users, allowing them to focus on processing business,rather than managing different systems, Hanby says.

The platform on which Jefferson Pilot bases its integrationefforts, Vitrias BusinessWare, has been in place at the insurer forthree years. As the carrier has moved more functionality to theWeb, the ability of Vitria to synchronize with back-end systems inreal time has been not only a competitive differentiator forJefferson Pilot, but a business advantage.

Weve moved a large percentage of our functionality out to theWeb, including policy administration, billing, and claims, Hanbyexplains. The group administrator can not only make changes to thegroup, but also determine how much they owe each month, which helpseliminate the need for them to calculate manually what they oweversus traditional methods of paying group insurance inarrears.

As part of its focus to provide information any way its clientsdesire, Jefferson Pilot also is deploying computer telephonyintegration from Genesys, which will connect as well with theVitria system for data integration.

Lincoln Financial Group
(PHILADELPHIA, PA.):
To increase business value quickly for the producer.

To manage licensing, contracts, appointments, and other aspectsof the sales authorization processes, Lincoln Fin-ancial Groupsprocessing staff had to deal with multiple interfaces to sevendifferent legacy systems. In fact, a complex transaction may haverequired entry into as many as 54 different screens.

The insurer recently deployed Meta-servers integration softwareto connect a newly purchased Producer Manage-ment AccountingCompensation System (PMACS) from E/W Group to these seven systemsto increase the efficiency of its processing staff and add value tothe carrier-agency partnership. According to Lincoln Financials Dr.Jason Glazier, senior vice president and CTO at Lincoln, theMetaserver approach differs from that of traditional middleware inthat integration is transparent to the mainframe. Rather thanexpose the functions of these legacy systems and connect middlewareto them, legacy applications run untouched. The resulting systemuses Seagull to map the screens generated by its legacy systems andMetaserver to provide the integration link between Seagull and thePMACS front end.

We considered a traditional invasive solution, where theintegration technology would require changes to the code of themainframe, Glazier explains. However, when you start doinginterfaces at lower levels, you need to make sure you encapsulatethe business logic and all the other tasks associated with actuallyhooking up a legacy application to new infrastructure. Our legacyapplications work, the screens work, so a noninvasive solution wasnot only faster to deploy but carried little risk.

The system currently is in full test mode, but Glazier reportsbenefits of the system when live already are apparent. In somecases, weve gone from 54 screens spanning the seven systems to setup a new broker to just five screens. Its a huge savings in termsof driving efficiency. Although specific dollar costs of theproject could not be released, the upfront software costs forMetaserver/ Seagull will have more than paid for itself in terms ofwhat we would have spent to do it via traditional [EAI] means,according to Glazier.

He adds Lincoln Financial, which does use MQ middleware invarious integrations throughout the IT organization, believesMetaserver would be appropriate for future enterprisewideintegration objectives. We did some load testing, and Metaserverheld up very well. I would argue as well the overhead of accessingdata through a mainframe screen is no more than going through amessage broker, because there also is overhead in the messagebroker when you have to process the message on the mainframe, heexplains.

Lincoln Financial targets future integration work at projectsthat will quickly derive business value by exposing data andtransactions that are on the mainframe through Web or other means,according to Glazier, who adds Metaserver likely will be the toolof choice to do so. If we need to view information available onthree different legacy systems, for example, to use an invasivetechnology would become expensive very quickly.

AXA Financial
(NEW YORK):
To provide users more information, more quickly.

Like many companies, we have systems that process businessdependably and have years worth of modifications and features,representing a valuable asset to us, says AXA Financials Buskard.Therefore, the insurer has deployed various in-house developed andpurchased solutions for more than a decade to integrate thesesystems, to incorporate new features, and to allow new front-endapplications to access data contained in disparate back-endsystems.

Life insurance and annuities represent very long-term contractswith our customers, contracts whose provisions remain substantiallyunchanged over that time, Buskard says. Therefore, any legacysystem rewrite, by definition, is a project where the samefunctions are being redeveloped in a newer technology. This is atextbook negative-ROI project from our standpoint. Weve determinedthat our best technology-related projects, like adding XMLtranslators to improve our Web access, are best done using ourproven middleware concepts.

However, because of its long history of application integration,AXA Financial also has had to deal with the question of whetherandwhento replace middleware connections. In general, when we look atgoing from a homegrown technology to a vendor product, well lookfor ROI based on the relief of maintenance. Where were addingfunction, the ROI is based on the ongoing need for the function,Buskard says. One of those recent business needs was to serveinformation more efficiently from as many as eight currentadministration systems to both internal and external users of thecompanys Web-based applications and, in turn, to allow those usersto update policy information in those legacy systems.

Our legacy systems are all of the COBOL, DB2, and IMS/DBvariety, and we have one major system per major product line. Wealso have a portal and several related Web sites customers andfinancial professionals use, Buskard explains. What we are tryingto do is to respond to the needs of our internal CSRs and salesassociates to get and update more information from these systemsmore quickly.

AXA Financials customer self-service Web site to access policyinformation dates back to 1997. Customer-update transactioncapabilities were added in 1999, and additional sales, customer,and public research and information tools became available with theportal deployment in 2001. However, maintaining a host ofconnecting technologies as well as looking to roll out a newWebstation portal for sales associates that would include completetransaction and sales force automation capabilities recently ledAXA to look to a standardized integration platform between itsvarious front ends and administration systems.

Having chosen WebSphere MQ as its integration platformapproximately four years ago for projects going forward, AXAFinancial saw the opportunity to reduce its development andmaintenance costs in the portal integration project by usingCandles PathWAI architecture development solution, which itdeployed in 2002. The power and flexibility of these [portal]applications in accessing information from [legacy] systems areenhanced by our middleware strategy implemented by PathWAI, Buskardsays. PathWAI is a more efficient way to deal with MQ. It providesa layer of business logic to manage the translation between the Webfront end and the legacy applications as well as a methodology forarchitecture design issues that doesnt require a significant numberof consultants. AXA Financial continues to implement the use ofPathWAI methodology, with work on the portal integration technologyand Webstation expected to be completed by the third quarter of2003.

The tools we use are an enablement of our technical applicationarchitecture vision; theyre not the definition of our vision,Buskard stresses. We had a dedicated vision for our technicalarchitecture before any of todays packaged integration platformswas a glimmer in some developers eye.

The Evolution of EAI
The first efforts at application integration involvedpoint-to-point connections, where insurers built custom integratorsbetween individual systems, often to address one specificobjective. Those connections often couldnt be used with othersystems. It would be like a library having a different librarian todirect you to each book, says Ilidio Ferreira, senior analyst atOvum consultancy.

The desire to create reusable connections led to the developmentand eventual proliferation of middleware, a single, common set ofinterfaces deployed to connect any number of systems. That led towhat Ferreira calls the n-tier revolution, where your businesslogic resides in the middle tiers, the data resides in the backend, and the front end acts as your thin client. As a result,people began to think more about separating business logic from theapplication, and it made the need for sharing information betweensystems even more apparent.

What middleware also added to the equation was the ability toautomate manual processes and manage workflow, says Robert Hunter,director of the insurance and financial services practice ofThoughtWorks, an application development and system integrationfirm. Also, because their back-end systems tend to bepolicy-centric, and not customer-centric, building a commoninformation bus, if you will, allowed insurers to deploy newcustomer-focused systems that connected to the back end.

Meeting customer-focused objectives and other business needs isthe objective of todays EAI initiatives. Of course, the reality ofdealing with particular pain points still requires insurerssometimes to undertake specific tactical, rather than larger,strategic, integration projects. When this happens, Ferreirastresses its important that methods and chosen technologies avoidthe limitations of point-to-point connections. Open standards areessential. Using Web services technology to expose interfaces, forexample, provides the reusability of components and the standardsXML already brings to the data representation.

Hunter also recommends an approach ThoughtWorks calls Agile EAI.IT departments often can over-engineer the infrastructure upfront,spending months working on things users never see, he says. WithAgile EAI, however, carriers build in increments and show users abusiness impact as soon as possible. The result is the ability tomitigate risk on large initiatives and favorably impact ROI.