Do cloud computing providers understand customer requirements? Do customers understand their requirements? No and no, and this is a problem.
Today, most cloud computing providers offer one-size-fits-all services – with few options or service level alternatives. As the market matures, there will be thousands of providers, each trying to differentiate by focusing on specific market needs, and offering service level alternatives and options to attract specific types of customers.
This sounds great, except service providers don’t really know what options the market needs, and perhaps more importantly, potential customers don’t always understand their service level requirements.
Service providers will figure this out by experimenting, and making adjustments as they go. Some of these adjustments will be hard and expensive to make (and retrofit). Some providers will simply fail. The customers will figure this all out by getting burned.
No doubt, there are many service needs that can be fulfilled just fine by one-size-fits-all services – go for it. But the next stage of cloud computing use – more varied, business-critical services – will require something more.
A key to success for cloud computing is getting the interface right, and getting the service requirements right. The interface defines the service offering in detail for the customer, and the service options link directly to automation behind the interface. Building this automation isn’t easy – and many providers will focus on specific market needs rather then create a huge array of options. If success requires new options, that means new automation, and that might require fundamental architecture changes. Providers who guess right on market requirements before they build their service offering will have a definite advantage over those who need to make a (perhaps costly) mid-course correction.
Enterprise IT organizations building private cloud services will have a different issue. Do they limit their offerings to their service catalog alone, or do they allow exceptions and special requests – which will add overhead and cost? A key to their success is spending time early in the design process understanding current and future enterprise requirements, and ensuring their architecture gives them enough flexibility to adjust as needed. Bottom line – understand your customer and their service needs, first!
But the real danger is to cloud computing customers – especially those bypassing enterprise IT to use an apparently attractive cloud service. In most cases, they’re used to an enterprise IT provider who reacts to custom requests and changes in requirements. There is someone to talk to. There are often implicit “service level” requirements that enterprise IT handles without the customer even knowing – like disaster recovery, security, regulatory compliance, availability, legal requirements/risk. Enterprise IT often over-provisions services for users – giving them more than they asked for. Don’t expect that from a cloud service provider. Failure to understand your own requirements might lead you to choose the wrong provider, increase your costs, or any number of scarier problems. Bottom line, fully understand your service level needs before you take the leap.
Even if enterprises don’t expect to use many cloud services for years, now is the time to start re-shaping the relationship between IT and the business. Build rich, detailed service level agreements. Make explicit those things that are provided implicitly. Prepare for the time when external cloud service providers will be a viable choice. A center of competency for cloudsourcing within the enterprise (or outside service broker help) is a good idea.