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.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.