Thank You Scott Adams!

Thank You Scott Adams!

Posted on August 14, 2007 0 Comments

Have you ever related to a Dilbert so much, you just wish you could open it in an editor, change a character's name, post it over the water cooler, and wait for said person to wander by?

I've been struggling with messaging around registries, and their impact on SOA. I'm frustrated. And, it's your fault.

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

Not to pick on Joe McKendrick in particular, but his is the most recent reference I've come across to this disturbing belief (http://blogs.zdnet.com/service-oriented/?p=934). He writes, in the third paragraph down, "various pieces needed to make up SOA: governance and registries..."

So many cliches come to mind... "garbage in, garbage out", "it must be true, that's how it was designed to work", and, my personal favorite, "we know what's happening in our environment".

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? Do you think we (the IT world in general) plan the problems that occur? They occur because we don't know they're going to happen. How does putting the things we know about in a registry prevent problems we don't know about from biting us later on?

Not that registries don't have their place (that's my placating statement for our registry partners), I just don't understand how/why they've become the cornerstone of SOA implementations.

That's why I need to thank Scott.

In his August 8th Dilbert, the Pointy-Haired Boss is chewing out Asok. PHB has decided to "manage by spreadsheet," and the spreadsheet tells him that Asok has been doing a bad job. Asok responds with the two key points I'd been searching for in my quest to explain why "governance by registries" is a faulty strategy for implementing SOA:

  1. Perhaps your spreadsheet is poorly conceived and does not capture the complexity of the real world?
  2. And, let's not forget the near certainty that your formulae are pointing to the wrong cells.

SOA What? I know you're probably wondering what this has to do with you and your SOA strategy...

Let me tell you two of the problems Asok has reminded me of that exist in "registry first" SOA implementations:

  1. Perhaps your registry is poorly conceived and does not capture the complexity of the real world?
  2. 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!

I know, as many of you read this you'll shake your heads and express sympathy for those companies without the rigid control processes in place at your company. It must be chaos at those organizations. But you're safe. Your IT policies hold back the chaos that threatens to bring your SOA infrastructures crashing down around your heads.

In my experience, it's exactly those who rest in the comfort of their policies that should fear registry most.

  • Like the manufacturing company whose test environment was executing BizTalk processes off the production floor. (Ooops!)
  • Like the financial services developer who spent a week chasing errant service users when his development machine was moved to the next project, even when he had emailed everyone two weeks prior about the change. (Ouch!!)
  • Like the HR consultant whose confidence turned to outright panic when the five groups he was certain were using his development service turned out to be 35, some of which were in production. (Yikes!!!)

Years ago, a cornerstone of process re-engineering was to enter data only once, at the point of first contact. That simple philosophy would capture all data, correctly and consistently, and with the least duplication of effort by all involved. Even better was when the data could be captured automatically via bar-code reader or scanner.

Have we forgotten this simple nugget when planning SOA?

Why not a SOA Management solution that does the same? Automatically collecting information on first use?

Put it in a registry, put it in a spreadsheet, or just keep a pretty-picture on the screen. Who cares? As long as it accurately reflects reality, we can spend time on really important things... like figuring out the best way to edit co-workers' and bosses' names into Dilbert strips.

david bressler

View all posts from david bressler on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments

Comments are disabled in preview mode.
Topics

Sitefinity Training and Certification Now Available.

Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.

Learn More
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

Loading animation