The beatings will continue until SOA governance improves

A few months back, I spoke with a CIO who recounted his company's first pass at SOA governance, which was perhaps a bit overzealous. The governing board clamped down firmly on all "unsanctioned" attempts at service creation, which, needless to say, did not help the business users feel very engaged or connected with service oriented architecture.

We're from the SOA governance committee, and we're here to help...

At a recent confab sponsored by Software AG (which is deeply involved with SOA governance via webMethods), there was general agreement that the term "governance" itself was a turn-off -- and opted for "service lifecycle management" as a more cheerful way to describe it.

Todd Biske, enterprise architecture extraordinaire, also recently took a look at the concept behind governance (or SLM), and agreed that it hasn't been evoking friendly images of cross-enterprise collaboration and cooperation:

"My suspicion is that for most people, it’s not a positive image. At its extreme worst, I’ve heard many people describe governance as a slow, painful process that requires investing significant time preparing for a review by people who are out of touch with what a project is trying to do that ultimately results in the reviewers flaunting authority, the project team taking their lumps, and then everybody goes back to doing what they were doing with no real change in behavior other than increased animosity in the organization."

As Todd so aptly puts it, "when governance gets discussed, people naturally assume a command and control structure," accompanied by statements of “Thou shall do this” or “Thou shall not do that.”

Todd compares this to the case of the NFL football coach who had an epiphany that a cooperative spirit -- not yelling and screaming -- was the only way to motivate his team to get to the Super Bowl. Applied to business, the best way to mitigate this command-and-control mentality is by fostering open communications around projects, Todd advises.

"If you are an in a position of authority (a policy setter and/or enforcer), you must keep the lines of communication open with your constituents and help them to set policies, change policies that are doing more harm than good, and understand the reasons behind policies. If you are a constituent, you need to participate in the process."

To build on Todd's thesis, I think the ability to automate as much SOA governance as possible also will better embed the process into day-to-day activities, and even provide a sense of uniform fairness. Anne Thomas Manes put it very well when she said that “governance should be as helpful and as automatic as possible. If it is a hurdle, if people have to do stuff they’ve never had to do before, it typically produces a bunch of resentment — and people will figure out ways to avoid it.”

There's no question that governance is essential to keep SOA on track, on budget, and aligned with what the business wants. But there's a reflex within many organizations to go overboard. Doing so only cuts off the innovative spirit.