SOA registries and the Dilbert complex

David Bressler takes me (and others) to task on observations that registries are a key part of the ingredients that separate SOA from JBOWS.

In a new post, David asks: "What is it about registries that everyone thinks is a panacea for all things SOA?"

'What is it about registries that everyone thinks is a panacea for all things SOA?'

I have said in various posts (most recently here) that SOA can't and won't exist without governance, and registries are part of governance. Other essential ingredients include business process management, and service sharing/reuse.

But David says there's too big a deal being made about registries, which essentially are only tools that merely reflect the vibrancy (or lack therefore) of the SOA effort. Registries in and of themselves do not make SOA:

"What makes creating a fancy database for service elements of the SOA any better at governing a SOA than using a spreadsheet and some procedural checkpoints as services are migrated from dev to UAT to production? ...How does putting the things we know about in a registry prevent problems we don't know about from biting us later on? ...I just don't understand how/why they've become the cornerstone of SOA implementations."

Fair enough. David emphasizes his point with a cue from a recent Dilbert cartoon, in which Pointy-Haired Boss reams out Asok with criticism based purely on numbers on a spreadsheet. David says organizations may be making similar miscalculations in their SOA work by relying too much on the registry (and paraphrases Asok's response to Pointy-Haired Boss):

• Perhaps your registry is poorly conceived and does not capture the complexity of the real world?
• And, let's not forget the near certainty that your service models are out of date. Documentation kept in a registry is no different than documentation kept in Word... it's out of date almost as soon as it's written!

This brings to mind Nick Malik's recent post that warned against relying on a "bottom-up" approach to SOA. Essentially, Nick cautioned, bottom-up SOA creates dependancy on a directory, which may get filled with useless services, or services that don't improve business processes, but actually make things worse.

David and Nick's posts make a lot of sense. Throwing a registry out into the infrastructure and expecting a vibrant SOA to spring up is like giving everyone a spreadsheet and expecting an immediate revenue boost.

I think there is probably a lot of push on registries coming from the vendor community for one simple reason: as is the case with Enterprise Service Buses, registry is a tangible offering. SOA is a tough sell, as it is more of a philosophy and new way of doing business, rather than a single product or even suite of products. Could you imagine vendors trying to somehow productize and sell "Enterprise Architecture?" SOA represents the same challenge.

A registry is a tool -- an important tool -- that is employed to get us further away from JBOWS and closer to SOA. But most of the transition has to come from transformation.