Todd Biske: Outside the Box

Governance is one of my favorite topics.  If someone asked me the thing that will influence the success of an SOA initiative the most, it would be governance. A very easy way to look at governance it is to compare it to a traditional government.  A government has to legislate, provide infrastructure, maintain strategic plans, enforce laws (police force), etc.  These are all activities that an IT organization must do to govern an SOA.  In reality, these are all things that an IT organization should have been doing, regardless of whether SOA is being done or not. 
 
The same challenges that municipalities face in their strategic growth are faced by IT organizations.  Urban centers grew through a very centralized approach, but have had to become more and more decentralized due to suburban sprawl.  As rural communities have grown, they have had to work more and more with their neighboring communities, possibly sharing common infrastructure and services.  The same is true of IT organizations. The urban center can be thought of as the mainframe or legacy systems.  Due to the web, web services, etc., portions of the legacy logic needs to be decentralized to meet the demands of the future.  At the same time, silo’d application development represents the rural communities.  These applications have grown, and the world of business processes is requiring them to work together seamlessly, rather than through inefficient handoffs and redundant processing. 
 
There are now tools out claiming to provide “SOA Governance.” The truth is that there is no tool or technology that will provide SOA Governance.  There are tools and technologies that can make governance easier, but ultimately, it will come down to process and communication.  If the process and communication isn’t there, the governance won’t be either.  At the same time, we can’t govern by process alone.  The things being enforced (i.e. the legislation) must be documented for all to see.  Herein lies the real challege with regards to SOA or, more broadly, applying governance to IT.  SOA is about looking horizontally while others are looking vertically.  How do you document the rules associated with making something an enterprise service versus an application-specific service?  Yes, we can have rules around WS-I compliance and naming conventions, but this often comes down to semantics and a strategic vision (i.e. business service blueprint).  This is akin to a business applying for a business license in a city.  There will be guidelines for the application that must be followed, but there is still a judgement that must be done by a city council as to whether they want the business in their city.  There may be general guidelines in the city master plan, and the opinions of the council members are exposed through the political process, but largely, things will be handled on a case by case basis by a set of people given the responsibility for making those decisions.  If you have the wrong people in place, you won’t be successful.