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

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

Vision Adapts to Reality

XML Web services are evolving in philosophy as well as technology. The original utopian vision of insurers finding a Web service via a global Universal Description, Discovery, and Integration (UDDI) registry has, not surprisingly, met with the reality of the way people do business. Nobody wants a single company to control that [registry], says Tom Flanagan, director of financial services at Fulltilt, a Web services consultancy and solutions provider. The [Web services] industry is now trying a federated approach, but that was really after the development of the standards.

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

Hyde reports ASG chose to deploy an XML Web service due to its inherent interoperability. Using a wrapper, I was nervous about speed, but weve had absolutely no problems with that. My biggest problem is that everybody forgets about the service because its running that well.

Web Services Description Language (WSDL), a protocol for describing services capabilities, and Standard Object Access Protocol (SOAP), a message-based protocol for accessing services, are keys to this integration. Web services give you the flexibility to change applications and components without negatively affecting other applications, says Stefan Van Overtveldt, IBMs program director for WebSphere technical marketing. Applications are not only decoupled, but the definition of how applications should interact are completely standardized.

ASG: One Down, Three in the Works

ASG staff, Calypso Systems, and Microsoft combined to create ASGs first Web service. The quote service was deployed in under eight weeks, which included scalability testing of the system at Microsoft labs.

Hyde reports that the bulk of development time was attributed to getting staff up to speed on the development tools as well as ACORD XML standards. The standard is clear but also extensible, and there were no examples to go from for the exceptions [to the standards to reflect ASG-specific fields]. So that was the biggest learning curve, he says.

ASG has continued its XML Web services work using exclusively its own IT staff. Recently, it deployed a service that allows its policy management system to pull data directly from one of its online quotation systems. Currently under development are two other XML Web services for internal systems; one that will act as a document server to create customized policyholder documents from database queries and another to add customized and mobile-accessible print functionality to a Citrix portal system in place.

In its first Web service installation, ASG was able to leverage existing hardware investments, limiting its additional costs to Visual Studio licenses and consultant fees. While specific dollar amounts were not available, Hyde reports a positive return on investment by virtue of being able to adequately scale a system that had previously been limited to 80 simultaneous users. Now, we can handle 8,000 simultaneous connections. And the reality is, we can just scale out if we need to by adding more servers and Web farming it. Thats important because the site is growing exponentially.

In addition to development of the four Web services, ASG uses ACORD XML elsewhere within the enterprise systems, such as in interfaces with carriers and comparative raters. ASG reports that exposing those components as XML Web services, thereby allowing them to be invoked by other applications on an ad hoc basis, will be a relatively straightforward task when the need arises. All we will need to do is add SOAP [messaging] as well as a description [via WSDL], says Kevin Schipani, director of corporate data standards.

Storebrand Extends Update Function to Employers

Storebrand ASA provides pension plans for nearly 400,000 employees of over 6,500 companies. Each time a members salary or personal information changes, that information needs to be updated in the DB2 Universal Database that is part of its enterprise legacy system. Several years ago, Storebrand developed a WebSphere Java application that was accessed by customers human resource departments via the Web or, if customers submitted changes directly to Storebrand, by Storebrand staff members via their intranet. Either way, data had to be entered twice; first into customers payroll systems, and then into Storebrands database.

The insurer looked to integrate this application directly with the payroll systems of its clients and chose to wrap the component as a Web service. Without Web services, we would still have used XML over HTTP, says Espen Sletteng, systems architect at Storebrand. The difference is that SOAP is a standard. Without it, we would have had to invent our own standard, and it would have been more difficult to get payroll vendors to use a proprietary standard.

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

There are three components to Web service implementation: a COM-based object in the employers payroll application that generates a SOAP request that accesses the Web service over the Internet; the Web service itself that resides on the WebSphere application server at Storebrand; and an MQ series integration layer that parses the XML data (based on ACORD XMLife standards), converts it to a COBOL copybook, and sends it to Storebrands S/390 server. Clients that arent using a payroll system currently integrated with the update Web service rely on Storebrands secure Web site, which connects to the same Web service used by integrated systems.

Storebrand staff developed the XML Web service themselves with some training from IBM. Having already been an IBM WebSphere and VisualAge customer, Storebrand needed no additional systems or software investment to develop and deploy the service, though it did receive additional support and training via IBMs Jumpstart program. And since the service was extended to third-party vendors, those vendors in turn needed to support Web services standards. It was definitely easier to get the payroll application providers to be willing to invest in [Web services] because they feel its an open standardthey can even start sending data to our competitors when they have Web services available, Sletteng explains.

There were no notable development problems and no ongoing production problems with the service. If you know Java, SOAP is very simple, says Sletteng. And the [Web service] is a very stable component.

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

Travelers Uses Web Services In Glass Claims Partnership

In April 2001, Travelers completed the reengineering of its TravGlass auto glass claims process, which included developing an XML Web service that is accessed via the Web site of business partner Mitchell International, creator of eMitchell.com, an Internet workspace and marketplace for the collision repair and claims industries. Previously, shops called Travelers to confirm coverage. Now, Mitchells site provides direct access to coverage information. The Travelers system also automates claim payments via funds transfer.

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

Even with XML, you have to define the data and do the typical business flow analysis to determine what data is needed on both sides of the equation, says Ken DAuria, second vice president in the claims system area. But it was nothing outside the normal development.

Travelers looked to Web services for a number of reasons. We dont want to be the only carrier utilizing [Mitchells system]. If we built a traditional interface, every time Mitchell wanted to add a different carrier, itd need to revise its system. Also, it may not be worth [going to the Mitchell site] for your mom-and-pop glass shop if only Travelers is accessible, but if every insurer is doing it, then its worth putting an Internet connection in your shop. Mitchell International was not available for comment.

In addition, Travelers had the reusability of the Web service in mind, which currently also is accessed by its call center via the corporate intranet. Security is handled on both the Mitchell and Travelers sides, with Mitchell verifying the identity of glass shops, and Travelers firewalls and standard protocols currently restricting access to the Web service.

To develop the service, Travelers used Microsofts Visual Studio.NET, and development took five months. Open standards meant that it didnt matter that Mitchell wasnt using .NET. With SOAP protocols, 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 Web service was purchasing Visual Studio.NET. The hardware investments were traditional. For any new Web app, we would have needed the suite of Web servers, database servers, and so on, says DAuria. Additionally, Travelers was able to leverage some of its existing Visual 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 cars fixed with little aggravation, the glass shops that are on board are extremely happy because they dont get caught in telephone tag in terms of confirming deductibles and coverage, plus, because of the whole electronic mechanism, theyre getting funds transferred in just a couple days. And weve moved some workload out of our call center 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 to address tactical projects. Particularly in claims, our goal is to expand the TravGlass architecture to support some of the other claims of this nature, such as towing and rental [reimbursement]. Our driving architecture guideline is to use Web services among any of 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 another application, Web services are what were doing. Were not reengineering old things, but as new needs arise, we ask how they can fit into a Web services architecture, says DAuria.

The real benefit comes long term, he continues. The development cost isnt that much more. But over time, the payback will be substantial. Its the reusabilitythats been promised many times before, but this is the first time I can say Im beginning to see it.

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 security component. If youre publishing your own internal application to a [public UDDI] repository, youre giving information on the application, what it can do, the IP address, and so on. Its an invitation to hack, and there are some real security concerns, says IBMs Stefan Van Overtveldt. Therefore, the primary uses of XML Web services now are for internal application integration and for controlled exchanges with trading partners, such as insurance brokers and agents.

Only later will there come public deployment of Web services, according to Calypso Systems CEO, Ted MacLean, and then most likely, 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 WSDL interface, or wrapper, to an application, so that all the input and output fields are mapped and described in WSDL. Next, you need to create a SOAP proxya piece of code listening to incoming requests and pushing those requests into the application logic. Ultimately, you could publish the service via an XML document to a directory of services.

There are many tools on the market to help you do this: All the major Web service evangelists have their own development studios, as do a number of niche companies. And encouragingly, there is general agreement that XML Web services represent an evolving technology, meaning that insurers are likely to not only find staff who already have the skill sets to handle the development but also undertake implementation of Web services incrementally. As the case studies included show, early adopters of XML Web services have been doing 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 at insurers, look to eliminate system redundancies as a way to maximize ROI. What we see financial services companies doing is evaluating their assets and saying, If I have five applications that are doing the same thing, why not take one and expose it as a Web service? says Josh Lee, global technical strategist for Microsoft.

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

What Will Building Web Services Cost You?

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

Need help in determining your readiness? For the assessment stage, Fulltilt charges from $25,000-$40,000, according to the consultancys Tom Flanagan. That gets them to the point where we identify what they have and identify something they could tackle as a pilot project. In total, A few hundred thousand will get them pretty far and will be an excellent educational experience for the team.

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

Five Steps Toward Successful Web Services

By Mateen Khadir

Web services hold the key to making integration work in the insurance industry. Automated XML-based services move data between systems and networks, and eliminate the need for custom interface development or proprietary adaptors. Protocols are still evolving and security concerns must be thoroughly addressed. So what advice is there for IT managers interested in exploring Web services? Try these five on for size.

Step 1 Which Web services?

The first step is to build your organizations knowledge infrastructure to understand the constraints and possibilities Web services offer. Research is needed to identify which of the varying development tools on the market best suit the needs of your organization. Because Web services technologies are not yet completely platform-neutral, a choice must be made.

Microsoft, Sun, and IBM all offer development approaches for incorporating Web servicesthe choice rests on which best leverages existing systems and expertise. Does your current production or execution environment rely heavily on Sun or Unix technology? Then think about J2EE for development. Are your developers more experienced with Microsoft technology? Then .NET might be a better approach.

Regardless of your developers talents on your selected platform, there will still be a learning curve involved in bringing Web services into your organization. Company management will also require some educating. No doubt, they have heard the phrase Web services. However, knowledge of the true definition of Web services, the costs involved, and how this technology can be used to minimize future integration challenges is often lacking.

Though Web services proponents envision a future of nearly plug-and-play solutions, that day has not yet arrived. Web services still require cooperation and agreement on the definitions of business transactions and processes, both inside and outside the organization. In addition, standards for defining the XML data elements passed to and returned from Web services are still under development.

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

Using an internal project for the first implementation will allow developers to address security issues before exposing your organizations data and systems to external hazards. While development tools are available to ensure safety, good design is still crucial to ensure adequate data authentication, authorization, and protection. Addressing security concerns in this first project can help provide a more secure foundation for looking at an external interface in a second project. As more carriers turn to outsourced solutions for claims processing and other tasks, secure external integration will become increasingly important.

The results of this first project will provide important data for future budgets and give insight into the cost savings Web services could offer your organization. Incorporating time for a thorough review and debriefing in your project plan, as well as developing metrics for measuring ROI, will help ensure these hazards and benefits are addressed as you move forward.

With the knowledge gained from your first Web services experience, you can begin moving beyond a single interface. Your second undertaking might involve expanding on the internal groundwork you have just laid, or you may want to step outside your firewall. An externally facing project would allow you to explore the issues involved in working with outside technologists and help you develop strategies for safely interfacing with other systems. Agencies or channel partners you have recognized as early adopters of technology might be good candidates for this type of effort.

One lesson you will learn, regardless of where you begin your investigation of Web services, is the importance of staying current with, and adhering to, insurance-industry XML standards as they develop. Not only will this attention ease headaches, it also will make expanding on any current work much easier in the future. ACORD (www.acord.org), the insurance industrys nonprofit standards developer, has already produced some standards and has working groups concentrating on further development.

Do not use this ongoing standard-development process as an excuse for ignoring Web services today. This new approach offers too many opportunities for addressing the integration issues raised by cross-platform systems, increased reliance on outsourcing and industry consolidation. By using focused implementations to begin the process of understanding potential pitfalls, you will be positioning your organization to take advantage of the benefits Web services will provide in the future.

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