The idea of SOA governance is to provide command, control, discovery, and monitoring, as well as design and development support for services that make up your SOA. Most people get that, but in some cases don't want to get that. Perhaps there is a larger opportunity here for both the SOA vendors and the end users.
What's so limiting about SOA governance is the fact that you're given an empty registry/repository and then are asked to fill it up with information about services that you create or in most cases expose. From there it's a constant struggle to keep that repository up-to-date, and thus the SOA governed properly. Indeed, we've been here before with metadata repositories that don't seem to get the maintenance they needed. Perhaps we are doomed to make the same mistake here, unless we come up with something a bit more clever.
We've been dealing with the notion of a shared registry/repository for some time now, delivered as a service. Heck, I've been involved with a few companies that were working on the concept. Instead of leveraging a local repository that just tracks services within your enterprises, you link to a shared repository that already contains thousands of services from thousands of providers, with design and governance information, and it's just a matter of picking what you need and then filling in the gaps with your own services.
This repository would provide more than just WSDL, but a complete design time and runtime SOA governance system delivered out of the cloud, perhaps linked with a local slave repository within your firewall. The core notion would be to provide access and control for both public services, which you and others are able to leverage, and private services that only your enterprise can see. That would provide a complete SOA governance solution, design time and run-time, for all services.
Also, since this is a cloud thing, we'll need to provide "new value." The core value that I see, beyond the use of hosted services you don't develop or maintain, is the fact that there will be design patterns already defined for you around specific categories of services, or pre-built policies around the operation of those services. This is shared: As the services are revised so are the design artifacts and the policies, both shared and private. In short, you're taking advantage of the community aspect of SOA governance delivered as a service to do most of the work for you…100,000 heads are better than one.
Not new, as I said. I've been kicking this one around for 10 years. Perhaps it's time to stop kicking and start doing.
New podcast is out tonight.