Baby Steps with SOA Governance Can Avoid IT/Business Power Plays


There's been a lot of chatter lately about SOA governance and how it should be conducted. To be honest, I was a bit dismissive -- yeah, yeah, everybody needs governance, blah, blah, blah. But when I went back and looked through all the discussion, I finally got the big deal.


This is an IT/business alignment challenge.


Oh, sure, there are technical considerations and best-practice details. There are security considerations and metadata considerations, and eventually you'll have to choose an SOA governance solution.


For instance, since services are supposed to be reusable, you'll need to understand the demands of design-time and run-time governance, though even this might be outside the scope of governance. MomentumSI CEO Jeff Schneider contends that these tasks are really better called "service life-cycle management."


It took me a while to sniff this out. For the most part, bloggers have been writing about SOA governance as a purely political problem.


Todd Biske, an enterprise architect blogger, best summed up the political tensions when he wrote about dictatorship governance versus representative governance. ZDNet's Joe McKendrick humorously played on the same issue in his recent "The Beatings will Continue until SOA Governance Improves" post, which suggests you circumvent some of the problem by automating as much governance as you can. And SOA consultant David Linthicum pointed out that this is a people issue that requires education, not top-down orders.


Obviously, people hate being told what to do without being given a reason, but that's hardly a real barrier to implementation or a single point of failure. I mean, humans are social animals and, as such, we accept and even expect a certain amount of unexplained, even unreasonable rules and regulations. The school systems alone are a great example of our willingness to tolerate seemingly random governance.


So, I suspected there was more to the problem than who's making the rules.


ZapThink's Jason Bloomberg apparently thinks so, too. In my humble opinion, he best summed up the real problem in a recent white paper, "Effective Governance of the Service Lifecycle." Bloomberg wrote:

"The SOA governance challenge, therefore, boils down to how to maintain adequate control while at the same time providing the flexibility the organization requires from their SOA initiative."

So, you see, it isn't just a political struggle. IT's need for adequate service control is bumping up against the business user's need for flexibility. And you can understand their frustration, since responsiveness and agility were among SOA's big promises to business users. They've got a legitimate beef.

Bloomberg's white paper offers the most practical advice I've seen thus far on addressing SOA governance. It's a long paper -- and there's some contained shilling for IBM's WebSphere Service Registry and Repository. But it also offers a smart, iterative approach to SOA governance that may help you short-circuit the conflict between business (flexibility) and IT (control).

The paper even offers four clear steps for getting started:

  1. Publish the goals of your SOA initiative. I would suggest you opt to take the stakeholders out to lunch instead of publishing a memo no one would read, but the point is to reach out early, before you start governance.
  2. Define the SOA organizational structure. Again, Bloomberg urges you to reach out to business early and make sure one representative from business and IT are on the team.
  3. Define SOA governance processes. This is the nitty-gritty work of defining what needs to be governed.
  4. Evaluate technical challenges for SOA governance. You'll notice this comes last.

Beyond those steps, Bloomberg explains how you can expand SOA governance with your SOA implementation. This gives you time to make corrections as you go, gently adjusting the need for control with the need for flexibility. Everybody has time to be heard and there's time for the SOA governance team to educate, rather than dictate.