Cloud Architecture, Human Service Design: Andy Hicks, Research Manager EMEA Telecommunications & Networking, IDC

For a few years now, “cloud” has been an industry yardstick for sophistication: in many parts of the ICT world, if a company can’t provide its services via a cloud model, it looks out of touch. But as an industry, I wonder if we’re not letting our expectations of infrastructure design constrain our ideas of product design, limiting the range of services available to the enterprise market.

While there are many ways to view the development of the cloud, I’m a telecoms analyst, so I tend to view it through a networking lens. To me, “as a service” delivery – whether it’s of compute, storage, software, platform, or what have you – obviously depends on fast, robust, and widespread broadband. Moreover, it hews to the utility model that underlay the rapid growth of the internet and the telecoms industry in general: shared resources, capacity on demand, usage billing, and an opex cost model. Companies like Tata Communications live on both sides of this equation, both building the enabling communications backbone and designing cloud delivery models for their services.

Whether on the network or on the IT side, builders of the cloud have accomplished a lot, and they have a lot yet to do. The understandable concentration on the remaining infrastructure challenges, though, may be influencing the way we evaluate the services enabled by that infrastructure.

If you’ve ever spent time in software development, you know why you need a specialist to do interface design: if the engineers did it, every screen would look like a database schema rather than something a human being would use to perform a task. Put plainly, service design is a different discipline than application architecture. This holds for enterprise services as well. When I hear people criticize a service because it’s not completely self-provisioned, or because it’s not a pure utility model, or because the underlying environment isn’t purely multitenant, I try to ask user-centric questions: Is the service as useful as it could be? Is it cost-effective? If so, great! If not, is it the fault of the infrastructure, or are there other aspects that could be changed?

One area where I see this tension playing out is in managed services. I have heard people describe service relationships that provide a concierge desk, or that involve some sort of professional services, or that incorporate custom features, or that have extensive contract terms, almost as failed cloud services, rather than as an alternate delivery model that meets real enterprise needs. What’s unfortunate about that kind of attitude is that managed services will increasingly rely on the same infrastructure components that make cloud computing possible; they’ll just fold the resulting efficiency and scalability into a service relationship that may include human support, services running locally, or different contract structures.

Just because self-provisioning is possible, doesn’t mean it is always preferable. An up-to-date cloud infrastructure is a great way to provide services efficiently, and therefore inexpensively. The closer it gets to its own platonic ideal, the broader the spectrum of services that it can support cost-effectively. That efficiency should be the basis for a flowering of service designs, incorporating all sorts of innovations in management, financing, risk sharing, and collaboration. Just as with engineers and interfaces, the technical infrastructure needs to support the service design, not determine it.