The analysts say it's a given. More than 65% of insurance companies in a study conducted more than two years ago by Gartner Inc., a Stamford, Conn., research firm, agreed that the general trend for IT architecture is toward a "services-oriented approach."Mark Gorman, research director with TowerGroup, a Needham, Mass.-based research firm, says its current research confirms that carriers are using some form of services-oriented architecture (SOA). "Carriers are more advanced in their knowledge of SOA," he says. "They're not just analyzing it any more."
It may be a known and desired commodity, but what insurers really know about its potential for success-and failure-remains to be seen.
Many organizations have already adopted Web services for applications that require linked communications. A more recent survey of top property/casualty and life/annuity insurance carriers revealed that 90% have adopted some form of Web services within their information technology architecture, and 58% of those have adopted the industry-specific ACORD XML standards as part of their Web services initiatives.
The survey, from SEEC Inc., a Pittsburgh-based provider of services-oriented business applications, also shows that carriers are looking to decrease IT costs through the adoption of Web services and ACORD XML. While IT cost reduction is a major benefit, however, the leading motivators appear to be enhancing agility and improving service. Survey respondents also expected improved ability to adapt systems, improved service delivery to agents and reduced application integration costs.
Some in the industry say expectations for improved service delivery and reduced integration costs are unrealistic, especially if not combined with the proper architecture.
"In many cases Web services are accessing wrapped or duplicated legacy code, not true services," points out Andy Labrot, chief technology officer, global operations, with U.K.-based Innovation Group. "True, the insurance industry has fully adopted the use of Web services to access their back-end legacy systems to support Web based applications. But just because Web services are being utilized does not mean that a company has implemented a [services-oriented architecture]. And in this regard the industry is still in the early stages of implementation."
The key difference, according to Labrot, is in SOA's ability to enable companies to consolidate processing platforms (e.g., policy and claims systems) over time and then retire non-strategic systems, thus reducing operating costs and simplifying maintenance.
"SOA is all about change," says Labrot. "Applications based on SOA are not constructed like typical applications. SOA requires IT to be organized in a non-traditional manner. SOA requires solid configuration management. In short, if an insurance organization is not prepared for the change that SOA brings, it will encounter severe difficulty."
Need for Distributed Computing
The industry seems familiar with change. Required as a result of mergers and acquisitions, increased product offerings and mandates-such as cost control, improved service levels, stakeholder and regulatory accountability, speed to market and competitive advantage-these changes have triggered the need for distributed computing.
Instead of just connecting systems, many insurance companies are looking at ways to extend their legacy systems and enable interoperability across heterogeneous applications-across departments, partners and customers.
In a siloed IT environment, where integration is already difficult, the answer lies in standardized architecture, and in that regard, SOA is gaining popularity quickly.
For Jim Lupton, vice president and director of systems management at Oklahoma City-based American Fidelity Assurance Co., building business applications that can exploit the company's core mainframe technology was reason enough to consider implementing SOA, which the company hopes to complete by July.
"We've been doing something similar to this for a while, but couldn't find a way to tie the pieces together and have a completely integrated solution without having to build our own system software," says Lupton. Adopting SOA meant the company would be able to use an enterprise service bus (ESB), open standards-based distributed synchronous or asynchronous messaging that provides secure interoperability between enterprise applications via XML, Web services interfaces and standardized rules-based routing of documents.
Working with longtime supplier Software AG, Reston, Va., the 45-year old family-owned carrier that provides insurance and financial services to education employees and trade association members already uses the vendor's legacy integration software and XML database and is currently installing and testing its Crossvision suite of tools. Ultimately, says Lupton, the goal is to use Software AG's toolset to deal with the myriad components contained in its many applications and provide a centralized location for users.
"We want our programmers, both internal and external, to access our site so they can request a particular service, which will explain to them how to do what they need to do," Lupton says. "Then they can write (software) to it and get the information they need from our Web site. We'll do that with partners, providers or whomever might require that functionality. Our HIPAA information system would be an example of that when the new technology is applied."
Starting from Scratch
Given the requirements of ICAT Managers LLC, a $140-million Boulder, Colo.-based company that provides catastrophe insurance to more than 60,000 buildings in 36 states, via the Web, a Web services/SOA-architected system was also a priority.
With three months remaining until the official start of the 2005 hurricane season, ICAT decided to replace its existing third-party claims administrator (TPA) and start from scratch by establishing its own TPA, Boulder Claims. Set up to administer claims emanating from ICAT's business as well as that of other insurance providers, Boulder Claims had a tall order to fill.
"In light of the ebb and flow of our business based on catastrophes, we require a distributed business model, and users need to be able to log in and work remotely in a primarily paperless environment," says Michael Dolbear, senior architect with MJD Software Ltd., Richmond, B.C., and consultant to ICAT.
After evaluating a few systems, Boulder Claims selected San Mateo, Calif.-based Guidewire Software's ClaimCenter. The three-month project included integration to ICAT's policy administration system and Oracle Financials.
"Guidewire has a certain set of required interfaces: policy administration and the ability to generate claim numbers," Dolbear notes. "We also required integration with Oracle financials. Those were three Web services that we needed from the get-go."
Jasmine Noel, partner with New York IT consultancy Ptak, Noel, & Associates, maintains that the notion of integration can cause confusion for insurance companies trying to sort out what they want in terms of SOA functionality.
"SOAs are not a new concept, what's new is the broad acceptance of Web services standards on which to base the implementation," she says. "Without these standards, insurance companies could find themselves in a tangled mess of integration spaghetti."
Many consider integration as one of the main sources of straightforward, short-term ROI, chiefly because of SOA's ability to obviate the middleware layer.
"Companies don't need more or better middleware to make their systems more agile," points out Baltimore-based Zapthink LLC analyst Jason Bloomberg. "Instead, they need to step back and think through how to leverage SOA through the power of metadata."
This, he believes, requires a sea change in thought. "It will be a difficult task to build loosely coupled services if you are thinking with an integration-centric mentality."
Bloomberg believes SOA replaces the integration-centric mentality with a services-centric mentality. "In this view of IT, services form the crux of the infrastructure," he says.
The notion that SOA and Web services enables insurers to componentize processes that they can reuse across systems and product lines points to the importance of creating and managing the metadata that these processes comprise.
David Vap, Software AG's vice president of sales and marketing business integration, notes that few insurance carriers fully grasp the importance of using data repositories to deal with metadata.
"Without a registry/repository to keep track of all the services and components that play a role in an SOA, you end up with anarchy," says Vap.
Analysts and vendors alike claim that insurance companies learning the realities of SOA implementation end up rethinking how they plan to compute. This restructuring often includes a well-thought-out plan-i.e., business process management (BPM).
"SOA and BPM are linked since both, to some degree, are focused on process support and improvement," notes Gartner's research vice president Kimberly Harris-Ferrante. "They have different approaches to how they attempt to help companies do this, (i.e., BPM by definition includes a lot of tools and technologies that do not require that insurers use services, such as workflow and imaging). But both can be key tools to help insurers improve business functionality across the company and from legacy environments."
Vap believes insurers who question whether BPM goes hand in hand with SOA should consider the analogy to enterprise resource planning (ERP). "ERP tells you: 'This is your process,'" says Vap. "This may work in an accounting scenario, but for SOA and Web services, you are not recoding core business processes, you're mapping to what the business wants-i.e., reconfigure versus recode. This places programmers at the bottom, architects in the middle and business analysts at the top. The business side decides the process, which means you must have an efficient BPM system in place."
Noel agrees. "SOA makes the connection between process design and process implementation an operational reality" she says.
ICAT may not have had a formal BPM program in place, but its three-month lead time to get Boulder Claims up and running on its SOA/Web services platform meant rethinking the company's processes based on the new architecture and creating efficiencies that could be applied across the enterprise.
"Our previous TPA tracked financial data and notes on a green screen, but not much about the claim itself," recalls Joan Zerkovich, ICAT's senior vice president, information technology. "It wasn't a question of using a formal BPM, but more a top-down view of how we could design services to enable us to paint a picture of the policy at the date of loss."
This informal approach to BPM enabled the company to create integrated policy data transfer services to accommodate all products lines, says Boulder Claims' Dolbear.
"Even with all the different varieties and permutations of policies, with all that complexity, Web services allows us to pull up a policy with all the endorsements and claims information, so that if someone calls in a Katrina claim a year from now, we'll be able to efficiently service the claim," he says.
ICAT's IT architect and manager Brian Scriber confirms that ICAT's common layer of architecture enables the company to share components that can be reused by different applications.
"The old model involved EDI transfer, files, pipes and a lot of approaches that caused us an industry to move to XML," reports Scriber. "Now we set up interfaces using a Web services description language (WSDL) specification, which provides a common method to describe services and the format for service requests, and as a result, it becomes an automated step."
Scriber confirms that ICAT also designs and builds its own applications. "We have our own policy administration database-a hub-between a lot of these different products we are running," he says. "The design was sliced that way. And using a WSDL, there is a piece that deals just with policy administration and a piece that deals with Guidewire's ClaimCenter, etc."
Case for Governance
The bulk of benefits inherent in this new way of computing carry with it uncertainty, and as companies such as American Fidelity and ICAT/Boulder Claims forge the SOA/Web services trail, control is top of mind.
"The greatest value can also be seen as the greatest liability," notes American Fidelity's Lupton. "The value is in the ability to deliver functionality to someone without our intervention. We can put a service up there, provide access to it, the service tells the programmer exactly how to write code against it, their system talks to ours, ours provides whatever they need, and they never have to call us. That's the biggest benefit. But when you change something, there is a good possibility you might break something. So you need to be able to track who is using it, and provide a messaging service so you can keep the lines of communication open when you make changes."
The philosophy at ICAT and Boulder Claims is one of "know thy architecture."
"It's all about people and architecture," says Zerkovich. "Business drivers may change, underwriting and policy administration changes may simultaneously occur, but if you keep them in synch, I don't consider this any more risk. In fact, I consider less risk than older platforms or ways of computing. You have to be clear about your architecture."
From the onset, the company has had an architect on board, along with routine communication of the rules of working within the architecture.
"We provide a framework and standards-the architect oversees all of this," adds Zerkovich.
TowerGroup's Gorman says that the insurance community is aware of SOA/Web services' value proposition and views governance as part-and-parcel of the commitment.
"The desire to move back-end functionality to the front and provide self-administration of policies, automated change capabilities and agent access to information is great enough that carriers are evaluating the control mechanisms that will enable them to do this safely," notes Gorman.
That piece of the value proposition may convince stragglers to adopt SOA/Web services, but ultimately, it may be the result of acknowledging the stark reality of rejecting it.
"Current systems cost far too much to modify and are very inflexible," says Innovation Group's Labrot. "New products can take up to a year to introduce, and rate changes can take as long as nine months. With SOA architecture, speed to market is enabled, giving insurers the ability to more quickly respond to market changes and demands while reducing total overall operating costs."
Register or login for access to this item and much more
All Digital Insurance content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access