Moving to the Cloud is not an event, it is a Journey. One important feature of the Cloud is that it is not one size fits all. There are lots of different ways to get the services delivered. While due to performance, availability, compliance or privacy requirements, the Cloud may not be right for you. But you cannot be too small, or too large, for the Cloud to provide real business value.
The journey is all about moving one or more business applications to the Cloud. A business application is the set of software, system services and data required to perform a specific business function. Email is a business application. So is on-line ordering, customer relationship management, inventory control, delivery scheduling, in-company March Madness pool manager… It might be third party software, your own proprietary software, a collection of documents, or some combination thereof. It might also be an administrative function such as the testing of a new release, patch or process prior to putting it in the live environment.
Alternatively, it might be something that will only be needed for a short time (from hours through a month or two), where the cost of going through the ten-step recipe isn’t justified by the business value or risk of just doing it. The Cloud can be very good at allowing you to try something quickly and inexpensively; something like a new marketing campaign, a new process, even a new business application.
In these cases, pick up your credit card and go to any of the dozens of Public Cloud providers like Amazon, Google, or Microsoft and rent your own little piece of the Cloud.
If your business application is not that simple, then we have a ten-step recipe that is our paradigm for your journey to the Clouds.
Your business requirements must drive your technology requirements. Understand the business drivers and the compelling events that have led you to considering the Cloud. Success should be measured not by the number of business applications you have moved to the Cloud, but the real business value you have achieved to doing so. In order to determine that value, you have to measure it, and then you have to know what to measure.
Selecting that first, or the next, business application is a thoughtful and deliberate balancing act in five dimensions:
It is that last point that drives the ten-step process. You have to plan and test and measure to be successful and be able to prove it. This is also how you manage and control the risk. Once you have done it, you will be able to repeat it with more complex business applications with confidence.
You will need to create written requirements for this business application. In many cases, you may already have performance and availability SLAs (Service Level Agreements) in which case you may be done with those components. Your compliance and privacy regulations may restrict where and how your data can be stored in the Cloud. Write all of those requirements down.
As you write these requirements and SLAs, make sure you document exactly how they are measured. For example, most Cloud Service Providers (CSPs) measure response time only within their own facility. Your response time SLA may be from your employee’s, partner’s, or customer’s workstation. Those are a different series of measurements.
The Cloud can also offer increased benefits in the areas of disaster recovery or business continuance, backup, archiving, and geographic expansion. As you are looking at the requirements for the selected business application, take the opportunity see if there is additional business value in these areas. If so, specify the requirements for those, but make them optional requirements. Try to get at least a ballpark estimate of the value of each of these optional features to compare with their cost later.
When you are done, compare your requirements with what you have today. It is very easy to slip things in because they would be nice to have. When you find them, either “reduce” them to what you have today or calculate an approximate cost of matching them in your current environment. Otherwise, you will have no way to compare the cost in the Cloud with the cost in your current environment.Cloud Cube. Given a business application and its requirements, you must then decide whether the right Cloud solution is a Private, Public, Community or Hybrid Cloud implementation of Infrastructure as a Service, Platform as a Service, or Software as a Service. You will save more money with a Public Cloud than a Private Cloud, but you will loose a lot more control in the Public Cloud. You can usually get better security, and better performance and availability SLAs from a CSP with a Private Cloud.
There are hundreds of viable CSPs. Usually, they specialize in some subset of the Cloud Cube. You want to find the handful that can provide the part of the Cloud Cube your business application needs, and are satisfying companies like yours. Ask your competitors and your business organizations what they use. Once you have a short list, carefully read each CSP’s web site. Look for references that are somewhat like you, and contact those references. Contact their sales department and get a sales person assigned to you. Explain what you want to do. At this point, you will get an “of course” and hopefully some more information about their services in the area you require.
Then send your requirements to each of the selected CSPs. Ask for separate pricing for your optional and “nice to have” requirements. Give them two weeks to respond, although you should be prepared to extend that by one more week if they ask. You will usually quickly get past the sales person to a really knowledgeable tech person or team who will have a series of questions. Be prepared to answer them. You will almost always get a good response to your request.
Carefully evaluate each response for compliance with your requirements. Make sure you understand how they are measuring their SLAs. Watch for upsell attempts: the CSP will likely offer you a package of options and features, at extra cost. If you need them, or they are worth the cost to your business, then take advantage of their offer. However, don’t pay for more than you need. Often the various CSPs will not respond with exactly the same SLAs, so you will need to spend some effort to keep the pricing on a level field.
Watch for missed “must have” requirements. The easiest way is to make sure that you received a response for each of your requirements. If one is missed, even slightly, then carefully evaluate whether you can afford to have it missed. After all, you had originally indicated they were “must have” in step 3.
The CSP decision is important. You will probably be running this business application on this CSP for several years. Changing CSPs is not easy.
There is currently little uniformity in the contracts or even the terminology among CSPs. There are a number of areas that you should carefully examine in their contract. Among them are:
Most importantly, make sure your requirements and the CSP’s responses are part of the contract, as well as anything else that was committed to in verbal or written conversations during the negotiations.
Make sure your legal counsel carefully reviews the contract. However, it is important that your legal counsel understands your business. Ideally, he or she will have some experience with outsourcing, managed services or Cloud contracts.
You probably started the planning stage once you picked the business workload back in step 2. Now that you have selected the CSP, it is time to finish that plan. The effort required will vary based on the complexity of the business application chosen and whether you can shut it down for long enough to actually turn it on in the Cloud.
In all cases, the plan should include a test phase: move the business application and its data into the Cloud in a test environment. This will tell you how long it takes to move the data and allows you to make sure the application performs correctly and reasonably.
If necessary, make sure you also test the ability to sync up the data between the live environment and the Cloud environment and know how long that takes. If it takes longer than your “down” threshold, develop and test the mechanism to allow you to run the existing and Cloud environments in parallel for some short period of time.
Your CSP will provide lots of help in all of this. Most of them really understand these issues and have solved them for other customers. Don’t spend time or add risk by trying to do this on your own.
One thing often forgotten is to plan how to leave a CSP. At some point, you are likely to need to move this business application from the CSP, probably to another CSP. You may not have a lot of time to do that, and you are not likely to get the same level of support from your CSP. Ideally you should test that process prior to going live.
When ready, turn on the Cloud implementation and turn your internal one off according to your plan. Unless your compelling event really imposes a strict deadline, it is better to delay the actual move to production until you have successfully completed all of the testing. In most cases, the business impact of a few weeks delay is a lot less than the impact of a failure.
Periodically, probably at least once a quarter, measure actual performance against your requirements. Your CSP probably has tools to help you do that. Make sure you are meeting not only those requirements but also the business goals. If not, make the necessary adjustments.
The Cloud is constantly evolving. You should be prepared to take advantage of improvements as they become available, if they provide business value to do so.
After successfully getting that first business application into the Cloud, it is time to go back to step 2 and look for the next opportunity.
It is very important to identify the stakeholders of the selected business application and keep them informed throughout the process. Explain to them why you want to move to the Cloud. Involve them in the requirements process, at least to the extent of allowing them to comment. I recommend that sometime near the step 5 to step 6 transition that you prepare and give a presentation to all your stakeholders. Having their buy-in will make it much easier for them to approve what is happening. Give them an update after you have gone live in the Cloud, and involve them in your periodic reviews.
Two very important stakeholders are your legal counsel and procurement officer. Get them involved during step 2 and keep them involved throughout the process. It will save a lot of time at step 7.
This is not easy, but it can be very rewarding to your business. If you don’t have a staff with expertise in the ever-changing Cloud, get help from a recognized expert.
We offer a webinar on this topic to help you with thought leadership within your organization.