Digital Transformation
Showing results for 
Search instead for 
Did you mean: 

Your adoption strategy can make or break your private cloud: Here are 3 ways to get it right


keithmacbeath.jpgBy KeithMacbeath, senior principal consultant with HP Software Professional Services



In my last post I wrote about the huge potential benefits that organizations can reap from adopting some form of cloud delivery. But you don’t see these benefits if you do cloud as an isolated science project. Many organizations spend a lot of time thinking about their cloud production model and ignore the other aspect: adoption.


There’s a high risk that if you don’t think carefully about adoption you will end up spending a huge amount on an environment that then gets lightly used. When that happens your CFO will say, “You told me cloud would radically improve our cost structure, but your costs have only gone up! What is going on here?”


Well that’s because if you create this fabulous private cloud or managed cloud that you’re paying for but it’s not widely used, then it won’t move the dial at all on your total financial numbers. So your challenge is not just to stand it up but to get it used. It’s not just production, it’s adoption. Here are three successful models we’re seeing with our customers.


1. Directed step change

In this approach you move chunks of applications to your private cloud on a planned schedule. We have one client doing this now. They’ve set up a highly evolved cloud with just a few server types and they’ve committed to redevelop all several hundred of their applications onto the Oracle WebLogic Application Server. This is a massive project: there’s a big financial commitment and there are risks involved with a project of this size. In particular it poses synchronization challenges. For example, for your first phase, you need, say, the first 100 apps to be ready to use the private cloud when it becomes available—otherwise you don’t get your cost takeout. Doing private cloud implementation this way requires App-Dev and Ops to run in lockstep (unfortunately not the way it works in many large companies). It also works best where there’s unitary decision making that Apps-Dev and Ops have to abide by. But if you can pull it off you’re able to get your cost take-out on plan, you’ve got a scheduled migration and at each step you’re able to reap huge efficiencies (what I’ve earlier called a disruptive improvement in Operations).


2. Incentive-based ramp

This approach is better suited to an organization that isn’t prepared to place big bets. In this case, the App-Dev group might be in a business unit and makes its own decisions about how where to run applications. And while Operations can set up a private cloud, it doesn’t really have any ability to tell the Apps groups what to do. So with an incentive-based ramp you essentially set up your private cloud as if you were a public cloud vendor and do it at price points that would incent your customer community to use it. (There are whole schools of thought that this is how you should run an organization anyway.)


With incentive-based ramp you’re truly thinking of your cloud as a business. And this is the challenge of this approach. You’re now selling a service internally, so you have to see how much penetration you can get over a certain period. If you’re not getting it, you need to come back and address the barriers to adoption. It forces you to consider your internal business units as customers in the true sense. They’re not mandated to do what you want them to do. Instead you have to incent them to do it, track your ability to sell to them and actively market to them. It’s a really different way of working for IT, which has historically used a more bureaucratic planning process.


3. Capacity block planning

The third approach is almost a hybrid step, evolving from the model where everyone planned their annual requests for capacity in the budgeting cycle. IT realizes that it needs to offer instantaneous self-service provisioning in order for it—as well as the enterprise—to remain competitive. So it stands up an budgeted block of capacity for the business unit and this is good for an annual budget cycle or whatever period makes sense. The business unit pays for that capacity and it’s up to them how they want to use. They can have instantaneous self-service provisioning, and they can use it for whatever they want whenever they want within that capacity envelope. So for infrastructure, IT is divorcing request fulfillment from capacity planning—and this is a really big step for some organizations. With this approach the internal service provider doesn’t assume all the capacity risks—because capacity is agreed at budget time. But the detail of what that capacity is going to be used for and how requests get fulfilled is now automated (leading to big productivity gains) and instantaneous—no more eight week lead times for infrastructure provisioning, which is typical in pre-cloud ‘build to order’ process.


To find which approach works best for you consider how centralized or distributed your App-Dev groups or decision rights are andwhether you’re able to get buy-in and manage a big-bet program to migrate applications to a private cloud. In addition, look at whether you’re able to manage and market an internal private cloud business or whether it makes more sense to continue an annual capacity planning and budgeting model. For more information, contact HP Software Professional Services.


Related links:

0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.

Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all