Service-oriented architecture is today perhaps the most widely used, yet widely misunderstood structure for insurance industry computer systems.

While definitions may vary (see the sidebar with this article), most experts agree SOA allows discrete business functions from various sources to be modularized and distributed as services via the Internet.

The insurance industry has, over the past four years or so, bought heavily into this concept in terms of quicker software development and a host of efficiencies that promise lower costs. The question now is how well SOA has delivered on the hype that has accompanied it.

"While it's not as sexy as some of the loftier SOA hype, Web services and SOA in insurance have contributed mainly as a form of better 'plumbing,'" said Jeff Goldberg, senior analyst at Boston-based Celent.

"Essentially, SOA has been a set of technologies and practices for more efficient sharing of data and transactional capabilities between systems, both internal and external, in a reusable way, allowing the value of systems investments to be leveraged repeatedly in subsequent initiatives," he explained. "While this may not sound like an enterprise-redefining technology, it's key to the [chief information officer's] mission of doing more with less, and it's a foundational change that will pave the way for future flexibility and efficiency."

Mr. Goldberg cited a Celent survey of information technology leaders across the industry finding that most business leaders are "somewhat aware" of SOA, "but few, if any, are pressuring IT to invest in the technology. Without such pressure, IT organizations have been able to adopt a reasoned approach to SOA, with an incremental implementation over time."

He added that "while there are surely some examples of insurers attempting larger-scale SOA initiatives without clear business goals, most companies have chosen to take their investments slowly rather than jump at the hype."

Celent research shows that the primary benefit of SOA thus far has been the reduction of integration burdens between internal systems, he added.

"The biggest challenge has been the explanation of SOA value to the business side," said Mr. Goldberg. "Web services and service-oriented architecture are deeper technology topics than most insurance IT investments, and the reality is that there is an up-front cost that does not start providing value until more and more SOA-enabled systems are built or licensed."

Celent recommends that IT leaders frame SOA in terms of a simple, project-by-project return-on-investment, with initial investments quickly paying off as new systems can be integrated into an infrastructure with lower costs.

"A second challenge has been the different definitions of SOA used throughout the industry, ranging from some insurers considering any system that communicates via XML to be service-oriented architecture, to those who adopt very strict definitions about service brokers and business process structures," he observed. "This varying definition makes it hard to get a true measure of SOA adoption throughout the industry, but also complicates even further the ability to communicate the value to the business."

The future of SOA in the insurance industry "is not just flexibility and efficiency," he concluded, "but also the ability to take the distributed servers and software built up or licensed in the data center and make them operate as one integrated business system."

Matt Josefowicz, director of insurance for New York-based Novarica, noted that SOA has been "an effective systems integration tool for many insurers. While few insurers have achieved some kind of SOA-induced architectural nirvana where the entire architecture is componentized and services-based, our research indicates that 30-to-50 percent efficiency gains in systems integration projects are not uncommon results of SOA investments."

He added that "by and large, insurers are not trendy in their IT strategies, and SOA is no exception. SOA has been embraced because it offers real business value."

Mr. Josefowicz agreed with Mr. Goldberg that the biggest challenge related to SOA is often "communicating the business value of this very abstract architectural concept to business sponsors. Insurance IT leaders need to communicate the improvements in project speed and reductions in cost that SOA can lead to. And they need to quantify those benefits and then deliver them and communicate that they were delivered."

Offering a contrary view, Judy Johnson, principal solutions architect of insurance for the Jersey City, N.J.-based Patni Computer Systems, asserted that "while it's true SOA is an architectural concept that requires an enterprise vision and/or strategy, most insurance companies, unless they are small, don't act as an enterprise or have business strategies and tactics as an enterprise. They operate within functional or line-of-business silos, which is how we all got here in the first place."

Ms. Johnson said that over the past five years, "SOA initiatives have given steady employment to many internal IT professionals as well as external consultants and systems integrators. They have provided a lot of fodder for the insurance trade press and opportunities for insurance company CIOs to get their names in print,and maybe win awards or accolades potentially leading to promotion."

Bottom line, however, "SOA initiatives have cost insurers a lot of money while providing minimal opportunities at present to determine what hard business value was received beyond 'gut feel' and anecdotal commentary," she said. "SOA has given industry senior management another reason to hope they will eventually be freed from the tyranny of their legacy systems and processes without too much pain."

Insurers have adopted SOA, said Ms. Johnson, "mainly as a means to hopefully integrate and modernize their legacy application portfolio. And yes, it is always a little bit about adopting technology trends–something insurers tend to do in the hope they will either maintain or improve their competitive position in the industry."

She said insurers are "always looking over their collective shoulder to see if somebody else from the industry, or even from financial services, is trying to steal a march on them to take customers or customer wallet share by being easier to do business with."

According to Ms. Johnson, insurance company IT departments have latched onto SOA "because they don't want their resumes to be outmoded in the event they wish to or need to change employers. Nearly everybody wants to be on the cutting edge, technology-wise, and while individual SOA projects may be completed in six months or so, the overall SOA effort itself will last long enough to make understanding the hard business benefits difficult at best."

Having said that, she added, "to the extent SOA efforts can aid in legacy systems and data integration, this is a real benefit."

Ms. Johnson said that "obviously, one of the challenges to SOA near term is the global financial crisis, which is generating significant activity around cost-cutting, shaving IT budgets, causing projects to be canceled or stalled, and generating more focus around ROI for initiatives that continue."

However, she concluded, there are multiple SOA opportunities "for organizations that undertake to develop a common business and IT strategy and vision and a common plan for IT execution."

Such opportunities, she explained, involve "rationalizing and streamlining outmoded business processes, updating or replacing legacy systems, streamlining point-to-point systems integration, and bringing the various parts of the organization to a more informed and consistent way of doing business."

POSITIVE CONTRIBUTION

Andy Edwardson, vice president of information technology, FAMI (Farmers Alliance Mutual Insurance), based in McPherson, Kan., stated that for his company, "The contribution of SOA to [the] enterprise has been positive.

"Adopting an SOA approach to architecting business processes has given us the ability to quickly turn out results, he said. "We have not yet realized all the benefits of SOA, but we do continually find methods of improving core business processes by this virtue.

"We did not view SOA as a trend or something in which we must participate. We saw SOA as a method to help us create an environment based on standards and consistency. Our desire was to minimize the variety of technologies, platforms and methods of messaging to reduce complexity within the IT environment," he noted.

"We also felt the SOA model would provide agility to our business, in the sense that we could quickly assemble business services, which result in a business process," he said.

Asked about challenges involved, Mr. Edwardson noted that, "Wrapping our arms around the how, what and where to begin has been the most challenging aspect of our SOA implementation. We felt the concept was solid in theory, but we had no real practical application within the SOA model.

"We struggled for nearly a year trying to determine whether we dive in, not fully understanding the concept in practice, or wondering if we should try to find an organization that could help us bridge the gap," he noted. "Ultimately, we made the right choice and found a partner. In short, the biggest challenge was 'testing the water' to determine if it was a right fit for FAMI."

According to Mr. Edwardson, "The nature of SOA is a paradigm shift, which does not stick overnight, so you must allow your organization time. Most IT organizations will see the return almost immediately, but the challenge may be demonstrating that value in business terms.

"Another challenge is simply the realization of SOA within an organization," he continued. "Even though FAMI felt it sounded good in theory, we were somewhat overwhelmed." He suggested that those who are in a similar position begin with a small-scale project as a test case.

"Also, it's helpful to select a good business partner who clearly demonstrates their understanding of SOA, and to have them serve as a mentor for the project through its execution," he said.

"SOA will provide opportunities to a number of organizations in different ways," he added. "If you look at the insurance industry in total, many of us share a number of necessary requirements–requiring technology to accomplish such. Most often, those requirements involve external entities to our own core operations. Those shared requirements can, and I believe will become much less complex when the industry and external entities adopt an SOA approach."

LEGACY INTERFACE

According to Steve Elfanbaum, president of Asynchrony Solutions, based in St. Louis, "SOA, typically in the form of Web services, has provided a well-defined, standards-based interface for agents, brokers, third-party administrators and other partner/vendors into an organization's legacy insurance applications."

He noted that the need for data exchange with agents, brokers, TPAs and other vendors/partners has been evident for quite some time. SOA fulfilled this need through a standards-based interface, removing the requirement to support multiple point-to-point interfaces with these external groups.

"There are a myriad of challenges in SOA implementations, starting from basic misunderstanding of core terminology to organizational boundaries and policy disputes about data ownership, security and access control," he pointed out.

"SOA at its core is a series of enterprise integration patterns. Many organizations think they must buy SOA as opposed to adding capabilities to their existing infrastructure to become SOA-enabled," said Mr. Elfanbaum.

"The opportunities for SOA are the same as they were 20 years ago when we called it enterprise application integration," he observed. "If you look at a COBOL copybook of two decades ago and how that represented a standard interface into a business capability, it is, not surprisingly, very similar to the XML schema you might find today–hierarchical in nature and typically defining a discrete business capability.

"The biggest opportunity for the future of SOA is for its simplification, the opportunity to get back to the basics that all the fuss was over in the beginning," he added.

While most experts have a general idea what they mean by service-oriented architecture, many disagree on the particulars. Here's a simplified version:

o A "service," in this case, is a unit of work (collection of computer code) that has a specific function and purpose.

o This unit of work, once defined, can be re-used (and even modified) in a number of settings, thus it can be thought of as a multifaceted tool–maybe something like a Swiss Army knife. SOA, then, is a data architecture (structure) that provides such tools, which can operate across data platforms and standards.

Got that? Okay, there's a little bit more.

o Those SOA resources (tools) can be made available as independent services on a computer network. No knowledge of their underlying platforms is needed.

o Web services–Web-based computer programs that use open, XML-based standards and transport protocols to exchange data between computers–are a common industry standard method to support SOA.

NOT FOR REPRINT

© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.