Competitive differentiation in the insurance industry is like a sailboat race, according to Fred Matteson, CIO of Fireman's Fund Insurance Co. - in a given boat race, all the competitors will be in the same design class, meaning everybody has the same type of boat, the same sails and the same number of crew members. That being the case, he explains, "If you're behind someone, you're going to be behind them until the finish line unless you try something different. Tactical errors of your opponents aside, to get ahead, you're going to have to take a different tack."
That kind of thinking is behind Fireman's Fund's ($4.3 billion in premium revenue) wholehearted embrace of service-oriented architecture (SOA) in an effort to consolidate up to 70 percent of its technology applications with the goal of transforming its IT organization into a more efficient and more flexible operation. The initiative, in turn, will make Fireman's Fund into a more agent-friendly and more agile insurance company.
Earlier this year, Fireman's Fund signed a 10-year contract with IBM to assist the carrier in developing a service-oriented architecture. The carrier projects to spend between $94 million and $157 million over the course of the contract. But it expects a return on investment in excess of $200 million above what it spends. "And that's just the system's quantified benefits," Matteson notes. "It doesn't start to get into the business value."
The Novato, Calif.-based P&C carrier isn't alone when it comes to interest in SOA. There hardly is an insurer that has not experimented seriously with Web services technology, which enables the external exposure of application functionality through open standards and is the foundation of SOA. And many insurance companies have embarked on SOA initiatives to explore the architectural approach. But relatively few have put SOA at the center of their architectural vision as the means of technology transformation.
Reasons for Caution
The reasons that carriers have not fully committed to SOA are various, ranging from the relative maturity of some of the standards by which the technology operates, and the scant availability of vendor tools that facilitate the creation and organization of service components, to the difficulty of designing the services themselves and the limitations of existing skill sets within insurance IT organizations. One of the great leaps involved with moving to SOA is the approach's shift from a technology focus to a business focus.
Many of the technological concepts underpinning SOA have antecedents in earlier development concepts, such as object-oriented programming and component-based development. But SOA enables the construction of open-standard enterprise technology based on units of business functionality - the services themselves - intelligible to the people on the business side of the house - at least, in theory. In fact, the way SOA forces the business and technology organizations together in the design and implementation of technology leads many to see it as the means of effecting and even institutionalizing the business/technology alignment that insurers have found so elusive.
If SOA works, among the benefits it will confer are lower development costs through the ability to reuse common bits of functionality in multiple applications; greater ease of doing business by enabling more-direct and more-customized interaction with distributors and other business partners; and greater agility in response to changing market demands since SOA makes it possible to locate and assemble the component parts of new products and applications rather than having to buy new hard-coded solutions.
Matteson describes SOA as a means of remodeling the carrier's business in which business executives communicate to IT in terms of services that IT provides to construct the products and services the carrier offers to its customers and agents. "To me, that's the power of it - to finally get a technology representation of how the business actually works," Matteson says.
"There's a pretty compelling value proposition if you do it right," continues Matteson, who sees SOA as integral to the carrier's brand proposition. SOA can have a transformational effect on the way agents interact with the carrier, he believes. Traditionally, interaction with a multiline company meant laborious, piecemeal interaction with multiple disparate systems. Matteson's vision is of "a unified, single view of who Fireman's Fund is to our agents, and that view encompasses a number of business lines," he says.
SOA can help to build and sustain that vision, while enjoying unprecedented speed, flexibility and efficiency, Matteson asserts. "Business models change much more rapidly today, and being able to reuse and recombine services into different workflows will bring huge benefits," he says. By utilizing existing embedded functionality - by exposing it as services - SOA also enables carriers to leverage their investments in legacy systems with a minimum of disruption, he adds.
Not a Panacea
As a technology veteran, Matteson is quick to point out that he doesn't believe technology is a panacea. But, he opines, "This is the best example I've seen of being able to describe the business process in a way that allows us to build flexible technology. That alone, if you can align your business partners to get it going, is a huge opportunity to transform both the business and, frankly, what IT does for a living."
At other carriers, that opportunity could be undermined by the way the underlying technology is being adopted. While the insurance industry is one of the leading adopters of technology, the penetration of technology at the architecture level is shallow, argues Michael Liebow, vice president of Web services and SOA, IBM Global Services (Armonk, N.Y.).
Enthusiasm for open service-oriented technology exists among business and technology organizations, but application of that technology tends to be isolated, Liebow contends. At the lowest level, developers tinker with trial versions of service-oriented products; on a somewhat deeper stratum, line of business heads may seek to deploy Web service-based solutions to address operational pain points. Such experiments make sense in principle and can bring real benefit. "It's all good," Liebow allows, "but it's not SOA."
'A' Is for Architecture
And there's the rub. What distinguishes SOA from Web services initiatives is the "A"; disparate service-oriented efforts not only fall short of, but can serve to undermine, ultimate efforts to construct a service-oriented architecture, which provides a standardized way of communicating and exchanging information throughout the business and with external partners. Point solutions thus undertaken, Liebow cautions, "have value to the individual line of business, but over time, they will show decreasing return in terms of how you share information horizontally across the enterprise."
Liebow says that such projects sometimes are seen as a more viable alternative to big-bang efforts, but that is a misconception. What is important is that any efforts, whatever their magnitude, be subsumed within a master plan aiming at a standardized end state. "SOA is a massive undertaking, but no one is advocating a big bang," he comments. "If you're not thinking through iterative steps, the process is chaotic and fails to provide value back to the business."
One of the difficulties in selling SOA to the business is that the value will be a long time coming. Certainly, smaller efforts planned within an SOA governance framework can be valuable, but the benefits of the architecture itself may take years to realize. Thus, securing the support of leadership is crucial at the outset, according to Mark Cyphert, principal in Deloitte Consulting's (Chicago) insurance practice. "You need to stay the course to realize any benefit," he says.
Within the broader aim of enterprise technology standards, IT must maintain a narrow focus first and build toward SOA, Cyphert recommends. That will present the opportunities to justify current work financially, as well as help in the essential task of demonstrating the long-term potential of SOA to senior management.
That absolutely is critical to success, Cyphert emphasizes. If agreement is reached within the organization to commit to SOA, "then you need to have a body in place in your organization that has the scope to span both business and IT, and that will enforce the standards - the guiding principles of SOA," he says.
Efforts toward building SOA can be aided by attention to three key areas, according to Ben Moreland, who heads The Hartford's (Hartford; $259.7 billion in assets) architecture group. The first is the technical aspects related to leveraging the relevant standards.
'High Learning Curve'
"At a high level, everyone understands what SOA is, but there is nevertheless a high learning curve for all of the specifications needed to implement it correctly," Moreland asserts. Developers will need to know SOAP (simple object access protocol), WSDL (Web service definition language) and UDDI (universal description, discovery and integration), for example. "These are not things you can pick up overnight," Moreland says.
While some aspects of SOA-related technology may be readily grasped, there still is plenty of room for ambiguity or the need for decisions that require further experience and understanding. Depending on the particular standard route taken, subsidiary protocols can proliferate, raising the learning curve. "It's not rocket science, but you need to have someone who really understands all the technology and can help you define best practices," Moreland says.
Second, it also is critical to understand that in an organization that is truly SOA-based, the sphere of control changes, Moreland advises. In an insurance organization where technology is built around lines of business, technology decisions are siloed accordingly and made without respect to other segments of the enterprise. That, of course, is anathema to SOA. By the dictates of reuse, consumers of services inevitably will need to leverage both business and technical services outside their traditional bailiwick.
Equally inevitable, at least in the earlier phases of enterprise SOA, is that the services "borrowed" from another area will not be perfectly suitable. In order to be able to perfect those services - in essence, to polish them so that they become usable as-is across the enterprise - the organizational structure needs to be in place to supply the necessary resources to make the enhancements and changes needed from an enterprise perspective.
Finally, just as supervisory control needs to prevail above the various segments of the enterprise to keep them in line, so should there be the kind of culture that encourages them to get with the program of their own accord. "There need to be incentives to use services from outside your area, and there should be incentives to create services that are usable outside your area," Moreland prescribes.
These necessary controls and machinations give rise to a somewhat uncomfortable realization - while meant to increase ease, SOA brings a new set of burdens, too. The Hartford is far from unique in that after facing the challenges of mastering the new technology, it found some of the toughest work lay ahead. "Having gone over the technology hurdle and now actually supporting and making it all work, we're facing more challenges on the operations side," Moreland relates.
For example, the transparency within an enterprise associated with the standardization of technology use and business process language doesn't happen automatically. "One of the costs that comes with SOA is increased communication," Moreland says. For example, someone wanting to release or test a new version of a service will need to understand the transaction profiles of all the invoking applications - those that may be consumers of the new version. "You have to coordinate with the testing teams, possibly within areas with whom you never had to interact with before," Moreland explains.
Having ramped up a service-oriented architecture initiative this year, Highmark (more than $8 billion in 2004 revenue) has the importance of communication top of mind, according to Mike Kronenwetter, the carrier's vice president, technology management. The initiative sprang from the implementation of a strategic information systems plan (SISP) promulgated in the fall of 2003. The plan called for a refresh of technology and application architecture definition, executed in 2004, out of which flowed the SOA initiative and a component and IT asset management effort in support of it, he relates.
"The mantra behind the SISP was to align IT closer with the business," Kronenwetter recalls. "They said, 'We want you to do things faster, better, cheaper.' But they also said, 'We want to create processes that allow us to work more collaboratively, so that in the end it's a win-win for everybody.'"
Kronenwetter shares that ambition and affirms that SOA brings the connection between IT and business to the fore. However, in pursing the long-term benefits of SOA, he emphasizes the need to deal with shorter-term expectations and misconceptions. For example, the tendency to think of SOA as a silver bullet rather than a slowly maturing goal can be found on both the systems and the business side, Kronenwetter relates. "Perception management and expectation management are key," he says.
Kronenwetter also has observed that some people newly exposed to SOA fall prey to the idea that upon taking SOA's business process modeling and service definition approach, integration and data architecture problems are solved. "What we actually find is that [the approach] exposes some things that might not be quite right at that level and need to be fixed before you can be effective with the SOA implementation," he reports.
In other words, transparency at a high level necessitates cleansing all the obscurity and incompatibility at lower levels. Compatibility thus leaves little room for error. When working in silos, all that matters is that the end product works for its limited purpose. In an environment of enterprise compatibility - to a level of quality permitting meaningful reuse - deviation from the norms can result in costly outcomes akin to two ends of a tunnel failing to meet in the middle.
To mitigate that kind of risk, it's necessary to be as open and thorough with communication as possible, according to Kronenwetter. The goal, he says, is "an understanding of all the things that need to be in place in terms of integration points, data needs." Part of that, he adds, is "making sure you've got the right business folks in the room to talk about service definition and to educate the business about what, exactly, business processing is - because they're not necessarily used to thinking of it that formally."
The component and IT asset management piece of Highmark's SOA initiative provides another crucial instance of transparency. The carrier has implemented LogicLibrary's (Pittsburgh) Logidex mapping and discovery engine to govern and manage its software development process. "There are many things that need to be in place for an SOA environment to be successful," Kronenwetter says. "One key piece is understanding and awareness of the services and the components that constitute those services."
Kronenwetter says that Highmark's IT organization had been working with components since the late 1990s but had never optimized reuse. "We never got the best value, even doing plain component-based development, because we never had a single place where we could allow developers of components to place them, with the appropriate metadata, and then allow an effective and easy way for consumers and potential consumers to find relevant code that they could reuse," he explains. "We needed a vehicle that allows that connection between producers and consumers." SOA provides that vehicle.
Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio