IDC Worldwide IT Cloud Services Taxonomy, 2012 http://goo.gl/Que0E

1. INDUSTRY DEVELOPMENTS AND MODELS
IDC's Worldwide IT Cloud Services Taxonomy, 2012
Frank Gens Robert P. Mahowald
Richard L. Villars Stephen D. Drake
Tim Grieser Mary Johnston Turner
Laura DuBois Matthew Eastwood
Gard Little Melanie Posey
Rona Shuchat Satoshi Matsumoto
Chris Morris Vladimír Kroa
Margaret Adam David Bradshaw
www.idc.com
Chris Ingle Ricardo Villate
Nigel Wallis Stephen Minton
Mette Ahorlu
IDC OPINION
F.508.935.4015
The IT cloud services market continues to grow and evolve at an astonishing rate.
New offerings come to market regularly, often defining new functional segments and
new deployment options. This study updates IDC's cloud services definition and
deployment models. It also updates IDC's taxonomy of the IT cloud services market.
P.508.872.8200
According to IDC's definition, a cloud service must be a shared, multitenant service;
packaged as an integrated solution; available through self-service; provide elastic
resource provisioning; feature pricing that scales up and down with usage; leverage
standard networks and clients; and be "open" for integration and enhancement
through published application programming interfaces (APIs). IDC defines a variety of
Global Headquarters: 5 Speen Street Framingham, MA 01701 USA
emerging cloud service deployment models, including public cloud services, and an
expanding range of private cloud service deployment options, including dedicated
private cloud (DPC) and virtual private cloud (VPC) services. In this study, we share
IDC's high-level functional taxonomy of IT cloud services, which we have enhanced
and extended in the following ways:
 U.S. National Institute of Standards and Technology's (NIST's) three broad cloud
service categories — software as a service (SaaS), platform as a service (PaaS),
and infrastructure as a service (IaaS) — have been added as a new top layer to
IDC's IT cloud services taxonomy.
 IDC's previous IT cloud services taxonomy has been "plugged in" below the NIST
model, providing clients with much deeper levels of cloud services market
definitions heretofore lacking in the simple NIST framework.
 Network and client functionalities, delivered as cloud services, have been added
to the taxonomy.
 IDC's application development and deployment (AD&D) cloud services segment
has been renamed (as PaaS) and revamped to reflect how cloud services are
changing that important part of the market. A new PaaS category — cloud
application platforms, focusing on the strategic integrated PaaS segment that
includes Microsoft's Azure, salesforce.com's Force.com, and other platforms —
has been defined.
Filing Information: March 2012, IDC #233396, Volume: 1
Cloud Services: Global Overview: Industry Developments and Models

2. TABLE OF CONTENTS
P
In This Study 1
Methodology ............................................................................................................................................. 1
S i t u a t i o n O ve r vi ew 1
What's New in IDC's IT Cloud Services Taxonomy? ................................................................................ 2
What Are "Cloud Services?" ..................................................................................................................... 2
Eight Cloud Services Key Attributes .................................................................................................. 3
Comparison with NIST's Cloud Computing Definition........................................................................ 7
Cloud Services Deployment Models ......................................................................................................... 8
More Detail on Public and Private Cloud Service Deployment Models.............................................. 8
Private Cloud Services Key Attributes (Points of Note) ..................................................................... 10
IT Cloud Services Taxonomy: Key IT Cloud Services Categories ............................................................ 12
Our Starting Point for Cloud Services Segmentation — IDC's Functional IT Market Taxonomy ....... 12
Important Changes for IDC's 2012 IT Cloud Services Taxonomy ..................................................... 13
Definitions of the IT Cloud Services Segments.................................................................................. 16
Future Outlook 17
Essential Guidance 17
Learn More 19
Related Research ..................................................................................................................................... 19
#233396 ©2012 IDC

3. LIST OF TABLES
P
1 IDC's New IT Cloud Services Taxonomy, 2012 ........................................................................... 14
2 IDC's Old IT Cloud Services Taxonomy, 2008–2011 ................................................................... 14
©2012 IDC #233396

4. LIST OF FIGURES
P
1 Cloud Services Key Attributes...................................................................................................... 3
2 Cloud Services Deployment Models ............................................................................................ 10
#233396 ©2012 IDC

5. IN THIS STUDY
The IT cloud services market continues to grow and evolve at an astonishing rate.
New offerings come to market regularly, often defining new functional segments and
new deployment options. This study updates IDC's definition of cloud services and
the various cloud services deployment models. It also updates and expands IDC's
taxonomy of the IT cloud services market.
Methodology
IDC developed its first cloud services definition in 2008 (blogs.idc.com/ie/?p=190),
and — while we have continued to refine and evolve our definitions
(blogs.idc.com/ie/?p=422) — you'll notice that our core definitional and taxonomic
principles have remained the same.
For this update to our cloud services definitions and taxonomy, we held extensive
discussions among IDC's global offices, sharing the latest observations and analysis
regarding cloud service providers' (cloud SPs') latest offerings and business/service
models, relevant technology/product trends, the activities of standards groups, and IT
customers' buying and usage trends. Because market definitions and taxonomies
should be crafted to be as durable as possible, while still being adaptable to important
market changes, IDC's analyst team invested many person-hours exploring what the
IT and cloud markets will look like over the next 5–10 years rather than creating a
simple map of the current market.
SITUATION OVERVIEW
The cloud services market continues to expand and evolve. Vendors with a great
variety of legacy products and services, management strategies, and experience are
entering the cloud services market, disrupting, diversifying and, sometimes,
complicating formerly well-understood market dynamics. In addition, users'
understanding and expectations about cloud services vary widely and are influenced
both by their growing cloud experiences on the consumer Web and by workplace IT
consumption habits built over the past 40 years.
To improve our market analysis and forecasting and help the market move toward a
common framework, IDC continues to evolve our IT market taxonomies on a regular
basis. There are substantial changes in the cloud services taxonomy from the
previous edition published in Worldwide and Regional Public IT Cloud Services 2011–
2015 Forecast (IDC #228485, June 2011).
©2012 IDC #233396 1

6. What's New in IDC's
IT Cloud Services Taxonomy?
IDC's most recent IT cloud services definitions and taxonomy information were
published in Worldwide and Regional Public IT Cloud Services 2011–2015 Forecast
(IDC #228485, June 2011). In this more comprehensive taxonomy document, there
are a number of enhancements to the definitions and taxonomy. Among these are:
 Adoption of the three NIST IT cloud services categories — SaaS, PaaS, and
IaaS — as the top level of our taxonomy. The addition of a new top level in
IDC's IT cloud services taxonomy is based on the widely used U.S. National
Institute of Standards and Technology cloud services categories: infrastructure
as a service, platform as a service, and software as a service. We've created
formal alignment of IDC's primary IT cloud services markets (e.g., applications,
application development and deployment, system infrastructure software [SIS],
servers, and basic storage) with these three top-level NIST categories.
 Expanded primary market categories. This new taxonomy expands the
number of primary IT cloud services beyond the original five, adding networks
(network functionality delivered as cloud services) and clients.
 "Other" SaaS, PaaS, and IaaS categories. To accommodate new and
compound solutions, we have added three "other" categories at the IaaS, PaaS,
and SaaS levels. The new categories accommodate new and/or complex cloud
services offerings beyond those that are cloud versions of simple primary market
product offerings.
 Expanded cloud deployment models. In our previous taxonomy, we defined
just three (public, private, and hybrid) cloud deployment models. In this study, we
expand our definitions to include several different private cloud deployment
models.
More detailed explanations of these changes are presented in the IT Cloud Services
Taxonomy: Key Cloud Services Categories section of this document.
What Are "Cloud Services?"
Cloud services are fundamentally about an alternative solution composition, delivery,
and consumption model — one that can be applied to IT industry offerings but also,
much more broadly, to offerings from many other industries, including entertainment,
energy, financial services, health, manufacturing, retail, and transportation as well as
the government and education sectors.
The cloud model goes well beyond prior online delivery approaches — combining
efficient use of multitenant (shared) resources, radically simplified "solution"
packaging, self-service provisioning, highly elastic and granular scaling, flexible
pricing, and broad leverage of Internet-standard technologies — to make offerings
dramatically easier and generally cheaper to consume.
2 #233396 ©2012 IDC

7. At a high — and overly simplistic — level, cloud services can be described simply and
informally as:
Consumer and business products, services, and solutions delivered
and consumed in real time over a network (most often, the Internet)
But this simple description is not sufficient to describe and capture the unique value
that the cloud model brings, and how it differs from traditional on-demand services
and online services.
Eight Cloud Services Key Attributes
IDC defines cloud services more formally through a checklist of key attributes that an
offering must manifest to end users of the service (see Figure 1). Cloud services, as
defined by IDC, require support of all of these eight attributes.
FIGURE 1
Cloud Services Key Attributes
Source: IDC, 2012
These attributes apply to all cloud services — in all public and private cloud service
deployment models — although the specifics of how each attribute applies may vary
slightly among these deployment models.
The sections that follow provide a more detailed explanation of what we mean for
each of these attributes. The final three cloud service attributes — ubiquitous
(authorized) network access, standard UI technologies, and published service
interface/API — are related to the same thing: leveraging the power of de jure and de
facto Internet standards to reduce costs, increase reach, and maximize
interoperability and combinatorial value creation.
©2012 IDC #233396 3

8. Shared, Standard Service
This is the most fundamental attribute of a cloud service, an attribute that is shared
with a wide variety of previous-generation online services, and the one that
differentiates cloud services from many traditional customer-unique outsourced or
hosted offerings.
Cloud services are shared, standard services built for a market, not for a specific
customer. These services present themselves to users as "multitenant" offerings,
although our definition — focused on the customer-facing aspects of cloud services
— leaves room for service providers to use a variety of underlying deployment and
architectural options.
"Standard" does not mean that services do not offer customers the ability to create a
"personalized" version of the service, however. Cloud services typically offer a wide
range of built-in configuration options that allow customers to personalize the service;
the key difference with traditional systems is that cloud services personalization is
based on choosing among commonly available, "engineered in" options rather than
making customer-specific "hacks" to the code.
The shared service model offers customers and suppliers both enormous operating
efficiencies and upgrade/enhancement velocity. In a private cloud deployment, the IT
department can be viewed as the cloud service "vendor" offering a standard service
within a single enterprise or across an extended enterprise.
Solution Packaged
One of the most obvious user benefits of the cloud service model is that it is
presented as an all-in, "turnkey" solution: the customer can access the offering
without the need to own, manage, or understand any underlying resources required to
support the offering. The cloud service provider bears that burden, offloading it from
the customer, making it much simpler and faster to adopt for customers.
One important implication of cloud services being technologically "easy" is that many
line-of-business (LOB) organizations without IT skills have been able to purchase and
leverage cloud services directly.
Self-Service
Cloud services allow customers' self-service capabilities for service provisioning and
administration. In the IT cloud services world, the range of self-service capability
varies widely up and down the stack: in the infrastructure-as-a-service area (e.g.,
cloud storage, cloud servers), "click to buy" provisioning is widely available today,
whereas much of the SaaS and PaaS community lags here.
While most SaaS and PaaS vendors provide a lot of self-service administration, there
is little click-to-buy provisioning simplicity and speed; some onboarding and more
complex customization functions typically require human intervention from the
provider's staff.
4 #233396 ©2012 IDC

9. IDC believes we'll see SaaS and PaaS vendors evolve in this area, providing more
automation around self-service provisioning. Customer self-service is a key tool for
providing greater operating efficiency, deployment speed, and customer satisfaction.
Elastic Resource Scaling
Rapid and flexible expansion (and contraction) of service usage is among the major
benefits of cloud services for users. Because the cloud services model allows users
to quickly access and utilize the services they require, when they require them, they
can greatly speed up systems' implementation/deployment.
Cloud services' dynamic provisioning (and de-provisioning) capability — including the
ability to access resources in finer-grained increments — also dramatically reduces
the need for costly overprovisioning. In addition, this characteristic substantially
reduces user burden to come up with demand plans for resources (CPU, storage,
network bandwidth, and support staff), which is a major challenge for organizations
and typically drives companies to greatly overprovision IT.
Like self-service, the way elastic scaling is manifested varies by the type of cloud
service offering. As for infrastructure-related services, such as server instances
(virtual machines) and storage, service expansion/reduction is possible on a very
detailed level such as the number of server instances, storage capacity, and data
transfer volume. On the other hand, contracts in the application field are based on the
number of users (accounts), but — optionally — contracts may not necessarily be
defined for individual accounts but for the entire user group.
In addition, there are cases in which a certain time is required to activate changes in
service contracts in the SaaS and PaaS worlds, although such changes can be
reflected dynamically (instantly) in the IaaS world. Still — even for SaaS and PaaS —
the time required to change cloud services flexibly is much shorter than the time
required to change traditional IT systems. This is because upgrading traditional
(noncloud) offerings typically requires additional resources — such as underlying
infrastructure and/or middleware components — to also be upgraded, and for
noncloud systems, these upgrades require significant manual effort. On the other
hand, cloud services are designed and deployed to promptly realize resource
reallocation, and the ability to respond quickly to changes is quite high. When
resources need to be reduced in on-premise services, doing so is often more difficult
to execute since spending on facilities and equipment is already on the balance sheet
and spending on personnel is not able to be rapidly reduced (or redeployed).
Elastic, Use-Based Pricing
Customers want services not only scaled to need but also priced to use, whether
that's in proportion to usage, the number of users, transactions, screen views, or
some other consumption metric. As a convenience to some customers, providers may
mask this pricing granularity with long-term, fixed-price agreements, but — to meet
the cloud service definition — suppliers must design their offering so they have the
capability to do fine-grained metering and pricing for customers that need these
services. In a private cloud setting, some IT shops may take advantage of the fine-
grained metering to support more detailed, usage-based chargebacks.
©2012 IDC #233396 5

10. Ubiquitous (Authorized) Network Access
This attribute means that cloud services are designed to leverage the most ubiquitous
public network on the planet. For public clouds, this is a no-brainer: it means services
must be accessible to (authorized) users that have access to the Internet. The core
benefit to both the service provider and the customers is broad, simple, and low-cost
access.
Obviously, this doesn't mean that a public cloud service is unsecured and unreliable;
rather, it means that the service provider (and customers) leverages security and
quality-of-service (QoS)/availability mechanisms that are Internet based (SSL, IP
VPN, CDNs, etc.) and take advantage of the huge marketplace of security and QoS
offerings that are building up around the public Internet.
For most private clouds, this attribute will still be a key one, especially where
employees are mobile, but we do see a model emerging for very secure private
clouds where access is restricted only through private IP networks. We are already
also seeing use cases where public cloud SPs offer customers with high-bandwidth
and/or security needs the ability to access the public cloud via private lines — one
example of what will be many "mashups" of public and private cloud services.
Standard UI Technologies
To clarify, we're talking here about the client and underlying technologies, not the
visual layout of elements on the screen (or a device). Cloud services should not
require any special heavyweight client environment (unlike the client/server world).
Like the network access attribute mentioned previously, this attribute is about
leveraging Internet-related de jure and de facto standards and technologies that are
widely deployed — and typically service/application independent — to give cloud SPs
and their customers maximum reach and access to leading-edge innovation at a very
low cost.
In the case of client technologies, we are talking about Web browsers, as well as
supporting technologies such as Ajax (asynchronous JavaScript, Dynamic HTML, and
XML), Flash, HTML, JavaScript, and SVG. Other service/application-independent
clients — such as AIR and Silverlight — that sit outside the browser but leverage the
same de jure and de facto standard technologies could also fit the bill as they become
widely deployed on users' devices. We are including de facto standards, so this
attribute obviously has some degree of subjectivity to it. The core thought behind this
attribute is this: SPs should leave the client choice for users as "open" as possible, for
their own, and customers', benefit.
IDC believes that service users, not SPs, should have the right to choose client
environments. Such an option will promote development and diversification of client
environments and eventually generate substantial benefits to cloud SPs and users.
Published Service Interface/API
The ability to combine services with each other, and to integrate them with traditional,
on-premise systems, is the foundation for being able to rapidly create — and,
importantly, allow others to create — new solutions and value, and therefore a core
element of modern cloud services.
6 #233396 ©2012 IDC

11. Published cloud service APIs transform online services from "islands" to high-
leverage building blocks within large innovation communities and marketplaces. It's
already obvious that cloud SPs that do not offer open/published, programmatic
interfaces — and thus fail to develop large ecosystems of solution developers around
their services — will simply not be competitive.
These APIs, and the ecosystems around them, will be the foundation for expanding
suppliers' market power. In our view, this is the brightest red line that separates first-
generation online Internet offerings and cloud services. It's no surprise that the first-
generation Internet businesses that have become cloud leaders — Amazon, Google,
and eBay — were among the first of the first-generation online/ecommerce providers
to open up their services with APIs and recruit huge developer communities.
In the IT industry, many SaaS/PaaS providers — and a fast-growing number of IaaS
providers — have published service APIs (SOAP, REST, etc.) that allow customers
and other vendors to access functionality within their offering; some expose a minimal
number of controls, while others publish many. But it's hard to imagine any successful
cloud services vendor not providing a way for its offerings to be leveraged for greater
value by customers, and by its own ecosystems. These APIs and the ecosystems
around them will be the foundation for expanding suppliers' market power. The
successful cloud SPs will have APIs in some form as the market matures, while
"walled gardens" will have a hard time being competitive in the cloud services space
— think "AOL versus the Internet."
Comparison with NIST's Cloud Computing Definition
Currently, market players often reference the U.S. National Institute of Standards and
Technology cloud computing taxonomy. NIST's definition of cloud computing is based
on service delivery/consumption model. There are many similarities between NIST's
"essential characteristics" of cloud computing and IDC's eight attributes.
The five essential characteristics of cloud computing as defined by NIST are:
 On-demand self-service
 Broad network access
 Resource pooling
 Rapid elasticity
 Measured service
The only major point of difference between NIST's and IDC's characteristics/attributes
is that IDC deems "published service/API" to be an essential characteristic of cloud
services.
©2012 IDC #233396 7

12. Cloud Services Deployment Models
At the highest level, the two types of deployment models for cloud services are public
and private:
 Public cloud services are shared among unrelated enterprises and consumers;
open to a largely unrestricted universe of potential users; and designed for a
market, not a single enterprise.
 Private cloud services are shared within a single enterprise or an extended
enterprise — with restrictions on access and level of resource dedication and
defined/controlled by the enterprise (and beyond the control available in public
cloud offerings); can be onsite or offsite; and can be managed by a third-party or
in-house staff. In private cloud that is managed by in-house staff, "vendors (cloud
SPs)" are equivalent to the IT departments/shared service departments within
enterprises/groups. In this utilization model, where standardized services are
jointly used within the enterprise/group, business departments, offices, and
employees are the "service users."
Two other often-discussed cloud service deployment model terms are hybrid cloud
and community cloud:
 Hybrid cloud: The term "hybrid cloud services" is used to describe the
consolidated coordination/management of multiple cloud services. Hybrid cloud
services include "public/public," "public/private," and "private/private"
combinations. IDC does not classify collaborations between cloud services and
non-as-a-service IT as hybrid cloud services.
 Community cloud: A "community cloud" is a multi-enterprise cloud service that's
been commissioned by, and is controlled by, a group of named enterprises (not a
market, or class, of enterprises). A community cloud is a type of private cloud in
that it's being built not for "a market" but for a specific, named group of
enterprises that have shared needs, control/specify the functionality of the
services, and share the cost burden. Alternatively, if a cloud service has been
developed by a third-party service provider for a specialized community of
interest (e.g., local governments) but is not owned in part by the
customers/community, and the customers don't have direct control over
specifying what the service looks like (at least not more control than big
customers have over, say, IBM or HP offering plans), and the SP is free to
market to other prospects with similar needs, then the cloud service would be a
type of public cloud or VPC (e.g., one designed for enterprises in a specific
industry). In short, the categorization of a multi-enterprise cloud service depends
on who owns and controls what the service looks like and who can join it. If it's a
named group of enterprises/customers, it's a community/private cloud. If it's the
SP, it's a vertical/specialized public or VPC offering.
8 #233396 ©2012 IDC

13. More Detail on Public and Private Cloud Service Deployment Models
Since the publication of Worldwide and Regional Public IT Cloud Services 2011–2015
Forecast (IDC #228485, June 2011), we have developed more granular definitions of
cloud service deployment models, identifying several deployments within the private
cloud category. These models — along with the public cloud deployment model —
are shown in Figure 2.
The two models on the left side of Figure 2 refer to two deployment models that
describe customer-owned private clouds in which the enterprise's IT department can
be viewed as an internal cloud service provider:
 Self-run private cloud. A self-run private cloud is a cloud service that an
enterprise owns and operates itself. The enterprise may have acquired the
hardware and software components required to build a private cloud and
assembled it (or had a systems integrator do so). Alternatively, the enterprise
may have acquired a pre-integrated private cloud system/appliance. The
commercial opportunities around a self-built cloud are to sell the required
hardware, software, and/or professional services. These "self-run private cloud"
opportunities are not counted in our IT cloud services forecasts but are counted
as use-case/workload segmentations of our hardware, software, and professional
services forecasts (i.e., hardware, software, and professional services sold to
support the development/operation of a customer's own private cloud).
 Managed private cloud. A managed private cloud is an enterprise-owned cloud
service that is operated by a third-party services firm. This is a less common model
and parallels traditional onsite managed services arrangements in which the
customer uses third-party staff to operate its traditional on-premise IT environment.
Focusing on the three third-party hosted offerings on the right side of Figure 2 — that
is, the models provided on a service provider's site, and the models IDC counts in our
IT cloud services forecasts — we've defined:
 Public cloud services. Public cloud services are shared among unrelated
customers and open to a largely unrestricted universe of potential users. Public
cloud services are designed for a market — not a single enterprise.
The other two hosted cloud service models in Figure 2 describe distinct hosted
private cloud service deployment models emerging in the market today:
 Dedicated private cloud service. DPC service is provided on dedicated/isolated
physical resources to a single enterprise or an extended enterprise. DPC
examples include Amazon EC2 Dedicated Instances, SAVVIS Symphony
Dedicated, and RackSpace Cloud: Private Edition.
 Virtual private cloud service. VPC service is a premium version of a public
cloud service, with tiered options for greater privacy/security and customer
control (e.g., VPN or private network access, firewall and IPS/IDS between guest
VMs and the Internet, and root access to guest VMs). Physical resources are not
dedicated to a single customer — allowing the SP and the customer to benefit
©2012 IDC #233396 9

14. from public cloud economics. VPC examples include Amazon EC2 Virtual Private
Cloud (excluding Dedicated Instances), SAVVIS Symphony VPDC, and IBM
SmartCloud Enterprise+. From a forecasting standpoint, VPCs are considered a
subset of IDC's public IT cloud services forecast; look for future IDC forecasts to
identify what portion of public cloud demand is for VPCs.
Over the next several years, we expect a steady market swing toward VPCs, as well
as a new generation of DPCs that use sophisticated resource management to deliver
dedicated resources from a highly efficient multitenant platform. This will be driven by
SPs becoming even more sophisticated in offering greater privacy, management, and
service-level options on top of their highly efficient shared cloud services offerings
and customers becoming more comfortable with multitenant environments.
One example of the new generation of DPCs is Amazon's Dedicated Instances, which
— through sophisticated scheduling software — allows customers to have a
guarantee of dedicated physical resources yet is delivered on Amazon's shared EC2
infrastructure. Once a customer terminates a dedicated instance, the resources are
released into the common EC2 pool; when the customer returns, its dedicated
instance will likely be set up on an entirely different set of EC2 resources. This
example shows why the lower bars in Figure 2 are overlapped — for the use case of
dedicated resources delivered on what is a multitenant delivery platform.
FIGURE 2
Cloud Services Deployment Models
Source: IDC, 2012
10 #233396 ©2012 IDC

15. Private Cloud Services Key Attributes (Points of Note)
We mentioned previously that the eight cloud service attributes apply to both public
and private cloud services — in other words, a cloud is a cloud. But there are some
nuanced differences in how some of the attributes are applied or interpreted in private
cloud environments.
The first important distinction is that with a private cloud service that is served up by
an internal IT group, it's important to note that the IT group is the "service provider"
and the enterprise users are the "customers." In assessing whether a private cloud
service is actually a cloud, the important perspective is "what does the end user
see/experience?" not what the IT staff delivering the cloud service sees under the
covers. If end users are seeing a shared service they access through a portal and
that allows them some control over configuration options, provides visibility of usage,
and is quickly able to scale up and down in both capacity and costs (if there is a
chargeback scheme) — then it can be considered a cloud. The IT department — as
the SP in this use case — may be provisioning the cloud with fixed resources (even
though they're presented as virtually "unlimited" to the end user) and may themselves
have a fixed cost for resources that support the cloud service delivery, but if the end
user's experience is of a "cloud" (all eight attributes), then IDC would consider the
private offering a cloud service.
The following summarize some nuances in the interpretation of key attributes of
private and public cloud services:
 Shared, standard service: In a private cloud, the multiple "tenants" sharing the
cloud service are typically not across multiple enterprises but different
constituencies within a single enterprise.
 Solution packaged: Same as public cloud services — the services are
presented and consumed as integrated offerings, without the need for users to
assemble, or be concerned with, underlying resources/components.
 Self-service: Same as public cloud services, services allow customers self-
service capabilities for service provisioning and administration.
 Elastic resource scaling: Similar to public cloud services, and as noted
previously, even though the IT department delivering the cloud service (the
internal "SP") may have fixed resources and costs under the covers of its cloud
service delivery, if the end users of the private cloud service are presented the
service as a scalable offering, it meets the elastic scaling criterion.
 Elastic, use-based pricing: Similar to public cloud services, the SP is able to
present usage detail to users. But for private cloud services delivered by internal
IT organizations, use-based "pricing" is not a requirement because many
organizations don't use chargeback as a funding process.
 Ubiquitous (authorized) network access: As in the case of the "standard UI
technologies" requirement, the principle here is that cloud services do not require
their own dedicated networks (just as they don't require dedicated client software
or hardware). For practical purposes, the vast majority of private clouds are built
©2012 IDC #233396 11

16. to be accessible over the public Internet for the simple reason that for many
employees, that is the primary network they have access to and use —
(authorized) accessibility over the Internet makes the private cloud more valuable
for most enterprises.
 Standard UI technologies: Same as public cloud services — the main issue is
that the service does not require a "heavyweight" dedicated client.
 Published service interface/API: In the case of private clouds, service
interfaces and API do not need to be widely published inside and outside the
company. However, the service interface/API can be easily leveraged by users
(IT administrators) within IT departments. And we expect, over time, to see more
private clouds that are "behind the firewall" implementations of public cloud
services, and share those services' APIs — making it easier for them to be
integrated in hybrid cloud environments.
IT Cloud Services Taxonomy:
Key IT Cloud Services Categories
Thus far, we've focused on describing what a cloud service is and what the most
common deployment options are. In this section, we describe IDC's taxonomy of IT
cloud services offerings — that is, just what categories of IT cloud services are
available (and what does IDC size and forecast), and how do these categories relate
to one another?
Our Starting Point for Cloud Services Segmentation — IDC's Functional
IT Market Taxonomy
As noted previously, IDC's most recent IT cloud services taxonomy information was
published in Worldwide and Regional Public IT Cloud Services 2011–2015 Forecast
(IDC #228485, June 2011). In that document, we noted that over the past several
years, we've used IDC's IT products' (hardware and software) functional taxonomy to
segment the IT cloud services market. We've chosen this approach as a starting point
for naming and functionally categorizing IT cloud services — rather than using the
widely cited, but not very granular, three-layer model described by the U.S. National
Institute of Standards and Technology — for the following reasons:
 The IDC IT product taxonomy robustly describes the vast majority of IT
functionality customers invest in, with hundreds of markets and submarkets
named, defined, and related to one another.
 This taxonomy is by far the most widely adopted model — by IT vendors,
customers, and investors — for describing and analyzing the IT marketplace.
 Using this existing functional taxonomy to describe IT cloud services helps
vendors and customers make the important connection between offering
categories they know well and invest in and the emergence of cloud service
versions of those offerings.
12 #233396 ©2012 IDC

17. This greatly facilitates the sizing and forecasting of the many cloud services
submarkets below the primary market level. Indeed, IDC analyst teams have already
started the process of sizing the secondary cloud services markets below the five
primary services discussed in this study. Examples of these more granular secondary
market forecasts include:
 Worldwide Public Platform as a Service 2011–2015 Forecast (IDC #232215,
forthcoming)
 Worldwide Public Cloud Application Platforms 2011–2015 Forecast (IDC
#232171, January 2012)
 Worldwide SaaS CRM Applications 2011–2015 Forecast and 2010 Vendor
Shares (IDC #232230, December 2011)
 Worldwide IT Project and Portfolio Management SaaS 2011–2015 Forecast and
2010 Vendor Shares: SaaS Drives IT PPM Adoption (IDC #232271, December
2011)
 Worldwide Cloud Security 2011–2015 Forecast: A Comprehensive Look at the
Cloud/Security Ecosystem (IDC #230389, December 2011)
 Worldwide Storage in the Cloud 2011–2015 Forecast: The Expanding Role of
Public Cloud Storage Services (IDC #232115, December 2011)
 Worldwide Software as a Service 2011–2015 Forecast and 2010 Vendor Shares
(IDC #229440, August 2011)
 Worldwide Cloud Testing and ASQ Software as a Service 2011–2015 Forecast
and 2010 Vendor Shares: Testing Emerges from and for the Cloud to Drive
Business Agility (IDC #229671, August 2011)
 Worldwide System Management Software as a Service 2011–2015 Forecast and
2010 Vendor Shares (IDC #229286, July 2011)
Important Changes for IDC's 2012 IT Cloud Services Taxonomy
For 2012, we have made some important changes and enhancements, on top of
IDC's traditional IT functional taxonomy foundation, to create a new IT cloud services
taxonomy. Table 1 shows the new taxonomy, which is followed — for the purposes of
comparison — by the old taxonomy (see Table 2).
©2012 IDC #233396 13

18. TABLE 1
IDC's New IT Cloud Services Taxonomy, 2012
IDC Top Level Primary Market Secondary Markets
SaaS Applications Collaborative apps, content apps, CRM, ERM, SCM, ops and manufacturing
apps, and engineering apps
System infrastructure System and network management, security, and advanced storage
software (SIS)
"Other" SaaS For new/emerging SaaS functional offerings not otherwise covered within the
traditional applications and SIS functional categories
PaaS AD&D Cloud testing, database as a service, integration as a service, cloud application
platform, data analysis and access, content management, app server
middleware, and other AD&D
"Other" PaaS For new/emerging PaaS offerings not otherwise covered within the traditional
AD&D functional categories
IaaS Basic storage
Server
Network
Client
"Other" IaaS For new/emerging IaaS functional offerings not otherwise covered within the
traditional functional infrastructure categories
Source: IDC, 2012
TABLE 2
IDC's Old IT Cloud Services Taxonomy, 2008–2011
Informal NIST
Alignment Primary Market Secondary Markets
SaaS Applications Collaborative apps, content apps, CRM, ERM, SCM, ops and manufacturing
apps, and engineering apps
PaaS Application Structured data management, app development, quality and life-cycle tools,
development and app server middleware, integration and process automation middleware, data
deployment access/analysis/delivery, and other AD&D
IaaS System infrastructure System and network management, security, and advanced storage
software
Basic storage
Server
Source: IDC, 2012
14 #233396 ©2012 IDC

19. The key enhancements we've brought into the 2012 taxonomy are as follows:
 Adoption of the three NIST IT cloud services categories — SaaS, PaaS, and
IaaS — as our top level. The addition of a new top level in IDC's IT cloud
services taxonomy is based on the widely used U.S. National Institute of
Standards and Technology cloud services categories: infrastructure as a service,
platform as a service, and software as a service. We've created formal alignment
of IDC's primary IT cloud services markets (e.g., applications, application
development and deployment, system infrastructure software, servers, and basic
storage) with these three top-level NIST categories. The NIST scheme has the
advantage of being simple and widely used. On the other hand, there is sparse
detail about which underlying market segments fit within each of these three
categories, so we've made some adjustments to IDC's former cloud taxonomy to
accommodate the adoption of NIST at the top level:
 "SaaS" segment redefined as apps and SIS offerings delivered as
cloud services. We are adopting NIST's narrower definition of SaaS, which
focuses just on applications and excludes AD&D cloud services. Within this
application-focused SaaS definition, we are also including all SIS software
segments delivered as cloud services since most can be considered
applications aimed at IT professionals; the ones that can't — such as
operating systems and hypervisors — are not counted as distinct cloud
services since they are bundled with infrastructure cloud services.
 Important: IDC's traditional "SaaS" market renamed as "cloud
software." With the adoption of the NIST definition of SaaS, we've relabeled
IDC's traditional "SaaS" market — which covers all packaged software
functionality (applications, AD&D, and SIS) delivered as cloud services — as
"cloud software."
 AD&D cloud services fully aligned with PaaS and revamped. In IDC's
updated taxonomy, we have chosen to align all of the application
development and deployment cloud services with the NIST "platform as a
service" category. Thus IDC's "PaaS" includes the functionality of all AD&D
secondary markets delivered as cloud services, including cloud testing,
database as a service (DBaaS), integration as a service, and other AD&D
cloud services (e.g., BI, content management, and app server middleware).
We have also expanded the PaaS secondary markets to include an
important emerging category — cloud application platforms, which are
"integrated PaaS" offerings such as Microsoft's Azure, salesforce.com's
Force.com, and Google's App Engine. Some in the market think of this
narrower group of integrated PaaS offerings as "PaaS" — it's important to
note our distinction: we consider PaaS to include not just the integrated
platforms but also component technologies (e.g., development tools, DBaaS,
and application servers) sold as standalone cloud services. This is
consistent with the principle that the top-level NIST taxonomy must be
collectively exhaustive and mutually exclusive.
©2012 IDC #233396 15

20.  Expanded primary market categories. This new taxonomy expands the
number of primary IT cloud services beyond the original five, adding networks
(network functionality delivered as cloud services) and clients.
 "Other" SaaS, PaaS, and IaaS categories to accommodate new and
compound solutions. We have added three "other" categories at the IaaS,
PaaS, and SaaS levels to accommodate cloud services offerings beyond those
that are cloud versions of simple primary market product offerings. Such offerings
could include complex/compound solutions that integrate the functionality of
multiple point solutions (such as cloud application platforms) and entirely new
offerings that were not previously offered in prior delivery models and are now
possible through the cloud model. Over time, as these "other" offerings become
better defined, and larger, we will pull them out of "other" into their own
categories (as we have with CAP).
Definitions of the IT Cloud Services Segments
Because IDC considers cloud services as a delivery and consumption model that can
be applied to virtually all traditional consumer and business product and service
offerings, our cloud services taxonomic approach has been to start with a foundation
of existing IT functional markets delivered as cloud services.
What this approach means is that the functional definition (with inclusions/exclusions)
of each cloud services segment (refer back to Table 1) is essentially the same as the
functional definition found in IDC's traditional IT products taxonomies but delivered as
cloud services.
For example, the functional description of the applications cloud services segment
(refer back to Table 1) is the same as that for packaged applications described in
IDC's Software Taxonomy, 2011 (IDC #228020, July 2011) but delivered as cloud
services. And the underlying secondary cloud services segments are functionally the
same as those within the traditional applications market (collaborative, content, CRM,
ERM, etc.) delivered as cloud services.
Accordingly, for more detail about the functional descriptions of each of our cloud
services segments, refer to the following IDC documents:
 For more detail on the application and system infrastructure software primary
markets and secondary markets, see IDC's Software Taxonomy, 2011 (IDC
#228020, July 2011).
 As noted previously, the AD&D cloud services segment was renamed platform as
a service and the secondary taxonomy "tuned" to reflect the emergence and
adoption of cloud services in this segment. For more detail on the PaaS primary
and secondary market segment definitions, inclusions, and exclusions, see
Worldwide Public Platform as a Service 2011–2015 Forecast (IDC #232215,
February 2012).
 Servers and basic storage include all server capacity and raw storage capacity,
respectively, delivered as cloud services. Storage-related cloud services that are
above and beyond raw storage — including backup, archiving, continuity, and
16 #233396 ©2012 IDC

21. data synchronization — are classified as advanced storage and categorized
under system infrastructure software cloud services (a submarket of SaaS). For
more detail on the storage and advanced storage cloud services taxonomy, see
IDC's Worldwide Storage and the Cloud Taxonomy, 2011 (IDC #228309, May
2011).
 The network and client cloud services segments are newly added to IDC's IaaS
cloud services category. For this document, we are simply and broadly defining
these as network functionality and client functionality, respectively, delivered as
cloud services. These segments will be defined in more detail in 1H12 as part of
IDC's expanded cloud services forecast process.
 As noted previously, the "other" SaaS, "other" PaaS, and "other" IaaS cloud
services segments are to accommodate cloud services offerings beyond those
that are cloud versions of simple primary market product offerings. Such offerings
could include complex/compound solutions that integrate the functionality of
multiple point solutions (such as cloud application platforms) and entirely new
offerings that were not previously offered in prior delivery models and are now
possible through the cloud model. Over time, as these "other" offerings become
better defined, and larger, we will pull them out of "other" into their own
categories (as we have with CAP).
FUTURE OUTLOOK
As noted, cloud services should be viewed as a delivery/consumption model that
may, and will, be applied to most traditional IT functional segments. But the new
taxonomy (refer back to Figure 1) is certainly not static. We expect wholly new cloud
offering categories to certainly emerge — and IDC will expand its cloud services
categories to incorporate functional offerings that fall outside of, or represent new
combinations of, our current IT taxonomy. But currently, the bulk of customer IT cloud
services buying can be tied directly to existing functional IT offering categories.
It is important to note, however, that while we generally use traditional IT product
markets naming (e.g., applications and systems infrastructure software) to describe
functionally similar cloud offerings, cloud versions of these offerings are
fundamentally different from the traditional offerings they mimic: IT cloud services
include all required supporting IT resources under the covers (i.e., they are online
versions of what used to be called turnkey systems). They are different from
traditional IT products in that they combine characteristics of both traditional IT
product and services delivery models.
ESSENTIAL GUIDANCE
Creating definitions and taxonomies around a market as rapidly emerging and
evolving as IT cloud services is challenging. But the core cloud services principles
that we identified in 2008 have held up very well and have kept our definitions and
taxonomy (and the forecasts built around them) from shifting much in the past four
years.
©2012 IDC #233396 17

22. These core principles that continue to inform our definitions, taxonomies, and
forecasts are:
 Don't "reinvent the wheel" by creating new functional markets where ones
already exist. Cloud services are a new delivery/consumption model that can be
applied to all existing functional offerings as well as enable entirely new offerings.
It makes absolutely no sense to reinvent new functional categories and names
for existing functionalities delivered through the cloud model; in fact, it makes it
harder to analyze the cannibalization effect: the shift of spending for a functional
capability across different delivery models. New categories and names should, of
course, be created when there are truly new functional offerings created.
 Pay attention to all eight cloud service attributes. Cloud services are about all
eight of the cloud attributes we identified in 2008 — including the often
overlooked but absolutely essential API requirement. The hallmark of the "cloud
services era" will undoubtedly be the emergence of huge innovator ecosystems
(and millions of new solutions) around those APIs. In the end, the innovation that
results from the "open API" principle of cloud services will be even more
important than the economic benefits of the "shared" and "scalable" principles.
 Acknowledge that cloud services are about what the customer buys, not
how the SP delivers it. Cloud services should be described by the attributes
customers experience, not by the implementation choices made under the
covers. That's why our eight attributes focus on things the customer sees and
experiences and don't mention implementation details like "virtualization." This
takes us out of the religious wars over what the best implementation
architectures and technologies are. Those choices are important, of course —
they are likely to determine who the winning suppliers are (and would be
factored, for example, in an IDC MarketScape vendor assessment) — but they
don't belong in the definition of an offering category like "cloud services." The
definition should be about what's delivered to a customer, not how it's delivered.
 Count the money where it's spent, and only count real cloud services.
Cloud services spending forecasts should account only for cloud services — for
example, if customers are buying cloud server capacity on which to run a
traditional business application, we count their cloud server payment in the cloud
server category; we don't count their application payments to their ISV in cloud
applications since the application itself isn't a cloud service — and only in the
cloud services category in which customers perceive they are buying — for
example, when customers pay for a CRM cloud service, we count those
payments in the CRM cloud services category; we don't spread their payment
across CRM and the infrastructure services the cloud SP may need to buy to
support their CRM cloud offering.
The good news is that it's very likely that these principles will remain valid for quite a
while. But the obvious challenge is that the cloud services market continues to evolve
in significant ways, almost daily. We will continue to monitor the market and look for
how these principles — and the definitions and taxonomy that are built on them —
need to change to adapt to the changing realities of this fast-moving market.
18 #233396 ©2012 IDC

23. LEARN MORE
Related Research
 Worldwide Public Platform as a Service 2011–2015 Forecast (IDC #232215,
Forthcoming)
 Worldwide Public Cloud Application Platforms 2011–2015 Forecast (IDC
#232171, January 2012)
 Japan Cloud Services 2011–2015 Forecast Update (IDC #JP1972808T,
December 2011)
 Worldwide SaaS CRM Applications 2011–2015 Forecast and 2010 Vendor
Shares (IDC #232230, December 2011)
 Worldwide Storage in the Cloud 2011–2015 Forecast: The Expanding Role of
Public Cloud Storage Services (IDC #232115, December 2011)
 Worldwide IT Project and Portfolio Management SaaS 2011–2015 Forecast and
2010 Vendor Shares: SaaS Drives IT PPM Adoption (IDC #232271, December
2011)
 Worldwide Cloud Security 2011–2015 Forecast: A Comprehensive Look at the
Cloud/Security Ecosystem (IDC #230389, December 2011)
 Hungary Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17873, November 2011)
 Croatia Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17723, November 2011)
 European Public Cloud Forecast Update (IDC #SP52T, November 2011)
 Poland Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17721, November 2011)
 Russia Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17640, October 2011)
 Slovenia Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17566, September 2011)
 Worldwide Software as a Service 2011–2015 Forecast and 2010 Vendor Shares
(IDC #229440, August 2011)
 Worldwide Cloud Testing and ASQ Software as a Service 2011–2015 Forecast
and 2010 Vendor Shares: Testing Emerges from and for the Cloud to Drive
Business Agility (IDC #229671, August 2011)
 Worldwide System Management Software as a Service 2011–2015 Forecast and
2010 Vendor Shares (IDC #229286, July 2011)
©2012 IDC #233396 19

24.  IDC's Software Taxonomy, 2011 (IDC #228020, July 2011)
 Worldwide and Regional Public IT Cloud Services 2011–2015 Forecast (IDC
#228485, June 2011)
 Asia/Pacific (Excluding Japan) 2011–2015 Cloud Services Forecast (IDC
#AP6684407T, June 2011)
 Canadian Public IT Cloud Services: 2011–2015 Forecast Overview (IDC
#CA2CCS11, June 2011
 IDC's Worldwide Storage and the Cloud Taxonomy, 2011 (IDC #228309, May
2011)
 Romania Cloud Services Market 2011–2015 Forecast and 2010 Competitive
Analysis (IDC #CEMA17725, December 2010)
 Defining "Cloud Services" and "Cloud Computing," blogs.idc.com/ie/?p=190
 "Defining 'Cloud Services' — an IDC update," blogs.idc.com/ie/?p=422
Synopsis
This IDC study discusses the IT cloud services market, which continues to grow and
evolve at an astonishing rate. New offerings come to market regularly, often defining
new functional segments and new deployment options. This study updates IDC's
definition of cloud services and the various cloud services deployment models. It also
updates and expands IDC's taxonomy of the IT cloud services market.
"This study provides the fourth update of IDC's cloud services taxonomy since 2008,"
according to IDC SVP and Chief Analyst Frank Gens. "Clients will be glad to know
we've maintained strong continuity with our prior taxonomies. But we've also made
some major enhancements, including incorporating the widely used NIST taxonomy,
adding important categories such as network and client cloud services, and adding a
new, strategically important segment called cloud application platforms that defines
integrated PaaS platforms such as Google's App Engine, Microsoft's Azure, and
salesforce.com's Force.com."
20 #233396 ©2012 IDC

25. Copyright Notice
This IDC research document was published as part of an IDC continuous intelligence
service, providing written research, analyst interactions, telebriefings, and
conferences. Visit www.idc.com to learn more about IDC subscription and consulting
services. To view a list of IDC offices worldwide, visit www.idc.com/offices. Please
contact the IDC Hotline at 800.343.4952, ext. 7988 (or +1.508.988.7988) or
sales@idc.com for information on applying the price of this document toward the
purchase of an IDC service or for information on additional copies or Web rights.
Copyright 2012 IDC. Reproduction is forbidden unless authorized. All rights reserved.
©2012 IDC #233396 21