Recent OVUM Cloud Forum 2012 as well as other events and publications demonstrate a shift in Cloud’s consumer’s attention (What is Happening to Clouds and Who is at Fault?) from technical to business aspects of Cloud Computing (hereinafter, Cloud), particularly, to its usability from business perspectives.
It seems that 2012 will be the year of business challenge for the Cloud. Many companies have ‘tried the water’ of the Cloud already, others are thinking about the Cloud and intensively looking up around the world for the practical advices, tips and warnings from those who analyse and/or use the Cloud already. However, if someone offers a word of caution, it is not easy to be heard through the marketing noise of the Cloud in both technical and monetary realms. It is even more difficult when corporate business does not want to listen to the voice of IT departments (that frequently set the business up by delivering much less than was required) and bravely steps into the market of the Cloud viewing it as of an IT off-premises, which it is not.
I think that Cloud clients are not and will not be just IT departments; Cloud clients are the businesses that may or may not have their own IT. Here, I offer my pragmatic but innovative checklist of artefacts a client company better be aware of to require certain deliverables from Cloud providers before signing a contract with any one of them. Additionally, as an example of a proactive thinking about corporate own interests, I propose a solution for inter-Cloud security that can reduce the cost of ownership of a Cloud-bases interactions (see an e-Course “How to Save on Security in Clouds: a Gateway service”) .
For the purpose of this publication, I refer to Public and Private Clouds only. The core differences from the client’s perspective between these two types are in 1) cost; 2) reliability; 3) convenience to work with; 4) visibility into actual state and status of client’s assets in the Cloud.
Artefact 1.
Principles of relationship that a Cloud consumer has to establish in all negotiations and contracts with a Cloud provider include as a minimum:
a) Preserve your own business and technological interest above an availability of Cloud services. The letter are “growing mushrooms after the rain” and if you do not find suitable service today, you’ll find it tomorrow, literally, just do your search.
b) Do not accept compromises because you will not have a control over them in the future (the Cloud is not your IT).
c) Turn a Cloud market into a consumer market and behave respectively.
d) Avoid “provider locking” by all means. Always be aware of competition in the Cloud market and demonstrate a potential Cloud provider your awareness. Construct the contract in a way that you would be able to change the Cloud provider at any moment you need; never give up you business flexibility because of technological difficulties.
e) Always leave the control over interactions with multiple Cloud providers (which you might need) in your company because nobody cares about your business more than yourself.
f) Approach all deals with the Cloud from the side of your business and technical risks. Gaining a little money for a ‘cheaper solution’ at the beginning and loosing much more by the end is a game-pattern for dilettantes.
Artefact 2.
Invest in an understanding of the difference between Public and Private Clouds, especially for the corporate top management. Note that a Hybrid Cloud is a masqueraded Public Cloud. The smaller a company, the more it inclined to accept a high risk for gaining more technical capabilities. The lageer a company, the more it persuades paying a little extra for Private Clouds for reducing uncontrolled risks of the Cloud.
Artefact 3.
The procedure of the Cloud provider’s background checking is different from such checking for other vendors of your company. Just asking a question “How long have they been in business?”does not work for Cloud providers because all of them are of age of pre- or primary schoolers. You have to apply the same checking methods and criteria that you would use to choose a collaborating partner. When you put your data and systems (tailored for your business) into Cloud, you give away a part of your company. Even if you still own them, you have only a de juro (de jure) ownership while de facto there is an additional owner in the game.
Artefact 4.
A Business Continuity of your company including all technical SLA characteristics is the key for all details of the contract with a Cloud provider. Your business must be clear about what will happen in a case of outage for particular Cloud (see example of Amazon outage) or if your Cloud provider is acquired or goes under an administration. A good provider usually protects all its systems (electricity , cooling, computers) via 100% functional redundancy for its own Disaster Recovery, but this is only the good one. In other words, no Cloud may undermine the Disaster Recovery of your organisation.
A regular back-up of your assets in the Cloud is a part of Business Continuity of your company. Make sure the details of the back-up offered by the Cloud provider are in the your contract.
Artefact 5.
Identify the assets you suggest to deploy in the Cloud and verify them from the business risk perspective. Business risks must include, first of all, a ‘rainy day’ scenario, i.e. your company should be ready at any moment to go without assets deployed with particular Cloud. You have to have a mitigation plan for such cases in spite of its cost (if the risk realises when you do not have the plan, you’ll pay much more). This relates not only to your applications and data, but also to all infrastructure, applications and data you might lease from the Cloud, for example, from IaaS and SaaS providers.
Artefact 6.
Make sure that the Cloud you think of guarantees compliance with all regulations that your own company is under. Also, make sure that this Cloud does not bring you more foreign regulations you do not want to deal with. For example, in the majority of EU countries, privacy of personal data is preserved by the Governments while the USA’s Patriot Act allows the USA Government to obtain your personal data from the businesses that are under the US jurisdiction. So, if your Cloud provider is an American company or if it stores your data-in-Cloud in the computers in the US, this provider is obliged to release your data to the US Government without your consent.
This requirement of Cloud compliance relates also to the policies on updates & upgrades of both your assets in the Cloud and the Cloud’s platforms themselves. Your contract has to state clearly: 1) the maximum latency a Cloud provider guarantees to implement any updates & upgrades that your company requires; 2) what impact on your company might be caused by any updates & upgrades of the Cloud’s platform initiated by the Cloud provider.
Artefact 7.
Consider a commodification of Cloud services. When you think about a contract with the particular Cloud provider for longer than 1 year, you have to remember that the trends in the Cloud market may change for such a period of time. For the next several years, it is expected that the quality of Cloud services will increase while the cost decrease.
It would be wise to reserve a re-evaluation of your Cloud service and even the provider in the current contract. This means that one of the conditions for contracting a Cloud service is that the service provider has to agree to review a market competitiveness of its own service for you after, e.g., 10 months. Also, if you are dissatisfied with the review results, you should be free from any penalties for terminating the contract with this provider after 12 months of execution. For instance, if you think about a 36 month contract, there may be two review points – on the 10th and 22nd months.
Artefact 8.
Require visibility on-demand into your assets in the Cloud and make it a clear statement in your contract. This means that you as a Cloud client should be able to find at any moment where your applications and data situate, who has access to them, who actually accessed them and when, how the SLA agreed with your Cloud provider has been preserved, when the modifications that you required were actually applied. You need such a visibility to meet the requirements of those who audit your company. You might have no such a visibility if you use a Public Cloud but you should be aware of this condition before you sign the contract. If a provider of a Private Cloud cannot deliver you required visibility, you can suspect that this Cloud is either not mature enough for you or not a real Private Cloud, i.e. it uses a Public Cloud somewhere in its network but had not disclosed this fact when signed the contract. Beware that Hybrid Cloud is just a masqueraded Public Cloud.
Artefact 9.
Verify that your contract specifies that the Cloud provider may not use any 3rd Party whose requirements to the identity and access controls are weaker than the ones you establish between your company and this Cloud provider. The latter may be engaged in network communications with other Cloud providers in a form that may affect your data and applications contracted with this Cloud provider. If a security of those communications is weaker than you consider for yourself, this constitutes an obvious additional risk for you that you might be not aware of. Even if your Cloud provider assures you that aforementioned communications are under control of a trusted authority like an inter-Cloud Identity Management System, this does not mean that you must trust this authority and rely on its protection; you have not evaluated and chosen this authority and its credentials may be OK for the Cloud provider but not for you.
Artefact 10.
Unification and standardisation are good for assembly business. For many others, it is very often that the uniqueness of your operations and systems have enabled your success. Remember that the more typical your business needs are, the easier for the Cloud provider to satisfy them. Therefore, the Cloud providers will consciously or sub- consciously try to squeeze your uniqueness into a unified typical format. Do not allow the tool drive the business; it should be the other way around.
Artefact 11.
When signing policies, processes and procedures of interactions between your company and the Cloud, for example, deployment process or failure recovery, consider business cultural aspects of your company. This will help to avoid significant resistance of your own personnel that will work with the Cloud.
Artefact 12.
Put special attention on the performance, availability and accessibility of the Cloud-based products including your own assets in the Cloud. The Cloud performance, as the recent researchers have shown, is the major client’s concern nowadays. Watch for integration between availability and accessibility characteristics in the SLA: a system may be available but not accessible via the network. Monitoring availability and accessibility characteristics is very important for your management of the relationships with the Cloud provider.
Artefact 13.
Ask your future Cloud provider for a test-version of offered Cloud service(s) that you will be able to use to test your connectivity and interactions. This is needed for your current project and for your future projects that might use Cloud services from the same provider. You will need to test your development with and in presence of those services rather than having them in your Test Environment.
Artefact 14.
Watch for fees (including hidden ones) like fees for an initial setup, ongoing consumption, updates, status requests, bandwidth limit related, number of users, recover from failover or disaster, and alike. Also, the contract has to define a cap on how much the provider may increase the rates and what contract termination options relates to this increase. As an advice before signing the contract, compare the TCO of your existing IT resources versus an accumulated cost of the Cloud-based solution over the period of time of 1 and 3 years; it is reasonable to suggest that your ‘rose’ expectations of financial saving may drop ‘down to earth’.
Artefact 15.
You can consider a scheme of penalties that the Cloud provider should pay to your company in case of violation of the SLA. You can estimate your potential losses (per minute/day/week) caused by the Cloud service downtime, and request compensation from the Cloud provider accordingly. These losses may include not only the lost sales but also the cost of increased support calls and mitigating operations on the side of your company as well as the loss of your brand goodwill.
Artefact 16.
A detailed Support Scheme is a must have section in the contract with a Cloud provider. Remember that the Cloud provider is a foreign independent business with its own internal policies and processes. However, a support is one of a few things that couple your internal business processes with the business processes of the Cloud provider. This is very sensitive matter, which, at the same time, may vital for your business. Requirements to the Support Scheme should be set adequately with the operational model of your corporate business.
HOW to ARCHITECT for DEVELOPERS 