To begin with, let’s look at the definition of cloud. It is a well battered term for pretty much anything as a service these days. Combined with all of those “as a service” terms, you also have to look at the location of these services in the vein of public, private or hybrid. For the sake of this blog, we are going  to refer to the cloud as a service provided including infrastructure, software, backup, desktop in an easy to configure and rapidly deployed solution. Now with this “loose” definition you can pick any of the services and realize that there are several key points that must be evaluated for a successful “as a service” implementation.

The first and foremost consideration to build to is what I will call “confidence as a service.” With all of the following risks and concerns at the end of the day if there is no confidence in the solution and the provider, there is no need to follow the cloud bandwagon. This is true whether the services are in house, external, or some combination thereof. When a public cloud goes down, it tends to be extremely public and the post mortem investigations are painful to say the least.  In order to instill confidence in the solution I recommend considering the following points.

Portability should be high on your confidence building list. It is unfortunate that many of the cloud technologies are moving to proprietary methods. Once you move something in the cloud there is no guaranty that the same information will port to another cloud without a massive rework effort.  While there are various scenarios of what and when to move certain things to the cloud, careful diligence should be paid to what happens if you are no longer happy with or chose to replace the could service with another (internal or otherwise) in the future.  This type of vendor lock in can cripple an organization if they are no longer happy with the service being provided. Databases are a good example of this. Not everyone is on the same platform; and at times, when porting from one database application to another, is a pain at best.

What works in the cloud and what doesn’t?  This is certainly partly risk based and partly functionality based. Home grown applications may have a harder time moving to the cloud that CoS (Commercial off the Shelf) software type packages.  It is well worth the testing and development time to determine that all functionality is still going to be there on another platform.  This also holds true for virtualization projects whether they are in the cloud or not. In a public cloud the real benefit is that the bill will return to zero at some point. This is a great solution for one off high bandwidth and potentially high demand applications that will cause a spike in resources . A good example is a fast food restaurant that wants to have a coupon promotion. If it is a good restaurant this could cause an unacceptable spike which would have an adverse effect on normally needed resources. The application could move to the public cloud and the bill would return to zero at the end of the promotion without the need to increase bandwidth and resources to support the effort.

Vendor dependency is a growing concern for the hardware side of things. Some electronics manufacturers are locking down their components due to the proprietary nature of their management and hardware hooks. Some even lock down the cables that you can use with their solutions by adding encryption to the cables. Years ago, the end user community as a whole fought long and hard for open systems. To see this turning back, is a shame. While vendors will show you studies “proving” that a single solution is best, the truth is they may not be the “best” at everything within your or your providers required systems for the “as a service” functionality that you need. The fairly recent tsunami cause some vendors to have extremely extended lead times leaving those that were waiting to delay critical projects. Open systems are they key to assuring interoperability and help you to avoid vendor lock in before you can meet critical business needs. With mergers and acquisitions running rampant, it pays to have an open system. If the company you have engaged is proprietary and they are acquired by another company, you may find yourself with early end of life on your equipment.

IT can often be threatened by cloud deployments. The thought of moving corporate systems and resources to an outside entity can be job threatening, and let’s face it. We all need a job to feed ourselves and our families. While companies may embrace cloud technologies for certain applications, it is very unlikely that a company can operate every system in the cloud. But the threat certainly can slow adoption or force a company into a private cloud when another perfectly good opportunity is out there waiting to be used.

Security is always at the forefront of any savvy CIO/CSO/CTO’s mind.  And in fact, is the sole reason that some companies have shied away from cloud computing all together. When you think about cloud computing and cloud strategies, one of the first things you should do is a risk assessment surrounding the data you wish to put in the cloud. There is some low hanging fruit for cloud even at the government level. Think of tax offices that get slammed at tax time with form downloads. This is a good example of that low hanging fruit. The risk is minimal as this is already public facing information.  

For the fruit higher up the tree, private clouds are becoming far more attractive. There was recently a file storage company that found that all of the files on its cloud were wide open without security for 3 days.  The greater the risk, the greater the security needs to be. If a cloud provider can’t provide you auditable security measures – run! Stay private and protect yourself. But again, remember some things are well suited for the cloud and some are not. Where in the cloud you put them is your choice and in the end could be your success or your failure.

Another area to examine in the way of security is through IT policy. Cloud savvy end users can put information in the cloud and completely circumvent company policies. This is an area that is not often addressed in actionable HR policies, but may need to be in the near future.  IT security and getting around IT security is a bit like radar guns/cameras and radar detectors for speeding. If you don’t have a “where you put company information” policy, now is the time to do so whether you currently use clouds or not.  Users certainly have access to a lot of information and proactive beats reactive hands down.

Bankruptcy or going out of business is another concern with some providers. When the term cloud exploded and became pretty much every service, providers started popping up out of the woodwork. Vendors, likewise, began offering cloud ready products. Granted it is bad if a hardware vendor goes under, but if you are on open systems, you can generally recover from that block.

Recovery is way more difficult to do if it is your actual cloud provider that goes under.  It is important to understand how long your provider has been a provider and what their financial outlook looks like.  I know of one company that put their data at a cloud facility only to have it ceased for the asset value and they were never notified. It was a good thing that their information was test data, but at the same time they lost quite a bit of development time and revisions of code that were stored in the cloud.

Geographic diversity is a great thing to have where information is stored albeit applications, databases, etc. Companies may plan to choose to build two tier II data centers as opposed to one tier IV as the tier II’s can be built at a fraction of the cost, but also provide this diversity. Backing up data or moving data to the cloud can offer some of the same benefits. The issue arises with new legislation in many countries and being considered in others to control where exactly data resides. For instance, European Union countries require that private/personal information be stored in country. Countries like Australia go farther and require that it be stored in state. In a public cloud, it is prudent to try to ascertain where the information is and will continue to reside so that you don’t accidentally find yourself in violation of regulatory compliance.

IT may not be involved in cloud decisions. While this sounds absurd, the truth is there are several factors that may put things in the cloud. Not the least of which are well read CEO’s and CFO’s that may make the move decision without understanding risk factors. The onus then falls on IT to educate early before their job and the company data moves to the cloud completely. Those in charge of IT should have the company’s best interest at heart regardless. So it is a natural progression to learn about the benefits and risks of cloud in a proactive approach.

Tangible and intangible ROI calculations are difficult at best. It never ceases to amaze me how some companies completely butcher ROI and TCO calculations in marketing literature to justify their solutions to CFO’s and those with decision making powers. You must first determine what is “real” and what is “vapor” when you look into the calculations. For instance, not buying an email system compared to a cloud email solution can look attractive. But look at the items under the tangibles and intangibles. If you are going to have to buy a security appliance for all applications, you can’t use NOT buying it as a savings in the cloud. There are always going to be line items that work and don’t work based on a company’s individual circumstances. In some cases, it may be far more attractive than noted, in some far less. Know what your tangibles and intangibles are prior to evaluations and be open to others as the services change. Make sure you know the difference between one-time costs and those that are reoccurring in your calculations.

Standards are another sticking point in clouds. Unfortunately this is a world that is largely devoid of standards making open systems more difficult and some vendors loving the proprietary hooks they can implement to “lock you in.” Management standards may increase learning curves, devices required, and the intricacy /complexity of a variety of systems. Hopefully as end user demands increase for single open solutions, so will the solutions that utilize them.

Lastly, you are going to have to require some significant information from any cloud provider outside of what is listed above. They should have the same change management practices that you would demand (provided you do). They should have a high bandwidth architecture because they are not just scaling your needs and requirements but are also juggling that with several customers at once. If they aren’t operating their systems in their own data centers, SLA’s are going to be very tricky due to finger pointing and the good old fashioned blame game. You should know all of the equipment, vendors, and solutions they are using, if you plan to use their services long term. If you can arrange a site visit all the better.

Contracts for cloud services can range from the very simple for short term, to very complex for long term solutions.  It is in your best interest to do a little shopping to get a feel for what is being provided. Some cloud providers are asking users to forgo SLA’s (Service Level Agreements) and accept a “best effort” service.  While that may be fine for a service you don’t pay for, it certainly may not be acceptable for one in which you do! You should put as much due diligence into your cloud provider as you would put into your own systems.