Can SOA governance technology be distracting?

In a recent post, David Linthicum asks "Can SOA governance technology be distracting?". His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I'd add to David's list of things that need to be 'worked out' before you get that cheque book out:

• What is your vision for governance itself? Do you want to adopt a 'iron fist' or 'hand in glove' approach? Is your registry going to be a mechanism for governing or a side effect of it?
• Who's going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn't going to turn into a dumping ground of candidate services?
• Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you've worked out how you're going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
• Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can't be addressed using your existing tooling (even if that's Microsoft Excel)? Be honest with yourself about when you're likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year's time you'll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that's where you're at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you've spent six to twelve months getting your ducks in a row, so to speak, you'll be in a much better place to make decisions.

I'd really welcome stories from people about how they've implemented governance platforms in the past, whether they're informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn't? What would you do differently next time?

Paul Freemantle: A new kind of (SOA) Registry

Forgive the misleading title; Paul isn't actually a new kind of SOA registry. But he does know a bit about them, it would seem. Especially the bad bits. Paul is proposing a REST-based registry implementation which completely sidesteps UDDI and friends. Paul's main accusation of the SOA Registry and Repository market is that it's very biassed towards commercial software, which is absolutely true. While I'm not convinced that this is UDDI's fault per-se, I do think there are plenty of things wrong with UDDI anyway, so am more than happy to see some alternatives on the scheme. What I love about the approach Paul's describing is its simplicity. Every other registry product I've looked at before (which isn't many, to be fair) has been almost defined by its complexity. Many even feel like they use it as a selling point. What Paul's describing does away with all that, relying instead on simple foundations (REST and ATOM), and then allowing the complexity to be built outside of the registry, just like in the blogging world. One to watch, I think. I'm off to download the code.