Todd Biske: Outside the Box

I’m sure David Linthicum is growing to expect a follow up blog from me after his “SOA Governance Monday” posts. True to form, I couldn’t let this week’s entry go by without commenting. There’s a good reason for that, however. Thanks to the good people over at Packt Publishing, my first book, SOA Governance, is now available for pre-order from Packt, with expected availability in October. It will also be available from your favorite online bookseller. Anyway, back to Dave’s blog entry.

The theme of this entry is SOA Governance as a service, which Dave states could be “a complete design time and runtime SOA governance system delivered out of the cloud.” I couldn’t help but think of the animation from Monty Python’s Flying Circus with the hand (or more frequently, foot) of God emerging from the clouds and squishing something beneath it. All humor aside, my first thoughts immediately came back to my usual comments on Dave’s past governance posts, which is that he’s focusing too much on the tools, and not on governance. His post probably should have been titled “Registry/Repository as a Service.” Of course, that’s what the original authors of UDDI tried to push, and that never came close to realizing that vision, but admittedly, the landscape has changed.

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.

Exposing the publishing interface is another story. If we get into the public service marketplace, we’d need this, but I think that’s a niche market today. Even if we consider a scenario where I deploy services into the cloud, I would argue that the publishing service is internal to the cloud provider. In short, the registry/repository capabilities would be part of the service hosting service (is that confusing or what?) made available by the cloud provider.

Back to governance. 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. If your services are deployed in the cloud, then it follows that the cloud must provide policy-driven run-time capabilities, such as request throttling, security, metric collection, etc. If your services are developed in the cloud, then the cloud must also provide metrics, code inspection, automated testing capabilities, and the same things that the design time tools used inside the enterprise provide. The cloud can not provide people, although I guess if a company wanted to outsource all of IT, and take a crowd-based governance model where everything they did would be open to the scrutiny of the developer community at large, then putting it all in the cloud would be a necessity.

The one upside to this notion of a registry/repository and all of the associated metadata associated with consumer/provider relationship out there in the cloud is that some large company with massive data centers (i.e. Google) could run their magic over all of that data and begin to extract out best practices for governing consumer/provider relationship, codifying policies, etc. Dave did call this out in his post, stating:

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.

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. If we think about it, this type of analysis on vendor contracts with enterprises is already done by companies like Gartner, so why shouldn’t a company like Google do the same for consumer/provider interactions with SOA? Even if that happens, it’s still not governance, it’s only analysis, which at best, provides better tools information for having good governance, but it won’t govern for you unless you choose to let it, at which point, you’re stating that the utilization of technology is a complete commodity for you, and you’ll just take whatever the big brother, be it Gartner, Google, or anyone else, tells you is the norm.

One Response to “Governance in the Clouds? No thank you.”