Therefore today, with their appetite for large and complex (read: expensive) projects diminished, and with the technology for technologys sake paradigm discarded, insurers are demanding to see the business objective in EAI projects. Just as the goal of integrating, if you will, the different components that make up an automobile were cleartravel farther, fasterthe goal of pursuing any technology integration project, enterprise or otherwise, must be evident to insurers before budgets will be approved. As a result, EAI has changed from a technology-centric to a process-centric initiative, and insurers should be looking at EAI as a way to better manage their business processes. Most applications are written to support specific business functions, yet carriers need to service multiple product lines, distribution channels, and processes that span any single function, says Cindy Maike, insurance market segment manager for WebSphere business integration worldwide. Making sure there are seamless business processes regardless of the channel the user is coming from, and doing that cost effectively, should be the underlying fundamental goal of application integration.

This refocusing on business objectives is both desirable and necessary, according to Ilidio Ferreira, senior analyst in the e-infrastructure group at London-headquartered analyst and consulting company Ovum. A few years ago, insurers spent their resources on solutions that seemed to be the best thing to buy for specific problems. Theyve fattened up, and now they need to go on a diet.

[Insurers] have all these system investments over years and years, so the real value proposition of EAI is to allow them to make the most of them, he continues. But in order to do that, they need to step back and see what the business really needs, and they may realize to meet those needs, they may very well need to buy even more EAI software. Its hard to impress people who have already spent 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, Why EAI? The following companies have answered that question and developed technology strategies to support business objectives.

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

Trustmark Insurance, like all health insurers, has to contend with transaction compliance deadlines for the Health Insurance Portability and Accounting Act (HIPAA). This business realitya technology challenge for carriersactually was seen as an opportunity by Nasser Farimani, Trustmarks vice president of information systems technology.

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

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

As a result, Trustmark decided on WebSphere as its integration platform, primarily due to its current investment in IBM technology. The insurer uses WebSpheres application server as well as its MQ integrator. The key vision we had was to bring the back-end data forward in a consistent fashion, rather than grabbing data, cleaning it up, and duplicating it in another database. We wanted to get away from data redundancy, which is a particular problem as an organization grows and acquires different systems through various means, as we have, Farimani says.

Additionally, while Trustmark was able to integrate applications effectively in the past, the company expects greater advantage from a homogenous EAI platform. The connections weve made to the various systems have caused, as is typical, a lot of maintenance. Our vision was to create an architecture where applications were loosely coupled, requiring less maintenance and allowing us to plug and unplug applications as needed, Farimani says

On top of that, while our Web technology is working, we knew ColdFusion was not the direction going forward, he adds. We wanted to standardize on a Web platform based on open technologies that would give us the opportunity to grow when the business need arises.

Specifically to address HIPAA transactions, Trustmark deployed iWAYs XML Transformation Engine and its HIPAA adapter to generate HIPAA-compliant code. The system receives standard ANSI X12 HIPAA transactions, validates the transaction, transforms it to its equivalent XML format, maps the data to internal data elements, builds and executes queries to retrieve data from Trustmarks VSAM and DB2 databases, and then generates a response, if and when required.

One of the biggest reasons we decided to go with iWAY is its rich set of adapters that are prebuilt to both WebSphere and Trustmarks legacy systems, Farimani says. These include VSAM and DB2 read-write adapters that provide a relational view of the data Trustmark could not achieve as easily before. Also, because we had standardized on WebSphere, it made sense to select a tool that complemented that platform, Farimani says.

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

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

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

Jefferson Pilot Financials Benefit Partners division has been able to handle double-digit growth in its group life, disability, and dental business over the past three years with minimal increase in head count. According to William Hanby, the carriers vice president of information technology, this has been directly attributable to integration efforts designed to reduce data entry into its variety of in-house-developed systems and operate more efficiently.

There is a significant cost savings to your operations if you have a common set of data connected; not necessarily a data warehouse, but a means of accurately populating the various systems that come into play. It also creates the perception of a single system 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 integration efforts, Vitrias BusinessWare, has been in place at the insurer for three years. As the carrier has moved more functionality to the Web, the ability of Vitria to synchronize with back-end systems in real time has been not only a competitive differentiator for Jefferson Pilot, but a business advantage.

Weve moved a large percentage of our functionality out to the Web, including policy administration, billing, and claims, Hanby explains. The group administrator can not only make changes to the group, but also determine how much they owe each month, which helps eliminate the need for them to calculate manually what they owe versus traditional methods of paying group insurance in arrears.

As part of its focus to provide information any way its clients desire, Jefferson Pilot also is deploying computer telephony integration from Genesys, which will connect as well with the Vitria system for data integration.

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

To manage licensing, contracts, appointments, and other aspects of the sales authorization processes, Lincoln Fin-ancial Groups processing staff had to deal with multiple interfaces to seven different legacy systems. In fact, a complex transaction may have required entry into as many as 54 different screens.

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

We considered a traditional invasive solution, where the integration technology would require changes to the code of the mainframe, Glazier explains. However, when you start doing interfaces at lower levels, you need to make sure you encapsulate the business logic and all the other tasks associated with actually hooking up a legacy application to new infrastructure. Our legacy applications work, the screens work, so a noninvasive solution was not only faster to deploy but carried little risk.

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

He adds Lincoln Financial, which does use MQ middleware in various integrations throughout the IT organization, believes Metaserver would be appropriate for future enterprisewide integration objectives. We did some load testing, and Metaserver held up very well. I would argue as well the overhead of accessing data through a mainframe screen is no more than going through a message broker, because there also is overhead in the message broker when you have to process the message on the mainframe, he explains.

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

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

Like many companies, we have systems that process business dependably 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 and purchased solutions for more than a decade to integrate these systems, to incorporate new features, and to allow new front-end applications to access data contained in disparate back-end systems.

Life insurance and annuities represent very long-term contracts with our customers, contracts whose provisions remain substantially unchanged over that time, Buskard says. Therefore, any legacy system rewrite, by definition, is a project where the same functions are being redeveloped in a newer technology. This is a textbook negative-ROI project from our standpoint. Weve determined that our best technology-related projects, like adding XML translators to improve our Web access, are best done using our proven middleware concepts.

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

Our legacy systems are all of the COBOL, DB2, and IMS/DB variety, and we have one major system per major product line. We also have a portal and several related Web sites customers and financial professionals use, Buskard explains. What we are trying to do is to respond to the needs of our internal CSRs and sales associates to get and update more information from these systems more quickly.

AXA Financials customer self-service Web site to access policy information dates back to 1997. Customer-update transaction capabilities were added in 1999, and additional sales, customer, and public research and information tools became available with the portal deployment in 2001. However, maintaining a host of connecting technologies as well as looking to roll out a new Webstation portal for sales associates that would include complete transaction and sales force automation capabilities recently led AXA to look to a standardized integration platform between its various front ends and administration systems.

Having chosen WebSphere MQ as its integration platform approximately four years ago for projects going forward, AXA Financial saw the opportunity to reduce its development and maintenance costs in the portal integration project by using Candles PathWAI architecture development solution, which it deployed in 2002. The power and flexibility of these [portal] applications in accessing information from [legacy] systems are enhanced by our middleware strategy implemented by PathWAI, Buskard says. PathWAI is a more efficient way to deal with MQ. It provides a layer of business logic to manage the translation between the Web front end and the legacy applications as well as a methodology for architecture design issues that doesnt require a significant number of consultants. AXA Financial continues to implement the use of PathWAI methodology, with work on the portal integration technology and Webstation expected to be completed by the third quarter of 2003.

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

The Evolution of EAI
The first efforts at application integration involved point-to-point connections, where insurers built custom integrators between individual systems, often to address one specific objective. Those connections often couldnt be used with other systems. It would be like a library having a different librarian to direct you to each book, says Ilidio Ferreira, senior analyst at Ovum consultancy.

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

What middleware also added to the equation was the ability to automate manual processes and manage workflow, says Robert Hunter, director of the insurance and financial services practice of ThoughtWorks, an application development and system integration firm. Also, because their back-end systems tend to be policy-centric, and not customer-centric, building a common information bus, if you will, allowed insurers to deploy new customer-focused systems that connected to the back end.

Meeting customer-focused objectives and other business needs is the objective of todays EAI initiatives. Of course, the reality of dealing with particular pain points still requires insurers sometimes to undertake specific tactical, rather than larger, strategic, integration projects. When this happens, Ferreira stresses its important that methods and chosen technologies avoid the limitations of point-to-point connections. Open standards are essential. Using Web services technology to expose interfaces, for example, provides the reusability of components and the standards XML 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. With Agile EAI, however, carriers build in increments and show users a business impact as soon as possible. The result is the ability to mitigate risk on large initiatives and favorably impact ROI.