SOA Governance: When, Where, and How

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Michael Stamback's Blog | June 29, 2007   5:46 PM | Comments (0)

SOA Governance is a complicated topic.  There are so many things associated with SOA Governance it can make your head spin.  There are technology elements, like registries/repositories, policy management, policy enforcement agents, security providers, service virtualization, and what seems like an endless list of other technologies, but there are also non-technical elements, like organizational structure, incentive models, and governance processes.  So this begs the question - with so many elements to SOA Governance, when, where, and how do I start?

 I'm in product marketing, and as such, you should expect an answer about which technology you should use, and whichever product I cover, you should assume I'm going to tell you it's that product.  After all, that's common of product people right?  Well, I'm going to take my product hat off for a moment and take an objective approach. 

There are two things to note up front.  First is that SOA Governance requires a mix of people, process, and technology.  Focus on one and not the others and you will get a partial solution to governance.  The second is that there is no wrong answer to when, where, and how to apply governance.

Let's start with when.  The simple answer is that it is never too late or too early to start applying governance.  However, the opportunity cost related to starting governance later rather then earlier is much higher.  Theoretically, you should start applying governance once you have a single service.  Unfortunately, that's not the typical case.  Many wait until it becomes a problem and their SOA introduces more chaos instead of solving their business problem.  The cost for having to course correct and apply governance once it's a problem is much higher then if you start earlier in your SOA initiative.  Bottom line, you shouldn't wait until you are experiencing pain to start enforcing governance in your organization.  If you had pain in your leg, would you wait until you couldn't walk before you went to the doctor? 

Next is the where.  SOA Governance should pervade throughout the organization, across IT and business boundaries.  Many mistakenly associate SOA Governance with governing services.  This is only partially true.  You need to govern the services that are built, both functional and business services, but you should also be applying governance across your BPM processes, as BPM processes tend to be consumers of SOA artifacts in addition to possibly being exposed as services themselves.   Finally, governance at the individual asset level can be overwhelming when trying to manage an entire project, so governance should be applied at the project level as well. 

Finally, there's the how.  This discussion could take a while considering how many aspects there are to consider, so I'm going to keep it high level at some entry points.  There are many ways you can get your SOA governance initiative started.  It really boils down to where your pain is and what you're trying to accomplish.  Here are some examples:

• You have been constructing and deploying services but now don't have visibility into what services exist, where they are being used, or what other assets they are connected to.  In this case you might want to start with a SOA Management solution to discover the services in your service network and get a snapshot of your ecosystem. 
• You're ahead of the curve and want to apply governance early on.  To do so, you want control over ensuring the right services are being produced in the right manner.  Here you might start with a registry/repository with policy management capabilities to catalog processes and services as they are developed and ensure compliance with rules on how they are developed.  
• Maybe you're an organization that is security and regulatory control conscience.  In this case, you might start by looking at a security solution.  A policy-based security solution that allows you to manage and govern your security outside the application code gives you the most flexibility to easily adapt to new security demands.   
• Next there is the notion of service virtualization.  Many organizations start here by implementing a service bus without realizing they are applying governance, although it's loosely applied.  Service virtualization is a common and efficient way to enforce change management, version control, and runtime policy compliance by breaking brittle point-to-point connections to backend processes and services and hiding the complexity associated with communication with those processes and services. 

The above are just a sample of how you can get started, but they are pretty technology oriented.  Earlier I had mentioned governance was more then just technology.  Common throughout all of the options above is the need for organizational structure and processes.  This is actually where you should start.  Without the right org structure and processes defined, the technology aspects have limited value without knowing the structure to which they apply.  In other words, the technology elements should be used as a means to automate the processes defined, and the organizational structure should be used to assign accountability and responsibility within the processes and other elements, such as vision, architectural direction, etc.

The above is obviously not an exhaustive list of everything that has to do with SOA Governance, as SOA Governance is a large and complex topic.  The bottom line is that you need to identify where your biggest pain or need is and start there.  Your SOA Governance framework can then evolve as your SOA evolves. 

Comments