Service oriented architecture governance is a critical success factor for any organisation wanting to pursue SOA as a software delivery strategy.
If you are just starting out with SOA (running a pilot, executing the first project or two), then it is not going to be top of your list to think about.
However, as soon as you get a few projects in and want to apply SOA consistently across projects and over time, it is really important to have processes and supporting technology in place that can help you get a high level of consistency in what you do.
That is what governance really is about in the context of SOA. Re-use is possible without a coherent governance approach, but it is a lot easier to build services for re-use, and then reuse those services, if you are tackling quality management issues consistently through the service lifecycle.
Governance comes in a couple of "flavours", but there is really just one issue: how can you ensure that your different teams and skill sets - from requirements management, through design, development, deployment, operation and subsequent change management - are properly aligned and handing off to each other effectively?
However, the "market" seems to have decided that there are two parts to the story: "design time governance", which focuses on quality issues when you are building services, and "runtime governance", which focuses on helping with quality issues with services once they are deployed.
You cannot have everything. At least people are starting to think about the issues.
At design time, governance systems invariably revolve around some kind of development metadata store where you store all your artefacts and manage them effectively.
At runtime, governance systems invariably revolve around some kind of runtime metadata store for storing service level agreements, policies, service interface details, and so on, and quite often a set of "agents" which sit in the network, monitor runtime behaviour and (sometimes) actively enforce policies that you set in order to control runtime behaviour.
For example, you can set security policies which are enforced to ensure that all inter-service communication is encrypted.