SOA Governance and Open Source Governance

SOA Governance is one of those great titles - it makes it sound like something incredibly difficult is happening. And the reality is - that in a large organization where SOA has grown up without controls - it may be difficult. But that doesn't mean it has to be. The basic principles are simple.

What are those basic principles? Open Source development principles!

The reason SOA governance is important is that SOA is inherently empowering. It is about enabling teams to take ownership of their own business services. Of course the problem is that you can't empower Bob without empowering Joe. That means that Bob has got to trust Joe, and Joe has to trust Bob.

Now Open Source developers are naturally dispersed teams who are empowered, and who trust each other. In Apache we talk about Meritocracy - which literally means giving the governance to the people who have merit. But it isn't just based on having wonderful smart people - its also based on processes and systems.

The main systems in place for OSS governance are simple:

• A shared repository with correctly managed access rights, accessible via command line, tools or website
• Versioning of every change so broken code can be rolled back
  
• Notification of code changes through publication
  
• A shared forum or mailing list for discussion
• A good build system that manages dependencies
• Validation of code through unit tests
  
• A well defined release process

These simple aspects create a framework for a community to govern multiple components across different geographies and teams. And it works. If you want proof, simply look at Apache's productivity - or Codehaus - or better still - WSO2.

What does this mean for SOA? Let's take each of those aspects and see how it maps to our SOA Governance solution - the WSO2 Registry:

• Shared repository: this is what the Registry is. It is a shared repository, with fine grained access control, and can be viewed as a website or via command-line/programmatic tools
• Every change to a resource is fully versioned, and you can checkpoint a directory at any time, capturing the exact state of all resources in that tree
• Notification of changes - you can subscribe to any aspect of the registry and repository using Atom, or extend the system using well-defined plugpoints to use email or other publication systems
• Even better than a mailing list, each resource has its own place for comments. You can subscribe to all comments across the system, but each comment is closely tied to the resource it applies to. This maintains the history of the discussion directly against the resource.
• Dependency management - both automatic (this WSDL uses this Schema) or simply added by the developers, this allows impact analysis - which WSDLs are affected when I change this Schema
• Validation - we now have build in WSDL validation and WS-I compliance testing, and the system can be extended to support any level of validation of resources (e.g. WADL validation or Policy checking)
• Release process - you can simply define a lifecycle for resources (or different lifecycles). These can be as simple as promote/demote, or can build in rules to invoke different users to authorize.

These simple models are the basis of a properly managed and well-defined SOA Governance process - and its available now, completely Open Source under the clean Apache License. Download the WSO2 Registry 1.1 release now!