I have been blogging about the Cloud for a while, primarily from the perspective of moving real and important work into the Cloud. By important, I mean workloads that if they “fail” can have a noticeable negative impact on your organization. This impact could be reputation, financial, or even legal. I have tried to explain why, from a business perspective, it is important for organizations to consider moving to the Cloud. The Cloud must be driven by business requirements, with the technology requirements geared to support them.
But the Cloud is not a product; it is a concept. Moving to the Cloud is not an event; it is a journey. I have provided some guidelines on selecting that first application to move to the Cloud and a ten-step process to move an application to the Cloud.
During your journey to the Cloud you will be presented with a lot of FUD (fear, uncertainty and doubt), even from the “supporters” in your organization. You may be getting direction to save money, reduce capital expenses, make IT more responsive to the needs of the business, and streamline the IT staff – all of which sounds like “To the Cloud with haste!” There is, however, always the little caveat “Don’t screw anything up.” There is good reason for the FUD. Moving to the Cloud can pose significant risks, and they must be understood up front, eliminated or at least mitigated during implementation, and continually monitored and managed over time. These risks usually fit into five categories:
Your Cloud solution must protect your data as required by compliance and legal regulations.
Your Cloud solution must provide the needed level of performance, probably measured in terms of response time: how long did it take before the end user received a “did it” notification.
Your Cloud solution must be available to your customers, employees and partners when they need it.
Your Cloud solution will change who controls your data and some of your processes. What negative results could occur because of this change of control?
The Cloud is different. There are probably people in your organization who resist change, sometimes because they are concerned for their own job, don’t want to learn something new, or just because “We have done it this way for years.”
These risks exist because you are bringing a new partner into your organization, the CSP (Cloud Service Provider). The CSP will have significant control over your data, and the performance and availability of your applications.
For each application you will need to identify the security, performance and availability requirements. They will help determine how to implement the application in the Cloud, and help you decide which of the multiple of CSPs can deliver an appropriate solution. You will need to identify the control issues, and determine that they are resolved appropriately. Often the “control” issues are really “fear of change” issues. These can be the most complicated to deal with, but I strongly recommend that you attack those from the very beginning. Talk to all of the stakeholders, get their concerns, and make sure you keep them informed throughout the process. Provide them with detailed information about how you are going to deal with their issues.
In a blog 18 months ago, I talked about how these risk areas are shared between the CSP and your organization. The bottom line: the CSP will limit their financial liability. Ultimate responsibility resides with your organization.
You don’t need to start with the hard stuff. Sometimes, the best way to start is with something easy. The application still should be important – you want people to notice that the Cloud worked and provided real benefit to the organization.
If it is really simple, just do it.
What is a “simple” business application? To me and 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).
- Doesn’t involve a lot of data (more than a few gigabytes).
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 process 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, a new geographic market, 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.
Start with a pseudo-Cloud. Four weeks ago I wrote about companies that provide services with Cloud in their name but which are really managed services, perhaps using your own IT infrastructure in your own facility. While they may not be the Cloud by definition, their solutions have a lot of Cloud attributes and can provide at least some of the benefits. They also represent less change and less transfer of control, so may be more palatable to some important stakeholders.
It really doesn’t matter how you start. It matters that you start the journey, and that the first effort is a measurable success.
The last word:
Next time I plan to talk about how you and the CSP can agree on how your will jointly manage the risk.
Keep your sense of humor.