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?

Robin’s rule – if you can’t easily grasp what a product does in 10 minutes of reading the datasheet, there’s a problem. This is currently case for me on the relatively new WebSphere Business Services Fabric. I understand all the words on the IBM web site, but it’s had to articulate in a snapshot what it all means.

It seems mainly like a packaging of all the bits from the WebSphere integration/BPM landscape that know and love such as Process Server, WID, Monitor, Modeller, WSRR, etc but there are some new bits thrown in such as a new Eclipse perspective for managing extensions stored in WSRR and other stuff.

Or I’m just dumb – for which I apologise.

Follow

Get every new post delivered to your Inbox.

Join 1,084 other followers