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

Loraine Lawson

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.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Aug 20, 2008 2:48 PM Rob Eamon Rob Eamon  says:
"ITs need for adequate service control..."This isn't an IT need. Service/component/application/et al stability is a business need. Indeed, the entire IT landscape is (ostensibly) driven by some business need. It is the balancing of competing and sometimes conflicting business needs that creates challenges.That some constraints are viewed as IT-driven is understandable to a point. People responsible for IT are the folks tasked with ensuring compliance with various policies and needs. So when the IT person brings it up, it is (incorrectly) viewed as an IT thing. But it is most likely a business thing, with IT as enforcer only.Business has a need for flexibility AND control. IT itself has zero requirements. Other than technology constraints (e.g. can't do a trillion transactions a second without some good technology), all other constraints come from business needs of some sort. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.