A mere year ago, the insurance industry was just fleshing outthe concept of what XML Web services are: platform-independent,loosely coupled, programmably addressable applications accessiblevia the Internet. Web services are a technology in transition, pastthe point of whats new columns in trade publications andimplementation by first-adopters, but not yet to the point ofcritical mass usage.

Many insurers are finding Web services to be a straightforwardsolution for specific problems, and the solutions to those problemsmay hold the key to bigger solutions ahead.

Whether deployed to combine the back-ends of consolidatingcarriers or create a consistent interface in a corporate portal,Web services have been helping get the job done. Implementationsusing Web services are as diverse as the insurers themselves. Forexample, Aon Services Group (ASG), the outsourcing and alternativedistribution arm of Chicago-based Aon Corp., is utilizing theseapplications in developing internal and external systems.Storebrand ASA, Norways largest provider of pension plans,insurance, and other financial services, is using them to betterintegrate payroll information. Travelers has included Web servicesin reengineering one of its claims processes.

In early 2001, ASG deployed a consumer-oriented Web site forCalifornia residents to obtain automobile insurance quotes. Thesystem was based on a multi-platform architecture, with Windows2000-based Web servers running ASP, JavaScript, and COM objectswritten in Visual Basic accessing an Oracle database and anexternal, third-party rating engine.

As the site generated business, scalability problems arose and,later in 2001, ASG decided to convert the system, includingwrappering an existing DCOM object as XML Web service that wouldaccess the rating engine.

We can now take multiple clients and interface them with the Webservice, says Arthur Hyde, development group manager at ASG. If wewant to interface to a Web application, we can do it. If we want todo a client server app, we can do it, using the same Web service.He adds they have had no problems with the service sincedeployment.

Vision Adapts to Reality

XML Web services are evolving in philosophy as well astechnology. The original utopian vision of insurers finding a Webservice via a global Universal Description, Discovery, andIntegration (UDDI) registry has, not surprisingly, met with thereality of the way people do business. Nobody wants a singlecompany to control that [registry], says Tom Flanagan, director offinancial services at Fulltilt, a Web services consultancy andsolutions provider. The [Web services] industry is now trying afederated approach, but that was really after the development ofthe standards.

Just as insurers refrain from selecting system providers bythumbing through the yellow pages or doing a Google search,traditional vendor evaluations will likely apply for futureconsumption of XML Web services. There will first need to be acontract between you and whomever youre going to get your Webservice from, says Rik Chomko, CTO at Calypso Systems, who alsosays that about half of the insurers hes contacted report using Webservices somewhere in their enterprise. Chomko adds that what willgradually change in the system installation process as a result ofWeb services maturation is the ease with which applications andcomponents are used and integrated.

Hyde reports ASG chose to deploy an XML Web service due to itsinherent interoperability. Using a wrapper, I was nervous aboutspeed, but weve had absolutely no problems with that. My biggestproblem is that everybody forgets about the service because itsrunning that well.

Web Services Description Language (WSDL), a protocol fordescribing services capabilities, and Standard Object AccessProtocol (SOAP), a message-based protocol for accessing services,are keys to this integration. Web services give you the flexibilityto change applications and components without negatively affectingother applications, says Stefan Van Overtveldt, IBMs programdirector for WebSphere technical marketing. Applications are notonly decoupled, but the definition of how applications shouldinteract are completely standardized.

ASG: One Down, Three in the Works

ASG staff, Calypso Systems, and Microsoft combined to createASGs first Web service. The quote service was deployed in undereight weeks, which included scalability testing of the system atMicrosoft labs.

Hyde reports that the bulk of development time was attributed togetting staff up to speed on the development tools as well as ACORDXML standards. The standard is clear but also extensible, and therewere no examples to go from for the exceptions [to the standards toreflect ASG-specific fields]. So that was the biggest learningcurve, he says.

ASG has continued its XML Web services work using exclusivelyits own IT staff. Recently, it deployed a service that allows itspolicy management system to pull data directly from one of itsonline quotation systems. Currently under development are two otherXML Web services for internal systems; one that will act as adocument server to create customized policyholder documents fromdatabase queries and another to add customized andmobile-accessible print functionality to a Citrix portal system inplace.

In its first Web service installation, ASG was able to leverageexisting hardware investments, limiting its additional costs toVisual Studio licenses and consultant fees. While specific dollaramounts were not available, Hyde reports a positive return oninvestment by virtue of being able to adequately scale a systemthat had previously been limited to 80 simultaneous users. Now, wecan handle 8,000 simultaneous connections. And the reality is, wecan just scale out if we need to by adding more servers and Webfarming it. Thats important because the site is growingexponentially.

In addition to development of the four Web services, ASG usesACORD XML elsewhere within the enterprise systems, such as ininterfaces with carriers and comparative raters. ASG reports thatexposing those components as XML Web services, thereby allowingthem to be invoked by other applications on an ad hoc basis, willbe a relatively straightforward task when the need arises. All wewill need to do is add SOAP [messaging] as well as a description[via WSDL], says Kevin Schipani, director of corporate datastandards.

Storebrand Extends Update Function toEmployers

Storebrand ASA provides pension plans for nearly 400,000employees of over 6,500 companies. Each time a members salary orpersonal information changes, that information needs to be updatedin the DB2 Universal Database that is part of its enterprise legacysystem. Several years ago, Storebrand developed a WebSphere Javaapplication that was accessed by customers human resourcedepartments via the Web or, if customers submitted changes directlyto Storebrand, by Storebrand staff members via their intranet.Either way, data had to be entered twice; first into customerspayroll systems, and then into Storebrands database.

The insurer looked to integrate this application directly withthe payroll systems of its clients and chose to wrap the componentas a Web service. Without Web services, we would still have usedXML over HTTP, says Espen Sletteng, systems architect atStorebrand. The difference is that SOAP is a standard. Without it,we would have had to invent our own standard, and it would havebeen more difficult to get payroll vendors to use a proprietarystandard.

Since deploying the service last summer, Storebrand has extendedit to two payroll vendors whose systems are used at about half ofthe insurers client base. Over the next six months, Storebrandhopes to integrate the Web service with most of the remainingvendor systems in place with its clients.

There are three components to Web service implementation: aCOM-based object in the employers payroll application thatgenerates a SOAP request that accesses the Web service over theInternet; the Web service itself that resides on the WebSphereapplication server at Storebrand; and an MQ series integrationlayer that parses the XML data (based on ACORD XMLife standards),converts it to a COBOL copybook, and sends it to Storebrands S/390server. Clients that arent using a payroll system currentlyintegrated with the update Web service rely on Storebrands secureWeb site, which connects to the same Web service used by integratedsystems.

Storebrand staff developed the XML Web service themselves withsome training from IBM. Having already been an IBM WebSphere andVisualAge customer, Storebrand needed no additional systems orsoftware investment to develop and deploy the service, though itdid receive additional support and training via IBMs Jumpstartprogram. And since the service was extended to third-party vendors,those vendors in turn needed to support Web services standards. Itwas definitely easier to get the payroll application providers tobe willing to invest in [Web services] because they feel its anopen standardthey can even start sending data to our competitorswhen they have Web services available, Sletteng explains.

There were no notable development problems and no ongoingproduction problems with the service. If you know Java, SOAP isvery simple, says Sletteng. And the [Web service] is a very stablecomponent.

The insurer is looking to other areas within its enterprise todeploy XML Web services. We may be in a position a year from nowwhere we have an outsourced call center, for instance, but we wantthe call center to trigger or be part of a process, Sletteng says.We could see Web services as a way to transport this process datafrom outside the firewall to our internal company. We also haveexternal brokers who need to have more access to our data, toinitiate transactions [and do] sale process management.

Travelers Uses Web Services In Glass ClaimsPartnership

In April 2001, Travelers completed the reengineering of itsTravGlass auto glass claims process, which included developing anXML Web service that is accessed via the Web site of businesspartner Mitchell International, creator of eMitchell.com, anInternet workspace and marketplace for the collision repair andclaims industries. Previously, shops called Travelers to confirmcoverage. Now, Mitchells site provides direct access to coverageinformation. The Travelers system also automates claim payments viafunds transfer.

Travelers didnt extend the XML Web service directly to glassshops as not all shops have an automated ERP or management system.Additionally, tweaking still was required to allow the back-endsystem supporting Mitchells Web site to interface with Travelersclaims system.

Even with XML, you have to define the data and do the typicalbusiness flow analysis to determine what data is needed on bothsides of the equation, says Ken DAuria, second vice president inthe claims system area. But it was nothing outside the normaldevelopment.

Travelers looked to Web services for a number of reasons. Wedont want to be the only carrier utilizing [Mitchells system]. Ifwe built a traditional interface, every time Mitchell wanted to adda different carrier, itd need to revise its system. Also, it maynot be worth [going to the Mitchell site] for your mom-and-popglass shop if only Travelers is accessible, but if every insurer isdoing it, then its worth putting an Internet connection in yourshop. Mitchell International was not available for comment.

In addition, Travelers had the reusability of the Web service inmind, which currently also is accessed by its call center via thecorporate intranet. Security is handled on both the Mitchell andTravelers sides, with Mitchell verifying the identity of glassshops, and Travelers firewalls and standard protocols currentlyrestricting access to the Web service.

To develop the service, Travelers used Microsofts VisualStudio.NET, and development took five months. Open standards meantthat it didnt matter that Mitchell wasnt using .NET. With SOAPprotocols, we could communicate, says DAuria. (For insights into.NET and J2EE, see Trends & Tech, p. 32.)

The only additional expense for the development of the XML Webservice was purchasing Visual Studio.NET. The hardware investmentswere traditional. For any new Web app, we would have needed thesuite of Web servers, database servers, and so on, says DAuria.Additionally, Travelers was able to leverage some of its existingVisual Basic components in the new service.

“One of the benefits of this whole process is that it was a win,win, win for us,” says D'Auria. “Policyholders are getting carsfixed with little aggravation, the glass shops that are on boardare extremely happy because they dont get caught in telephone tagin terms of confirming deductibles and coverage, plus, because ofthe whole electronic mechanism, theyre getting funds transferred injust a couple days. And weve moved some workload out of our callcenter and off to the glass shops.”

Based on the ease of deployment and success of this initiative,Travelers is looking to Web services technologies to continue toaddress tactical projects. Particularly in claims, our goal is toexpand the TravGlass architecture to support some of the otherclaims of this nature, such as towing and rental [reimbursement].Our driving architecture guideline is to use Web services among anyof the layers that we can. We dont use them to go to the mainframe.But anywhere from a Web server to a database server or anotherapplication, Web services are what were doing. Were notreengineering old things, but as new needs arise, we ask how theycan fit into a Web services architecture, says DAuria.

The real benefit comes long term, he continues. The developmentcost isnt that much more. But over time, the payback will besubstantial. Its the reusabilitythats been promised many timesbefore, but this is the first time I can say Im beginning to seeit.

Michael P. Voelker is principal of Equinox Communications,Inc. He can be reached at[email protected].

The Missing Component

Still missing in the larger Web services world is a securitycomponent. If youre publishing your own internal application to a[public UDDI] repository, youre giving information on theapplication, what it can do, the IP address, and so on. Its aninvitation to hack, and there are some real security concerns, saysIBMs Stefan Van Overtveldt. Therefore, the primary uses of XML Webservices now are for internal application integration and forcontrolled exchanges with trading partners, such as insurancebrokers and agents.

Only later will there come public deployment of Web services,according to Calypso Systems CEO, Ted MacLean, and then mostlikely, for read only functions, such as rating engine queries.Critical mass in the use of Web services will likely come by 2004,say most industry analysts.

Understanding Web Service Technology

Creating an XML Web service involves first adding a WSDLinterface, or wrapper, to an application, so that all the input andoutput fields are mapped and described in WSDL. Next, you need tocreate a SOAP proxya piece of code listening to incoming requestsand pushing those requests into the application logic. Ultimately,you could publish the service via an XML document to a directory ofservices.

There are many tools on the market to help you do this: All themajor Web service evangelists have their own development studios,as do a number of niche companies. And encouragingly, there isgeneral agreement that XML Web services represent an evolvingtechnology, meaning that insurers are likely to not only find staffwho already have the skill sets to handle the development but alsoundertake implementation of Web services incrementally. As the casestudies included show, early adopters of XML Web services have beendoing so as point solutions with a broader outlook in mind.

What system components are good candidates for Web services?With internal integration the likely first role for Web services atinsurers, look to eliminate system redundancies as a way tomaximize ROI. What we see financial services companies doing isevaluating their assets and saying, If I have five applicationsthat are doing the same thing, why not take one and expose it as aWeb service? says Josh Lee, global technical strategist forMicrosoft.

If you simply want to make sure that any new IT work you do ornew systems you acquire are ready for the future of XML Webservices, there are three steps to take, says Phil Ehlen, chiefarchitect of P&C solutions at Computer Sciences Corporation.First, make sure systems are componentized. Second, when youexternalize your data or transaction services, do it in a standardXML format. And third, make sure the protocol youre using tocommunicate is HTTP. From there, SOAP and WSDL are small steps tomake.

What Will Building Web Services Cost You?

The answer to this question is as variable as theinfrastructures in place across the industry. It could be atraumatic increase in cost [if an insurer is] a pure mainframe shopand its not getting support from its vendors [for Web services],says Uttam Narsu, senior industry analyst at Giga InformationGroup, the Cambridge, Mass.-based IT advisory and research firm.Itll need to build out tools and techniques to enable Web servicesor bring in a systems integrator to do the work. If its alreadypart-way along to a Web services architecture, if it has done someWeb-to-host projects or reconstituted some business logic to havean n-tier type of application, [those insurers] will have an easiertime.

Need help in determining your readiness? For the assessmentstage, Fulltilt charges from $25,000-$40,000, according to theconsultancys Tom Flanagan. That gets them to the point where weidentify what they have and identify something they could tackle asa pilot project. In total, A few hundred thousand will get thempretty far and will be an excellent educational experience for theteam.

Assuming youre ready, youll need to have a development tool anda Web server. IBMs Stefan Van Overtveldt reports that the WebSphereStudio Application Developer has a list price of $3,500 perdevelopers seat. For an application server to run the service, heestimates about $8,000 per processor, or around $12,000 withclustering and failover support. So if you want to start a smallproject with five to eight developers, one or two processorlicenses on an application server, youre looking at $40,000-$50,000list price, he says. Figures for a comparable .NET project werentavailable.

Five Steps Toward Successful Web Services

By Mateen Khadir

Web services hold the key to making integration work in theinsurance industry. Automated XML-based services move data betweensystems and networks, and eliminate the need for custom interfacedevelopment or proprietary adaptors. Protocols are still evolvingand security concerns must be thoroughly addressed. So what adviceis there for IT managers interested in exploring Web services? Trythese five on for size.

Step 1 Which Web services?

The first step is to build your organizations knowledgeinfrastructure to understand the constraints and possibilities Webservices offer. Research is needed to identify which of the varyingdevelopment tools on the market best suit the needs of yourorganization. Because Web services technologies are not yetcompletely platform-neutral, a choice must be made.

Microsoft, Sun, and IBM all offer development approaches forincorporating Web servicesthe choice rests on which best leveragesexisting systems and expertise. Does your current production orexecution environment rely heavily on Sun or Unix technology? Thenthink about J2EE for development. Are your developers moreexperienced with Microsoft technology? Then .NET might be a betterapproach.

Regardless of your developers talents on your selected platform,there will still be a learning curve involved in bringing Webservices into your organization. Company management will alsorequire some educating. No doubt, they have heard the phraseWeb services. However, knowledge of the true definition ofWeb services, the costs involved, and how this technology can beused to minimize future integration challenges is oftenlacking.

Though Web services proponents envision a future of nearlyplug-and-play solutions, that day has not yet arrived. Web servicesstill require cooperation and agreement on the definitions ofbusiness transactions and processes, both inside and outside theorganization. In addition, standards for defining the XML dataelements passed to and returned from Web services are still underdevelopment.

As with all new technologies, experience is the best teacher. Asmall project focusing on a single interface can help provide vitalunderstanding of the security, data elements, business processes,standards, and setup involved in a successful implementation. Suchan effort could also lay the groundwork necessary for largerimplementations later. A little work is required to identify thebest candidate for a successful trial run. For this first venture,concentrate on an internal process involving a single interfacebetween two systems. Although this should not be anorganizationally critical operation, it should be complex enough totest current development limits and offer opportunities for aphased expansion if successful.

Using an internal project for the first implementation willallow developers to address security issues before exposing yourorganizations data and systems to external hazards. Whiledevelopment tools are available to ensure safety, good design isstill crucial to ensure adequate data authentication,authorization, and protection. Addressing security concerns in thisfirst project can help provide a more secure foundation for lookingat an external interface in a second project. As more carriers turnto outsourced solutions for claims processing and other tasks,secure external integration will become increasingly important.

The results of this first project will provide important datafor future budgets and give insight into the cost savings Webservices could offer your organization. Incorporating time for athorough review and debriefing in your project plan, as well asdeveloping metrics for measuring ROI, will help ensure thesehazards and benefits are addressed as you move forward.

With the knowledge gained from your first Web servicesexperience, you can begin moving beyond a single interface. Yoursecond undertaking might involve expanding on the internalgroundwork you have just laid, or you may want to step outside yourfirewall. An externally facing project would allow you to explorethe issues involved in working with outside technologists and helpyou develop strategies for safely interfacing with other systems.Agencies or channel partners you have recognized as early adoptersof technology might be good candidates for this type of effort.

One lesson you will learn, regardless of where you begin yourinvestigation of Web services, is the importance of staying currentwith, and adhering to, insurance-industry XML standards as theydevelop. Not only will this attention ease headaches, it also willmake expanding on any current work much easier in the future. ACORD(www.acord.org), the insurance industrys nonprofit standardsdeveloper, has already produced some standards and has workinggroups concentrating on further development.

Do not use this ongoing standard-development process as anexcuse for ignoring Web services today. This new approach offerstoo many opportunities for addressing the integration issues raisedby cross-platform systems, increased reliance on outsourcing andindustry consolidation. By using focused implementations to beginthe process of understanding potential pitfalls, you will bepositioning your organization to take advantage of the benefits Webservices will provide in the future.

Mateen Khadir is director of technology for Visibillity,Inc. He can be reached at [email protected].