Journey
Your Journey to the Clouds
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.
If it is really simple, just do it
What is a “simple” business application? In this context, a simple business application is one that:
Doesn’t involve data that is subject to compliance or privacy regulations.
Doesn’t have strict performance requirements:
There is no business penalty if it doesn’t respond “instantly” all of the time.
You don’t expect to push a high rate of transactions through the business application (a rule of thumb: more than 10 a second).
Doesn’t have strict availability requirements (i.e., there is no business penalty if it is only available 95% of the time).
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.
The ten-step recipe
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.
1. Understand your business needs
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.
2. Select the business application
Selecting that first, or the next, business application is a thoughtful and deliberate balancing act in five dimensions:
You want the business application that will provide measurable business benefit, whether that is reduced IT cost, reduced management aggravation, or increased agility to react to seasonal or unexpected business opportunities.
There must be a low risk of damaging the business due to the delay or failure of the project.
It should not have extreme requirements in the areas of security, performance, availability or the amount of data it requires. On the last item, up to several terabytes should be OK, but if you measure this business application’s data in petabytes, then I would select another business application as my first Cloud exercise. For the other items, you can go significantly beyond the “really simple” application limits suggested above, just don’t try for more than 99.9% availability or a few hundred transactions a second, and don’t try where the data is covered by some of the more stringent compliance requirements (e.g., PCI).
It must be “Cloud-ready.” In most cases this means the applications have already been virtualized in your own environment. If not, then take that step first before you move it to the Cloud. That includes verifying that the business application continues to operate correctly and performs well enough. In some cases, that can occur in parallel with steps 3 through 6.
It must be important enough that people will notice that it in fact continued to operate at least as well when it reached the Cloud. If no one cares, you risk not impressing the people that will have to approve your next Cloud project. Your in-company March Madness pool manager is not a good choice.
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.
3. Create Requirements
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.
4. Determine where in the Cloud it goes
There are a lot of ways to deliver Cloud Services. We represent those with our Purposeful 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.
5. Select a set of candidate Cloud Service Providers
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.
6. Submit the requirements and evaluate the responses
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.
7. Negotiate the contract
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:
Who owns the data?
Some CSPs will specify that they do.
Where is the data?
Some CSPs will not tell you where your data will be stored, even to the level of which continent. Most reserve the right to move your data around and store it multiple places without telling you.
Who has access to your data?
What controls do they have on physical access? What do they say about how they vet their employees and partners who have access to your data?
Performance SLAs.
Carefully read and understand what is being measured. It is usually only within their own facility. You will need to add any Internet-induced delays to make sure you can meet your performance SLAs. For example, Internet delays add more than one quarter second to response time between the east coast of the US and India. Every contract I have ever seen caps the penalties at your monthly Cloud fees.
Availability or up-time SLAs.
Carefully read and understand what is being excluded and how “down time” is calculated. Every contract I have seen caps the penalties at your monthly Cloud fees, and excludes the time spent performing software updates. In some cases those update interruptions are allowed to be up to 10 hours long, with two weeks advance notice. Most CSPs also do not consider you “down” if you can do anything for an extended period of time, usually between five and fifteen minutes. Make sure you understand how to translate their version of down time into your down time expectations as measured by your employees, partners and customers.
Termination.
Many CSP contracts allow the CSP to terminate the agreement for no reason on very short notice, sometimes as short as ten days. Most allow immediate termination for any violation of the contract. Some require that you pay for the entire term of the agreement if you terminate the agreement. Also pay attention to what the CSP commits to do with your data when the agreement is terminated for any reason.
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.
8. Plan the actual move in (and back out again)
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.
9. Execute the move
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.
10. Measure and review
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.
Keep your stakeholders involved
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.
Webinar also available
We offer a webinar on this topic to help you with thought leadership within your organization.
Key Services Links
