I'm doing a feature for InfoWorld on SOA governance and collaboration. The genesis was a short piece I did for InfoWorld on emerging collaboration options. Somehow Eric Knorr and I got talking about how SOA was a formalization of how collaboration can happen in building distributed applications and that governance was a key part of all that.

Governance is a term that has been much hyped in the last year, but that's because it's so important. Like most things, the technology of SOA isn't the hard part--its what Rohit Khare calls level 8 and 9 in the OSI seven-layer model: economics and politics. Governance is all about managing layers 8 and 9.

This view that governance is more important to successfully employing SOA than the technology factors is the basis for viewing SOA as a way of formalizing collaboration in the application development process. Governance prescribes and proscribes patterns of interaction, acceptable standards, and creates communication channels. Done right, governance also aligns the incentives in the organization with the goals of SOA and sets up support structures inside the organization.

One of the things that we'd like to do in this article on governance is be a bit more prescriptive than we have in the past. With that in mind, one idea I have is to center the article around a list of things to do to create good governance--best practices--and, as a result, manage layers 8 and 9. Here's an initial cut at such a list:

1. Do your homework
• Understand the governance requirements at each stage of the SOA lifecycle--run-time policies are created and implemented very differently that development-time policies.
• Find the right sponsor--having the right executive sponsor is critical to accomplishing everything else on this list.
• Find out what SOA activities are already underway--you probably have pockets of excellence in your organization. Work to expand their influence.
2. Build a governance process
• Establish the communication patterns that will create, approve, and implement SOA policies.
• Ensure the feedback loop is working--if something isn't working, will you know?
• Determine how policies will be enforced--if you're not enforcing policies, they're just suggestions.
• Create a board of review for governance process--constant tweaking of the process is a fact of life. A board of review can ensure continued improvement.
3. Build your SOA Enterprise Architecture
• Start with an interoperability framework--the IF is the easiest part of the enterprise architecture to create. Get it going to break everyone in and find the weak spots in the process.
• Develop the right policies at the right time--You don't need to create a 3-inch rule book before you start using SOA. Pick the low-hanging policy fruit.
• Create reference architectures (enterptise and system level)--reference architectures show developers, architects, and project managers the preferred way to do everything from building hooks in their code for the WSM tools to preferred hardware deployments for high-availability applications.
4. Get the tools in place
• Use one registry for production level processes and another for production and QA--You need a registry to enable deploy-time and assemble-time policies. In fact you need at least two and the production registry needs to be redundant.
• Use Web services management (WSM) tools to automate as much of the runtime policy as practical--WSM tools not only help enforce policy automatically, but they save developers from building things like security services into their services.
5. Build the right support into the organization
• Enlist the project management office--the PMO is already controlling how projects happen, they're a great place to get some non-intrusive enforcement.
• Align financial incentives with governance objectives--if people are rewarded to doing things that are counter to building an effective SOA process in your organization, you've lost the battle before you show up.
• Create and use a center of excellence--supporting the SOA effort with a group who can showcase best practices, evangelize SOA, and answer questions gives the whole effort a boost.

Now, I'll admit that this probably isn't a linear process--it's a Hasse diagram at best. Still, this has to be presented in some order.

Why am I sharing all of this now? I want your feedback on what I've missed and what I've messed up. I also need to get in contact with people doing these things and talk to them. Contact me directly, or leave a comment.