Why Governance isn't an SOA after thought

One of the bigger challenges with SOA implementation is when to start worrying about governance, you don't want to get all heavy handed and stop anyone doing anything, and after all all these web service things make stuff easy so governance shouldn't be as much of an issue.

Historically governance has been about making people re-use things, mainly because re-use was hard, or at least tricky, so people would either cut and paste the code or just do it themselves. This was paticularly true when you had a great big EAI team that acted as a major preventative to getting anything actually done due to them being the single biggest IT bottleneck.

Now however we are in a world where point-to-point integration has never been easier, and anyone can call a web-service with a couple of button clicks. This means that the emphasis of governance has changed to enforcing policy which has a couple of implications

1. You need a policy to enforce
2. You need a mechanism to enforce it by

This means that in SOA governance is more about direction than it is about championing the approach. What SOA governance needs to be focused on is enabling good behaviours and preventing bad ones. This doesn't mean it turns into a Security Department and says "no" all the time, but it does mean that there needs to be an active communication plan on what "good" looks like for SOA in the enterprise.

This is one reason that organisations get bitten much quicker with Web Service technologies than they have done before, the time to create the "rats nest" that EAI was meant to solve is much less and the ability to by-pass company policy and security can quickly get out of hand (right-click, expose "CompanyPayDetailsService"). So when planning to move towards SOA be aware that the technologies you will be implementing much of this with enable some spectacularly complex (messy) infrastructures to be created in a hurry, and some amazingly dumb things to be done equally quickly.

When planning for SOA don't think of governance as something that you will look at in Phase 2, or it will be the only problem you are looking to solve in phase 2! Create a simple, lightweight, briefly documented policy on how services should interact (having a Business Service model helps here) and put in place some basic measures of "who is calling what". As your SOA grows so will the governance, so its a fine line to balance, you have to increase the formalism as the SOA implementation grows, start light and build up, but always plan to have governance.

And that really is the point, SOA aims to link up business and IT more effectively this means that planning is critical and governance of these stakeholders and groups is what will enable the flexibility you want.

If you create a free for all it will be a dream for a consultancy, but a nightmare for your company.