The space of SOA governance can be very complicated. Governance became yet another hot marketing word, and as a result, the range of tools claiming to provide assistance in the SOA governance space was quite varied. To properly understand where to leverage technology, we need to take a step backward and first understand what SOA governance is. In my book, I defined SOA governance as "the combination of people, policies, and processes within your organization that will ensure that the desired behaviors of your strategic SOA initiative are achieved." That's a very broad statement, but it's because strategic SOA isn't easy!
Taking apart the definition for the context of SOA governance tools, we need to look to the last P: processes. You're going to have people building and managing services, and you need to have policies that describe the desired behaviors, but the only place that tools can offer assistance is in your processes. There are four key processes involved: policy definition, education and communication, enforcement, and measurement and feedback. Based on these processes, there are really two classes of tools: repositories and policy enforcement points. Not surprisingly, vendors in both of these areas have used SOA governance in their marketing. Clearly, a repository supports definition, education and communication, and measurement and feedback, while enforcement is aligned directly with policy enforcement points.
Where do dedicated tools make sense? It's a very easy answer. Tools provide the most benefit when the things being governed are systems, such as the run-time behavior between a service consumer and a service provider. That behavior is defined by a contract, which can be viewed as a collection of policies. If the contract says a given consumer can only make 1000 requests per second, the infrastructure needs to enforce that policy. That means the policy must be codified in a way that the enforce point can use it. Policies may need to be shared across multiple consumers or multiple services.
Where is the value harder to see? It's where the things being governed are people, not systems. This is typically where behaviors need to change to achieve the SOA goals. Policies here can include things like, "Projects must utilize existing services wherever appropriate." There's not an easy way to take people out of this one, but tools can make things more efficient. In order for developers to abide by this policy, assuming they're aware of it (which isn't always the case), they would need to know what services already exist. An Excel spreadsheet buried on someone's hard drive doesn't cut it. An Excel spreadsheet on a SharePoint site might, but a searchable and browsable service repository could make it even easier.
Is it possible for an Enterprise Architecture team to achieve good governance without spending money on tools? Absolutely. In my experience, the most common policy domain enforced at run-time are security policies. There are security specific tools that many organizations have that can handle this. The area that seems to drive investment in service-specific enforcement tools is when an organization exposes services to partners or the general public. For internal consumers only, you may not need service-specific tooling right off the bat. My opinion is that as your efforts mature, you'll probably need something in this space, but it's not a critical first step.
For policies that involve people, the success is far more dependent on how well the organization communicates than how advanced tools they have. If people haven't been trained to look for existing services, it doesn't matter whether you have an Excel spreadsheet or the highest rated SOA repository on the market. This is the far bigger behavioral challenge. For organizations that are on their way to the desired behavior change, the value in tools is very clear, because they can point to the exact points in their processes where tools will make things more efficient. Organizations that have poor processes and expect a tool to fix it will be disappointed.
This was first published in May 2010