Service oriented
architecturegovernance 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.