Cloud Brokers MAKING ITAAS A PRACTICAL REALITY?

Transcription

1 Cloud Brokers MAKING ITAAS A PRACTICAL REALITY? This report examines what a cloud broker is, its components and functions, its role(s), its audience and how it supports the delivery of ITaaS by turning technology into service delivery. KEY FINDINGS If cloud is the on-demand version of computing, brokering is the on-demand version of IT procurement. A cloud broker is one capability of a cloud management platform (CMP). CMP suppliers are in a tricky position: They must preserve the agility and self-service model that led the business to adopt the cloud in the first place, while at the same time allowing IT to retain control. Cloud brokers business model is similar to those of traditional distributors, VARs and SIs but in the cloud world they must respond more quickly and be able to scale. Brokering is not about price, per se it s about matching workloads to the cloud to find the best performance match for those workloads. The trust that comes with branded technology is less important than getting the experience right. This market is not terribly meaningful from a revenue point of view today; however, it is very meaningful from a leadership perspective. OCT 2014

2 I 451 RESEARCH ABOUT 451 RESEARCH 451 Research is a preeminent information technology research and advisory company. With a core focus on technology innovation and market disruption, we provide essential insight for leaders of the digital economy. More than 100 analysts and consultants deliver that insight via syndicated research, advisory services and live events to over 1,000 client organizations in North America, Europe and around the world. Founded in 2000 and headquartered in New York, 451 Research is a division of The 451 Group Research, LLC and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication, in whole or in part, in any form without prior written permission is forbidden. The terms of use regarding distribution, both internally and externally, shall be governed by the terms laid out in your Service Agreement with 451 Research and/or its Affiliates. The information contained herein has been obtained from sources believed to be reliable. 451 Research disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although 451 Research may discuss legal issues related to the information technology business, 451 Research does not provide legal advice or services and their research should not be construed or used as such. 451 Research shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. New York 20 West 37th Street, 6th Floor New York, NY Phone: Fax: San Francisco 140 Geary Street, 9th Floor San Francisco, CA Phone: Fax: London Paxton House (5th floor), 30 Artillery Lane London, E1 7LS, UK Phone: +44 (0) Fax: +44 (0) Boston 125 Broad Street, 4th Floor Boston, MA Phone: Fax:

3 II Cloud Brokers TABLE OF CONTENTS SECTION 1: EXECUTIVE SUMMARY INTRODUCTION KEY FINDINGS METHODOLOGY SECTION 2: WHAT IS A CLOUD BROKER? WHAT IS ITAAS? WHY ARE BROKERS NEEDED? Figure 1: Best Execution Venue for Workloads by Cloud Type WHY BECOME A CLOUD BROKER? Figure 2: Entities Involved in Broker and Traditional IT Procurement SECTION 3: HOW DOES IT WORK? CLOUD BROKERS BROKERING THE SELFIE APPROACH DISTRIBUTORS-TURNED-BROKERS CLOUD EXCHANGES AND BROKER-DEALERS CLOUD MARKETPLACES INTEGRATORS Figure 3: The Cloud Broker Market Landscape SECTION 4: BROKER-ENABLING TECHNOLOGIES REQUIRED TOOLS AND FUNCTIONS Figure 4: Broker-Enabled Technology Market Landscape CLOUD BROKER AS PART OF A CLOUD MANAGEMENT PLATFORM Figure 5: Common Service Offerings of CMPs SECTION 5: GETTING INVOLVED CONSIDERATIONS WHEN BECOMING OR USING AN EXTERNAL BROKER SERVICE CONSIDERATIONS WHEN BECOMING AN INTERNAL BROKER

4 III 451 RESEARCH 5.3 THE ENTERPRISE ITAAS MATURITY MODEL Consumerization and Shadow IT Does the Organization s ITaaS Maturity Match the Technology Offered? Figure 6: The Enterprise ITaaS Maturity Model Where To Start SECTION 6: USE CASES AND ECONOMICS CAPGEMINI T-SYSTEMS VODAFONE ENTERPRISE PERSPECTIVE SECTION 7: MARKET OVERVIEW THE MARKET FOR CLOUD BROKER SERVICE PROVIDERS THE MARKET FOR CLOUD BROKER-ENABLING TECHNOLOGIES SECTION 8: CLOUD BROKERS: CONCLUSIONS AND RECOMMENDATIONS RECOMMENDATIONS FOR VENDORS RECOMMENDATIONS FOR SERVICE PROVIDERS RECOMMENDATIONS FOR ENTERPRISES RECOMMENDATIONS FOR INVESTORS INDEX OF COMPANIES 31

5 1 451 RESEARCH SECTION 1 Executive Summary 1.1 INTRODUCTION Cloud adoption is a fact. Demand for delivering IT at lower cost is growing and irreversible. The experience of using new style IT services principally cloud and new-generation applications underpins this shift. These economic pressures and the rise of the cloud have IT departments thinking more like businesses and striving to transform themselves from cost centers into IT as a service (ITaaS)-delivery organizations. The broker label has typically been used to connote a middleman who deals in a commodity and simply makes a small margin in buying and selling it focusing on the financial aspects of the transaction. But like the term private cloud which has been the battleground for endless definitional debates there seems to be a more commonly accepted usage emerging: A cloud broker helps customers use multiple cloud providers and gives them freedom of choice in which service is used for what purposes or workloads. It directly supports what 451 Research calls the operation of best execution venue (BEV) strategies. Carrying out BEV strategies involves a lot of complexity under the covers, handling APIs, configuration management, resource behavior differences and so on. But the net result is that customers should be able to use brokers to give them the same optionality as using cloud providers. It s been 18 months since our initial surveillance of the embryonic cloud broker market. Now it seems everyone wants to be a part of the cloud broker gestalt in one capacity or another. This report examines what a cloud broker is, along with its components and functions, its roles, its audience and how it supports the delivery of ITaaS by turning technology into service delivery. The report charts the cloud broker market, highlights firms that supply technology components and/or provide service delivery that support ITaaS, and scrutinizes the diverse range of business models that are either in play or being road tested. It also identifies technical, organizational and business challenges that remain unsolved or unresolvable. 1.2 KEY FINDINGS If cloud is the on-demand version of computing, then brokering is the on-demand version of IT procurement. A cloud broker is one capability of a cloud management platform (CMP). CMP suppliers are in a tricky position: They must preserve the agility and self-service model that led the business to adopt cloud in the first place, while at the same time allowing IT to retain control. Cloud brokers business model is similar to those of traditional distributors, VARs and SIs but in the cloud world they must be able to respond more quickly and be able to scale.

6 2 Cloud Brokers Cloud broker-enabling technology vendors provide tools that enable vendors and IT departments to act as brokers themselves. These tools may enable multicloud migration, management and billing, but it s still the role of companies and departments to pay bills directly to their cloud providers. A thousand CMPs are blooming; however, enterprises that are risk-averse will seek customer references and evidence of long-term sustainability before entrusting management tasks to third parties. Credentialing the approach with customer references remains a key challenge for CMPs and broker service providers. For consumers, cloud brokers provide the combination of free will to choose BEVs and a trusted advisor to help them make decisions. They also give the consumer someone to blame (and contact) when things go wrong, as well as a single view of the IT landscape. Successful CMPs will enable customers to consume the cloud the way they want to rather than enforce a prescriptive approach. For providers, cloud brokers offer a cheaper cost base, an easier justification as a trusted advisor, the opportunity to add value and a stickier solution. Increasingly, a CMP won t be considered full-service unless it can deliver a cloud broker function that provides BEV capabilities to users. Brokering is not about price, per se it s about matching workloads to the cloud to find the best performance match. The trust that comes with branded technology is less important than getting the experience right. This market is not terribly meaningful from a revenue point of view today; however it is very meaningful from a leadership perspective. Success is measured in usage, not providing brokerage to the galaxy of suppliers. Technology is the easy piece; enterprises need to understand their own level of maturity in using an ITaaS approach. A typical enterprise is running VMware with automation internally, has some Amazon Web Services running, has Azure via an enterprise Microsoft license and will be examining the suitability of OpenStack. That s a bunch of clouds which will need to be brokered. This is a long-term game. An IBM or HP can afford not to do anything here for many years and still come out on top by acquiring market leaders. We wouldn t bet against the CMP opportunity ultimately rolling up to the incumbent manager framework vendors that have proved very resilient over the years. Legacy CMPs by their nature tend to have strong integrations with traditional enterprise tooling, such as ITSM, and deep domain expertise around specific technology, such as on-premise VMware. The downside is that support for hosted cloud is an add-on in most cases it s not the DNA of the CMP and usually immature as well.

7 3 451 RESEARCH 1.3 METHODOLOGY This report is based on a series of in-depth interviews with a variety of stakeholders in the industry, including IT managers at end-user organizations across multiple sectors, technology vendors, managed service providers, telcos and VCs. This research was supplemented by additional primary research, including attendance at a number of trade shows and industry events. Reports such as this one represent a holistic perspective on key emerging markets in the enterprise IT space. Because these markets evolve quickly, 451 Research offers additional services that provide critical marketplace updates. These updated reports and perspectives are presented on a daily basis via the company s core intelligence service 451 Market Insight. Forward-looking M&A analysis and perspectives on strategic acquisitions and the liquidity environment for technology companies are also updated regularly via 451 Market Insight, which is backed by the industry-leading 451 M&A KnowledgeBase. Emerging technologies and markets are also covered in additional 451 channels, including Datacenter Technologies; Storage; Enterprise Platforms & Infrastructure Software; Networking; Information Security; Data Platforms & Analytics; Development, DevOps & Middleware; Social Business Applications; Service Providers; Cloud & IT Service Markets; European Services; Multi-Tenant Datacenters; Enterprise Mobility; and Mobile Telecom. 451 Research also has a robust set of quantitative insights covered in products such as Change- Wave, TheInfoPro, Market Monitor, the M&A KnowledgeBase and the Datacenter KnowledgeBase. All of these 451 services, which are accessible via the Web, provide critical and timely analysis specifically focused on the business of enterprise IT innovation. This report was written by William Fellows, Research Vice President, with substantial assistance from Dr. Katy Ring, Research Director Global IT Services; and Dr. Owen Rogers, Senior Analyst, Digital Economics. Any questions about the methodology should be addressed to William Fellows at [email protected]. For more information about 451 Research, please go to:

8 4 Cloud Brokers SECTION 2 What Is a Cloud Broker? Cloud brokering, in theory, is a simple enough concept facilitating the use of cloud resources from one or more providers. Unfortunately, this simple definition has the consequence that a great many entities have laid a claim to being a cloud broker. The result, in the spirit of cloudwashing that preceded it, is brokerwashing. So many companies are now using the term as a marketing slam-dunk that it has become devalued. However, it s important to recognize that this is still a real trend, and we must take care not to throw the baby out with the bathwater. Being a broker owning and operating a control plane, catalog or console that can automate scheduling, delivery and access to cloud services is shaping up to become a new and lucrative development of cloud adoption. Suppliers from all sides of the industry are pushing this battle from both technical and financial points of view. There s a spectrum of functions brokers can perform that extends from basic B2B meet-me and introduction services such as aggregation, federation, selection (decision engine), integration, migration and fulfillment to capacity management and optimization, billing, vendor management, contract negotiation and contract ownership. The more of these functions that are in place, the greater the broker capability, and, from the enterprise perspective, the bigger the headache as buyers experience the complexity of catalog sprawl from competing providers. Being a broker requires a range of supporting technologies, over and above a standard CMP. 2.1 WHAT IS ITAAS? ITaaS is an operational model in which the IT department acts and operates as a distinct business entity, creating services for the other lines of business (LOBs) within the organization. At its core, ITaaS is a competitive business model where an IT department views the LOBs as having many options for IT services, and the internal IT organization has to compete against those external providers for the LOB IT requirements. To pursue ITaaS as a strategy, certain tools are required to support cloud brokering on one hand and consumer-like access to services on the other. Internal IT departments need to move to a more ostensibly commercial footing, competing with service providers and technology vendors. Service providers themselves need to undertake radical internal change in order to restructure around the requirements of new-style IT service delivery. Because of the significant changes required on both the buy and the supply sides, this is not an instantaneous market development. However, few doubt its inevitability.

9 5 451 RESEARCH 2.2 WHY ARE BROKERS NEEDED? Users expect to be able to make rational decisions about how and where to run applications and tasks based on workload profile, policies and SLA requirements. Service delivery options are growing as the worlds of outsourcing, hosting, managed services and cloud converge. The most sophisticated IT users may choose to operate as brokers. However, even those with supplier management expertise will likely struggle with the complexity of mechanisms available in the as a service (-aas) world to manage services. Today, the reality is that most organizations, especially smaller ones, don t have access to more than a handful of cloud services the same kind of access they probably have to utilities as consumers. Indeed, where these relationships do exist they are mostly bilateral sourcing relationships between the end user and service provider. This is why we expect third-party tools and services, including technical and financial cloud brokers, business application marketplaces and other integrators, to play an important role in providing access to additional resources, services and BEVs for enterprise buyers. A cloud broker offers a service that procures and orchestrates BEVs on behalf of users. Some applications, workloads or service requests may be best suited to running on premises; for others a public, multitenant cloud may be sufficient, while a dedicated hosted venue may be necessary to meet others. Figure 1 from TheInfoPro Cloud Wave 6 Study shows how different venues and services will be required for different workload and application types. In an ideal configuration, a BEV wrapper describing the requirements of the application, workload or service request will enable it to be parsed by a CMP s broker (plus relevant decision and transformation engines) to automate procurement from the appropriate venue. FIGURE 1: BEST EXECUTION VENUE FOR WORKLOADS BY CLOUD TYPE Batch Computing Applications 55% 29% 8% 8% Customer-Facing Enterprise Applications 35% 39% 8% 17% Back-Office Enterprise Applications 32% 40% 8% 21% E-Business Hosting 27% 31% 10% 32% Test and Development of Applications 26% 45% 10% 19% Collaborative Applications 18% 26% 10% 45% Cloud-Native Applications 15% 8% 74% 3% Non-Cloud Private Cloud Hybrid Cloud Public Cloud

10 6 Cloud Brokers Brokers deal in multiple services, providing access, enablement, fulfillment and possibly contract ownership. Regardless of sector or vertical, their raison d etre is to arrange a transaction between a buyer and a seller. In the IT world, brokers have existed for decades vendors and service providers have relied on networks of distributors, resellers and SIs to match their products to their revenue-generating customers. What has changed is the nature of their roles: The cloud means that intermediary parties must operate dynamically and offer services on demand. In the traditional model of IT, distributors, resellers and SIs have not been consumption-based entities. This has meant long sales cycles, fulfillment measured in weeks or months and no guarantees a product would be in stock. In the cloud world, users expect services to be available as soon as they are requested. This is due in no small part to users experiences with consumer technology, which have set a high benchmark. And here lies the big difference between the traditional IT supply chain and the new cloud supply chain: If cloud is an on-demand version of computing, brokerage is an on-demand version of IT procurement. New markets and opportunities are emerging as a result: Vendors are selling technologies to create and operate brokers, and cloud broker service providers are emerging as both discrete entities and additional functions of existing market players. There are increased distribution opportunities and new target acquisition candidates for service providers themselves. Both internal and external buyers and sellers will require brokers acting as distributors, resellers or system integrators these are the broker service providers. And indeed within enterprises many IT departments expect to act as brokers themselves offering ITaaS, matching internal demand with external providers. Broker service providers, whether they are a third party or internal, need to deliver consumers on-demand access to disparate and aggregated cloud resources, either natively by the broker itself or federated directly from the cloud supplier. Broker-enabling technology vendors supply tools to create brokers. Using a broker model also has a range of other benefits. It: Enables effective data-driven decision-making by offering transparent choice in cloud services. Removes the pain of governance, procurement, utilization and settlement. Offers options and flexibility to avoid being painted into a corner. Uses decision engine and BEV wrappers to determine destination venue/service source automatically. Empowers enterprise IT, helping to turn it from a cost center into a service broker to the organization. Policy engine ensures IT retains control and provides DevOps with the agility and flexibility of on-demand resource access, thus offsetting the use of shadow IT. Reduces headaches in contract and vendor management. Role-based access and a single management pane to all services enable organizations to regain control of shadow IT.

11 7 451 RESEARCH Supports right-sourcing. Reduces time-to-use by using cloud broker as a trusted advisor to bypass lengthy RFP processes. Enables a user to move workloads without disrupting the business control, instead of relying on central IT to fully manage the workload. Matches workloads to cloud, rather than focusing on price. Provides a contractual arrangement for moving workloads from one cloud vendor to another should the need arise. 2.3 WHY BECOME A CLOUD BROKER? Enterprises will always desire a range of BEVs to address all their needs and preferences. The fact of the matter is that the cloud market is competitive, and providers that are not meeting enterprises demands risk losing business to their competitors. Enterprises want to deal with a small number of trusted advisors that can help them with all their requirements if a current provider is not taking on this role, someone else likely will. But providers should embrace this opportunity; the more services that a customer is taking from a provider, the more embedded that vendor is likely to become in the ethos of that company. This provides a private view of the organization s current and future requirements, which the vendor can addressed before its competition can. Once embedded, an element of lock-in is likely to take hold it s much more difficult to migrate interdependent, multicloud services that are integral to the customer than to migrate single-point services. Addressing customers needs is surprisingly simple: Using thirdparty services allows providers to choose the best-of-breed services for each particular aspect, meaning there is no need to compromise on quality. As technology evolves, new services from third parties can be added quickly and cheaply too; as the market evolves, providers can reach into new verticals simply by choosing new third-party services to include in its portfolios. These integrated services are also likely to attract greater gross margins, not just from the additional value generated, but also from a lower cost base. Fixed overheads mean that gross margins will grow with higher levels of consumption; only negligible increases in overhead are needed to resell 100,000 VMs to the customer, as opposed to 100. Self-service reduces the need for expensive sales staff to deal with every order and allows simple cross- and up-sell to new services. Pay-as-you-go pricing is only likely to encourage customers to self-serve with a greater volume of services as and when they need it. And as capital commitments are reduced and costof-sales can be directly attributed to consumed resources, the financial accounts are likely to look a lot more healthy too with potential reductions in bad debt and sunk costs.

12 8 Cloud Brokers FIGURE 2: ENTITIES INVOLVED IN BROKER AND TRADITIONAL IT PROCUREMENT CONSUMERS OF CLOUD SERVICES CLOUD BROKER SERVICE PROVIDERS INTERNAL BROKER SERVICE PROVIDERS SERVICE DELIVERY Distributor Value Adding Reseller BROKER ENABLING TECHNOLOGY PROVIDERS Cost Reporting System Integrator Transform & Integrate Decision Engine Enterprise Brokered Procurement Direct (Traditional) Procurement Cost Metering Cloud Management Platform Security PROVIDERS OF CLOUD SERVICES

13 9 451 RESEARCH SECTION 3 How Does It Work? 3.1 CLOUD BROKERS Cloud broker service providers manage access to and procurement of cloud resources up to and including owning the paper on the contract with the resource supplier and paying the bill. At one end of the scale, brokers can manage multiple clouds and move workloads into them with the consumer being billed directly by each cloud provider for the consumption that has taken place. At the other, a broker may buy and then resell resources to the consumer. It could be charging the customer directly for the resources it has already consumed, or it could wrap it into a higher solution price where the cloud component isn t visible. By taking advantage of instruments such as reserved instances, spot markets and on demand as well as wholesale and volume discounts, and other upfront commitments a provider may arbitrage its entire stock across the aggregated demand from customers and sell it on to them with a margin. In some cases, the cloud broker service providers will own the paper (the contract) for the resource contracts they manage and even procure. They must offset this cost by charging consumers enough that revenue exceeds the cost of these resources, and therefore a profit margin is achieved. Our research finds no single approach has any leading position. Dell, for example, owns the relationship (the paper) with the third-party suppliers; Capgemini, which will provide contract types, contract negotiation and vendor management to its broker customers, doesn t. Full cloud service brokers will deliver services from a self-service, user-operated master catalog. A decision engine will assess the suitability of service types to meet application and workload needs. A policy engine will govern what, where, when and how services may be provisioned. It can be optimized with different rules to support the CIO, LOBs, DevOps or other role-based needs. The key for brokers here is to preserve the agility and self-service model that led the business to adopt the cloud in the first place, while at the same time allowing IT to retain control. A billing engine consolidates all the metering information related to a specific customer account and provides automated billing. The engine triggers the provisioning of services via APIs. Performance management, incident management and user support are provided as a consolidated service. Key technology components include a decision engine that determines which services/ resources are the best fit and a transformation engine that provides workload and application migration. The cloud broker will typically package this as an offering to manage separate suppliers and deliver the SLA on behalf of clients. The cloud broker should be able to deliver as much management resolution as required, up to and including running the entire portfolio or enabling the customer to buy and implement the broker product/service but still manage the provider relationships itself. The broker may own contracts with cloud service suppliers that can be used by the customer, however, which party actually owns the paper on those contracts (the end user customer or the broker) isn t a default position.

14 10 Cloud Brokers 3.2 BROKERING THE SELFIE APPROACH A single cloud provider may offer a range of its own clouds both public and private hosted, and private on-premises. Enabling customers to choose any combination of these, including moving workloads between them, is one kind of brokering. VMware is an example of this. It facilitates the brokering of VMware services between on-premises use and its hosted vcloud Air (formerly known as vchs). Users can also access the vcloud Air Network of partners (VMware Service Provider Program, vcloud Director, etc.). Other service providers, such as CenturyLink, foreground the ability to use a package of services colocation, public and private IaaS, PaaS and developer environments that can be accessed and managed via the same portal and management tools. However, the commonly understood use of the term cloud broker implies access to multivendor services. For a service provider it means in some way offering and managing access to third-party services alongside native services. Many companies are adding access to and management of third-party services alongside their own. This is often brought on by a need to offer a public cloud service without having to develop it in-house. For organizations that do not already have a shared infrastructure cloud but plan to offer one, this will be the predominant model federating with Amazon Web Services (AWS), Azure and others. 3.3 DISTRIBUTORS-TURNED-BROKERS Ingram Micro and Arrow are examples of companies transitioning from IT distributors to cloud brokers by brokering access to cloud resources from a single location, with pre-negotiated discounts. These entities are similar to (or the same as) the IT distributors of old, as their role was to purchase hardware and software components for service providers and enterprises. The value distributors-turned-brokers offer is in providing consumers a single location from which they can access a range of products, and where negotiation and distribution is essentially outsourced. 3.4 CLOUD EXCHANGES AND BROKER-DEALERS A cloud exchange is a meeting place for sellers and buyers of resources. Two cloud exchanges are currently in development: Chicago Mercantile Exchange and Deutsche Borse are exchange providers working with broker-enabling technology vendors 6fusion and Zimory, respectively. Additionally, the Cloud Team Alliance and Helix Nebula in Europe also offer an exchange-type service for participants. A cloud broker may use an exchange to purchase and sell cloud resources on a provider or consumer s behalf. The resources are purchased as defined; the purchaser is responsible for architecting solutions using the acquired resources. Exchanges are also used by broker-dealers to purchase advance access to resources from a range of providers and then provide them to their consumers. The broker-dealer profits by obtaining a discount through the advance purchase of bulk resources; it keeps some of the discount for itself and passes some savings on

15 RESEARCH to consumers. The only such firm currently in the market is Cloud Options. It is likely that other broker-dealers will enter the market, but only if the exchanges achieve enough liquidity in the form of buyers and sellers. 3.5 CLOUD MARKETPLACES A cloud marketplace can also procure access to cloud resources on behalf of the consumer, while adding a level of value to the process. The marketplaces negotiate a price framework so that the marketplace and consumer save versus purchasing directly. The marketplace purchases resources on the consumer s behalf and then bills the consumer directly for consumption at the discounted rate. Offers typically bundle single sign-on (SSO), a single reporting pane, access control and simpler invoicing. The marketplace also takes away much of the architectural planning from the consumer and provider, usually allowing end users to buy resources (IaaS, PaaS and SaaS). Cloud marketplaces are similar to VARs that use many different providers and then help shape them into a single service. The cloud marketplace s value is in pre-negotiated pricing and tools to enable a single view of procurement. Most cloud marketplace vendors currently provide software that enables enterprises to act as their own brokers, including Verio, Jamcracker, ComputeNext and AppDirect. These companies still really act as broker-enabling technologies, specifically in the procurement sector. ComputeNext has a public marketplace that makes it both a cloud broker service provider and a broker-enabling technology provider. Cloud providers typically offer cloud marketplaces from which consumers can purchase cloud applications to be deployed as IaaS. In addition to deriving direct revenue through the sale, providers also benefit from increased IaaS consumption and offering a diverse range of products to meet customer needs with little cost or effort. AWS, Rackspace, IBM, Oracle, HP and CenturyLink, among others, provide such marketplaces. Because these services are being deployed on the providers own cloud, the providers cannot really be classed as cloud brokers. New entrants here include the datacenter and colocation operators, which are creating a form of cloud marketplace in which enterprises and vendors within their ecosystem can buy/sell directly within that network. Equinix, Digital Realty and Switch are examples. They foreground the benefits of the proximity and fast interconnections of operating in the marketplace, as well as their direct network connections to IaaS providers. Other vendor-led marketplaces include Dimension Data s OneCloud (in which the 15 partners report that on average 22% of revenue generated across the program is transacted between partners); OnApp s Cloud.net federated marketplace; Virtustream; and possibly Cisco Inter- Cloud though it is unclear at this time what the end state for it is intended to be.

16 12 Cloud Brokers In the US, the General Services Administration (GSA) is acting as a de facto marketplace for the federal government, crediting Akamai, AT&T, AWS, Autonomic Networks, CGI, CTC, HP, Lockheed Martin, Microsoft and IBM as FedRAMP-compliant cloud service providers. Indeed the GSA looks like a would-be cloud broker. If the GSA were to put a FedRAMP in place for cloud management vendors, it would likely start a feeding frenzy. The key actors in this space such as General Dynamics, Lockheed Martin, Unisys, ManTech, CGI, Accenture, Booz Allen and the SIs are now figuring out how to build, buy or partner their way into this market to be attractive to the federal segment. Although the GSA recently issued an RFI for cloud brokers, this is really an information-gathering exercise as there are no funded projects in the offing. Other examples include the UK Government G-Cloud initiative with its CloudStore and the EU s Helix Nebula Marketplace. 3.6 INTEGRATORS SIs see themselves as natural heirs to the service-integration market, which is ultimately how services delivered from various types of clouds will be procured and used. They are the highest level of outsourcing available to consumers. Integrators not only procure access to a range of cloud resources, but also facilitate the integration of these services and the use of data sources. They may fully control the architecture of the application, provisioning and scaling as required, to deliver to SLAs. Cloud service integrators combine cloud and non-cloud services to deliver a bespoke solution that is fully integrated, managed and scaled. Cloud integrators may pass on costs to consumers or may bundle them into a single solution price. From a commercial point of view this makes perfect sense: Rather than building vast infrastructures that can t compete on cost relative to the likes of AWS and Google, integrators can use a range of third parties that are not just more affordable, but also have specific expertise.

17 RESEARCH FIGURE 3: THE CLOUD BROKER MARKET LANDSCAPE CLOUD BROKER CATEGORY Cloud exchanges, cloud brokerdealers Cloud marketplaces EQUIVALENT TRADITIONAL ENTITY IT distributors VARs FUNCTION NEW PLAYERS REVENUE MODEL Provides consumers with a catalog of purchasable items from a range of providers, which consumers must control and architect Provides consumers with a catalog of purchasable items from a range of providers, with some level of integration (e.g., SSO) and pre-architecture Cloud integrators SIs Provides consumers with a catalog of purchasable items from a range of providers as part of a broader managed solution that is fully integrated Enterprise service managers Datacenter marketplaces/ exchanges Internal IT departments Datacenters Provides employees with a catalog of purchasable items from a range of providers via the organization s master catalog Enterprises and vendors within their ecosystems can buy/ sell directly within that network 6fusion/CME, Deutsche Borse/Zimory, Strategic Blue, Ingram Micro, Arrow, TechData Appura, ComputeNext; Cloud providers include: Amazon Web Services, Rackspace, IBM, Oracle, HP, Dimension Data, Virtustream, OnApp, CenturyLink, Dell, Bitnami Capgemini, Atos Canopy, Accenture, CSC, KMPG, Vodafone N/A Equinix, Digital Realty, Switch Exchange: transaction fee; broker: delta between cost and sale price. Percentage of consumer spend (15%) or delta between cost and sale price. Varies. Likely cost plus upfront and recurring fees. Monthly price determined by metered costs. Ranges from continued management of all IT costs that may use showback and chargeback to reallocated IT costs given directly to internal LOB budget holders. Colocation charges plus direct connect bandwidth fees.

18 14 Cloud Brokers SECTION 4 Broker-Enabling Technologies 4.1 REQUIRED TOOLS AND FUNCTIONS To act as a broker, the service provider or enterprise needs tools to manage multiple clouds from a technical point of view, including provisioning and turning-down resources, migrating workloads between providers, ensuring security compliance and preventing data leakage. Tools are also needed to ensure that the overall business strategy of operating internal ITaaS or generating company revenue is met. These include tools for measuring consumption and allocating to users, reporting on performance and establishing necessary contracts with cloud providers. Cloud Management Platforms: Workloads need to be provisioned and managed across multiple cloud entities under a single, unified point of view, typically using APIs. Cost Management Auditing and Metering: Brokers need to ensure they are metering the customers consumption of cloud resources for billing purposes. An external broker will bill customers for this consumption; an internal broker will bill departments or business units. Cost Management Reporting: Data must be collected from each service provider to assess cost, performance and usage. This is typically done through APIs or data files kept in object storage platforms. Decision Engine/Procurement: To purchase resources from multicloud vendors, multiple accounts and pre-negotiated contracts are needed, including recommendations on best fit included. Security Services: Appropriate security is needed to ensure that provisioning is authenticated and attributed, and data is kept safe and compliant across multiple clouds. Transformation Engine/Migration: Brokers need to ensure they can move data and applications from cloud providers as changing requirements dictate, or even from on-premises cloud applications. These technologies can be provided as point or integrated services. ITaaS vendors usually provide full capabilities such that enterprises can define their own service catalogs from which departments and end users can purchase resources. This is the key value proposition for a private cloud: They allow enterprises to define the catalog and run the self-service portal that enables users to request resources, effectively duplicating IaaS behind the firewall. The majority of point broker-enabling technologies provide their capability through a SaaS platform on a recurring subscription model. The recurring cost depends on the amount of workloads or the cost of the workloads under management. For software delivery, a recurring license model is commonly used based on workloads under management.

19 RESEARCH FIGURE 4: BROKER-ENABLED TECHNOLOGY MARKET LANDSCAPE FUNCTION DEFINITION SAMPLE PLAYERS WITH FUNCTION AS PRIMARY FOCUS ITaaS cross-functional tooling Transformation engines Cost management reporting Cost Management Auditing and Metering Cloud management platforms (CMPs) Decision engine/ procurement Security services Provides end-to-end ITaaS capability Provides the capability to move workload between clouds Collecting data from multiple clouds to ascertain consumption Metering the delivery and consumption of IT resources Workload provisioning and termination across multiple clouds Has prearranged contracts that can be reused by those wishing to build their own broker services and provides recommendations Provides security, data leakage, authorization and compliance across multiple clouds BMC, CA, HP, IBM, ServiceNow, HP, VMware RiverMeadow, Racemi, RackWare, AppZero, CloudVelocity, ClouDesire, Appcara, GigaSpaces, RISC Networks, Kaavo, UShareSoft, Krystallize, Microsoft, Novell, AWS OpsWorks Cloudability, Cloudyn, CloudCheckr, CloudBolt, CloudHealth, CloudScreener, CloudVertical, RISC Networks, Semperity, AWS Ylastic, Datapipe, Akasia, KEDARit, Apptio, Xervmon Cloud Cruiser, Talligent, 6fusion, MetraTech Appura, Dell, RightScale, CA, BMC, CSC ServiceMesh, Cirba, Copper.io, Scalr, Xervmon, Ensim, Egenera, Ostrato, CliQr, Cognizant, CompatibleOne, Ensim, Gravitant, VMware, CloudMGR Jamcracker, Gravitant, ComputeNext, Cisco Inaya, Skyhigh, Skyfence, Elastica, CipherCloud, FireLayers, Adallom, Bitglass, Netskope 4.2 CLOUD BROKER AS PART OF A CLOUD MANAGEMENT PLATFORM Increasingly, a CMP won t be considered full-service unless it can deliver a cloud broker function that provides BEV capabilities. This might be delivered by an SI to customers or by an internal ITaaS provider to an organization. An SI will typically need cloud management technology to provision and manage workloads across multiple clouds; it will need to meter and bill customers for their consumption and report it back; and it will need to migrate workloads from existing platforms. It will also need contracts and procurement protocols in place with the providers it uses, together with a decision engine that can provide service selection. Figure 5 offers an example of a cloud management platform stack or catalog that includes a broker capability.

20 16 Cloud Brokers FIGURE 5: COMMON SERVICE OFFERINGS OF CMPS FEATURE Hybrid cloud networking Multivendor private, public, hybrid cloud support Blueprints (for services) vendor and user VM provisioning, high-availability scaling, recovery Developer tools (continuous delivery) Self-service portal, service catalog Integration/migration (transformation engine) Service selection: BEV/broker (decision engine) Consumption management/optimization Access control/security SaaS and on-premises license models App monitoring and system tool extensions (patching, backup, OS monitoring, etc.) SaaS, on-premises license models AUDIENCE DevOps, enterprise business DevOps, enterprise business Enterprise business DevOps DevOps DevOps DevOps Enterprise business Enterprise business DevOps, enterprise business Enterprise business DevOps, enterprise business Enterprise business

21 RESEARCH SECTION 5 Getting Involved While we ve shown that there is a need for cloud brokers, there are contrasting views and questions that deserve attention, including: SI, aggregators and cloud brokers embody market inefficiency. Their very existence highlights the industry s failure to pre-integrate components and services. There is more hype about cloud brokering than actual shopping for services via brokers at this point. Cloud brokers are a shorthand for consulting and professional services, a get-out-ofjail card for SIs that seem most likely to be disrupted by the cloud. The broker market still looks a whole lot like a potential replay of the failed bandwidth broker/exchange models of the 1990s. That failure was primarily caused by the fact that liquidity suppliers (telcos) did not want to be disintermediated from their clients. There are also several questions that arise, including: Is the market being conditioned by self-serving interests of suppliers rather than business need or complexity? What happened to pay-per-use and on-demand? A cloud broker introduces another layer of cost associated with cloud adoption. What about SLA ownership, accountability, customer relationship and support? Can these complex issues be handled by brokers that may have little market experience? Does the broker have long-term relationships with multiple players or is this just a ring-fenced partner network? 5.1 CONSIDERATIONS WHEN BECOMING OR USING AN EXTERNAL BROKER SERVICE Enterprises themselves must consider various questions when becoming or using a broker service. They include: Who owns the paper? Who owns the resource and is responsible for paying the bill? There is no single approach or model that has a leading or winning position here. Some firms own the paper on the services they broker; others don t. Who takes the risk? Cloud broker providers will need to buy resources and then pass the cost on to the consumer. In both exchange and non-exchange (over-the-counter, in technical terms) environments, most cloud brokers are taking on liabilities. Some potential pitfalls include:

22 18 Cloud Brokers What happens if brokers promises cannot be met by available supply? What happens if brokers advance purchases are not demanded? It s difficult to plan for unexpected turbulence e.g., black swans, market failures and market shocks. Risks are particularly high with distributors: low margin, only value in procurement. Who is responsible for SLAs? If the broker is responsible, its financial liability is at the mercy of third-party processes. Is the compensation obtainable from partners enough to cover the broker s financial exposure? If partners must answer to the broker s customers, what happens when multiple or integrated services fail? Who is the customer s champion and who is liable for this end-to-end failure? Who resolves issues across clouds? Diagnosing an issue across multiple clouds is still a challenge, as each provider will only share an abstract view of its underlying infrastructure and architecture. To diagnose an issue, the broker needs to determine which partner has the issue, which can be difficult in complex applications where services are integrated. How are partners accountable to help solve these issues, and what SLAs do they offer? How can issues be escalated, and how can multiple points of contact across partners share information and collaborate? Where does the buck stop who is ultimately responsible? Is there compatibility between aggregated providers? APIs vary between cloud providers, and many technologies use adaptors to translate calls between different syntaxes. As more providers add proprietary features, how will brokers be able to take advantage when they are tied to a standard set of API calls? Is there a single point of failure? What happens if the broker goes down? Who is responsible, and what is the consumer supposed to do in this circumstance? Might we start to see consumers using multiple cloud brokers for resilience? What is the data transfer protocol? In theory, moving resources between providers should be fairly straightforward. In practice, however, moving huge workloads, databases or datasets can take a significant amount of time and a lot of expensive bandwidth. Most cloud providers allow consumers to post hard drives for manual uploading to the cloud. For brokers to be agile, the movement of data needs to be seamless. 5.2 CONSIDERATIONS WHEN BECOMING AN INTERNAL BROKER Internal IT departments planning to become service brokers must pay careful attention to some specific factors before introducing this approach to service delivery. In particular, the maturity of the organization around areas such as IT usage and IT costing and budgeting can make or break an internal broker strategy. They must consider:

23 RESEARCH Financial backlash. Getting departments to pay for what they use is a huge transformation and is unlikely to be easy. For starters, departments are used to having IT for nothing how are they supposed to pay for it? An increase in each department s annual budget is likely to provide the cash, but how much more is reasonable and how is it assessed? Determining the annual cost of a typical user is risky, as the whole point of the brokerage model is that individuals have access to the resources they need. Using showback before implementing chargeback gives departments time to monitor and reduce their expenditure but it also peels back the veil of IT spend, meaning CIOs and CEOs are likely to start asking for more justification for expenditure. IT literacy. End users and departmental heads sometimes struggle with using the software packages they need. Giving them power to provision and control resources with associated costs and data risks is dangerous without training and a settling-in period. Data security. If users can start and stop resources, there are risks that data might not only leak but also might be destroyed. How is this controlled and who is responsible? Lack of financial controls and bill shock. Some departmental heads may consume more resources than they did previously simply because they can. Or they may choose a more expensive resource, simply because they don t want to risk using the cheaper one. End users may forget about resources or may accidentally purchase more. This can result in bill shock the feeling of horror upon receiving the cloud consumption bill (like that for roaming or data overage charges on a cell phone bill). And as the department is liable, budget will naturally have to be taken from other activities. 5.3 THE ENTERPRISE ITAAS MATURITY MODEL CONSUMERIZATION AND SHADOW IT The IT department needs to provide capabilities internally at the same time it s dealing with the decentralization of IT. This is causing IT to drift into a service broker role, with other departments potentially providing services as well as external providers. IT organizations used to address this issue via service portfolio management underpinned by well-understood frameworks such as ITIL and ITSM. Over the past 18 months, however, most IT organizations are in reactive mode expanding service delivery rapidly because of the wide impact of technology consumerization, which is putting pressure on them to provide more accessible, easyto-use services at low cost. From a technology point of view, enterprise IT organizations now need to be able to provide a unified front-end experience via a portal that enables access to a service catalog, which can seamlessly link to other catalogs from external service providers as necessary. And this all then needs to integrate with a unified backend capability managing assets, policies, pricing and governance. The ultimate goal is to make it easier for internal IT to deliver services and mandates on governance and cost optimization, while also providing a strong user experience that eliminates shadow IT. This requires the IT department to be both the broker and

24 20 Cloud Brokers control point between commercial external suppliers and internal providers and employees, enabling departments to purchase services directly with their own cost budgets. While conventional internal technology management (ITSM) has long angled to provide just this vision, the shift in cloud brokering is a change in the underlying infrastructure the use of cloud technologies both on- and off-premises to one that is more agile and programmable than what IT dealt with previously. In short, cloud automation works better than plain old virtualization and traditional automation DOES THE ORGANIZATION S ITAAS MATURITY MATCH THE TECHNOLOGY OFFERED? As discussed above, there are a number of considerations that need to be explored while developing an internal enterprise brokerage. While the ultimate goal is to optimize the provisioning of IT services, it is not sensible to attempt to leap straight to Level 5 in the Enterprise ITaaS maturity model (see Figure 6). Most enterprise organizations are currently at Level 2 and need to focus on getting their arms around the provisioning of internal IT services more quickly. At Level 2, the main audience for the service portal will be a technical one. In fact, the portal approach can form a best practices component of moving the internal IT organization to more of a DevOps culture. FIGURE 6: THE ENTERPRISE ITAAS MATURITY MODEL From the beginning, ITaaS needs to be accepted within the internal IT organization itself. LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4 LEVEL 5 For this reason, initial usage of catalogs and brokers in the cloud service context tends to be AD-HOC REPEATABLE DEFINED MANAGED OPTIMIZED centered around the management of IaaS rather than for the wider management of SaaS No catalog, procurement. Catalog used within Organization-wide Mature resource The catalog is used centralized, the IT department use of catalog with management means to request services monolithic IT to manage basic an access portal that the organization beyond IT and to As IT organizations evolve to address other business units confidently with an uses ITaaS show-strategyback and chargeback requirements for new shape and they procure processes processes and providing consumer-like that experience the IT department evolve toward Level 3, controls and it is around at this point for IT usage starts down the services; path of sophisticated becoming IaaS and SaaS is technical services the domain the internal of cloud provider for the entire Employees business; use it to this is not a one-and-done brokerage proposition, in place The internal broker is but ad-hoc a phased shadow IT Some use of IaaS support device and used for the majority of evolution. Often the departure point will be around BYOD management Minimal shadow for certain IT brokerage SaaS procurement IT procurement categories of worker, as well as providing choices new employees with their requisite workplace tech- Ad-hoc nology during the on-boarding process. Optimized Very few organizations have moved to Levels 4 and 5 of the Enterprise ITaaS Maturity Model, and indeed to do so requires a level of maturity in which the IT department is not seen as a cost center. Instead, business lines accept responsibility and budget for their IT spend. This is an important phase of development and one of the most difficult to achieve once it has been, all the pieces are in place to develop an optimal ITaaS capability with the portal and enterprise app store at the heart of enterprise technology spend and use. Some organizations are jumping straight to Level 5 in terms of opening up the portal to request a variety of services (typically for HR and field management services) before establishing organizational maturity around technology spend. This may help raise the status and profile of IT above other areas of cost within the organization, but it does not help the organization move to a more mature understanding of technology spend and its influence on business outcomes.

25 RESEARCH Very few organizations have reached Level 4, which involves properly budgeted management of technology. Currently, many enterprises do not add pricing to the services in their catalog, simply zeroing out the price. Others calculate the cost of components behind a service and price that way for showback. Indeed most organizations attempting to price services are using showback rather than chargeback because IT remains a funded model, not a pay-as-you-go model. To evolve to chargeback, organizations need to move from a resource budget approach, in which the IT organization acts as the conscience of the enterprise, to a financial budget approach with different departments making budgeted choices about technology procurement WHERE TO START From a service consumption perspective, organizations should consider their existing catalog technology and think about whether it enables them to create new services easily, as well as whether it can keep pace with technology change and consumer trends in usability. There are many vendors in the market with good catalog technologies including BMC, CA, HP, ServiceNow and VMware any one of these is a good investment starting point. The next step is to make an inventory of services and work with internal service providers within the IT organization to map those available and how they will be delivered. Then build out a service catalog of what IT offers and refine the list through the lens of the end user. Web pages and forms that use technical acronyms will not do, especially once the audience expands beyond the IT organization itself. To build new perceptions of ITSM, leveraging social media tools that allow end users to interact beyond the Web catalog can prove useful. End users can, for example, create micro-communities interested in certain technology areas and use the social media tools to sign up for beta testing or to crowdsource service support. This begins to socialize the organization and prepare it to move to the next level of ITaaS maturity. Of course IT organizations often do not have much of a choice of where to start with ITaaS as it is often a pain-driven rather than a top-down and strategic approach. Because of this, BYOD and mobility as a whole are probably good pain points to begin to address with ITaaS as an initial phase of evolution toward an internal brokerage. Whatever an organization s level of maturity and starting point, the main things to bear in mind are that the services should be easy to consume, search and buy, and part of the value is to use the enterprise s muscle to negotiate low costs for standard pieces of technology. It is acceptable for internal services to be more expensive as long as it is clear to buyers that the internal service is more expensive because it includes advanced capabilities, for example, and is a trusted service. This is generally a much easier and effective way of influencing behavior than trying to create an aggregated price comparison model, because weeks and months can be lost trying to agree on that model. Above all, the main point of ITaaS is for internal IT to act as a broker, not simply to provide a catalog that blocks external purchases.

26 22 Cloud Brokers SECTION 6 Use Cases and Economics 6.1 CAPGEMINI The broker service that Capgemini offers within its Dynamic Services portfolio enables customers to source 10 pre-contracted cloud providers. It sells the broker tools independent of process to customers, or it can replace the office of the CIO by using consultants to set up service blueprints. The resulting platform, managed by Capgemini, then offers cloud service brokering between its cloud providers. Cloud services brokerage is offered alongside app and service stores, a service orchestration engine, service integration and service aggregation. Service orchestration is provided by the Cloud Orchestration Platform (COP), which has been under development by Capgemini and VMware. As part of its cloud-brokered services, Capgemini delivers a portal-based service store (membership access) to offer services from a master catalog. It s a multitenant single source of service provisioning. Clients can also receive a customized version of services via standardized APIs. A policy engine governs what, where, when and how services may be provisioned. The engine triggers the provisioning of services via APIs. A billing engine consolidates all the metering information related to a specific customer account and provides automated billing. Performance management, incident management and general user support are provided as a consolidated service. Capgemini is packaging all of this as an offering to manage separate suppliers and deliver the SLA on behalf of clients. The company provides as much management resolution as required, from running it completely to buying and implementing the product only. Capgemini sees two use cases among current broker customers. In the first, users buy directly from AWS or Azure and want to own the contract or contracts. The user can load use parameters (geography, size, cost, etc.) into its decision engine to determine who can access what services, where and how. This is common among organizations that are spending $100m or more annually on their IT. In the second scenario, customers simply want access to cheap application developer resources and use Capgemini to source and manage the access. Most will use Capgemini s contracts to operate the relationship with the cloud provider (although the customer still holds the paper on that cloud provider relationship); some will want to retain control. For its decision engine, Capgemini is using Gravitant s CloudMatrix (and Capgemini has become Gravitant s biggest customer as a result). The COP provides the backend provisioning and execution. Capgemini captures all the data into its standard service integration stack both a data warehouse and a CMDB for billing and usage reporting. The goal is to enable a user to provision and perform self-service in three clicks. The State of Texas Department of Information Resources is Capgemini s marquee reference customer for Dynamic Services, with $1.6bn of spending being managed. ACS State & Local Solutions (now Xerox State & Local Solutions) is the other key service integration contractor on

27 RESEARCH the deal. Gravitant s CloudMatrix cloud broker software is used under the hood as the portal from which services are accessed. Gravitant s broker portal is being supplied to the contact by General Dynamics, which has licensed CloudMatrix. Capgemini says the revenue opportunity in these kinds of deals will be on average just 13% of what it has historically earned (and less than 10% of contract value, which in this case would be a high watermark of $160m); however, margins are at least 10% higher meaning Capgemini will need to win more of them. 6.2 T-SYSTEMS T-Systems has built a multitenant cloud broker and offers it as a hosted service for customers to access multivendor private and public IaaS clouds. It does this to capture as many of the opportunities in cloud consulting and integration as it can. This market, it believes, far outstrips the value of the market for basic infrastructure services itself and is growing faster as well. There are three key elements to its cloud broker service: Centralized management of all cloud services, including T-Systems own Dynamic Services Infrastructure, Deutsche Borse Cloud Exchange, AWS, Azure, vcloud, HP Eucalyptus and OpenStack The support and inclusion of all third-party interfaces A decision engine to identify the best cloud fit Functional capabilities of the cloud broker include auto scaling, which detects load peaks and automatically provisions extra resources (or decommissions them), to meet the need. A transformation engine (this is the product of Racemi migration technology of which T-Systems is an investor) transfers and migrates customer workloads between providers (where practical) using image conversion. The broker also maintains public and private cloud models and ensures the correct separation of -aas resources. T-Systems believes its approach will enable users to create a charging system for self-managed virtual environments, as well as provide billing transparency (e.g., AWS). Governance is enabled by delivering transparency on cloud usage throughout an organization (at least all that goes through the broker), allowing for optimization without having to ban use. It will provide a rapid way to provision new services. The ability to store images on the broker allows for a quick restart of the system positioned by T-Systems as DR light. The broker will enable users to transfer apps between development and production environments over a lifecycle. It will reduce management effort by providing access to all platforms and providing reporting across all services. Access to public and private clouds is provided via a central service layer and management portal containing the Racemi decision engine (which includes the service catalog, tagging, adjustable weightings and cloud comparison). Also included in this layer are identity manage-

28 24 Cloud Brokers ment, a transformation engine, alert notification and reporting, automation (scaling, backup), budgeting and monitoring. Pricing and costs can be overwritten so that internal IT can charge out services at whatever price necessary, regardless of actual service cost. Only the management piece runs through the broker, so T-Systems doesn t control SLA delivery of third-party cloud services nor does it own the paper on contracts. The customer owns the service contracts with the cloud providers; T-Systems isn t assuming this. It will look at offering monitoring of third-party services as a value-added service via the broker in future. Pricing for the -aas service starts from 1,990 (US$2,533) per month for an XXS version with management of up to 50 VMs, one migration and one parallel migration. Other versions include XS, S, M, L and an XL which is 25,000 per month supporting 1,400 VMs, 50 migrations and 16 parallel migrations included and 1.6TB storage. T-Systems offers a 30-day trial for the XS version of the broker with up to 180 VMs managed by the broker, five migrations, 100GB storage, one parallel migration and unlimited clouds (cloud-service-provider charges are not included). 6.3 VODAFONE Vodafone had originally planned to build its own shared IaaS service, but somewhere along the line it nixed the plan in favor of purchasing hyperscale equipment. For the leaders in IaaS, it s a billion-dollar investment game beyond Vodafone s expertise or appetite. Moreover, industry leaders typically control and influence the ingredients of supply (manufacture of hardware and software) at a level that delivers a cost base and feature set that is difficult for Vodafone, as a service provider, to replicate. Indeed, like other telcos, hosters, integrators and IT service suppliers, Vodafone has decided it doesn t want to go up against the hyperscale cloud vendors. Instead, its Cloud & Hosting Services group will deliver shared IaaS from a range of partners. The logic isn t hard to follow. It will combine these with its own private (and initially hosted) cloud and networking services and offer them to customers as a single, selfservice, brokered cloud relationship. It will sell its own private cloud services, plus multiple third-party shared services, which it will broker to customers. Additional security and control are offered at the points of peering, and partners services are integrated with its own services and its networks, in effect making Vodafone a cloud service broker. It will also offer its own professional services (assessment, etc.), as well as lifecycle management and those services it already white-labels from EMC. Vodafone services such as unified communications and enduser computing are also layered on top. It will operate two models in terms of who owns the paper on the third-party cloud relationships. In the first, the customer will buy Vodafone s broker service but have the contract with the third-party supplier. In the second, the customer will use Vodafone to source the contract as well. It will also offer customers the ability to use only its connection to the cloud. Above all, it will offer customers the ability to buy an outcome rather than technologies and services.

29 RESEARCH 6.4 ENTERPRISE PERSPECTIVE One of the main use cases for ITaaS in the enterprise centers around IaaS. A lack of awareness about the cost of virtual versus physical servers means that many IT departments have struggled to set prices. For example, one enterprise deploying a large number of virtual desktops tiered the desktop offerings into small, medium and large based on the existing physical system resources it was using. That resulted in the cost of the large tier being set too low, causing all internal departments to want a large system requirement. To manage this, the IT organization increased the cost of the large systems to influence behavior. This is an example of how, although in theory cost and price should be transparent, the IT organization will often need to empower end users via self-service while meeting the company s wider business goals. Early adopter enterprise brokerage practitioners often overreach by setting up too many services too quickly. It is not best practice to deliver services that no one uses. As an example, one organization delivered 1,200 services in a year but internal adoption of those services has been slow. In contrast, another organization delivered 35 services and increased their adoption over 10 months from 2,000 to 130,000 users and achieved $135,000 ROI in the first month of operation. Gamification was used in the latter case to increase adoption of services to support business goals offering incentives for the first 25 employees that used a service. The main enterprise learning from leading-edge deployments is that the success of ITaaS is measured in usage of the portal, not in providing brokerage to the galaxy of services available.

30 26 Cloud Brokers SECTION 7 Market Overview 7.1 THE MARKET FOR CLOUD BROKER SERVICE PROVIDERS COMPANY SUMMARY CUSTOMERS PARTNERS CLOUD INTEGRATORS Atos Canopy Offers broker facility to customers Accenture Accenture Cloud Platform N/A Claims $300,000 brokering engagement AWS, Google and Microsoft Capgemini Dynamic Services State of Texas Gravitant Cloud Alliance Team CSC Cognizant EU federation of cloud providers to provide single framework for crossjurisdiction purchasing Hybrid Cloud Services/ ServiceMesh Cloud360 Beta trials, Q Claims top 10 pharmaceutical companies, a US healthcare provider and a top three airline AWS, Microsoft, NTT Communications, Verizon Terremark Numergy, Belgacom, Enter Srl, KPN, Portugal Telecom AWS AWS, Azure, Verizon, CenturyLink Dell Dell Cloud Manager N/A Numerous Prologue Use-IT N/A T-Systems Cloud Broker N/A Vodafone Future deliverable N/A AWS CLOUD MARKETPLACES ComputeNext Helix Nebula Public marketplace for IaaS, PaaS and SaaS services EU research cloud powered using SixSq, looking for industry consumers Public users unknown CERN, The European Molecular Biology Lab (EMBL), the European Space Agency (ESA) AWS, Azure, VMware and OpenStack clouds including CloudWatt and Numergy Deutsche Borse Cloud Exchange, AWS, Azure, vcloud, HP Eucalyptus, OpenStack Claranet, CloudSigma, Dimension Data, GoGrid, HP, Interoute Atos/Canopy, CloudSigma, CGI, DANTE, European Grid Infrastructure, Interoute, Memset, SAP, SixSq, SWITCH, Indra, The Server Labs, T-Systems, Ultimum Technologies

31 RESEARCH COMPANY SUMMARY CUSTOMERS PARTNERS CLOUD EXCHANGES AND BROKER-DEALERS CME Group Charity Engine Deutsche Borse Strategic Blue/Cloud Options Developing cloud exchange using 6fusion s WAC as the unit of consumption for a spot exchange based on CME Group s trading capability Aggregates spare donated capacity to provide single IaaS platform Developing cloud exchange using Zimory s cloud management platform Cloud broker-dealer Due Q Wolfram Alpha TUV Rheinland, Leibniz- Rechenzentrum, PROFI Engineering Systems City Index, Comic Relief, Friends of the Earth, Render Rocket, Failbetter Games Not disclosed N/A End-users CloudSigma, Host Europe, Devoteam Consulting, Equinix AWS, GreenQloud, SoftLayer, CloudSigma

32 28 Cloud Brokers 7.2 THE MARKET FOR CLOUD BROKER-ENABLING TECHNOLOGIES COMPANIES BY CATEGORY INTEGRATED ITAAS VENDORS BMC CA HP IBM ServiceNow VMWare CLOUD MANAGEMENT PLATFORM (CMP) AppZero Cedexis CliQr CloudHealth Cognizant CompatibleOne Copper.io Dell Ensim Ostrato RightScale Scalr SixSq Tapp.in Xervmon Zimory COST MANAGEMENT - AUDIT & METER 6fusion Apptio CloudCruiser KEDARit Talligent COST MANAGEMENT REPORTING Cloudyn CloudHarmony CloudCheckr Cloudability DECISION ENGINE/PROCUREMENT AppDirect Cisco CloudGenera Cloudscreener ComputeNext Gravitant Jamcracker XOcur SECURITY Adallom Bitglass CipherCloud Elastica FireLayers Inaya NetSkope SkyHigh TRANSLATION ENGINE/MIGRATION 2nd Watch AppCara AppZero CliQr Cloud Velocity Cloudamize ClouDesire CloudGenera Corent Technologies Krystallize Technologies Racemi Rackware RISC Networks RiverMeadow UShareSoft

33 RESEARCH SECTION 8 Cloud Brokers: Conclusions and Recommendations That intermediaries will have a role in providing access to third-party services is inevitable given the rise of new-style IT, in which the consumption of multiple -aas offerings is the organizing principal. While the exact nature and role of a cloud broker is still being assembled in the market, a need for this function is not in question, even if longevity is an open-ended question. Rightly, a demonstration of use cases, benefits experienced by consumers and suppliers alike, as well as revenue attributable to these, will be required to credential this market, especially to risk-averse IT buyers. 8.1 RECOMMENDATIONS FOR VENDORS Consider cloud brokers as offering another route to market for -aas services. Price technology on a no-risk, pay-as-you-go model to target brokers. Brokers then have little to lose by using your technology initially, but gross margins should grow exponentially over time as a result of the network effects of integration, cross-sell and upsell. Consider partnering with other vendors to offer a suite of integrated products for the cloud broker market. Becoming a cloud broker requires offering a range of services rather than just cloud management. 8.2 RECOMMENDATIONS FOR SERVICE PROVIDERS Keep in mind cloud brokers could be a useful channel to provide access to additional geographies, markets and audiences. Service suppliers should ensure they are included in any decision engine data, and that they are being recommended for target scenarios. Service providers should consider what relationship they will have with the end user via a broker. Determine whether there is an opportunity to broker services to customers, including the native services you offer, partner services or other third-party services. Consider that you risk a disadvantage if you don t offer broker services. Be careful when locking consumers into financial commitments. The value of the broker is agility; take that away, and consumers might wonder if they d be better off going with a direct approach.

34 30 Cloud Brokers 8.3 RECOMMENDATIONS FOR ENTERPRISES Look at brokers as a way of intermediating multiple services in order to deliver ITaaS, rather than having to manage multiple bilateral relationships. Understand who is responsible for what (SLA, availability, billing, etc.) doing so will be key to the successful use of brokers. For consumers, cloud brokers provide the combination of free will to choose best execution venues together with a trusted advisor to help them make decisions. They also give the consumer someone to blame (and contact) when things go wrong, and a single view of the IT landscape. Don t underestimate the social, financial and political fallout from becoming an internal broker or of using an external broker, for that matter. Know where you are on the Enterprise ITaaS Maturity Model to help shape the route you take. Keep in mind that the success of ITaaS is measured in usage of the portal, not in providing brokerage to the galaxy of services available. 8.4 RECOMMENDATIONS FOR INVESTORS Beware the fact that there are more brokers in the market than publicly referenceable contracts recognized as brokering of cloud services. This market is not yet meaningful in terms of contract value or deal flow. Don t sleep on cloud brokers. We expect a cloud broker capability will be a first-class citizen within any full-service cloud management platform. A broker capability will be meaningful in terms of leadership. Take into account the significant partner and ecosystem opportunities for successful brokers, which should have a multiplier effect on their businesses. Cloud brokers won t only require cloud management platforms they will need a broad range of broker-enabling technologies to address the many aspects of the disruption cloud brokers may bring. Pay attention as major SIs and federal systems suppliers evaluate the range of cloud broker tools and suppliers to see what works. As this market comes on stream, these broker properties will gain value in the eyes of these players.

35 RESEARCH INDEX OF COMPANIES 6fusion 10, 13, 15, 27, 28 Accenture 12, 13, 26 Akamai 12 Amazon Web Services 2, 10, 11, 12, 13, 15, 22, 23, 26, 27 AppDirect 11, 28 Arrow 10, 13 AT&T 12 Autonomic Networks 12 Booz Allen 12 Capgemini 9, 13, 22, 23, 26 CenturyLink 10, 11, 13, 26 CGI 12, 26 Chicago Mercantile Exchange 10 Cisco 11, 15, 28 Cloud Options 11, 27 Cloud Team Alliance 10 ComputeNext 11, 13, 15, 26, 28 CTC 12 Dell 9, 13, 15, 26, 28 Deutsche Borse 10, 13, 23, 26, 27 Digital Realty 11, 13 Dimension Data 11, 13, 26 Equinix 11, 13, 27 General Dynamics 12, 23 Gravitant 15, 22, 23, 26, 28 Helix Nebula 10, 12, 26 HP 2, 11, 12, 13, 15, 21, 23, 26, 28 IBM 2, 11, 12, 13, 15, 28 Ingram Micro 10, 13 Jamcracker 11, 15, 28 Lockheed Martin 12 ManTech 12 Microsoft 2, 12, 15, 26 OnApp 11, 13 Oracle 11, 13 Racemi 15, 23, 28 Rackspace 11, 13 Switch 11, 13 T-Systems 23, 24, 26 Unisys 12 Verio 11 Virtustream 11, 13 VMware 2, 10, 15, 21, 22, 26 Vodafone 13, 24, 26 Zimory 10, 13, 27, 28