Promises, Promises

"One of the big projects that we have completed recently has been providing a COM [Component Object Model] interface to our system that can support a Web application or other automation needs," said Mark Strelau, director of product technologies at P&C software provider Instec. Currently that interface is used to communicate with other applications within the enterprise; setting data, developing premiums, and returning results, for example.

Moving to a Web services model would allow Instec customers interplatform compatibility. "Today, with our COM model, we're tightly tied to a Microsoft technology base," Strelau said. "We could easily put a CORBA wrapper around our COM interface, but you're still tying yourself to a specific platform. With SOAP, it doesn't matter if you're calling from a Unix box into something that's hosted on a Windows box; they'll still be able to communicate. Our fundamental object model remains the same, and the only change that we need to make is to go to the Web services standards that are in the process of being developed."

CSC is working to expose the application functions of its package solutions as services by building its own component-based application program interfaces [APIs] and extending those interfaces using third party tools. "About half of our participating components are based on the Microsoft platform, and half are based on Java," said Brian Wallace, who heads CSC's financial services e-business practice initiatives.

CSC also anticipates being a provider of Web services in the context of application outsourcing or business process outsourcing. "The Web services model, when fully realized, will enable new alternatives for the packaging and delivery of sourcing solutions," Wallace said. "In the long run, the impact of Web services on outsourcing could be just as significant as it has been on product development."

In life insurance software, Solcorp has created a Java-based architecture called Pathfinder that surrounds the company's flagship Ingenium policy administration system. "The Pathfinder architecture allows the Ingenium application to be integrated into any Web portal or Web exercises our customers are currently going through," said Todd Haney, vice president of product management at Solcorp. Although the company has no immediate plans to deploy Ingenium or any of its other software directly as a Web service, Solcorp reported it could be done by extending the current set of services interfaces that facilitate integration. "A SOAP services interface can be layered directly over one or more of these business APIs," Haney said.

Ditto on Java for the Freedom Group. Scheduled for a 2002 deployment, Freedom is adding Policy Star and Claims Workstation/J-component-based Enterprise JavaBeans systems for policy and claims administration, respectively. These are in addition to Freedom's existing portfolio that includes Claims Workstation, which is based on a VB/COM architecture.

Meanwhile, ASPs-and the insurers who use them-may have a leg up on other software providers when it comes to doing business under any forthcoming Web services model because of their current familiarity with Internet delivery of application functionality. For instance, ASP Visibillity's Web-based insurance litigation management application uses XML for receiving and sending claims data. "Right now, our tools are already Microsoft DNA architecture based," says Visibillity president and COO Asif Ahmed. "So on our side, [using the .Net architecture] would simply mean compiling our application components using the additional development tools and redeploying the software on our Web servers."

Visibillity also deals with issues of enabling insurers' legacy systems to integrate with its own software via the Internet, building custom interfaces to create XML output or recommending off-the-shelf solutions depending upon the state of the particular client system.

Pick a Platform, Any Platform

A logical concern for insurers looking forward is what Web services platform will likely prevail in the industry. Not surprisingly, many vendors claim the lead, but the frontrunners are Microsoft with its proprietary .Net platform and, in the open source Java arena, IBM with Websphere.

"Microsoft is clearly ahead. The .Net technology, which is in beta right now, is expected by the end of the year," said Narsu, who also added that an early lead doesn't necessarily mean ultimate victory. "There's a certain ease of use [by Microsoft] that hasn't been achieved by some of the Java vendors, but it would be wrong to assume that Web services are only a Microsoft thing, as the .Net branding implies. And in an industry as immature as Web services, the J2EE vendors have plenty of time to catch up."

"The software industry is backing the J2EE [Java 2 Enterprise Edition] solution because it's an open standard," said Joe Aloia, CTO of the IT consultancy Tybio. "Sun is obviously a major player on the Java platform side, but on the tool side, IBM is really ahead."

In the end, will it matter to insurers who wins the Web services market share battle? As a consumer of Web services, and assuming a consensus on standards and common language runtime, probably not. "The goal would be to allow participation across a number of vendors," Wallace said. "That is the role of standards in a multi-vendor marketplace." Naturally, as is the case with the development of most standards, there will be some fractioning around definitions. "Ideally the same standards would be endorsed and supported by all participating vendors…To the extent they're different, we see bridging solutions…brokering those differences."

If an insurer decides to publish a Web service itself, fractioning may become more of an issue. "Right now, if I deploy a Web service in BEA WebLogic, and then my company migrates to IBM Websphere, the service should run under Websphere," Narsu said. "But I will find it difficult to change because each J2EE vendor uses different conventions for implementing the Web service. So I have code-level interoperability, but it's write-only, meaning it's difficult to change in a new application server environment. The J2EE vendors will fix this, but for now we have a Microsoft that has a mature, tightly integrated vision around Web services, versus an open, loosely integrated but potentially more complete vision of Web services from the J2EE vendors."

The desire to set the J2EE Web services standard is one reason IBM has jumped ahead, promising a platform deliverable by the time you read this. "They're trying to freeze the market," Aloia said.

Be Prepared
Web services are coming. Take the right steps to be ready for them.

What should insurers do in practical terms to prepare for the advent of Web services, while hedging their bets against unexpected changes in systems and standards? Aside from the usual "plan carefully" and "become familiar with the technology," there are some steps to take of which, interestingly, none are technological.

"For companies that already have a Web presence, most of the [infrastructure] grunt work is already done," said JoeAloia, CTO of IT consultant Tybio. "We find organizational changes are more difficult than technological changes."

"The overhead of Web services is very low," said Stefan Van Overtveldt, IBM's program director for Websphere technical marketing. "There hasn't been a large impact on internal networks. You'll rarely get into communication streams where a single request generates even 10K of network traffic." Dan Sholler, a senior program director with Meta Group, agrees. "A tagged message is larger than a bitmap message, but in order for it to be an issue, it would have to be [a much greater] order of magnitude."

Microsoft suggests that there are two key components businesses need to consider as they migrate to distributed Web applications. "Foremost, they need to embrace open standards," said a Microsoft spokesperson via e-mail. "We have referred to this as the XML- and SOAP-ification of their existing applications. Secondly, business processes need to be rethought to leverage a service model."

That means determining not only which application components can be best run as a Web service-the traditional rent-versus-buy value equation-but evaluating which services an insurer itself could provide to generate new revenue.

"A business needs to decide 'What's in it for me?,' and it requires a level of creative thinking and brainstorming," Sholler said. "You have to start thinking along the lines of 'Do we want to be a user of a Web service? Do we want to provide a Web service?' If…I have the best of breed capability to do something, that capability is an excellent candidate to deploy as a Web service."

So insurers with strengths in claims services, rating, or even underwriting can generate additional revenue by deploying those strengths as services. For instance, an insurer could deploy the calculator of Solcorp's Ingenium as part of a CRM package to its agents for doing needs analysis or illustration.

"An insurance company can define a product once in the Ingenium designer component and use the definition of that within the calculation server that can be embedded in the back office, in the illustrator component, or in any other component it has within the enterprise," said Solcorp's Haney.

That's fine for a new application created or purchased with a distributed architecture and Web-enabled functionality in mind. But how do insurers deploy a legacy application as a Web service, or use a Web service application with existing systems? It begins with exposing core application functions and applying an XML-based interface to them.

Naturally, vendors will offer middleware solutions designed to accomplish this. For example, IBM promises to be able to apply a "wrapper" to common languages found in insurers legacy systems, such as COBOL, as a Java class. Similar wrappers apply database load procedures or component-based applications built using COM or currently utilizing CORBA wrappers.

Things get more difficult when CICS applications are involved, however. "With today's technology, it is still very hard to do anything other than screen scraping on [CICS applications], and screen scraping does not lend itself well to high volume reuse in a Web services application," said Van Overtveldt.

As always, insurers should carefully scrutinize the promises made by middleware. "If people think they can get the full benefit of Web services from just wrapping, they're sadly mistaken," Aloia said. "There are a lot of issues that need to be taken into account, to allow people to truly take advantage of a Web services model. Most mainframe systems were not developed in an object-oriented fashion."

Important for insurers to know, however, is that application providers are at least building current systems with Web services in mind, helping ensure that a new purchase today won't be a dinosaur tomorrow. "Web services are not a substitute for installed software; they are an extension of them," said Microsoft.

"Are we implementing a pure Web services model today? No," CSC's Brian Wallace said. "But what we have been doing is getting a head start on all of the difficult and time consuming work that will have to be done eventually to allow our customers to realize the benefits of a Web services model, which is reusing components and breaking up monolithic applications. Since we support Internet protocols and maintain an awareness of SOAP, UDDI, WSDL, and know what we need to be doing to support those standards, when those standards mature, we're only making final adjustments."

First Deployments

Early deployments of Web services as defined will probably be targeted toward new business and CRM. "I would expect quote and issuance to occur first, and then claims," Giga's Uttam Narsu said. "It's natural, and follows the evolution of [insurance on] the Internet, to tackle the customer facing applications first."

Also, Web services will likely make early inroads into insurers' intra-enterprise systems. By having a published series of standard Web services interfaces, front-end, Web-enabled applications can more readily communicate with each other and with the back office.

Though this potential is still only a promise, precursory Web services technologies today are being used to an extent to facilitate EDI. For example, Storebrand ASA, Norway's largest financial and insurance company, is using IBM Websphere in its pension fund management. Insureds transmit employee data in XML format using SOAP to communicate between whatever system they use and Storebrand's IBM-architected system. Websphere receives and authenticates the request and modifies client records in Storebrand's central database.

Note, though, that there are some areas where Web services won't make immediate sense for insurers, such as when there are static relationships between companies, or where there's already good exchange of information. Particularly important, systems must be able to support real-time processing, making any existing batch processing systems virtually ineligible for exposure as a Web service.

Web What?

Problem number one: The concept of "Web services" means different things to different people (admittedly, hardly a first when talking technology). Some consider Web services the process of simply Web-enabling applications, or providing B2B or B2C services to customers online. Here, however, we're talking about delivery of applications and application components themselves via the Internet-essentially, software as a service.

Think 'evolution of ASP,' but with components, not monolithic applications. Application components hosted both externally and internally can communicate by using XML messages, regardless of operating system or language. More important than simple information exchange, Web services applications as defined offer programmatically addressable interfaces, allowing their capabilities to be invoked by other applications, and vice versa. Web services are also an evolution of object-oriented software components that currently exist and comply with differing standards such as Enterprise JavaBeans, the Component Object Model (COM), or Common Object Request Broker Architecture (CORBA).

The benefits of Web services? The ultimate in scalability and flexibility. The ability to pick and choose best-of-breed solutions to a high specificity of function. Freedom from worry about the infrastructure of services being used. The ability to maintain a relatively stable front end regardless of changes made to back-office systems.
"[I]f you look at the dynamic model, insurers could [locate and use] different providers on the fly," in theory, different ones for different transactions, according to Brian Wallace of CSC. "The definition of Web services is based on dynamic or fairly modular components; 'insourcing' and outsourcing of those elements of your business that are strategic versus those elements where you need the internal capability. Literally, customers could assemble solutions based on what they need."

But for this all to work, it requires consensus on standards. Fortunately, HP, IBM, Microsoft, Oracle, and Sun have put their collective heads together to come up with standards on ways to locate services that are available (Universal Description, Discovery, and Integration protocol, or UDDI), ways to describe how to connect to a Web service (Web Services Description Language, or WSDL), and ways to message between Web services (Simple Object Access Protocol, or SOAP).

We've heard promises of this level of compatibility before, right? So what makes this any different? "It looks to have a real shot of happening," said Joe Aloia, CTO of Tybio. "Typically, the industry developed the technology first and the standard second, but in this case, the standards emerged as the beginning."

click here
BEA Weblogic: www.bea.com
CSC: www.csc.com
The Freedom Group: www.freedomgroup.com
The Giga Group: www.gigaweb.com
HP: www.hp.com
IBM Websphere: www.ibm.com
Instec: www.instec-corp.com
The Meta Group: www.metagroup.com
Microsoft .Net: www.microsoft.com/net
Oracle 9i: www.oracle.com
Solcorp: www.solcorp.com
Sun ONE: www.sun.com/software/sunone
Tybio: www.tybio.com
Visibillity: www.visibillity.com