I hope you have been through my previous blogpost on how to have a stepped approach to evolve towards cloud. I described previously the first step, on how to make the inventory of workloads in your organization. The result of the first step is a list of workloads separated in two parts: (a) workloads with one ore more constraints and (b) workloads without constraints. In this blogpost I will take you through the next two steps that should bring you closer to cloud computing.

2. Prioritize the workloads to determine the best candidates for cloud

In this second step we will prioritize the workloads, which will enable us to determine which workloads are the best candidates for a move to the cloud. To complete this step you should do two things for each workload:

First, determine the benefits of having the workload in the cloud under the assumption that the workload is available as a cloud service, thus available as the most ideal situation in terms of cost and flexibility. You should not pay attention to the constraints imposed on the workload to determine the idealistic benefits. Typically you would quantify benefits such as business responsiveness, flexibility, cost (capex/opex), support level, skills maintenance, and others. Each benefit should be quantified on a weighted scale and then summarized

Second, determine the pain of moving the workload from its current environment into the cloud ; again do not pay attention to the constraints imposed on the workload. Typically you would look at the pain caused by the impact on the change of technology, by the requirements on availability, by the requirements on security, and other.s Also here, these pains should be quantified on a weighted scale and the summarized.

The outcome of this exercise is a table of workloads, with for each workload a quantified benefit (summarized benefits into the first number) and a quantified pain (summarized pains into the second number). You can now put this table of workloads into a two dimensional graph with the quantified benefit as the first axis, the quantified pains as the second axis, and the workloads plotted on the graph as dots. This allows you to group the workloads into three clusters: (1) the first cluster are the workloads with great benefits and a low pain to migrate, consequently are these the best candidates for cloud, (2) the second cluster are the workloads with low benefits and a big pain to migrate, consequently these are the worst candidates for cloud, and (3) the remaining workloads are in between the previous two clusters, we call these the potential candidates for cloud.

We have now determined which workloads are tangible the best candidates, those that are potentially candidates, and those that are the worst candidates to move to the cloud. We can now proceed to the third step.

3. Determine the destination area of the workloads

In the third step we will determine to which level of virtualization and which level of collocation of cloud we will move the workloads to. I propose to use the two dimensional graph depicted below.

On the horizontal axis we have the level of collocation, from private cloud to public cloud, and on the vertical axis the level of virtualization, from infrastructure as a service to business as a service. On the bottom I included the traditional IT environment. The trend is to move workloads from the traditional IT environment to the right for reasons of cost, and to upper levels for reason of responsiveness.

In this step we determine the landing areas for the workloads. Here we take the constraints imposed of the workloads into account. For each workload we see how far we can move it to the upper-right corner. Constrained workloads will be typically situated more to the left compared to unconstrained workloads. This result in a graph as an example depicted below.

We can now know the target areas for cloud, these correspond to area where we have potential workloads landing. In the graph above we have shaded the area of constrained workloads red and shaded the area of unstrained workloads green.

In my next blogs on cloud I will further elaborate on the next steps towards cloud. Come back soon!