True to form, Todd Biske took me to task for my last "SOA Governance Monday" post floating the notion of SOA governance in the cloud. He entitled his response "Governance in the Clouds? No thank you."
I hope I did not send Todd running down the hall to the datacenter to hug his server. :-) However, I suspect a lot of people in the enterprises out there have a similar take on this as Todd did, and I thought he brought up some good points, perhaps even agreeing with me on most points, as I read it.
From his post:
"I have no issues with providing a registry/repository as a service. Certainly, the querying interface must be available as a service for any company exposing service outside their firewall. Likewise, if I'm consuming many services from the cloud, it would be great to let someone else handle putting all of those services into a common, queryable location, rather than me having to establish some form of federation or synchronization between my internal registry/repository and the registries/repositories of the service providers in the cloud. This is no different than the integration problem faced by a company that builds some services from scratch, but gets others from third party products like SAP that may have their own registry/repository, like SAP ESR."
OK, so far so good. However, I'm not sure anybody would disagree all that is on the way. Indeed I was just talking to John Musser, the founder of ProgrammableWeb, who is working on a registry/directory API that does something very close to that. Thus, you'll be able to access these services using a common directory API, which will include basic SOA governance capabilities. In essence, one-stop shopping for API information, standing between the consumer of the service, and the provider. Going forward, we will see thousands of service providers, all discoverable and governed through a set of well-established APIs/services. Basic governance at first, then more advanced as time goes on.