Newsletter Sign-up

These days, you can't set foot into an information-technology department without hearing the expression "services-oriented architecture." Companies that change their technical infrastructure to follow this model are headed to the Promised Land of double-digit returns on IT spending and much lower costs, so proponents argue.

Tower Group Inc. analyst Mark Gorman, for example, says that carriers that fail to adopt this architecture will find themselves in danger of lagging behind their peers. "People that are doing this are going to emerge with it and are going to transform," he says. Laggards will find themselves in danger of playing catch-up--forever.

The more skeptical among the insurance IT community, some of whom point to the failure of the client-server model of a decade ago, maintain that a services-oriented architecture is not easy to implement, and that companies risk spending big for just another industry fad.

A services-oriented architecture, these skeptics say, is just a retread of shopworn ideas that have swept through the industry over the past 20 years. "The business side is wary of services-oriented architecture," says consultant John Hagel III, a former principal with McKinsey & Co., who delivered the keynote address at the annual meeting of the Association for Cooperative Operations Research and Development. "They've seen the hype before. They have a strong allergic reaction to architectures."

For experts like Richard Vlasimsky, chief technology officer of Valen Technologies Inc., services-oriented architecture is old news. "My view on that is what we used to call mainframe-hosted," he says. "Then it was client server, then it was Web services and HTML."

But Gorman rejects these arguments. He says that when it comes to a services-oriented architecture, the myth that a new technology approach rears its head every three to five years is not true.

No one is arguing that implementing a services-oriented model is cheap, or easy, or even all that new. David Peterson of Insurity says the idea of component-based architectures has "been around a long time."

"Many carriers are at level one, when in fact they need to be at level three to be able to do it," adds Paul H. McDonnell, senior vice president and insurance segment leader with Bearing Point.

Such projects, which can take five years or more, can end up costing in the tens of millions of dollars. One glimpse at a flow chart summarizing the promise of enterprisewide integration that a successful services-oriented model can deliver is enough to have you lunge for your bifocals.

Still, some top-tier insurers are giving it a try. Carriers doing "interesting things around SOA," says McDonnell, include MetLife, Aflac, Fireman's Fund and American International Group Inc. In the United Kingdom, Standard Life is using a services-oriented approach, says Norbert Dick, general manager in the insurance industry practice with IBM Deutschland.

Some Japanese carriers have also shown interest as they, too, are interested in broadening their distribution channels. "Globalization is a force that will move the industry toward SOA," he says.

Carriers on the leading edge are doing so in stealth mode, says Gorman, which is perhaps an indication of how much top executives believe a functional services-oriented architecture can add to their bottom lines.

Without doubt, carriers are treating their service-oriented architecture experiments as a state secret, and are ramming these projects through the corporate bureaucracies at warp speed.

"The leaders are moving fast on this," says Gorman. "The big guys are moving on this and not telling anyone about it."

Yet even then, these huge companies aren't gambling vast sums, relatively speaking, on this infrastructure model. They are experimenting with services-oriented architectures only in far-flung pockets of their organizations.

That shows a certain reticence to adopt the services-oriented architecture model wholesale, at least for the moment, and underscores the difficulty of implementing a successful services-oriented architecture.

In the real world of tight budgets, hard-to-find technical talent, changing priorities in the C-suite, a laser-like silo approach to doing business and the slow pace of adopting data communications standards, developing a broad-based, modular strategy for a company's technical infrastructure is a promise easier made than kept.

"Companies are developing SOA in pockets because, throughout the enterprise, talent varies, and different parts of the organization rarely stick to the same plan over long periods of time," says McDonnell. "Insurance companies are often tactical in nature, while SOA is a five-year journey. It's a matter of establishing governance, it's a matter of getting projects approved."

Even agreeing on what it means to implement a services-oriented architecture makes one wonder just how much traction this model can generate in the marketplace.

For starters, defining SOA appears to be a fairly discretionary exercise.

Gorman says IBM Corp. defines a services-oriented architecture as follows: "SOA is an application framework that makes it easy to reuse and combine the discrete business processes and services that make up your business."

Sun Microsystems Inc. thinks of SOA as "a design paradigm based on a loosely coupled collection of reusable services."

For its part, BEA Systems Inc. believes that "SOA is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable standards-based services that can be combined and reused quickly."

"It's a buzzword," says Buddy Blair, IT development manager for ImageRight. "Like most things, it gets a lot of ground because somebody decides to call it that."

But at least there's a thread in the definitions used by IBM, Sun and BEA Systems: A services-oriented architecture is one that can be combined and reused, in other words, an architecture built around a modular approach to an IT infrastructure.

"SOA is not a product or vendor," says Brian Kane, director, solutions architect, for Travelers. "It's an approach."

Yet even he will admit that building such an architecture is "an evolutionary process," in which the maturity phase will dawn only after the corporation follows a series of other "baby" steps.

Kane says that part of Travelers' goal of working toward an architected approach to its IT strategy is to develop an "integration competency center," built around a quality control process developed by Sun Microsystems.

For now, though, carriers like Travelers, venturing into the open, modular approach to IT infrastructure, are the exception. The history of insurance carriers, at least the legacy institutions who've built warehouses out of 50 years' worth of data running on COBOL-based mainframes, reveals that these carriers are not easily sold on the value of open architecture.

Shifting course to steer toward a services-oriented world is "not easy stuff," says Hagel, but it's vital if the IT department and the business side of the house are going to move the company forward as one, which they will have to do as companies find themselves under more and more pressure to be profitable.

Financial pressures will force carriers to make a choice, says Hagel. Carriers that stall will lag behind their newer, more aggressive rivals. Those that go forward will survive, and perhaps even thrive.

"SOA is not an excuse for rearchitecting," says Gorman. "It's an opportunity to evolve to a new state."

CYRIL TUOHY is managing editor of Risk & Insurance®.

September 15, 2006

Copyright 2006© LRP Publications