• Login
• Become a member
• RSS
• Part of the TechTarget network

Cloud computing is one of the most exciting advancements of IT in the last few years. But even with all the hoopla, private cloud

adoption has realized less than one percent of its potential in the enterprise.

One reason why cloud adoption has been lukewarm in the enterprise could be that cloud deployment projects take longer than expected. Another equally important reason is that potential enterprise users are less than confident in realizing the actual cloud costs and benefits associated with private cloud. Users are also reluctant to accept the fact there may be some application changes associated with cloud adoption.

Companies need to change how they assess their knowledge of private cloud as they progress through a deployment project. At the start of a cloud implementation project, nearly all companies consider themselves “knowledgeable” about the cloud, its technologies and its applications. After a year of planning and preparing to implement a private cloud in their environment, most of those “knowledgeable” companies realize they actually knew little about the cloud when they started.

All projects start with a plan, so should cloud adoption
We can attribute nearly every project failure in cloud computing, at least in part, to mistakes that occurred during the planning phase. All good IT projects start with an accurate estimate of benefits and costs; IT teams must assign steps to secure these benefits within cost constraints and then execute them. While any step in the planning phase can be a misstep, most reported problems during private cloud planning occur during the cost-and-benefit phase.

After a year of planning and preparing to implement a private cloud in their environment, most of those “knowledgeable” companies realize they actually knew little about the cloud when they started.

There are two classes of cloud projects: those aimed at reducing the cost of running an internal IT function and those intended to support applications not easily hosted by internal IT. First, IT teams generally have to prove that a cloud project’s total cost (usually projected at three to five years) will be lower than the current internal IT costs. Additionally, those cost savings must be enough to justify the chief financial officer’s rate-of-return expectations (about 25% and 35%).

Second, IT staff must prove business benefits -- productivity improvements or sales gains -- will be enough to justify the cost of implementing a private cloud. Getting accurate data for either of these justifications is another place where cloud projects often stall. Most often, the cost side of the cloud creates the biggest headaches for IT teams.

All IT activities have a capital cost and an operating cost component, and those costs are spread across a “stack” that consists of hardware, system software and middleware, application software and user support. Cloud services don’t ever displace all of these costs -- user support is needed for any application, no matter how the app runs -- and most cloud services will displace only the lower hardware and system layers. It’s critical to understand how the cloud service will affect the cloud stack and to include both cloud and internal costs for each layer in the assessment. That will give you a true cost estimate as well as a framework for identifying cost assumptions that will drive your project execution.

Getting buy-in for a private cloud project 
A cloud project plan needs more than the CFO to sign-off on it; all line departments that will interact with cloud resources must support the project. Two-thirds of all cloud projects fail when IT teams don’t get buy-in from all business units. A lack of support from line departments is the primary reason for cloud project delays after the planning phase.

Getting buy-in from all departments needs to start with approval from operations, which needs to include the cost and benefit assumptions you developed in the initial planning stage. For example, many IT administrators are under the false impression that an application will run in the cloud exactly as it did in the data center.

There may be differences, and those differences need to be small enough so as not to annoy end users. Most often, applications that have moved from on-premises to the cloud experience degradations in response times or quality of experience (QoE). Set application QoE goals and have line departments validate them to keep a cloud project moving forward.

From pilot to production: Time to launch the cloud
After you have buy-in from all lines of business and have set expectations on what each unit should expect from the cloud, you’re ready to transition from a pilot cloud project to a production cloud. And buy-in is just as important here as it was in the previous stage.

A pilot test is -- or should be -- designed to prove that critical assumptions in securing the project’s cost and benefit use case are, in fact, being met. The only meaningful evidence of this would come from business units that use and depend on the application. However, in nearly half the cases we’ve seen in which cloud projects are delayed, not all users are consulted before the project advances to the production phase. That creates operational problems that push the cloud project back to its test-and development stages.

To avoid this, track how the cloud project will achieve its goals within specified cost constraints while you’re developing the deployment plan. Then ensure the pilot test validates that each goal has been achieved.

The most critical challenge is testing a cloud application at scale, which means running it with the volume of data you can expect in the production environment. This often involves load generation, test data production and other activities related to testing that should have been identified during the requirements phase and that could be ignored when planning the pilot stage. If this happens, cloud performance problems that compromise the project may not be exposed until the application goes live in the cloud, and the delay and cost of addressing these problems could be substantial.

At-scale tests also allow users find project costs they had missed; and while it’s better to catch these unexpected costs before this point -- because they’re less expensive to fix -- catching them here is better than waiting until your first cloud production bill comes in.

Enterprises implementing cloud computing typically overestimate their cloud knowledge going into an adoption project. Make sure all those involved in the cloud installment -- IT teams, business units and end users -- are properly educated before the project begins. Approach a private cloud deployment project logically to ensure that all phases -- cost-and-benefit analysis, goal setting and transition to production -- are established in advance, as well as understood and accepted by all parties involved.  

Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982.

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

All Rights Reserved,Copyright 2010 - 2013, TechTarget