Wanted: new term for SOA 'governance'

Here's a quote that's too good to pass up:

"Let’s be honest, the term 'SOA governance' sucks. It reeks of someone else telling you what to do, hectoring you over every little detail of a project. It sounds about as desirable as a colonoscopy with an IMAX camera." -Michael Meehan

Does 'SOA governance' sound too much like 'SOA politburo'?

I wish I could have come up with an analogy like this. In a new post, Mike looked at all the attention being heaped upon the topic of SOA governance and wonders if the term -- not to mention the concept it represents -- is too overbearing for our business culture?

"It’s a particularly sticky term here in the U.S.A. We don’t like a lot of governance. In fact, we get uppity when we think we’ve been placed under the yoke of too much governance. We’ll dump your tea in the harbor when that happens. In fact, you can be sure many project teams have formed some unprintable thoughts about governance without representation."

In other words, does SOA governance have too much of a ring of "SOA Politburo"? (How's that for a better term?) The trouble is, that may be the perception some organizations have.

Mike's main beef is the term "governance" itself, of course, but I'm wondering if governance is being sold as a panacea for fixing any and all dysfunctional SOA attempts. Granted, ungoverned SOA would not be SOA at all - Just a Bunch of Web Services tangled up in a Spaghetti Oriented Architecture, with no clue as to what's being used and what value it's delivering. But with too much governance, as we've seen in the past, end users end up doing end-run around the rules with either sneaky approaches or all-new technologies altogether.

I've even heard of cases where SOA governance itself has tended to go too far, strangling the innovation that service orientation and loose coupling is supposed to promote. One vendor executive I recently spoke with said he saw customers pull back on governance when they realized that the restrictiveness stifled the ability to effectively deploy and reuse services. Besides, sometimes rogue services can desirable, and even profitable, too.

I have always thought that simply calling it "SOA management" fills the bill, anyway.