Insurance company IT people began kicking around the phrase "service-oriented architecture" at least four or five years ago. For short, some call it by the two-syllable name "soa," while others prefer to spell out the letters "S-O-A."However it's pronounced, SOA refers to a way of thinking nearly as old as computing itself and bound to remain relevant far into the future. It's all about creating services that save time and money because applications developers can re-use them-often on mainframes.
As with so many IT concepts, the term SOA has many meanings and is often defined to fit the needs of a product someone is trying to sell, says Stephen Korow, vice president of technology at Decision Research Corp., a Honolulu-based software vendor.
Sometimes definitions vary among the business units of a single company, says Archie Roboostoff, director of product management at NetManage Inc., a Cupertino, Calif.-based software supplier.
A CTO at a carrier that will remain unnamed here calls SOA "formalized common sense," according to Mark Gorman, associate director in the Insurance practice at TowerGroup, a Needham, Mass.-based research company.
That CTO describes SOA as a natural outgrowth of activities under way for decades, including object-oriented software development, componentized functions and disaggregation, says Gorman. "Those issues have merged and evolved to the point we've put a name on it," he says. "We've called it SOA."
For the insurance industry SOA means more than services, Gorman says. People with a SOA mindset value the mainframe computer and the intellectual property built up on mainframes over the years as a valuable asset, a critical component of services-oriented architecture and a vital part of the technology stack.
Still, some of the code on older mainframes needs fixing, cautions Chuck Johnston, product marketing senior director for Redwood Shores, Calif.-based Oracle Corp. "Be careful you don't paint over rotten wood," he says.
And while useful, SOA can't banish every woe. Carriers should introduce SOA gradually, using it in projects where it makes sense and avoiding it in projects where it serves no purpose, advises Hans Brunner, GBS solutions manager for Armonk, N.Y.-based IBM Global Business Services. In the wrong place, SOA consumes money needlessly and can slow some processes, he says.
How much money? "If you look at the cost to get existing solutions to interoperate, it's very expensive," says John Burke, vice president for insurance at Waldorf, Germany-based SAP. "An adapter on a point-to-point could be anywhere from $10,000 to a million dollars."
What's more, keeping SOA in mind when it's not in use requires an awfully good memory, so New York-based Metropolitan Life Insurance Co. has found a way to institutionalize the mind set, says Stephen Kessler, MetLife vice president of application development.
The SOA consciousness for his part of the MetLife IT universe resides in a team of about a dozen IT people that includes service developers, analysts and project managers. The team specializes in building services and making technologies talk to each other, as Kessler puts it.
Most developers do that kind of work only once a year or so. Because the SOA team does it every day, they're quick and efficient at mixing and matching pieces of the services already in the toolbox, Kessler says. They know what's there and how to use it. "They don't start with a blank piece of paper" when they start a project, he says of the team.
Team members also serve as SOA evangelists, presenting SOA road shows at MetLife IT meetings and prowling the company IT scene to see where SOA can benefit projects about to get under way or in an early stage.
Reminding IT people of SOA early in a project means a lot, Kessler says. If a job has progressed too far, developers may fear that going back and introducing SOA could make them miss the deadline.
That can happen even though MetLife has an IT "building permit" process. As IT projects progress there, the development team has to obtain and renew building permits-just as though they were constructing a house.
Kessler pursues the metaphor, saying that "if you're building a house and you don't find out what the electrical standards are until the inspector is there telling you, 'You did it wrong,' you're not going to have that house delivered when you thought you would." The same goes for SOA, he says.
But errors with SOA aren't limited to forgetting to include it. Overdoing SOA-using it where it's not needed-can cause problems, warns William Awad, vice president of enterprise architecture for The Travelers Cos. Inc., St. Paul, Minn.
"There are clear fundamentals that have to always be in place regardless of the technology you're looking at, whether it is SOA or something else," says Awad.
One way of keeping SOA in perspective is to work closely with the business side to ensure that IT is not building services for their own sake, says Awad. Putting business first is a goal deeply engrained in the Travelers culture, he notes.
At companies where the link between IT and business has yet to evolve to that higher state, a three-step SOA process has emerged, says the TowerGroup's Gorman. First, companies use SOA in maintenance projects, moving next to operational work and finally to strategic projects, he says.
Using SOA for maintenance doesn't require cooperation with the business side of the company and can produce the relatively easy, relatively quick victories that an IT department needs to begin establishing a SOA culture, says Gorman. As an example of a SOA maintenance project, he cites a carrier that created a consistent interface for name and address changes across the organization. Before, the company had 15 applications for that job.
However, maintenance doesn't provide the big victories that reveal the true promise of SOA, Gorman warns. As carriers become more comfortable with SOA they can begin to use it from an operational standpoint, he says. In one example, a carrier wanted to use analytic models as scorecards but lacked the methodology in its normal operating systems. The company engaged a vendor to help set up a service for new business quotes and new business underwriting.
"Then we're seeing organizations that are talking about strategic, competitive advantage through services and the abilities that services offer," Gorman says of the third level of the progression, "to increase visibility and transparency and to better interact with external providers, clients and service organizations."
The progression emerged in leading-edge carrier IT departments and is emulated by other insurance companies, Gorman observes. As with the three levels of the SOA progression, Gorman sees three levels of SOA readiness at carriers.
The few companies at the highest level understand and embrace SOA and already are moving forward. At the second level, the largest group, carriers understand the potential of SOA but are still wondering how they can get started or how they can succeed. Carriers in the third group understand SOA but find themselves too busy with other issues to start down the SOA path. Gorman says his research will soon reveal the size of each group.
Even at companies that Gorman considers top tier, like MetLife and Travelers, trepidation and skepticism still cloud the SOA horizon.
Carriers need to avoid introducing a SOA process that takes a second and a half into the midst of a batch process with a hundred thousand records "screaming through the programming in milliseconds," cautions MetLife's Kessler. That kind of error can produce a crippling slowdown.
And even though MetLife has made valiant strides toward realizing the potential of SOA, Kessler feels the company has not gone all the way. What MetLife has, he says, is "a lot of smart people with comprehensive knowledge of what [components] are in the environment and what's re-usable."
What the company has yet to achieve is "the textbook SOA, where people publish services and other people go out and find them and consume them without talking to each other," Kessler says.
One barrier to the SOA ideal comes from vendors who refuse to embrace standards, Kessler says. "If they do things in a proprietary way, they cement their value proposition," he says of vendors. "By fully supporting standards and making their environments standards-enabled, they're commoditizing their product."
If SOA software becomes undifferentiated, carriers would have little incentive to buy a particular product, other than price or perhaps service. "There's no reason to pick them," Kessler says of suppliers in that kind of market. "You could use anybody's," he says. "They don't have a way to lock you in."
Even in a less-than-perfect world, SOA holds great promise for the carriers who figure out how to use it effectively. MetLife has worked long and hard since 1999 to realize the potential.
"Part of it's education"-teaching developers and the business side to keep services in mind without over-using them, Kessler says of the company's work on SOA. "Part of it is getting the program up and running and letting it mature," he continues.
"Those first few years we had more of the hard conversations than the easy conversations," says Kessler. "You have to get the message out and you have to show some wins."
TO MANAGE RISK, ADD GOVERNANCE TO ERM EQUATION
Insurers should integrate corporate governance and enterprise risk management (ERM), while bringing both under strict oversight by corporate boards, according to The Conference Board Inc.
Only when executives cease to view corporate governance as a regulatory burden can they understand its value to risk management, says Matteo Tonello, author of the Conference Board study "Emerging Governance Practices in Enterprise Risk Management."
The report says companies can reduce costs by developing synergies among business units and departments to aggregate risks, thereby increasing the accuracy of quantification and helping to create risk response strategies.
Using the report, companies can minimize risk exposure by identifying interdependencies among unnoticed risks.
Through emphasis on overall risk appetite-an objective basis for resource allocation-companies can improve capital efficiency and return on equity, the report says.
To stabilize earnings and reduce stock-price volatility, carriers can use hedging techniques to reduce unanticipated earnings fluctuations, the report advises.
Tools to make profitable, risk-adjusted investment decisions can improve transparency, thus reducing regulatory scrutiny, litigation expenses, costs of access to equity capital and the rate of return on incurred debt, the study says.
