A Fresh Look at SOA Governance

Loraine Lawson

Honestly, I'd rather write about anything besides governance, particularly SOA governance. I'm not sure what it is, but despite my high tolerance for tedious topics-I actually enjoyed covering planning and zoning as a journalist-the very term "governance" causes me to lose focus and drift off to some great online time suck-like Twitter or Facebook.


Like most people, I assume if it bores me, it must bore you, so I seldom write about governance. I just add it to the growing pile of things I felt guilty about not doing.


But this week, when I stumbled across yet another SOA governance article, I begrudgingly read it. It's written by enterprise architect and blogger Michael Poulin, who draws parallels between SOA governance and Alice in Wonderland.


Huh? Of course, that got my attention. And I was pleasantly surprised to find myself nodding my head as I read, muttering, "Yeah, why is that?"


Poulin raises some pointed questions about SOA governance that I realized have long bugged me, but I'd never thought to vocalize. For instance, why is that when people talk about governance, they're really just talking about managing SOA? Is "governance" just a more officious-sounding term for management and enforcing rules?


And just why does SOA need to be governed anyway?


Poulin attempts to answer these questions. Governance, he argues, is and should be separate from management for a good reason: The balance of power. He writes:

....the separation allows us to better understand what is what, why something is needed, who has to do it and be responsible for the governance and for the delivery of results. Furthermore, this separation helps us to organise the governance control, compliance reporting and monitoring of the agility to the corporate strategic plans expressed via governing policies. ... In other words, Management itself must first adhere to the governing policies, and then it can enforce these policies onto the governed subjects.


Blurring the distinctions between the two, he adds, is causing confusion in SOA governance, and yet, he observes, many standards groups seem to confuse the two. He prefers the way OASIS distinguishes between the two:

...governance is concerned with decision making. Management, on the other hand, is concerned with execution. Put another way, governance describes the world as leadership wants it to be; management executes activities that intend to make the leadership's desired world a reality....


The answer to the second question-why does SOA need to be governed-is more complex and comprises the bulk of Poulin's piece. And be forewarned: This infoQ article is long-we're talking long enough to be a book chapter here-but Poulin explains his position thoughtfully and thoroughly. He looks at how SOA governance relates to other governance programs, specific areas SOA governance should address, including frequently overlooked issues, the politics of SOA governance and the proper role of SOA governance tools.


SOA governance tools can actually confuse the SOA governance question, and Poulin's not the only one to comment on this problem. In fact, ZD Net recently republished a ZapThink column on the topic of SOA governance "in the narrow," which is what tools typically address-and SOA governance "in the broad," which looks at SOA governance in the context of overall IT governance.


Poulin isn't the first to make a case for separating SOA governance from management, but it's a point worth revisiting, particularly since this year's news that SOA governance can actually cause problems, if done incorrectly. You might also want to check out a past post, "How the Best-in-Class Manage SOA Governance."


What I realized after reading his piece is that, really, understanding SOA governance is a lot like the planning and zoning board. People came to the planning and zoning board because they wanted something changed, but really, the board just administered-or managed-the land-use plans already created by a higher authority, the county or city's elected representatives. They could recommend exemptions and changes, but as a whole, they were managing-not governing.


SOA governance is your long-range, service-use plan. So be careful what you put in and what you leave out.

Add Comment      Leave a comment on this blog post
Nov 26, 2009 8:16 AM Jean-Jacques Dubray Jean-Jacques Dubray  says:


Governance was invented because the form factor of a "service" is different from the one of a "solution". Governance is a (poor) attempt to express that a service needs to have a degree of coherence that spans the enterprise (and some people argue time well, but I don't, because I don't view reuse as reusing something you built 3 years ago, but having the ability to change something without breaking something you built 3 years ago, this is known as forwards compatible versioning). A solution typically has a much smaller scope (BU or department).

Of course by creating an enterprise wide scope, you obviously need to bring "management" in the decision process, and they probably don't want to be pulled in at the level of designing a WSDL operation.

The real problem that people are trying to solve, but don't seem to see, is that each business object in the enterprise has a lifecycle. An order has one, an invoice has one, a payment has one, and so on. Traditionally, each system in IT has managed different and sometime overlapping aspects of the lifecycles of these business objects. SOA is about bringing this lifecycle under the management of a single service.

>> SOA governance is a lot like the planning and zoning board

Hence, I would fundamentally disagree with your statement,

a) if you can't change a service (to meet the needs of a new consumers) without breaking solutions that consume the service

b) if you once and for all look at business entity lifecycles for what they are (the behavior of business entities across the enterprise)

If we build services following these principles, there wouldn't be any need to all these boards where nobody knows what to do. There wouldn't be any need for all these rules and policies that nobody can apply.

SOA Governance as it is defined today creates more chaos than less.

What if for a change, we could focus on simplifying SOA rather than making it more complicated (in the hope of selling solutions). There is no need to invent problems that don't exist.


Post a comment





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



Subscribe to our Newsletters

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