SOA Governance is not about Technology

I've had a few meetings recently where, much to my frustration, clever people have either explicitly or implicitly equated governing SOA or managing SOA with technology solutions that call themselves 'SOA Governance' or 'SOA Management' solutions. This has come from several corners of the industry, of course from technical people from software companies as you might expect, but also from architects at large blue-chip corporates as well. Normally in this case it's the Web Services Management and SOA Registries technologies.

But this is crazy. It seems to be a repeat of the 'IT tool syndrome' where IT people think that implementing a tool will somehow change people's behaviours. Reading Dan Creswell's comment on Steve's Dark SOA Revisited post compelled me to add comments there on a very similar topic.

So, where has this recent resurgence of the G and M words in a software context come from? I'm guessing that it's been from the recent growing realisation that if you don't have a way of managing the services you have above the level of each project or initiative or team (and the particular requirements of each) then you are extremely unlikely to be able to make SOA work (in any way more than a new type of technology plumbing) across projects, initiatives or teams. And that is very important for SOA.

But managing does not just mean storing it in a repository, putting it on a web-site for developers to look at, controlling the deployment, or monitoring the runtime. It's not that all of these things aren't useful, or important. It is that _managing_ in this context is not a technology issue. The technology may be useful, but it isn't the issue. Buying and using the tool won't change behaviours in an Enterprise environment without the processes, roles, stakeholder buy-in, incentivisation, and behaviours that will allow the tool to add efficiency.

Plus, managing in this context also has to fundamentally include proactively collaborating with each part of the business on planning, defining, evangelising about, running and improving a portfolio of services that they can care about and see value in (rather than 'technical stuff' which makes their eyes glaze over faster than you can say SOAP [or REST])

... that way when you come to manage the requirements for each service / project IMO you're far more likely to end up with shared services, consolidated services, composite services, differentiated services etc rather than a new fragmented duplicated obscure legacy of services to add to the old legacies you already have.

Technorati Tags: Enterprise IT SOA Service Oriented Services Architecture SOA Governance Web Services Management