Leading insurers will continue to be big consumers of enterprise integration as they strive to tie together legacy systems and a plethora of custom and packaged applications that span multiple platforms and languages.
Theres also the need to work through mergers and acquisitions–not to mention the goal of leveraging technology to improve the bottom line through initiatives such as customer relationship management.
It has become hard to talk about enterprise integration without mentioning Web services. But very few enterprises plan to move forward until more is known. However, there are good reasons why companies should not sit on the sidelines until the technology proves itself. For one, major vendors are investing heavily in the technology to drive the adoption of Web Services. More importantly, insurers who position themselves to move quickly when the time is right will have a strategic advantage over those who wait it out.
What follows is an introduction to Web services, as well as some prudent steps insurance IT leaders can take to prepare their organizations for emerging technology that will become a standard weapon in the effort to improve business speed, efficiency and financial performance.
Web services are self-contained units of business logic and data that can be assembled into applications. These loosely coupled software components are delivered over Internet-standard technologies, which makes them universally available.
Web Services are the cornerstone of a service-oriented architecture (SOA). SOAs allow developers to assemble systems from Web services published by internal or external providers, eliminating the need to build new applications from scratch. Services are accessed via standard protocols that are language-, platform-, and location-independent and managed through a central registry. This provides a streamlined way of integrating existing systems and adding new functionality.
Easier and faster integration, in turn, improves profitability. Insurers can use it to more quickly adapt to changes and seize growth opportunities.
SOAs are different from traditional enterprise application integration (EAI) solutions. EAI involves translating data from the format of one application into the format of another incompatible system. Most EAI solutions implement message-based architectures that rely on proprietary protocols and adapters in order to do this. Most also provide business process management tools, which are just emerging in the world of Web services.
Web services have gained a lot of attention, primarily because the underlying technologies are based on industry-standard protocols like XML and HTTP. As such, the technology promises to address interoperability requirements that prevented similar concepts from firmly taking hold years ago. Standardization also allows for cross-vendor compatibility and provides a forum for open-market tools and products.
Apprehension over Web services persists, however, because the debate continues over which standards will prevail. Critical standards for infrastructure services, such as data integrity and systems management, are also yet to be defined. In addition, theres concern over how long it will take for standards to mature and which will fit the bill when they do.
Regardless of these factors, however, the tremendous vendor support for the technology cannot be ignored. The fact that a number of prominent vendors are fully committed to Web services speaks volumes about its staying power. Vendors large and small have also introduced tools and architectures that make developing, deploying, and managing Web services-based solutions easier. Additionally, multiple vendors have already filled some standardization gaps.
The best way to get a handle on how the technology can deliver tangible business value is through a proof of concept (POC). This also allows carriers to get a jump on the competition with minimal risk. Here are some things that will help companies deploy successful Web services POCs:
Get focused: Tie the POC to an actual business problem. IT leaders need to focus on a host of issues, such as how a SOA will be managed, where Web services fit with existing and planned technology, and process evaluation. Together, IT and business leaders should build a solution that supports both IT and business requirements.
Work in parallel: The IT group can proceed while business issues are debated. Business and IT will join when the time is right. In fact, progress on the POC will answer many business issues and vice versa.
Develop incrementally: The POC is a learning exercise. As such, its important not to over-architect the POC to solve grandiose business problems. Instead, start with a relatively simple service and move forward in short iterations. More functionality can be added later. This minimizes cost and allows insurers to build on knowledge gained.
Make it real: The POC should touch on enough systems and applications to allow for meaningful feedback.
Follow the beaten path: Stick to standard Web services platforms and development and management tools. Theres no need to reinvent the wheel. The primary cost will be measured in time and talent.
Query vendors: A POC identifies specific problems and opportunities. From there, ask vendors to demonstrate how their offerings suit your particular needs as a way to separate fact from fiction.
Deploy specialized skill sets: Dont confuse a SOA with custom application development. The two differ, which makes it necessary to tap into experienced integration expertise.
Given these guidelines, lets assume a large carrier with multiple business units and a wide range of products/services wants to streamline business processes, improve responsiveness and raise customer service for claims-related operations.
To get there, the company might start with a POC–a first notice of loss (FNOL) Web service, for example. Such a Web service would enable business units inside the corporate firewall to more efficiently access data on initial claims notifications. Customer service representatives might be the first users.
This application would make it much easier for representatives to submit FNOLs because the application is exposed as a Web service and communicated via the industry standard, XML messaging. The system will also be a much more valuable corporate asset because it enables other business units to easily leverage FNOL data.
After the POC satisfies the needs of internal users, it could be deployed outside the firewall for agents and even policyholders. There are also products now on the market that can help test the true value of a Web services POC.
Say, for example, a series of earthquakes strikes the California coast. The carrier might use such a product to monitor all FNOL activity within that region to assess potential liability and business impact. Based on the results, it might decide to deploy claims service representatives from other parts of the country to better service customers.
A POC allows insurers to learn what they dont know. Of course, that makes it difficult to say how long it will take to complete the POC. The answer will reveal itself over time. (Therefore, iterate, so you can stop at any time.) Nonetheless, a POC allows carriers to chart a course for success before Web services become the standard. In the meantime, those who delay will be left looking for a map.
Bob Hunter is director, Insurance Practice, and Gregor Hohpe is senior architect for Thoughtworks, based in Chicago.
Reproduced from National Underwriter Life & Health/Financial Services Edition, July 22, 2002. Copyright 2002 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.