A recent article by Phil Windley, Teaming up for SOA discussed keeping SOA governance collaborative rather than chiseling the "Ten Commandments".  The article can be summarized thusly, SOA governance is about managing the desired behavior of an organization in order to ensure successful SOA adoption and efforts by applying the appropriate level of governance, using the correct mechanisms, at the appropriate time in the project lifecycle and allowing for collaborative feedback to evolve the governance process.

The topics that Phil covers in his article are the same sort of topics that I have discussed here on several occasions. SOA projects are not done in a vacuum nor are they remote islands in a far off place.  While must organizations begin their SOA journey with a pilot project, they soon move down the path towards initiatives that span multiple departments or business organizations.  As new players, tribes, become engaged in the SOA journey they bring their own cultures which is quite different from a pilot effort where there is only a single culture.  Now the organization is whole new game because everything changes.

SOA governance requires their be extreme levels of collaboration.  As I have stated numerous times, the technical aspects of SOA aren’t the most difficult, but rather hard part is managing the culture, politics, and economics, better known as governance.  As Phil states, some have deemed these as Layers 8 and 9 of the OSI seven-layer model: economics and politics.

SOA governance addresses collaboration patterns, acceptable standards, and establishing communication channels.  A good governance framework will also align the incentives within an organization with the goals of SOA and establishes SOA support structures.

Most organizations have some sense of IT governance, which is defined as "specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT" by Peter Weill and Jeanne Ross, and augmenting that to align with the SOA aspirations of the organization should not be detrimental, mind-numbing, or difficult.

Some organizations like a step-by-step guide for performing tasks, a "cookbook".  IMHO, when is comes to SOA, in particular governance, this is to prescriptive and assumes that the level of governance and the same processes will be required for each SOA effort.  SOA is an evolutionary mindset, a culture change, and is different for each organization, even each individual component with an organization.  Thus not every SOA effort will need the same processes and governance.

A checklist of considerations seems more practical to me and would seem to add more value to organizations.  There have been several best practices and recommendations made by people from lessons learned when it comes to governance considerations.

Governance considerations:

• SOA Competency Center

• success criteria

• compliance policies

• performance policies

• development policies

• security policies

• process improvement mechanism

• incentive plans

• enabling technologies

SOA Competency Center:  I have discussed the establishment of an SOA Competency Center, or similar type organization, several times here.  As SOA adoption moves from a single pilot project into multiple projects and ultimately throughout an organization to necessity of an SOA CC type organization becomes more evident.

Success criteria:  It is important for all parties involved in the SOA effort to understand the vision and the criteria for determining success.  Success criteria are needed for each stage of adoption as well as the end-state.

Compliance policies:  Policies related to compliance ensure that organizations adhere to regulatory compliance (i.e. Sarbanes-Oxley), interoperability standards (i.e. WS-I Basic Profile), or other organizational policies.  These are typically design-time sorts of policies.  By that I mean that these policies are enforced while the service component is being developed and its interface being published to a registry repository.

Performance policies:  Policies related to performance  ensure that a service consumer is receiving an agreed upon level of service (i.e. SLA), message routing occurs properly (i.e. dynamic routing), or mediation occurs properly (i.e. content or protocol mediation).  When developing an SLA a common template seems to work quite well.  People have asked me, especially recently, if such a thing exists and I point them to the legal industry because SLAs are a legal binding agreement and you better to consult than attorney.  SLAs are not new to SOA so start by reviewing existing SLA examples that don’t involve service experiences and SOA specific attributes.

Development policies:  Development policies ensure that service components are design and developed with reuse, collaboration, and participation in mind from the outset.  BEA as a mechanism that allows an organization to prescribe certain service, or service types, for a project to use, a kind a prescriptive reuse. 

Service components need to be design and developed for collaboration with other service components, through open standard interfaces, and for as part of a larger canvas, not going to deploy single service or SOA.  An enterprise SOA is going to be made up of  smaller SOA deployments from many groups, departments, or business units, so service components need to participate in the larger execution context and not simply in a localized one.

Security policies: Security policies ensure that only authorized and authenticated parties, human or machine, are granted access and visibility to service artifacts and data.  Security policies need to address service artifact access and usage and authentication and authorization of service consumers.  There are several standards that assist with these concerns such as Security Assertion Markup Language (SAML), Public Key Infrastructure (PKI), eXtensible Access Control Markup Language (XACML), and Web Service Secure Exchange (WSS).

Process improvement:  Organizations need to establish a way to receive feedback on the governance approach, both successes and failures, in order to continuously evolve and hopefully improve the approach.  Organizations must be in extreme collaboration in order for SOA adoption to succeed.

Incentive plans:  SOA is a mindset that requires a culture change and in order to get an organization to change its culture there needs to be a reason to do so.  One can’t say, "Oh SOA is a good thing" and expect people to simply buy into it.  The culture has to be nourished, cultivated, and incetivized in order for it to change.  One incentive plan I heard of was based on a point system.  Each time someone performed a best practice or complied with established policy the received points, points were deducted for the opposite.  Furthermore, if someone went beyond best practices or compliance they received bonus points.  Each point was worth $1.00.  Points could be cashed in for various rewards (i.e. iPods, gift cards, etc.)

Enabling Technologies:  There are several technologies for enforcing SOA governance.  First and foremost is the SOA registry repository.  The SOA repository manages the lifecycle of a governance policy.  Some of the more popular PePs include products from IBM Datapower, Layer 7, Cisco, Radiant Mercury, and Forum Systems.

An ESB is also a type of intermediary that handles the messaging portion of an SOA.  The policies that it enforces are concerned primarily with routing and mediation.  While it can handle security policy enforcement it wasn’t necessarily designed for such and organizations may encounter significant performance issues.  It is best practice to off load things that an ESB may not have been intended to address to dedicated devices for such reasons.

Web Service Management tools provide runtime enforcement of policies such as SLAs, Quality of Service (QoS), and other performance policies. 

Policies may be authored in the repository, but is not required to be.  Intermediaries can also be policy authoring points but the policy should be managed in a centralized, logically speaking, location. Either way organizations need bi-directional communication between the registry repository and the intermediaries in order to ensure the collection and dissemination of metrics to gage the health of the SOA.  These metrics will allow organizations to improve the governance approach, evolve their SOA ecosystem to meet demand and usage, and improve service component development over time.

Conclusion

I believe that if organizations attempt to follow a "recipe" for implementing governance, especially at the tactical level, they are simply building a "recipe" for failure.  Granted a repeatable process is warranted but organizations shouldn’t consult Betty Crocker for their SOA activities.