You know, I love an election year. The drama, the emotion, the positioning, it all makes me think about running for office myself - or at least going through the motions to generate a large war chest that I can dip into (I AM from New Jersey, it's a time-honored tradition). Oh, wait a minute this isn't an election year. Not that you'd know it from the slew of politicians tossing their hats in the ring. I guess it's a good idea to get in the race early if you're aiming for the brass ring.

Service Oriented Architecture is a complicated endeavor: it provides great flexibility in implementing business functionality at the cost of additional management and oversight.

Some part of that additional management responsibility falls on the shoulders of a new breed of software - the composite application, which is made up of services combined into processes. What used to take place in a single application now takes place across a network where messages inform services and processes control functionality.

But there's another set of management tasks that don't have software realization - they fall squarely in the lap of human management. We usually refer to these tasks as SOA governance.

Governance is all the tasks that revolve around managing business processes in a service environment except possibly those that actually get implemented in software. Even those have a definition phase that relies on human interaction and approval processes for final implementation.

Defining services, and composing business processes out of services, isn't simple. It requires cooperation among multiple groups in most cases and usually involves the coordination of competing priorities. For example, one organization I worked with in the past had over 100 separate ways to calculate the details of a customer account. Part of this was simply systems history as methods for determining the account evolved over time as systems were added. Another part of the puzzle revolved around the fact that different groups in the organization had different needs and requirements for systems relating to the customer account. So each individual fiefdom created its own slightly different version of the mechanism for determining the account. The end result - a nightmare of similar methods that conceptually all did the same thing - but were divergent in one or more ways from one another. Rationalizing a single method of evaluating the value of a client account from over a hundred variants is a challenging exercise, but it's ultimately achievable. But only if SOA governance provides a means of resolving issues.

And these issues, while not technical, can prove to be the most serious threat to actually implementing a Service Oriented Architecture. Because they're the ones that can stop a project in its tracks, cancel its funding, and subvert technical goals for business or political reasons.

Take the client account, for example. While it may make absolute sense from a technical perspective to have a single view of the customer and his accounts, it may not make political sense to the parties that currently have control of the fragmented solitary views of that same customer account. Governance under such circumstances is as much about driving political and organizational change as it is about determining the best technical approach to software development in a services environment.

This is the most underestimated and undervalued aspect of Service Oriented Architecture - its capacity to become a change agent in an organization based on the need for consolidating and rationalizing the service catalog. With proper planning and the right backing, the case for change can be a powerful weapon for the entire organization. Without such backing, governance issues and organizational politics can easily defeat an SOA effort regardless of the technical feasibility of the implementation.