SOA Governance Monday: More on SOA governance in the cloud

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 br

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.

"My constant theme on SOA governance is it is about people, policies, and process. The only role of tools is to make the processes more efficient. The cloud can only provide tooling. The degree to which you will need a registry/repository in the cloud will be completely dependent on the degree to which the rest of your tooling is in the cloud."

Once again, we agree. SOA governance should be a focus on the people, policies, and processes. I'm simply asserting that the SOA governance delivered as a service may be able to provide much more value versus on-premise, including access to common patterns and policies, the value of "as a service," and the ability to better leveraging the resources that are emerging outside of the enterprise. Thus, more effective application of the technology pattern in support of the people and the enterprise.

"While I don't think the majority of large enterprises would be willing to allow their data to be analyzed in that manner today, it won't surprise me at all if it happens in the future."

Again, we agree. There are a ton of enterprises out there who won't let any enterprise data escape their firewall. While this was the prevailing thinking just a few years ago, the acceptance of SaaS-delivered solutions such as Salesforce.com has made data living outside of the enterprise more accepted. Hopefully, SOA governance in the cloud will follow the same path, I think there is still something here.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies