It also helps companies avoid the problems associated with uncontrolled proliferation of service components. "There are a number of risks [with SOA]," asserts Bloomberg. "One of the most serious is the rogue services risk–groups publishing services in different ways that could be redundant or even dangerous by exposing confidential information" through services interfaces.

"Before [SOA], we had fixed APIs that made it difficult to access enterprise resources," Bloomberg explains. "SOA gives organizations more powerful tools to access those resources, but with power comes responsibility. Otherwise, it's like giving a circular saw to a six-year-old."

For the most part, insurers do realize the importance of governance. Highmark has focused on governance since it started building out its SOA.

"We have a service modeling process, consisting of identification, specialization, and realization of services–deciding how we're going to implement a service and following through," reports Tim Barnickel, lead SOA architect at Highmark. "We've integrated that governance within the traditional Highmark development methodology as well as the RUP [rational unified process] methodology we put in place."

That type of integration with existing structures and processes is essential to minimize the impact of governance on the IT organizational chart and to ensure the focus of SOA governance is more on effective cooperation than enforced control.

"[SOA governance] must be part of the normal software development process, deployment process, operations process, and change control process. If it requires a separate and distinctive process, it will be circumvented," says Anne Thomas Manes, research director at Burton Group.

"The goal of the process is not to follow an arbitrary set of rules," adds Jeff Goldberg, senior analyst at Celent. "It's to make sure you are building components that can be leveraged across the company and aren't adversely affecting any other constituency as you use them."

There are two main phases of SOA governance: design-time and run-time. Design-time governance involves creating and enforcing rules around building services–anywhere from ensuring services are technically sound to making sure they comply with industry standards. Run-time governance involves monitoring services after they are deployed, whether that involves responding to system failures or proactively monitoring services' performance against established service-level agreements (SLAs).

Design-time, as the name implies, is where governance starts. "We are not only leveraging business services for reuse, but we also are taking advantage of standardized development methodologies that enable us to deploy new services more quickly and build stronger applications," says Doug Ross, chief technology officer at Western & Southern Financial Group.

For Western & Southern, leveraging design-time governance pays dividends. "Application development teams used to spend approximately a quarter of their project hours on authentication, authorization, and role-based access. Now, because those are part of the [SOA] standard, they don't have to worry about them and those hours can be reallocated," Ross says.

Despite the availability of design-time governance tools, most insurers employ manual governance processes. For instance, at Western & Southern, the architectural review board (ARB) maintains the company's wiki-based registry of services. "We've looked at service registry technology, and there isn't anything that meets our needs yet, based on service volume," Ross says.

Even though wikis need to be manually maintained, they can be effective, at least until the number of services in an SOA reaches critical mass. "With a wiki, you're not just registering Web services in a WSDL [Web Services Description Language] directory, you're publishing it to a human-readable database," says Goldberg.

Complying with Western & Southern SOA standards, the enforcement of which falls to the ARB, is not onerous for development staff, according to Ross. "For a typical project, you actually might go before the ARB only a couple of times. [The ARB's]goal is to provide the sanity check–to make sure services are designed with the loose coupling that is desired," he says.

The composition of the ARB, which draws experts from the areas of application development, security, and enterprise architecture within Western & Southern, helps keep governance practical. "The ARB might be aware there already is a service that can meet the development need or there already is an integration point available. Other times, it might encourage a service be promoted to other areas because [the service] is particularly valuable for reuse," Ross says. Also encouraging developer buy-in is that Western & Southern created communities of interest around SOA at the same time it incorporated SOA governance into its ARB.

"We find many of the application teams that would otherwise never intermingle now present information to each other on a regular basis. They're sharing best practices around design architecture, concepts, and processes. They evangelize the SOA approach. And because there is an SOA community of interest, people are much better prepared for review by the ARB, which has helped streamline the process," says Ross.

Western & Southern's SOA work started with using Web services technology to interface with third parties, such as quote aggregators and medical providers. From there, the company targeted internal integration, including a customer data integration (CDI) project and a current initiative to service-enable its mainframe applications.

"That service enablement is intended to extract and componentize our back-end administration systems and provide a core set of reusable services," Ross says. "As a result, a developer won't have to worry about creating new point-to-point integration when we acquire additional books of business because we've created platform-neutral integration on the back end."

As Western & Southern's developers have become savvier in SOA development and as its governance processes have matured, the company has seen better use of services in a standardized way for its application development teams. "That sets the stage for better process orchestration and better monitoring of processes," he says. "Getting a foundational layer of integration points that provide interoperability, based on a standard that is technology agnostic, lets you meet the needs of the business more quickly."

Determining what services to work on is both a top-down and bottom-up endeavor. Top-down, Western & Southern looks at front-line processes, particularly where there are customer contact points, and tries to find better ways to leverage underlying business services to benefit that transaction. Bottom-up, the insurer's IT staff works with business to evangelize the value of SOA.

"We try to get the business thinking about its needs for IT in terms of services, rather than looking narrowly at an application and asking for changes to it," Ross says. "A classic example is an address change. Rather than making individual changes to numerous applications, that process can be extracted and treated as a common business service that can be offered and tied into a Web site, call center, IVR, or any number of various clients within the standardized integration mechanisms of SOA."

That business thinking, enabled by SOA development and supported by SOA governance, has paid dividends at Western & Southern. "Avoiding the 'spaghetti' diagram of systems through SOA means work saved and maintenance reduced," Ross says. "Governance supports those benefits because a lot of the rework that used to occur, we no longer have to go through. And by connecting people through the governance process, we find opportunities to share practices we otherwise wouldn't."

At Highmark, governance has been part of its SOA initiative since it began in 2004. "You need consistency from the start, and governance is the only way to ensure consistency," Kronenwetter maintains.

Highmark's SOA governance extended from the company's existing IT and enterprise architecture standards. Enforcement of governance was charged to the company's SOA center of excellence, which the company created as a counterpart to existing centers within its enterprise architecture area. This strategy has helped SOA governance fit naturally within IT.

"We didn't want to reinvent the wheel," says Patrick Hale, director of technology implementation and reporting. "We had a lot of governance already built into our software development life cycle and for our enterprise architecture. Our SOA center of excellence supplemented what already existed, because SOA doesn't stand outside other initiatives that are going on in IT."

Valerie Scott, manager of technology architecture implementation and head of the SOA center of excellence at Highmark, views the company's governance strategy as an enabler of developers. "We're actually engaging with our developers as we have new projects, doing mentoring on service modeling, and helping them build services," she says.

Highmark has taken a two-pronged approach to SOA development: on one side, creating new services that can be reused in multiple processes; on the other, looking for ways to service-enable existing applications. The company currently is halfway through a five-year legacy modernization process to rebuild its administration platforms within an SOA construct.

The company has invested heavily in IBM's WebSphere platform to support its SOA development: an enterprise service bus (ESB) based on WebSphere Message Broker; the WebSphere Data Power SOA Appliance for security; and WebSphere Process Server and Business Process Modeler for process choreography and modeling. However, Highmark has not yet deployed a dedicated SOA governance platform, choosing instead to repurpose an existing Logidex repository from LogicLibrary it had used to catalog software development assets.

"We're still at the point where this strategy is OK because we don't have hundreds of services right now," Scott says.

Weaving SOA governance into existing IT governance constructs and showing developers the benefit of standards compliance has helped Highmark achieve buy-in from developer staff. "We're avoiding rework," Kronenwetter says. "If you develop a service and you didn't follow the logical data model and the service development process, you have to backtrack, and our staff sees the cost of that."

Enforcing standards and creating common integration mechanisms through SOA governance also increases overall process efficiency. "The best mediation is the mediation you don't have to do," Barnickel adds. "If you don't have to do data translations because everyone's using the common canonical format, you alleviate the misunderstandings and the need to translate. It's a benefit that's difficult to quantify, but it definitely alleviates a burden."

The other half of the SOA governance process is run-time governance, involving in-production monitoring of security, SLAs, and overall system performance.

"Run-time governance for insurers means bringing SOA and Web services to a level of reliability we haven't seen yet," Goldberg says. "We are just now beginning to get to the point where we can impose the kind of reliability and stability that has typically been seen in the mainframe space."

The spectrum of run-time governance processes ranges from fully manual approaches to high-level monitoring via dashboards to automated systems that monitor SOA system traffic in real time. Currently, Highmark's run-time governance process mirrors the manual process of its design-time SOA governance. However, the company is evaluating what solution might best provide automation in its services run-time environment going forward.

"Philosophically, we know [a run-time governance tool] is the right thing to have in place, but we haven't gained the confidence level to interject one into our system from a vendor perspective," Kronenwetter reports. "We don't want to create a [system] failure point by adding a monitoring tool into the environment that has the potential to bring the system to a halt. If the [SOA run-time governance] registry goes down, you don't want to stop mission-critical applications."

Likewise, Western & Southern is taking a cautious approach to run-time SOA governance. "We have yet to climb that curb in any significant way outside of any rudimentary monitoring," Ross says.

"We believe dashboard-type monitoring can be the role of an ESB, and we are looking to an ESB for easier location, orchestration, management of services. Our goal is to have an ESB in place over the next 12 months, but right now a lot of our bandwidth is being taken by legacy system service enablement," he adds.

Although manual processes can be effective, automating SOA governance will become increasingly important for an insurer as its volume of service assets increases. SOA governance systems contain a registry and/or repository of services that provide an index of assets within an SOA; metadata about those assets and where within the SOA they are located; routing and notification capabilities; and monitoring and management of service performance based on data on service characteristics, SLAs, and relationships among services.

"These [SOA governance] tools have become full life-cycle governance tools," says Bloomberg.

In its 2008 "Forrester Wave: SOA Service Life-Cycle Management," Forrester Research noted, "A manual process is sufficient to coordinate a handful of teams providing and consuming a relatively static catalog of services, particularly in a pilot setting, but robust processes and automation are necessary to manage a large number of teams using a dynamic and diverse service catalog." However, there is no clear-cut point at which the number of services becomes "dynamic and diverse," reaching a critical mass where manual management is no longer effective. That makes it difficult for insurers to decide when–and in what–to invest.

"We want to be pragmatic, understand governance and how it ties into the ESB, and do our selection carefully and effectively," says Ross.

Automated SOA governance tools also "need to integrate with the other tools you use to automate your processes," Manes says. "For example, during design and development efforts, the governance tool should seamlessly integrate with your software development tools and processes–the IDE plus the build and integration processes and the testing processes."

In a way, the discussion around governance automation parallels other enterprise management technology decisions, such as content management. That is, most insurers have implemented imaging solutions where users manually can search and retrieve needed content. However, fewer have made the investment in enterprise-grade systems that automatically manage content throughout its life cycle, enforce policies around its creation and publication, and make it available for repurposing in different applications.

"I haven't talked to an insurer that has a complex SOA scenario" requiring automated governance, says Goldberg. "The simplest and most common [governance enforcement mechanisms] are really e-mail and meetings, spreadsheets and Word documents. What I would recommend for carriers is, before spending money on a tool for governance, think about how you would go about doing it without technology. Then, if you think a tool will help you do it more efficiently and reduce manual time, that's when you need a tool."

Ultimately, tools only support–not supplant–a sound foundation of enterprise SOA governance processes and practices.

"Rule number one–you cannot buy SOA governance," says Manes. "Governance is a program that relies on people, policies, and processes.

"You can automate some processes, thereby facilitating certain aspects of the governance program, but if the people aren't incented to participate, or the policies that specify what's right have not been defined, the governance program fails. Unfortunately, no amount of technology can make people get involved," says Manes.

Regardless of the balance struck between manual processes and automation, companies need to have governance strategies grounded in the realities of the way people work. This not only minimizes the impact of SOA governance on the IT org chart but also helps ensure the overall success of the governance initiative.

"One of the challenges organizations still run into is having too much governance," says Bloomberg. "Too many policies, too many hoops to jump through, and people will find a way around them. If the only way to publish a service is by filling in a 30-page form in triplicate, no one will do it. It is important for people to understand there is an optimal amount of governance."

"Governance should be designed to help you know where to go to get the [development] support you need," Kronenwetter says. "Without that support, SOA development will be all across the board.."