“We're seeing clear movement and progress toward a service-centric [IT] portfolio that allows insurers to focus on the most effective way to deal with functional and business requirements,” says Mark Gorman, strategic advisor for TowerGroup's insurance practice.

Gorman maintains this work is critical to meeting the evolving demands of the insurance industry. “Insurers are looking to make 'opportunity investments' [in SOA technology] that increase the speed at which they can bring new products to market,” he adds. “We're also seeing an orientation toward 'innovation investment,' where companies try to identify and leverage SOA as a disruptive technology that can revolutionize the business and give them a clear competitive advantage.”

SOA: 2007

The concepts of component-based design that underlie SOA aren't new. “It's only now that SOA is really practical,” claims Ronald Schmelzer, senior analyst and founder at ZapThink, an advisory firm focused on SOA. Yet even with its history, SOA often is surrounded by confusion regarding what the term actually means, particularly since explanations tend to be couched in tech-speak.

To clear the confusion, let's start with the definition from the SOA reference model that information standards group OASIS released in August 2006: “Service-oriented architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

Once you get past the inclusion of the overused word paradigm, this definition actually is quite useful. The key word is “capabilities.” SOA is a method of getting things done using whatever capabilities you have, wherever those capabilities reside, and in whatever fashion those capabilities can be organized or combined in ways that deliver the maximum benefit to the enterprise.

The journey to SOA therefore starts by changing your thinking from how to build systems to how to get business done most effectively. “People want to jump right into WSDLs, XML SOAP, and Web services” when planning an SOA, says Michael Kronenwetter, vice president of technology management at Pennsylvania-based health insurer Highmark. “Instead, you should be discussing your business goals, your process methodology, and your corporate culture.”

This is particularly important because SOA is not limited to a particular technological approach. “When we surveyed carriers, we had the initial hypothesis they were moving from the mainframe to Web services” in their SOA projects, Gorman says. “But [they all] said no; they were going to leverage what they had in place by surrounding [legacy code], externalizing functionality, and reusing systems wherever they could.”

“Companies have been able to build SOA right on top of their mainframe environment if they so choose, and the technology we use today will be different from what we will use five years from now,” says Schmelzer. “The key to SOA is the 'A.'”

HAVING A PLAN

The build-out of SOA is going on feverishly in the insurance industry, reports Gorman. “Most of it is going on well under the radar,” he says. “The thought leaders are focused on it, but most aren't talking publicly about it.”

Highmark formally began its SOA initiative in 2004, which arose from a strategic information systems plan. As Highmark worked to move forward with an SOA framework and methodology, the company discovered it first needed to take a step back.

“As we started to talk to our information systems areas about getting to an SOA capability, we realized we hadn't thought out how to translate our business processes themselves to the component level,” Kronenwetter recalls.

For the next two years after completing the strategic plan, Highmark staff members worked on several parallel tracks related to the SOA effort. They began to develop the technical understanding of SOA and an SOA methodology in IT; they determined what systems should be refreshed, rebuilt, or acquired; and they used IBM's WebSphere Business Modeler to optimize process design. “We've already seen the process-modeling activities bring business and IT closer,” Kronenwetter says.

Prior to working on its formal SOA plan, Highmark already had developed a number of XML-based services–which Kronenwetter terms “generation 1″ components–such as an insurance coverage verification service the company currently extends to medical providers. What Highmark didn't have was a good way to locate and manage those components for effective reuse and speed of deployment. Therefore, the company deployed Logic Library's Logidex registry/repository system, which today manages all the components that exist in its environment.

The next step in Highmark's SOA development will be to deploy an enterprise service bus and a process choreography engine, using BPEL output from WebSphere Business Modeler.

“We left the technology piece until last,” Kronenwetter summarizes. “We looked first at how we were going to drive our SOA from the business down through process modeling, then from the bottom up through technology enablement. This year, we are beginning to roll that methodology out through some pilot projects.” The largest SOA-related project on its slate is a rearchitecting of Highmark's claims administration system, which the company expects will take several years.

INCREMENTAL GAINS

While Kronenwetter indicates Highmark is not in the “value realization” stage of its SOA efforts, he stresses the company has seen benefits from its work with SOA technologies to date.

“Just by using 'generation 1' services specifications and capabilities, we've realized a fairly significant value in getting changes to market quicker. Particularly in the last year and a half, we've also been able to derive value from the reuse of components and by being able to deploy standards-based components to new processes more quickly,” says Kronenwetter. “The next step this year is to take those specifications and determine how to make those services more extensible using WSDL, SOAP, and Web services standards.”

Highmark's approach mirrors the trend in the rest of the industry. According to an Aberdeen Group study from 2006, most companies committed to SOA are building composite applications to deliver value to line-of-business units while the SOA is concurrently under development. In that study, 52 percent of respondents said the need for faster implementation was a driver for the development of those applications.

Among the many speed-to-market benefits being targeted by insurers, bringing new capabilities to the distribution channel tops the list. “Insurers are trying to interface better with external partners, suppliers, and agents, even more so than using [SOA] to create a type of infrastructure that can drive products to market faster,” Gorman says.

That has been the philosophy of Swiss Re, which is looking to grow its book of commercial lines P&C business in the numerous specialty markets it targets. “We do want to bring products to market faster that are more relevant to customers, but what we're also trying to do is increase the efficiency of the distribution channel to allow [agents] to produce more business with less administrative effort,” says Michael Rubin, senior vice president of technology in Swiss Re's commercial insurance business.

Swiss Re also wants to facilitate cross-selling of products by agents, but complicating the effort is the host of different quoting and policy administration systems the insurer runs that support its niche-focused underwriting strategy. Additionally, having just completed a five-year replatforming project, modification of those systems was out of the question. “We like what's in our existing platform,” Rubin explains. “We have strong controls and good transparency, but those systems don't have the simplicity of use we want for our agents.”

In its e-Submit project, Swiss Re used Insurity's Studio toolkit to put a Web-services wrapper around quote and underwriting systems to expose them to agents via its agent portal and to make those systems accessible for future services connections. The first systems targeted, supporting professional liability, were scheduled at press time to be online by the end of January.

Creating standardized integration to these systems also has enabled Swiss Re to change the nature of the development process. “In the past, when we launched a new front-office system, we used to have an equal front- and back-office team. Now, the links already are there to the back-office systems, and we can focus instead on creating the front-office systems knowing everything downstream is in place,” Rubin says.

As a result, the first e-Submit deliverable was completed in eight weeks but would have taken six months in a non-SOA approach, Rubin reports. He expects the speed of future deployments to increase similarly by orders of magnitude over traditional development approaches by reusing services and leveraging nonsequential development methodologies.

SOA AND BPM

Speed to market is an important objective of reusing and combining services within SOA to create new systems and support new products and processes. However, speed without control leads to chaos.

“Agility is great, but the concern is you can create something that is nonfunctional,” says Miko Matsumura, who is chair of the SOA Adoption Blueprints Technical Committee at OASIS and vice president of SOA products at integration vendor WebMethods. “For instance, you could create an insurance package that actually is economically nonviable for business reasons or had some regulatory problems. Making sure agility fits within the realm of constraint is a key success factor.”

Therefore, business process management (BPM) is a concept that should be connected to the SOA effort. BPM starts with the process-modeling activities described earlier and culminates with the systems put in place to orchestrate and govern both business and IT development processes.

Within BPM, rules engines give carriers the ability to automate the constraint mechanism rather than slowing down the development process for manual review. Matsumura illustrates the relationship with an anatomical analogy: The architecture is a “skeleton” that provides the structure, and the business rules are the ligaments and tendons that coordinate activities. “Power in a coordinated fashion is what really defines agility,” he says.

Rules engines are a staple of automated decision systems in use at many insurers, such as in underwriting and claims fraud, as well as in business workflow and task routing. Now, carriers also are looking to extend rules engines into the development process.

For instance, HealthMarkets, which is in the process of formalizing its SOA, is looking to its Business Rules Management System from Haley Rules to play an important role in that development.

HealthMarkets began using Haley Rules in 2002 in connection with a quotation system for agents, called Digiquote, in order to ensure agents were issuing quotes in compliance with state mandates, licensing restrictions, and company-specific objectives. By separating the business logic for this control from the quotation system, the Haley system already allows HealthMarkets to make changes and create new rules quickly in response to regulatory mandates or new product development.

“We can make business rule changes within minutes that used to take a change management process,” says Chris Robison, vice president of IT for the Agency Marketing Group at HealthMarkets.

The Haley system gives HealthMarkets a shared business rule repository that will reduce duplicate business logic throughout multiple applications. “Utilizing a business rules engine has changed my outlook on architecture,” Robison says. “A few years ago, we used to adhere to pure object-oriented development, and every object would have to know how to talk to every other object. Today, we are building adapters as bridges that can translate a rules engine product into a rating engine product, and that way you completely 'black-box' your SOA services or all your system components.”

COSTS AND BENEFITS

If a carrier truly envisions SOA as a way to meet its speed-to-market and other business objectives, SOA needs to be business driven. “You need to understand what it is you want from SOA, what the method is you will use to get you there, and then get all the constituencies on board with that vision,” Kronenwetter says.

“When we started our research, we thought we'd find SOA was 70 percent technology and 30 percent business. Instead, it was the opposite,” Gorman maintains. “Insurers were most successful when senior business and IT leaders worked together to establish a strategy that the company would work toward SOA wherever possible.”

Getting business first to understand and then support SOA is critical because building services to be reusable typically carries a greater upfront cost. “This has been one of the biggest inhibitors to the adoption,” Andrews says.

For instance, if the development of a reusable service costs more upfront, can the increased cost be justified, and what department's budget should be tagged with the difference? Or if one department pays to develop a service that is later used by another, should the second department reimburse the first?

“Solving the challenges of implementing technology are not easy, but they are easier than the challenges of changing business models and business mindset–getting the organization to transcend its line-of-business focus and to take an enterprise view of its IT assets,” Gorman asserts.

A long-term view is critical. “Once the initial set of services is in place, the benefits of being able to modify and change components and systems more quickly as the business process changes significantly improve,” Andrews says.

He also points out companies are becoming more adept at SOA development. For instance, Evans Data found upward of 40 percent of developers working with SOA report being able to complete a typical SOA development within three months–more than twice as many as reported being able to do that a year ago. Over the last two years, the total number of companies with more than 40 Web services in production has doubled, according to the Evans Data study.

“Companies have gained greater experience in how to implement [services], plus there are more tools and frameworks available now to assist in the development and deployment,” which will impact the cost problem positively, Andrews says.

Carriers committed to SOA believe that speed-to-market benefits outweigh any increased costs. In fact, Gorman argues the industry's movement toward SOA is inexorable. “The thought leaders and market leaders are focused on defining a business architecture that can be the basis of both the technology services and the technological architecture that should be built,” he says. “The motto among SOA leaders in the industry today is, 'Think big,' even if they start small.” TD