By its very nature, an SOA encourages services to be shared across organizational boundaries. Among departments or business units, disputes arise over how to build, consume, modify, and retire services, as well as over levels of service availability. SOA breaches the usual departmental silos, so conventional management approaches tend to fall short.

Many early adopters are feeling their way through these issues. “Governance is a hard sell and requires organizational change,” says Bobbie Young, CTO of Unisys. She recommends that organizations evaluate their capabilities to manage such change before going down an SOA path and discovering that endemic resistance blocks any real SOA benefit from being realized.

In some cases, resistance may be unexpected. For example, although the SOA promise of agility through the composition of reusable services sounds appealing to business execs, it also can threaten some business leaders who place higher value on consistency and predictability. “Often, the CFO and COO like the fact that the system is inflexible because it makes it hard for the little guys to change the processes,” notes AMR analyst Finley. And the planning stage of an SOA can resemble Congress trying to pass a bill, he says. “There’s a huge amount of politics about how to standardize processes. It’s easier to say, ‘This is it.’”

Inertia can also be a barrier, notes Keane’s Daly: “With SOA you’re talking about enterprise-wide standards and approaches. But most companies have so much invested in their systems that there’s no incentive to change or share.”

Other governance issues center around control of the services that are developed. Typically, the service owner (usually the creator) can veto any usage that compromises availability and has disproportionate sway over any proposed modifications to meet others’ needs. An architectural group can usually help resolve these issues, such as by ensuring modifications don’t hurt the owner; it can also separate the modifications into an additional service that works with the original service to deliver the new functionality without affecting the original owner.

Although specifics vary from company to company, it’s becoming clear that there needs to be a central entity to establish and maintain policies for building and using services, including monitoring compliance and resolving disputes. This can be a center of excellence, an architectural review board, a competency center, or a program office.

This governing entity is usually composed of both business and IT staff, and it can be fluid in terms of who’s assigned to individual projects based on need and experience, suggests Ettienne Reinecke, CTO of the consultancy Dimension Data. This entity may also set targets and issue rewards and penalties, or leave that to other managers based on the central entity’s findings.

How this central entity works depends greatly on the political culture of the enterprise, but it is important that this body — as well as the architects — have real authority to make decisions and enforce standards, the analysts and consultants we spoke with all agreed. Otherwise, departments will fall back to their old habits and have no penalty for doing so. “SOA needs a benevolent dictatorship. Otherwise it becomes a collection of fiefdoms,” says Keith Siever, CIO of Kemper Auto & Home Insurance, which has adopted the SOA approach.

On the other hand, you don't want a bureaucracy that puts unnecessary barriers in place, either. The sets of policies that underlie governance need to be organic, with a responsive feedback loop inclusive of all parties involved. And make sure policies are less stringent for services or SOA-related activities that are less mission-critical, such as mashups. Applying stringent, overly detailed policies across the board is one way to stifle SOA development — or to ensue that developers and others simply give up trying to follow the rules.

Back to intro | Next: Changing developer culture