"We can't expect this [SOA] movement to come from within the development organization. IT can't say, 'This is a new development style' or 'a new way of exposing functionality.' If you let your developers define SOA, you're saying to them, 'Please organize my business for me,' and that makes no sense," Schmelzer argues.

Since the architectural group generally is part of insurers' IT organizational structure, focusing on the business may seem counterintuitive to the architects. "It takes real work in IT in order to turn the leviathan around to concentrate on the real needs of the business," Sprott claims.

Furthermore, architects sometimes find they need to get IT to buy in to the value of SOA in order to enforce governance. "Today, the project or program manager builds walls around a project and actually reduces connectivity and reusability because he or she is focused and evaluated on meeting target dates," rather than developing applications within an SOA framework that ultimately deliver greater business benefit, adds Sprott.

If your development staff sees architectural governance as an impediment, any attempt to align business and IT around SOA is doomed. Instead, all IT staff members need to see architecture as a way of enabling them to respond more quickly to business needs, either as a matter of best practice or, more pragmatically, simply a way to keep their jobs.

"There is a huge gulf between IT organizations and their business counterparts at many companies we deal with because IT simply can't support the business in the time frame required. As a result, we see some insurance organizations outsourcing and offshoring large amounts of activity, quite often not even involving the IT organization in that decision," Sprott observes.

"Good [IT] architects are good communicators," Schmelzer says. "They are effective planners, constantly seek to reduce redundancy, and also are thrifty, meaning good architects never seek to rebuild anything if they can refactor what a company already has."

Insurers that have worked to align business and IT around architecture tend to elevate the importance of the enterprise architect. In fact, Schmelzer recommends the architect be given a seat at the table at the highest level.

"Enterprise architects truly should be senior executives, even to the point of having CIOs be the chief architect of the company as part of their responsibilities, if not their title. If a company buries the architect at some low level, that person will be ineffective," Schmelzer says.

This elevation of responsibility leads to corporate structures designed to converge business and IT around business-focused IT architecture. Esurance, for instance, utilizes a technology board comprised of senior executives from across the company in both business and IT. The board meets biweekly and covers a mix of business and IT topics.

"Both the business and IT environments always are changing and expanding, so we need to keep everybody in sync," says Steve Ariana, director of systems engineering in IT at Esurance, who sits on the board and serves as the company's chief architect.

Speaking the Language

"You've got to be able to talk to the business using language and terms it understands and in any method–informal, formal, semiformal–your audience uses," stresses Karl Gouverneur, chief architect and vice president of information systems at Northwestern Mutual.

Regarding SOA in particular, there are many business-focused explanations that distill the concept into Lego-block analogies. However, oversimplifying the concept of SOA risks pushback by the business. "Business people need grown-up explanations, not oversimplified ideas that give dangerously false impressions of ease of implementation," Sprott says.

Instead, Sprott urges companies to focus on the concept of "services" themselves, something business readily understands. Business services that are part of the insurance process–vehicle inspections, medical tests, property appraisals–can be obtained from any number of providers and have contracts associated with their performance. Emphasize to the business SOA and Web services can provide the same type of flexibility–and accountability for performance–associated with any other service framework.

"Businesses are familiar with the idea change is intrinsic to what they do and they need to be flexible in order to respond to that change. If they see SOA as a tool that enables change management and is part of an excellence and quality framework in IT, they will respond more readily," Sprott contends.

In order to explain the benefits of SOA in these business terms, IT must take the time to learn the insurance business. "The architecture team needs to understand clearly the business performance indicators of whatever line of business you're in–what are the key ratios that make your company tick," Gouverneur says. "You can't operate in a vacuum."

And no matter what you're trying to sell, Gouverneur asserts there's one language any business understands: "Dollars are what talks. You need to find opportunity for real, hard-dollar cost reductions directly attributed to architecture and then talk about the upside in terms of revenue or growth."

"As long as we are successful in articulating the benefits [of architecture] in terms of TCO [total cost of ownership], it is not that difficult a discussion," says Guru Vasudeva, enterprise chief architect at multiline insurer Nationwide. "But oftentimes we, as technologists, get sidetracked into the coolness of the technology and forget to investigate TCO."

Another thing business understands is compliance. Esurance saw the benefit to compliance in a project to consolidate its document-generation systems around a common, SOA-enabled platform from Duck Creek.

"The way we produce, transport, and store documents will be consistent," Ariana says. "Demonstrating we have a common, well-defined method for handling documents is important for the requirements being driven out of Sarbanes-Oxley and other regulations."

Esurance already had used several components of Duck Creek's EXAMPLE platform to power a Web-based rating system, choosing the system in part because of its SOA design. The company is planning to deploy the EXAMPLE Forms component, expecting to connect the system first to its policy billing and administration systems this year and then to replace document-generation systems for claims and financial systems in 2008.

"Also from an IT-efficiency standpoint, it is a way for us to consolidate a number of different document-generation systems with a document-production service that provides a common interface," Ariana notes.

The good news is business is familiar with the concept of SOA (see "SOA Awareness," p. 22). The bad news is the hype factor surrounding SOA has raised the suspicion of business around what it may view as just another in a long line of acronym technologies that haven't lived up to their promise.

Also, nothing makes a business executive's eyes glaze over like a lengthy discussion on architecture. "Talking to business about SOA is likely to produce at best a yawn, at worst frustration," Sprott says. Focus on efficiency benefits rather than lofty, hard-to-quantify objectives of "business transformation."

"We've taken the position we are not going to oversell the value of SOA," Vasudeva says. "We have a declared intent to move toward SOA, but our approach toward it is very realistic and grounded in business objectives. For instance, there are things people do repeatedly across customer touch points, and distribution channels should produce the same results regardless of what point of entry they come through. How architecture enables those results are the types of benefits we focus on."

"We stress SOA is a way to establish a framework for creating services and designing interfaces that not only benefits us from an IT-efficiency standpoint but also helps us deal with a growing level of interconnections and data dependencies," says Ariana. He points to a growing need within Esurance for its claims system to connect to the policy system.

"There are things our customers and claims reps need to see and do that would benefit from a higher degree of integration on both a functional and data level. Developing an architecture that defines common interfaces and provides a well-defined framework is important for us to be able to deliver that type of functionality to the business and to do it in a timely and cost-effective manner," he says.

One difficulty of quantifying the value of architecture to the business is SOA is not something a company simply installs. "People think it's a switch–you have no SOA one day, you have it the next–and that's not the case," Schmelzer points out. "You're asking the business to invest without pinning the costs on something you can buy."

The oft-cited strategy is to identify projects in which SOA concepts can be applied, and most insurers have used Web services to some degree–from internal integration to third-party connectivity. This approach can be successful as long as the objective is focused on achieving business goals rather than simply adding to the curriculum vitae of developers.

"Early on, many IT organizations said, 'Let's make this project a services project' simply because they could, and that did not work because the promise of SOA is in reuse and leveraging the investment in the technology stack. Targeting an individual project as a service doesn't guarantee reuse; it just creates a project with more initial cost and overhead," indicates Mark Gorman, strategic research advisor in TowerGroup's insurance practice.

A top-down approach to SOA beginning with a business architecture is the ideal scenario articulated by many SOA evangelists, but in the real world such a strategy is seldom undertaken. "A top-down approach takes a long time and a huge commitment from the business community at the same time both business and IT are trying to deal with tactical needs," Vasudeva says.

Nationwide takes what Vasudeva calls a "pragmatic" approach to SOA. "We know our business well, and we know what key services we often call from different applications," he explains. "Traditionally, we have reused and implemented those in a more procedural manner–duplicating pieces of code. Now, we are going after those services and making them callable, using standards-based approaches and interfaces."

So far, this has led to Nationwide's creation of a continually expanding portfolio of services–termed the company's "crown jewels," according to Vasudeva–such as transformation engines and rating systems.

"We monitor those through our architectural governance process as well as our funding process and mandate those [components] are used across line-of-business solutions," he says.

And when tactical demands do rule the day, business needs to be made aware of the costs of developing outside the SOA framework. "We always look for quick wins–projects where we can make a difference [with SOA]," Gouverneur says. "When we do make a tactical decision, we need to put all the costs on the table to make sure the total cost of ownership is well understood. It's important we make informed decisions, and the architects are accountable for ensuring long-term costs are visible and transparent."

Budget battle number one around architecture results from the challenges already discussed–simply getting the business side to commit funds to a project with long-term payback while dealing with urgent functional needs today. The second battle arises from the process of architectural governance–the fact that enforcing development standards for reusability of services design may cost the line of business doing the development more time and resources than it might have otherwise.

"How can the [line of business] organization be driven to be the first buyer or the first creator of a service?" asks Gorman. "This is where we actually see businesses being creative, including finding ways to credit one organization when a service it created is reused by another."

At Nationwide, "when it comes to [new] 'crown jewels,' we have chosen to build those corporately and develop a funding model that reflects the corporate-level benefit, even though the development may have been done at the line-of-business level," says Vasudeva.

He points to the development of the company's customer information file (CIF) as an example. "Establishing a CIF is an expensive undertaking that may not really provide a compelling business [case] if looked at from the scope of one business unit," he remarks. "But when we looked at it in terms of what customers expected from us–an ability to understand all the relationships they had with us–we were able to gain the support of the business community to build it."

At the line-of-business level, Nationwide monetarily rewards developers for identifying and creating reusable services and has created a corporate funding structure to recognize the fact reusable development may cost the originating business area more.

"We use these [financial] mechanisms to drive the right behavior because, even though we can articulate the benefits of reuse easily, it can be difficult to implement when the short-term needs of the business appear to outweigh the other benefits from the developer's point of view," Vasudeva says.

Architectural initiatives will continue to pose a challenge for insurers. Even if business and IT agree on the need to invest in the standardization and development of an architectural approach that ultimately will enable an insurer to deploy capabilities more quickly, a company must respond to tactical business demands today.

"We need to reengineer parts of the aircraft while we're in flight," Sprott says.

And the initial parallel made above between the architecture of buildings and that of IT overlooks a critical point: Buildings are static, whereas business and technology constantly are evolving.

"The business says, 'If I spend money on [IT architecture], will you tell me when you're done?' But the truth is, you're never done," Schmelzer asserts. "It's a constant process of learning, development, and adaptation."