Web services can help insurers relieve system complexity and reap the rewards of simplicity. However, achieving those objectives requires good design, careful management, and avoiding any new complexities Web services implementations themselves may introduce.

BY MICHAEL P. VOELKER

We humans have created countless devices and de-vised a plethora of ways to make our work easier and our lives simpler. Likewise, technology evangelists always strive to find new tools and approaches to simplify the development and maintenance of insurance systems. One of the most important developments in that endeavor in recent years has been the maturation of XML Web services.

As an integration mechanism, Web services can replace proprietary, tight coupling with open, message-based connections that facilitate cross-platform interoperability. As a wrapper for legacy system components, the technology can expose existing business functions to new users and through new delivery channels. And at the most complete level of adoption, Web services may be used by insurers to rearchitect monolithic applications as loosely coupled components that can be more easily maintained, modified, and replaced (see WS vs. SOA, p. 20).

However, just as the proliferation of so-called convenience items eventually can complicate ones personal life, so can the uncontrolled growth of Web services within a technology environment ultimately create inefficiency.

There is a way the process of service-oriented development should be governed in order to lead to an outcome that will minimize complexity, says Mike Gilpin, vice president and research director at Forrester Research. To achieve the simplicity Web services solutions offer, the secret in developmentas in lifeis to exercise discipline and find the right balance.

Practical Magic

The original Web services vision was companies would be able to assemble dynamic business software from any number of Internet-delivered building blocks. However, the reality today is Web services implementations primarily are deployed within the enterprise (sometimes referred to in those in-stances as network services, business services, or simply services) or used in connections with established trading partners.

Aon, Chicago, Ill., has used Web services for the past three years to build new business functionality into an environment that includes connections to or access from different legacy systems on multiple platforms. Using Microsofts Visual Studio development tools, the insurer created as many as 18 new services targeted to both customer service objectives, such as an online quotation service, as well as internal efficiency, such as a document server. In addition, Aon rearchitected some existing application components as Web services to improve scalability and simplify integration.

Arthur Hyde, director of solutions delivery at Aon, explains the SOAP messaging that allows new services to communicate with other applications also has helped the company extend the lives of existing systems by allowing them to bolt on new functionality. We use Web services as a migration technique, Hyde says. We can deploy new technology without having to change the world.

The reduction in integration complexity Web services solutions enable has a hard-dollar payback potential for insurers. The benefit usually is in the development cost, states Gilpin. If you compare the cost to build a Web services integration connection with the cost of the previous generation of proprietary technology, you can see a 30 percent reduction in integration cost.

Reduce, Reuse, Recycle

Development [of Web services] you effectively can reuse is simpler than in prior architectural patterns where you just are individually writing software to do different things, says John Kellington, chief technology officer and senior vice president at Ohio Casualty Group, Fairfield, Ohio.

Reuse is not a new concept in the world of programming, but effective reuse that simplified both application development and maintenance rarely was achieved in the past. Often, it had meant simply cutting and pasting blocks of code from one system to another, a process rife with the potential for problems that include lack of documentation, discovery, and management. In contrast, a single Web services component can be used by multiple systems and processes, eliminating those version control issues if managed appropriately.

The reusability of the Web services developed by Hydes team means Aon can offer its business units a veritable application cafeteria plan. If you want document management, no problem. All you have to do is interface to that Web service, and [we supply] the definition for that service. You choose to buy the service you want, and in some areas, [users] are sharing services among business units of hardware, which further reduces their cost, he says. It definitely has brought stronger technology, more cost effectively, to [Aons] business units.
Reuse has helped PacifiCare Health Systems, Cypress, Calif., simplify the integration of systems while complying with HIPAA requirements. The company uses Vitria as both a development environment and integration hub for transactions generated between internal systems and received from external trading partners.

Pre-Vitria we were using a number of transformation tools and individualized, proprietary connections between systems, explains Dwight Law, director of enterprise EDI services at PacifiCare. Having standardized interfaces and reusable componentssuch as Vitrias HIPAA compliance modulehas helped PacifiCare compress the development time frame and meet tight project schedules associated with recent corporate acquisitions.

Now, the company is undertaking an ambitious multiyear project to rearchitect its existing systems environment toward service-oriented architecture. In developing individual services within that architecture, the company first will target services that lend themselves toward multiple uses internally and externally.
We look at [which users] or what other system processes those services will benefit, explains Kevin McCloskey, IT manager responsible for EAI middleware at PacifiCare. Two potential functions to be redeployed as services are claim inquiry and eligibility verification.

Like PacifiCare, most insurers tend to think of reuse from a top-down perspective, designing services with multiple applications in mind. But Gilpin points out the potential for bottom-up reuse, where new uses for a service are identified after it is developed, has an equally important value proposition, although it is more difficult to manage.

In top down, you realize the need for documentation, ongoing support, and code maintenance from the beginning. In the bottom-up approach, those things often have not been considered, Gilpin says. The more an insurer can anticipate future requirements by performing use cases and designing services accordingly, the greater the potential payback gained both by reducing the cost of component maintenance and modification and by increasing the understanding of services in use within the environment (see Managing Services, p. 22).

Counterpoint

While Web services can help insurers simplify integration and new development, the technology does have the potential to add complexities of its own. With monolithic code, the people writing it see all of it, Gilpin explains. When you start carving things up, although any one of those components is simpler than the monolithic application, collectively it can be more complicated for developers to figure out. There also is the potential for lack of communication between different teams and understanding what each of them has done [leading to] duplication of work.

Operationally, it can be easier to determine the load a monolithic system would have on the production environment vs. assessing the demands of different services that each have their own peaks and valleys of usage. Additionally, despite the inherent interoperability of Web services, if teams building those services deal differently with issues such as security and authentication, it can complicate reuse of those services later on. Reducing duplication, ensuring consistency, and achieving simplicity therefore requires strong governance and architectural discipline.
At Ohio Casualty, for example, discipline starts with the companys enterprise architecture model. We also have an extremely effective [enterprise] architecture organization, states Kellington.

That organization includes architects who are responsible for functional areas and others who are responsible for components and services. Kellington believes this structure helps share knowledge across functional boundaries, drives consistency in application development, and is particularly important in the development of services that may be used by multiple systems.
Ohio Casualty has found its architectural model and the reusability of Web services have helped simplify development and shorten delivery time frames. As background, Kellington explains the company began migrating in the late 1990s a host of different policy administration applications to a consolidated system, which it built internally based on IBMs Insurance Application Architecture (IAA) enterprise component model, called PARIS. Though built prior to the maturation of Web services standards, Kellington de-scribes PARIS as well architected with clean component boundaries and therefore a good fit for the addition of new XML Web services components.
Adding Web services interfaces has been, quite frankly, easy, he notes. Using IBMs WebSphere Studio Application

Development, the carrier built and de-ployed its first external service in 2002a billing inquiry application for agentsin just four weeks. I dont know how we even could have provided that [service] before, Kellington says. With Web services enabling computers to talk to other computers easilyhaving an easy messaging pattern in XML thats rich and self-describing, an infrastructure via the Internet to move messages, and protocols like SOAPtechnology made that [project] doable, whereas we would have struggled [to provide that service] in the past.
Ohio Casualty since has continued to use Web services to bridge to various agency management vendors, such as Applied Systems and AMS Services, which support and provide their own services interfaces. For instance, when the carrier recently prototyped a new service to extend to agents via AMSs TransactNow, Kellington reports Ohio Casualty did not need to make any changes to connect with Applied Systems via Transformation Station.

Since the technology consists of individual components designed to perform a particular function, another potential complexity of Web services is more are required to replicate the process of a formerly single application. Ultimately, this could result in a proliferation of services distributed across the enterprise that creates a host of problems, including less effective reuse and difficulty in disaster recovery.

The more moving pieces, the harder they are to keep track of, comments Janelle Hill, vice president and research practice lead at META Group (at press time, soon to be acquired by Gartner), whose research has focused on Web services and middleware. The primary issue with disaster recovery and Web services is not loss of data, since services have very limited data persistence. Rather, the issue simply is not keeping track ofor not even being fully aware ofservices in use throughout the enterprise.

Not surprisingly, companies that have the strongest governance over application development also have the fewest issues with disaster recovery. Using Web services has had no impact on our recovery efforts at all, Kellington explains. We simply have another environment [WebSphere] to restore, and we manage that with the same discipline we have for the production, CICS, and mainframe environments.

As insurers develop a larger portfolio of services, they find a system to manage those services becomes increasingly important, particularly when looking to orchestrate those services into more complex applications. Control of services generally falls into a category of technologies under the umbrella of the enterprise service bus (ESB). Without such a bus, each service needs to know where another service is or how to find it in order to interface with it. With the bus, a service needs only to contact the bus that knows where all the services are.

More of a technology class than actual platform, an ESB could include anything from service directories to complete business process management systems that orchestrate services into composite applications and automate end-to-end processes. As services evolve from an enabling technology to architecture, the role of the ESB hub becomes increasingly important to ensure a company ends up with a whole that is greater than the sum of the parts.

ESBs cost money, but if a company needed the kind of flexibility and decoupling an ESB provides, the alternative previously would have been an EAI tool costing three to five times as much as the equivalent service-based technology for integration, Gilpin claims.

Weighing the Options

For most insurers, the potential complexities of Web services pale in comparison with the difficulties of previous technologies, contends Josh Lee, program manager for financial services architecture at Microsoft. Web services can produce complexity if not managed very carefully, but any poorly run architecture can produce as much or more complexity, he says.

In a typical legacy environment, You have message mapping complexity as well as transformation complexity that requires you to go from one [data] format to another before you can do a single piece of business, Lee adds. You trade that for maybe having a few more interfacesthe initial shock of having 100 services where you had 10 beforebut you gain standardized protocols, communication mechanisms, and standards within the Web services environment.

Insurers must weigh the risks and decide where and to what extent Web services solutions are a good fit for their business objectives and technical environment. We are committed to developing a service-oriented architecture, says PacifiCares Law. Our whole strategy over the next 18 months will be to build as many as feasible.

Aon, an early adopter of Web services, actually has backed off its use of Web services in recent months, converting 10 of them to remote objects instead. We found it was a better architecture for those items to use remote objects and remoting [technology], particularly when those servers were right by each other on the same back plane. Were still big fans of Web services, but we just are being pragmatic in cases where interfaces were static and the overhead of IIS [Microsofts Internet Information Services Web server] wasnt always required, says Hyde.

Most insurers using Web services technology today find that it is part of the solution and that combinations of solutions, from other component technologies to mainframe systems, comprise the best-optimized environment for their unique business needs. Companies need to insert [application] architects into the development process at the point where they can recognize whether a [new] service is needed or whether theres a perfectly adequate mainframe transaction to do that service and all they have to do is give access [to that function] through a service bus, Gilpin asserts.

However, as standards for XML in the insurance industry continue to mature and the benefits of services-based development are proven, the use of Web services will continue to grow. There are enough initiatives coming out of IT today that allow [insurers] to recognize the potential of Web services to lower the cost of integration and to lower overall IT costs just from gaining economies of scalehaving people converge on a similar set of programming skills, rather than having multiple languages and platforms, and moving programmers around more easily from one project to the next, maintains Hill. Its an advancement thats going to last a long time.

WS vs. SOA

The terms Web services and service-oriented architecture (SOA) frequently are used in the same context; however, they are distinctly different concepts.

SOA is an architecture that establishes the principles for the design and management of services built within it. Those services could include Web services, DCOM or CORBA components, or other messaging services.

Just as a business may implement an SOA without using Web services, so might one be using Web services without an overall SOA strategythe potential drawback being that establishing an SOA helps bring the discipline needed to achieve the full extent of the simplicity, flexibility, and reusability of Web services.
Certainly there are organizations working on Web services initiatives that are completely disconnected from business strategy, and in large part thats happening because developers are trying to learn new things, says Janelle Hill of META Group. Theres a ton of grass-roots-level efforts, particularly with Microsoft technologies because Web services capabilities come within products [insurers] already have, such as BizTalk [Server] or Visual Studio.

Microsoft competitors, including Sun Microsystems and IBM, offer similar SOA-focused capabilities in their development tools, and Microsoft itself recently announced enhanced Web services development resources in upcoming versions of its .NET-based programming platform.

Managing Services

Those who dont learn from the mistakes of the past are doomed to repeat them. The reason legacy often came to mean difficult to work with rather than valuable asset in IT had much to do with practices surrounding the historical development of legacy systems. Lack of documentation and lost knowledge led to a growing lack of understanding of systems, difficult maintenance, and tortuous new development.

To avoid creating a misunderstood mass of Web services, Forrester Research recommends developing a process framework, which it calls a business service model (BSM). The BSM would include:

a description of all services interfaces, including functions performed and usage protocols required,
the format of content delivered by services,
the definition of service attributes,
a dictionary of common data elements, and
the relationship between all of the above.

Tech Guide: E-Systems, E-Commerce, Web Services, Security

Accenture
Palo Alto, Calif.
312-737-8842
www.accenture.com

AdminForce Remote LLC
Philadelphia, Pa.
610-734-1900
www.adminforce.net

AdminServer, Inc.
Chester, Pa.
www.adminserver.com
610-619-3100

Aladdin Knowledge Systems
Arlington Heights, Ill.
800-562-2543
www.ealaddin.com

Allegient Systems
Wilton, Conn.
203-761-1289
www.allegientsystems.com

Allenbrook
Portland, Maine
877-764-6452
www.allenbrook.com

Allfinanz
New York, N.Y.
888-824-2929
www.allfinanz.com

Applied Systems
University Park, Ill.
800-999-5368
www.appliedsystems.com

AQS, Inc.
Hartland, Wis.
262-369-7500
www.aqssys.com

AscendantOne
Nashua, N.H.
603-598-5427
www.ascendantone.com

BindView Corp.
Houston, Tex.
800-813-5869
www.bindview.com

BMC Software
Houston, Tex.
800-841-2031
www.bmc.com

CGI Group, Inc.
Montreal, Quebec, Canada
541-841-3200
www.cgi.com

CMS Peripherals
Costa Mesa, Calif.
714-424-5520
www.cmsperipheralsinc.com

Computer Associates International
Islandia, N.Y.
631-342-6000
www.ca.com

Connective Technologies
Houston, Tex.
713-690-6789
www.connective-edi.com

Connextions
Orlando, Fla.
877-772-6868
www.connextions.net

COSS Development Corp.
Milwaukee, Wis.
262-241-8989
www.cossdev.com

CSC Financial Services
Austin, Tex.
800-345-7672
www.csc-fs.com

Decision Research Corporation
Honolulu, Hawaii
800-836-6057
www.decisionresearch.com

Digital Sandbox
Reston, Va.
703-390-9770
www.dsbox.com

Duck Creek Technologies
Bolivar, Mo.
866-382-5832
www.duckcreektech.com

DynTek, Inc.
Irvine, Calif.
877-297-3723
www.dyntek.com

Eagle Technology Management
Marion, Iowa
800-975-3245
www.eagletm.com

EDS
Plano, Tex.
972-604-6000
www.eds.com

eHealthSystems
Sunnyvale, Calif.
408-542-4800
www.ehealthsystems.com

Engedi Technologies, Inc.
Bumpass, Va.
540-894-0100
www.engedi.net

ePolicy Solutions
Torrance, Calif.
310-819-3200
www.epolicysolutions.com

Ernst & Young Security & Technology Solutions Practice
New York , N.Y.
212-773-3000
www.ey.com

Examen
Sacramento, Calif.
916-921-4300
www.examen.com

Fair Isaac
San Rafael, Calif.
415-472-2211
www.fairisaac.com

FileNet
Costa Mesa, Calif.
800-345-3638
www.filenet.com

Financial Services Information Sharing and Analysis Center
Reston, Va.
888-732-2812
www.fsisac.com

First Notice Systems, Inc.
Boston, Mass.
800-310-4367
www.firstnotice.com

Fiserv
Brookfield, Wis.
800-422-3220
www.fiserv.com

Genelco Software Solutions
St. Louis, Mo.
800-983-8114
www.genelco.com

Global Technologies Group
Arlington, Va.
703-486-0500
www.gtgi.com

Group Technologies
Milford, Mass.
508-473-3332
www.group-technologies.com

Guidewire Software, Inc.
San Mateo, Calif.
650-357-9100
www.guidewire.com

I-Alliance
Indian Head, Pa.
800-997-5871
www.iallianceonline.com

Insureworx, Inc.
Emeryville, Calif.
800-785-4526
www.insureworx.com

Insurity
Hartford, Conn.
860-616-7721
www.insurity.com

INSURSYS
San Francisco, Calif.
415-495-7335
www.insursys.com

LIDP Consulting
Services, Inc.
Woodridge, Ill.
630-829-7100
www.lidp.com

Mayfare Software Solutions
Hoboken, N.J.
201-792-7743
www.mayfaresoftware.com

MFXchange Holdings
Toronto, Ontario, Canada
866-639-6399
www.mfxfairfax.com

Navisys
Edison, N.J.
800-775-3592
www.navisys.com

Oblix
Cupertino, Calif.
408-861-6800
www.oblix.com

onClick Corporation
Houston, Tex.
713-784-7600
www.onclickcorp.com

Ovum
Boston, Mass.
800-642-6886
www.ovum.com

Pilotfish Technology
Weathersfield, Conn.
860-257-0523
www.pilotfishtechnology.com

RedSiren
Pittsburgh, Pa.
877-360-7602
www.redsiren.com

Results International Systems
Worthington, Ohio
800-875-2126
www.resultscorp.com

S1 Corp.
Atlanta, Ga.
404-923-7637
www.s1.com

SANS Institute
Bethesda, Md.
301-654-7267
www.sans.org

Seagull Software
Atlanta, Ga.
404-760-1560
www.seagullsw.com

SecureWave
Durham, N.C.
919-806-4403
www.securewave.com

Steel Card, LLC
Santa Barbara, Calif.
(800) 553-9961
www.steelcard.com

Swingtide
Laconia, N.H.
603-431-7900
www.swingtide.com

Sygate
Fremont, Calif.
510-742-2600
www.sygate.com

Terrorism Research Center
877-635-0816
www.terrorism.com

Tumbleweed Communications
Redwood City, Calif.
800-696-1978
www.tumbleweed.com

Value One, LLC
Morrisville, N.C.
800-565-9598
www.e11online.com

Verian Technologies
Charlotte, N.C.
800-672-8776
www.procureit.com

Webmethods
Fairfax, Va.
703-460-2500
www.webmethods.com

Whale Communications
Fort Lee, N.J.
877-659-4253
www.whalecommunications.com
Whitehill Technologies
Moncton, N.B., Canada
888-944-8344
www.whitehilltech.com

NOT FOR REPRINT

© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.