Tuesday, June 10, 2008
Service registries: now for cloud services?
Roy Schulte delivered the Monday morning keynote, setting the context for where we are today in the evolution of enterprise IT. He touched upon a number of things, and mentioned in passing that registries and repositories are going to gain prominence in the years ahead, beginning with the immediate future. Frank Kenney expressed similar sentiments four years ago, when I was here last time, co-presenting the just adopted UDDI version 3 on behalf of OASIS.
In the intervening four years we kept hearing about service registries and metadata repositories being finally ripe for massive deployment. Everyone pointed to SOA governance as a systemic problem and to the registry as a necessary piece of the solution. Indeed, adoption of registry and metadata management infrastructure spiked up and the market evolved quite a bit, perhaps most notably with emergence of CMDB as one of the outcomes through these years. (The causal relationship here is more direct than it may appear to be: for example, HP’s CMDB push is the direct result of its Mercury acquisition, which earlier acquired service registry leader Systinet. As a reminder of that, I saw Radovan Janecek, Systinet’s VP of Engineering, talking about HP’s CMDB vision later in the day.) But we are still in the early days, perhaps reflecting where we collectively are in our adoption of service orientation.
Service orientation itself evolved in these years. Interest in cloud-based computing is very high, if session attendance is any indication. With SOA being the dominant architectural paradigm, anything-as-a-service (XaaS) delivery model is viewed through the prism of service delivery requirements. David W. Cearley and David Mitchell Smith, in their session on the cloud platforms, offered this cloud service taxonomy:
· System infrastructure
· Application Infrastructure
· Application
· Information
· Process
· Ecosystem Management
Each type of cloud service supports a distinct set of service delivery capabilities -- from systems on the lowest level to composite applications and mashups on the highest. Depending on the requirements, cloud service adoption may involve getting in at system infrastructure level (cloud-based application execution), where there is legacy application engineered in a traditional single-tenant software framework. New software can be implemented on provisioning models higher up the technology stack, such as application or mashup platforms.
Reflecting this evolution of service delivery models, the David & David session also included mention of registry capabilities. It came up in the context of search, whereby services provided in the cloud by vendors and partners are required to be discoverable. Clearly, we are not talking about registry as Web 1.0 infrastructure, which is where the modern service registry originated. These registries would be company-specific, managed by enterprise IT departments. Indeed, the services’ location independence, afforded by properly designed SOA and deployed enabling technologies, makes it irrelevant to service consumers where the services are hosted, along with the other internal details of their delivery.
It was repeated throughout the day, including by David & David, that all enterprises will end up sooner or later as cloud service providers themselves. You will be not only consuming, but also providing cloud services to partners. Leaving other implications aside for now, metadata publishing and SLA compliance are among the concerns that require a deliberate metadata management architecture. Hopefully, by the time these requirements appear on our collective enterprise radar, the requisite processes and technologies will be deployed for the reasons we need them now. And these reasons are fundamentally the same as 4 years.
Subscribe to:
Posts (Atom)