During the early 2000s, many companies anxiously sought ways to avoid purchasing servers and other IT gear. Server virtualization fit the bill perfectly. Because so many servers (especially ones running Windows) were greatly underutilized, virtualization let one physical box do the work of many. And, importantly in the context of that time, virtualization delivered savings even if it was rolled out piecemeal to avoid cutting purchase orders for new servers. As virtualization has become more widespread, IT shops have started approaching it more strategically. But it started out as a tactical, cost-cutting move.

However, not all technologies lend themselves to ad hoc use -- at least without causing more problems down the road than they solve. Cloud computing falls into this camp. That's not to say that it can't be brought on board in an evolutionary way -- in fact, we consider doing so a best practice. However, our experience to date tells us that the best practice for building an on-premise cloud is to take a phased, systematic approach. In addition, while the informal use of public clouds can make sense under some circumstances, it's important to ensure that confidential data is properly secured and that the development environment is consistent with whatever will be used for the application in production.

There's no single approach to "properly" adopt a cloud within an organization. It's more important to establish some deliberate process than it is to follow a particular one. With that said, we've been leveraging a methodology developed by the IT Process Institute based on a large number of interviews with end-user organizations that dovetails nicely with our field experience to date. The IT Process Institute calls the first phase of cloud adoption "Cut through the cloud clutter."

The goal in this phase is to refocus your initial virtualization efforts on skills and competencies that support private cloud deployments. The initial discovery pilot phase will enable identification of challenges, requirements, and key metrics that will prepare you for the larger cloud implementation. Your mantra for these activities is, "Get ready for dynamic workloads." You should set end goals for virtualization and private cloud deployment. You should start laying the groundwork for building shared resource pools and for managing mobile and transitory workloads. 

Getting ready to build a cloud consists of the following five steps:

Building a private cloud designed specifically for your enterprise has to start with a business discussion. If your infrastructure group is starting a cloud project without developers on the team, stop them. Round out the team with developers, users and, more importantly, externally facing product, marketing, and sales managers. Engage all stakeholders in a discussion about how cloud can accelerate business processes or transform business offerings. Establish clear objectives and success criteria in business terms.

Not all workloads are suitable for a virtualized environment. Likewise, not all workloads are a good fit for private cloud. As you move ahead with a cloud strategy, you’ll most likely be managing a mix of physical, virtual, and cloud resources. As a result, you will allocate a portion of the data center as a pool of shared, virtualized, and scalable resources.

Many IT executives plan to put 30-50% or more of workloads in their private cloud environment. However, private cloud resources will be managed in an environment with physical servers and mainframes, as well as static virtualized resources. To put it in real estate terms, building the cloud-centric data center of the future will be a remodel, not a tear-down. Doing so requires understanding the key attributes of current workloads, scoping the mix of heterogeneity of current environments, and examining how requirements change as you progress from development through test or quality assurance to production.

Assess your current workloads to identify those that are a good fit for private cloud. This snapshot will be used to set long-term targets for the percentage of overall workloads targeted at private cloud. In the short term, it will also be used to identify workloads for initial cloud deployment.

Then move beyond planning. Get hands-on with two critical activities: 

Evaluate different models in the context of your objectives. Be sure to consider agility, service quality, cost, and security and compliance. Consider hybrid computing models that utilize internal and external cloud resources. Note that private cloud resources may include resource pools hosted by an external service provider. A hybrid model may include features that allow movement of workloads from private cloud to external public cloud service providers. 

Deploy vendor solutions in-house and determine how higher levels of automation and standardization integrate with your existing infrastructure, processes, and skill sets. The overall goal of a proof of concept is to demonstrate success with a working reference implementation based on business requirements. To get there, you must test the assumptions you made during your evaluation.

It's natural to equate process with heavyweight process. And heavyweight process with bureaucracy and analysis paralysis. That's certainly not the intent here. Rather, it's to recognize that by bridging IT silos, automating actions, and providing self-service to users, cloud computing delivers a powerful tool to make your IT infrastructure more flexible and responsive to the business. But wielding that tool effectively just takes a bit of upfront planning.