SOLUTION WHITE PAPER

Five Steps to Effective Cloud Planning

Identify existing assets, assess your business needs,
and develop a technical and business plan for your cloud
Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Cloud Planning –Why Do It? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Who needs to be involved? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Steps to Effective Cloud Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
»» Step 1: Discovery and Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
»» Step 2: Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
»» Step 3: Costing and Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
»» Step 4: Planning for Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
»» Step 5: Designing the Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

The BMC Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Learn more . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Jim was debating the architecture of the cloud computing solution for his company. It was clear to him they would
need a provisioning engine, a self-service portal, and some mechanism for decommissioning services. But, even
before he put pen to graph paper, a few questions were nagging in his mind. Who would all the users of this cloud
be? What services would they need — and what options should he provide? How would this cloud interact with his
existing systems? Something told him he’d better take a step back and think through these topics before he started
drawing…

Executive Summary
Constraining and defining the role of cloud computing in your organization is a critical first step before designing
and building your cloud. You are going to have many groups associated with the cloud effort — producing it,
operating it, and consuming it. Identifying all those who will be impacted, whether they are initially engaged or
brought in later, will help prevent surprises along the way for all concerned.

Consider how the cloud will interact with the rest of the data center environment. Are there shared management
tools? Security requirements? Compliance rules? Or is your cloud an island? Now think beyond your data center.
Will you be leveraging public cloud resources, as well?

As you answer these questions, you will need to define the requirements, outline the different options, identify
the costs associated with delivering each option, and create an implementation plan.

Key steps to cloud planning include:

»» Discovery and assessment

»» Service design
»» Costing and pricing
»» Planning for capacity
»» Designing the cloud architecture

1
Cloud Planning –Why Do It?
A little IT planning saves millions of dollars and prevents failed projects, unmet expectations, and general
frustration. As with any business problem, before uncoiling a single network cable or procuring a single 64-way
box, it makes sense to take a step back and consider the best approach to addressing that challenge.

In the case of the cloud, that problem is often characterized as “more resources faster” or “less capex on the
books” or even “halting the surreptitious use of public cloud resources outside the boundaries of internal IT”.
These types of statements imply some defined goals and expectations for your cloud effort.

The other primary source of motivation often comes from industry buzz, in which the topic becomes so hot
and hyped that individuals in the organization feel “someone better look into what we’re doing with cloud.” This
second type of statement usually implies that there are not defined goals for the project. However, if you wish to
be successful with your cloud project, those goals should be articulated.

A good cloud plan can be created in a few short weeks, with the right people and the right motivations. Armed
with a plan, technology decisions will be easier to make, stakeholders will have properly set expectations, and the
implementation team will have a strong go-ahead to move forward.

Who needs to be involved?

Cloud planning not only engages the initial stakeholders in an organization, but also envelops users from across
IT and across the business. Gathering stakeholders early in the planning stage will ensure that their goals
are properly represented and that you continue to get their support as the project progresses. By considering
differing perspectives, you can also hedge against the risk of omitting key requirements that might significantly
impact the group. The goal is to set the tone of incremental delivery against the cloud requirements, with
collaboration along the way, when needed.

Potential cloud stakeholders to consider:

»» The cloud architect, if one exists in your organization, charged with designing the cloud environment
»» The IT operations team, who will look after the cloud once it is operational
»» The network team, upon whose resources and skills you will rely to network the cloud
»» The storage team, whose storage boxes will be critical to supporting cloud workloads — and for whom
demand may grow significantly with this new technology
»» The applications team, who are often the de facto “users” of the cloud — unless that premise is examined
»» The capacity and performance team, whose job it will be to ensure the cloud performs as well as — or better
than — the physical alternative

Other individuals within the organization can also shed light on the cloud planning process. These might include
representatives from finance (who can help determine how a cloud environment is funded — and how it
charges its users) and business representatives (who can help identify projects that could best utilize the cloud).
For example, if a bank is looking to increase the transaction capacity of its online systems, the target growth
numbers can help inform the capacity decision.

While it is important to consider all the stakeholders while designing a cloud, it may not be critical to actually
include all of them on an early cloud design team. Some organizations have found success by starting with a
small tactical team to build out an initial cloud with future broadening and ongoing development in mind. The
initial cloud offering would include only a handful of service offerings, and demonstrate the power of cloud. The
small initial team would then strategically expand its membership as it further pursues long-term options. 

2
Steps to Effective Cloud Planning
Step 1: Discovery and Assessment
The process of discovery and assessment looks for all workloads, servers, virtual machines (VMs), and
applications in an environment, and identifies any dependencies between them. Many companies do not have
an accurate, current inventory of both their physical and virtual environments. The first step to developing a
plan for your new cloud environment is to take a correct inventory of your current one.

While, at many organizations, discovery can be a manual, tedious, and time-consuming process, there are
alternatives. For example, the BMC Atrium Discovery and Dependency Mapping solution can be run on an
ongoing basis, or it can be run as a part of a professional services engagement to do a one-time assessment. It
automates the discovery process, cataloging all the elements in your data center and the dependencies that exist
between systems. The dependencies are particularly important when planning for the cloud, as failures can
occur when interdependencies are not properly configured, both in the cloud and across cloud/physical lines.

The next step in planning is to assess which among your existing workloads should be moved to the cloud.
Usage patterns, such as which workloads can be consolidated, which may need more resources, and which
are potential P2V (physical to virtual) candidates, should all be taken into consideration.

Key planning steps in discovery and assessment:

»» Identify existing physical and virtual resources and workloads

»» Map dependencies between VMs and physical machines
»» Determine the required levels of service critical to supporting the workloads
»» Identify areas of potential consolidation or greater resource needs
»» Locate key dependent services and multi-tiered applications

Step 2: Service Design

Service design is aimed at designing what to offer users through a service catalog. At its most basic, a service
catalog is a listing of services from which a user can choose, thus initiating the cloud service provisioning
process. When designing a service catalog, it is helpful to identify your cloud users to determine their needs.
Potential users to consider while designing critical services offerings include:

»» The development team of software engineers

»» R&D groups (for example, those engaged in scientific research)
»» The application team in charge of building and maintaining internal applications

The challenge of service design is that there is a natural tension between users, who want the ability to
completely customize their offerings, and the IT group, which has to maintain tight controls on the services in
the environment.

The role of the service catalog is to bridge that gap. The service catalog enables IT to define the areas of
configuration and choice that users can select, according to their role. Users then feel some measure of
customizability of their cloud services.

3
The following attributes are often defined in the service catalog:

»» Resource configurations – including CPU, memory, and storage allocations

»» Operating systems
»» Middleware stacks
»» Applications offered
»» Networking options – for both simple network configuration and multi-tenancy support
»» Compliance packages
»» Monitoring tools
»» Service levels
»» Prices associated with each component, if desired

IT can choose which services to offer to users and how customizable those services will be. At one extreme,
users can be offered a choice between only two or three non-customizable full-stack configurations. On the
other extreme, users can be offered an extensive set of choices for each component, enabling them to fully
customize their stack. A common middle-ground approach is for IT to determine which broad offerings should
be presented, which elements should be optional and which should be required (like compliance or monitoring),
and which users will be presented with which options.

Beyond the contents of the service catalog, service design also includes the design of the workflows that
support each provisioning process. For many, the workflow will be an automated series of approvals. But,
for some, human approval might be required, due to the sensitivity or scale of the request. Designing these
workflows is critical to service design.

Key planning steps in service design:

»» Distill various platforms and offerings into a critical subset

»» Identify key applications and optional services that will be offered for each type of user or role
»» Determine permissions on provisioning and approval workflows

Step 3: Costing and Pricing

IT typically needs to have an idea of what things are going to cost. In the cloud, however, it’s even harder to
associate costs to the department that is incurring them (since there’s no easy correlation between one physical
server and one cloud service). Each bit of hardware, each software license, and the human costs of managing
the environment on an ongoing basis all need to be priced.

Even if IT cannot implement true chargeback (the billing of each department based on its usage), at a minimum
it should be able to do “show-back” (the presentation of the theoretical bill, even if real money will never change
hands). Consequently, during the planning stages, an organization needs to develop a costing model for the
cloud environment, based on the organizations’ own costs.

With a chargeback model, users can see the prices for the services they are choosing in the service catalog.
Indicating a price will change behavior of the user. Just knowing it takes 3x the amount of money to support a
cloud service with more resources will often drive people to select the less costly alternative.

The final benefit of costing is to demonstrate to IT leadership some of the costs associated with delivering
the value of the cloud. Because IT always has to build out a cloud environment in advance of the requests for
service, all investments are made before a departmental “purchase order.” That investment is best justified with
some financials on the current environment, including the cost of operation. Thus, planning around costing is
supportive of a growing cloud environment.

4
Key steps for costing and pricing:

»» Establish appropriate tailored costing model for cloud resources

»» Input appropriate price information — from hardware to software and variable resources
»» Determine how IT will “bill” the business, if at all, for the cloud usage

Step 4: Planning for Capacity

When planning a cloud, you should consider how much cloud your organization is going to need, and begin to
plan out a growth rate. When virtualization was first implemented, people found that requests far exceeded
their expectations for virtualized resources — precisely because there was pent-up demand. Cloud will only
ease the procurement process and lower its costs, releasing more of this pent-up demand. Capacity elements
can be anticipated once the cloud is up and running, such as:

»» Over time, more and more of those existing workloads will move to the cloud environment
»» There will likely be a queue of requests that can be immediately fulfilled by the cloud environment
»» There will be more new requests than originally anticipated

In addition, IT should consider the possibility of using overflow capacity from a public cloud. Developing a
relationship with a public cloud can help buffer against potential spikes, if certain workloads can be sent there.

Key considerations for planning capacity:

»» Determine required capacity for existing workloads and new resources

»» Evaluate required buffers to achieve service levels
»» Identify physical resources to migrate into the cloud environment, and new resource investment
requirements
»» Consider public cloud resources to augment the capacity of the private cloud

Step 5: Designing the Architecture

A cloud may feel like a clean slate upon which a whole new, properly working, well run, solidly architected
infrastructure can be built. It often includes new or reasonably new hardware, storage resources, and
networks, as well as new stack elements (such as virtualization) and new paradigms (such as workload
mobility). There are probably also some new elements, such as customer self-service and the service
catalog.

At the same time, the cloud is still part of the IT infrastructure. It is still serving many of the same customers,
hosting most of the same applications, bound by the same security guidelines, and audited according to the
same regulatory compliance rules. All those previously built processes and policies should move seamlessly
onto the cloud infrastructure.

The process of defining the interplay between traditional management and cloud management is the cloud
architecture challenge. IT seeks to ensure that the best of security, compliance, change management, and
countless other nontrivial management investments are applied equally to the cloud — preventing the
need for a recreation for the new environment. Meanwhile, many of the archaic process and workflows can
be optimized to further automate a cloud environment, removing manual approvals and other barriers to
efficiency in the cloud.

Key considerations for planning your cloud architecture include:

»» Design the new cloud architecture — from servers to storage to network topology
»» Identify areas where traditional compliance, change management, and other functions could benefit the
cloud environment
»» Modify processes that could hamper the efficiency of the new environment
»» Create a data center architecture where the cloud is not an island, but an integrated component

5
The BMC Solution
Cloud computing promises to deliver significant benefits, but the road to designing and building a cloud is not
always straightforward. With BMC’s prescriptive approach, you will quickly establish a robust and scalable cloud
computing environment that delivers tangible business value with reduced risk.

BMC’s Baseline Discovery Audit provides a detailed understanding of your current environment. For each
instance, a wide variety of product and business application categories will be discovered (if present in
the environment).

Working in conjunction with BMC’s Baseline Discovery Audit, a Cloud Solutions Planning Workshop puts your
organization on the right path. This one-to-three week workshop is designed to help you:

»» Understand how your processes will need to adapt to address the unique requirements of cloud computing
»» Create a cloud strategy that directly connects business needs with IT requirements
»» Identify and reduce cloud implementation risks
»» Prioritize your cloud process improvement initiatives with a detailed 18-month roadmap

With BMC, you can develop a plan for your cloud computing that will support the unique needs of your
organization. BMC has implemented countless cloud environments at enterprises worldwide and has
tremendous experience in the challenges both for planning for and implementing cloud environments. With
our expertise and your organizational knowledge, together we can plan for a cloud that will rapidly bring value
to your organization — and continue to deliver for years to come.

Learn more
To learn more about Cloud Planning, please visit www.bmc.com/cloud.

Business runs on IT. IT runs on BMC Software.

Business thrives when IT runs smarter, faster, and stronger. That’s why the most demanding IT organizations
in the world rely on BMC Software across both distributed and mainframe environments. Recognized as the
leader in Business Service Management, BMC provides a comprehensive and unified platform that helps IT
organizations cut cost, reduce risk, and drive business profit. For the four fiscal quarters ended September 30,
2010, BMC revenue was approximately $1.96 billion. Visit www.bmc.com for more information.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be
registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other
countries. All other trademarks or registered trademarks are the property of their respective owners. © 2010 BMC Software, Inc. All rights reserved. *180241*