Moving to the Cloud - Establishing a Decision Process

[drus...@ca.ibm.com]

There have been some excellent comments to-date on what we need to
consider in “Moving to the Cloud” for the Cloud Computing Use Cases
White Paper (http://groups.google.com/group/cloud-computing-use-
cases). Rather than trying to put explanations in place for each of
the suggested considerations, it is worth stepping back and look at
establishing a process on how cloud services could be identified.

NOTE: The Cloud Consumer (CIO / CTO / CFO) will want to see a ROI from
moving a service to the Cloud and the Cloud Provider needs to make
money from hosting the service. Both those thoughts are valid.
Therefore, It is important to consider the business implications of
moving to the cloud first before applying rules to minimize risk.
Bottom line, if moving to the cloud does not have a positive impact on
the success of the business, then it's probably not worth doing.

Take a look at the following suggestions and let us know if this logic
makes sense and identify what you feel may be missing from the
following discussion.

Step 1 – Identify existing or new processes, services and data as
candidates to “Move to the Cloud”

Not all processes, services or data are candidates for the Cloud. If
we are going to use business criteria to identify cloud candidates,
the following are possible examples:

- Save money?
- Increase flexibility to handle fluctuating volumes ?
- Improved customer access / satisfaction ?
- Off-load work from existing IT environment ?
- Consolidate like work with other enterprises within the cloud?
- Other considerations ?

If the candidate, either, new or existing meets one or more of the
above then that candidate could potentially move to the Cloud.

Step 2 – Manage the risks for those candidates to be moved to the
cloud.

To get through managing the risk and make it easier, one needs a
starting point. If one considers the data aspect of the candidate,
then hopefully, all the other considerations become dependent on the
characteristics of the data to be considered to be moved. Examples of
data types are:
- Public access (think parts in a catalogue )
- Private access (info that is either confidential or needs to be
kept private or both)
- Shared data between enterprises
- Data that needs to be accessed 7 x 24
- Data that needs to have sub-second access time
- Other types of data

Once the data step has been considered and applied against the
identified candidates from Step 1, it is very important to identify if
that candidate can be separated from other processes, services or data
from services which are not identified as candidates. If the
identified candidate(s) can be executed independently then the risk
level can be assigned. As part of assigning the risk level one has to
consider the security policies assigned to the data. Other risk
considerations are SLA, Single Sign-on capability, availability,
disaster recovery, etc. can be determined. (Pull from the list that
the group has already created.) As part of validating the risk
assessment, one may also want to be able to test the candidate in a
Private Cloud environment, ensuring that the security policies
established by the enterprise are intact before deploying the service
to a Cloud Provider.

Step 3 – Metering

In parallel to ensuring that the risk issues have been determined and
addressed, then comes the cost of doing business in the Cloud based
based on data volumes and risk management.

For a service in the cloud, a cost factor will be assigned for
accessing the data. It is important to understand the cost equation
for the data access. The cloud consumer needs to project the average
access rates, the peaks and the valleys. By understanding the volume
projections and the access patterns, a cost can be estimated.
Remember, the CFO does not want any surprises at the end the month or
quarter, especially when the cost of running the cloud service exceeds
the budgeted amount.

The three steps represent an overly simplified approach to identifying
the right cloud candidates to migrate to the cloud. If these steps
make sense, then we can use these steps as a base.

It is important to have a repeatable process to qualify the value
and the risk of Moving to the Cloud, otherwise the wrong decision can
be easily made.

I look forward to your comments as we begin to build the “Moving to
the Cloud” portion of the Use Cases White Paper at
http://groups.google.com/group/cloud-computing-use-cases.

Dave

[Rizwan Ahmad (Ryu taichi)]

dear Dave 

this is good and I want to make some suggestions:-

the cloud user and provider are two entities that are incorporated to equally share the data and collective responsibility. The first step that you have mentioned is the basis of why a company needs cloud services. from the management perspective the company needs to decide on the relevant questions you posited. However, from the management and security perspective the company going for clouds needs to define extra variables and answers to the following questions:-

identification

classification of information assets for 

1. information assets that can be choreographed in the clouds in connivance to company's policy
2. quantification of information assets calculating the ROI
3. Risk assessment 
4. Processes required 
5. Process ownership (collective responsibility to formulate the balance of due diligence)
6. any legal compliance or arbitration within the jurisdiction?

for the second part here is my suggestion

Risk Management

1. Operational security which includes business continuity and information assurance
2. Risk assessment and probable definition of residual risk

I agree with the third but risk assessment for the operational cost can be added

the preliminary model. Dave suggested the process to be iterative so it can be enhanced with time.

Rizwan Ahmad

--
You received this message because you are subscribed to the Google Groups "Cloud Computing Use Cases" group.
To post to this group, send email to cloud-comput...@googlegroups.com.
To unsubscribe from this group, send email to cloud-computing-us...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cloud-computing-use-cases?hl=en.

[Edmond Lau]

For step 2, I would suggest to add topics like disaster recovery and
self-healing infrastructure. The procedures to procure these and
setting them up in place would be different in the public or hybrid
cloud use cases.

For step 3 - metering, I think we have to be careful with the "save
money" topic in step 1. Data-intensive applications can be expensive
if deploy to external cloud. We also need to highlight the money for
bandwidth usage, and impact to the internal network.

[Madhurranjan Mohaan]

Experts,

Good points. For point 2, I would also suggest looking at Cloud
security standards . Eg, getting the cloud provider certified with ISO
27001 before they can offer these Cloud services which also works in
the way of building confidence of the cloud customers to move their
data to the cloud.

thanks

Madhurranjan

[Rizwan Ahmad (Ryu taichi)]

dear Madhurranjan,

I think SAS 70 report should be aligned with ISO-27001/2 in order to safeguard customer.  

[Abhijit]

Dear Dave,For "Moving to Cloud", I think it is important to have the
clear cut information on SLA & SLOfor this please find my submission
and candidature for volunteer"What is difference between SLA &
SLO?"Service Level Agreement (SLA) is a contract agreement for the
specific services and commitments made between the contract parties.
It includes a Service Provider and it’ customer. SLA is a draft which
consist of languages which describes all the terms like overall
services, financial aspects of service delivery, fees penalty’s ,
bonus, terms & conditions. It also includes the specific governing
matrix governing the compliance of service delivery. This individual
performance matrix is called as Service Level Objective (SLO).There is
no rule for how many SLO’s are to be included in the SLA but what is
important is to monitor what matters most. Each SLO is single
measurable performance characteristic.Thanks and regardsAbhijit