WebServices dot org

Why Limit ‘Governance’ to SOA and Web Services?

In a typical governance scenario, systems track the location and change of various development artifacts, which may reside in change configuration systems, databases, and specialized management/security policy repositories. Some governance systems also provide their own repository allowing development artifacts to be centrally stored. The ability to provide governance at all levels of the IT technology stack -- and not just at the level of Web services -- is also vitally important. In other words, these artifacts may be limited to the XML variety, or they may span the full extent of IT activity, such as documentation, Java code, legacy COBOL copy books, and just about anything else.

There is an emerging school of thought that discusses SOA governance in the context of the broader challenges of IT governance. In other words, to approach SOA governance not from the traditional viewpoint of artifact management, but as a way to apply the benefits and principles of SOA to the entire business and IT organization that supports it. Jason Bloomberg and Ron Schmelzer of ZapThink put it this way: "SOA isn't a single application that you can stick in a corner somewhere; instead, it's important to implement SOA as Enterprise Architecture, applying Service-oriented principles across the entire scope of interaction between the business and IT."

Personally, I find myself alternating between applauding Ron and Jason for their range of vision and shaking my head somewhat sadly and saying to myself "not for the next ten years or more, guys."

Adopting an all-IT vision of governance, as appealing as it is, too wholeheartedly at this point in the evolution of business, IT, and SOA might very well be premature. It could leave an IT organization with more enemies than friends amongst their business counterpoints. There are several risks, not least simply being biting off more than you can chew.

Organizations are frequently challenged when it comes to defining and maintaining their policies even within much more narrow technical bounds. Are the money, technology, standards, and leadership really there to create these broader business-level governance mechanisms Ron and Jason describe today? And, what about the complex business-IT meta-policies they describe that would be demanded by such an approach? Sadly, the answer is no, at least at this time. Furthermore, such a visible and ambitious endeavor could expose a nascent SOA initiative to unwarranted risk rather than be a foundation for success.

Architecturally and politically, opening up governance may also be a case of putting the cart in front of the horse. First of all, many business executives have no desire to define such policies on an enterprise portal or anywhere else. While IT people may find it difficult to believe, many high-level business people prefer to keep their eyes completely focused elsewhere.

Businesspeople would rather call IT on the phone and say, "please make this happen." While the idea of inviting business leaders to participate in the governance of IT in this new way may be laudable, there is no doubt that it might also a profound affect on runtime environments. It's like inviting the passengers in a 747 to contribute their life-experience and wisdom to help fly the plane. The passengers may want to help steer, but you would want to insure that considerable controls existed first. Until your entire IT infrastructure and the SOA that lives above it are appropriately instrumented to enforce, monitor, and control your runtime and the effects of all policy changes, you want to be careful about who is allowed to help fly the plane.

The bottom line is that management and governance can fit together like peas in a pod. They can complement each other and both are ultimately necessary for a successful SOA. But, pursuing such a high order of governance has, as a prerequisite, comprehensive and integrated runtime management and security at all technology levels, not merely at the level of that your SOA implementation. You simply can't put the cart in front of the horse.

For now, what may be much more important is to choose your SOA solutions based on understanding the traditional roles of management and governance. These roles are very different. They are oriented either towards creation and policy enforcement in the runtime world or the life-cycle management of artifacts in development world. They are very different. Building on these two broad foundations should keep an IT organization occupied, and ultimately satisfied with well-understood and worthwhile results. These results may provide the impetus to carry the evolution of governance and management within an organization to even higher levels over time, and that's a good thing, too.