Cloud Business Models

B2B Business Model Inventory Release 1.0 TR174 Addendum A Version 1.1 April 2012 TM Forum 2012

Notice No recipient of this document shall in any way interpret this document as representing a position or agreement of TM Forum or its members. This document is a draft working document of TM Forum and is provided solely for comments and evaluation. It is not a Forum Approved Document and is solely circulated for the purposes of assisting TM Forum in the preparation of a final document in furtherance of the aims and mission of TM Forum. Although it is a copyrighted document of TM Forum: Members of TM Forum are only granted the limited copyright waiver to distribute this document within their companies and may not make paper or electronic copies for distribution outside of their companies. Non-members of the TM Forum are not permitted to make copies (paper or electronic) of this draft document other than for their internal use for the sole purpose of making comments thereon directly to TM Forum. If this document forms part of a supply of information in support of an Industry Group Liaison relationship, the document may only be used as part of the work identified in the Liaison and may not be used or further distributed for any other purposes Any use of this document by the recipient, other than as set forth specifically herein, is at its own risk, and under no circumstances will TM Forum be liable for direct or indirect damages or any costs or losses resulting from the use of this document by the recipient. This document is governed, and all recipients shall be bound, by all of the terms and conditions of the Intellectual Property Rights Policy of the TM Forum (http://www.tmforum.org/bylaws/1094/home.html) and may involve a claim of patent rights by one or more TM Forum members or by non-members of TM Forum. Direct inquiries to the TM Forum office: 240 Headquarters Plaza, East Tower 10 th Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110 TM Forum Web Page: www.tmforum.org TR174 Addendum A Version 1.1 TM Forum 2012 Page 2 of 24

Table of Contents Notice... 2 Table of Contents... 3 Executive Summary... 4 1 Introduction... 5 1.1 Rationale and purpose... 5 2 Cloud business model inventory... 7 2.1 NIST Scenario 2 Cloud Provider /Carrier SLA... 11 2.2 NIST Scenario 1 business models Service Broker... 15 3 References... 20 3.1 References... 20 4 Glossary... 21 5 Administrative Appendix... 23 5.1 About this document... 23 5.2 Document History... 23 5.2.1 Version History... 23 5.2.2. Release History... 23 5.3 Company Contact Details... 24 5.4 Acknowledgments... 24 TR174 Addendum A Version 1.1 TM Forum 2012 Page 3 of 24

Executive Summary The Enterprise Cloud Leadership Council (ECLC) has issued a set of enterprise requirements on suppliers of Virtual Private Cloud (VPC). In general VPC are delivered though combinations of services from different service providers. To determine the impact of these enterprise end user requirements on service providers it is necessary to analyze a number of example business models. This document investigates detailed business model examples - based on those used as examples by the NIST Cloud Reference Architecture - to support the analysis of the ECLC Cloud Requirements and determine the likely impact on services providers in different business models. Whilst business models cannot be exhaustive, even a small number give strong insights as to how end to end SLA and billing requirements impact each SP participating in a Business Model. The examples are simply to aid analysis and are neither a recommendation nor preferred over other published models elsewhere. The analysis is based on creating detailed business model examples using the CANVAS method adopted by the Enabling New Services Team. The focus is on end to end SLA and billing. It will be necessary to extend the analysis to address security in a later version. TR174 Addendum A Version 1.1 TM Forum 2012 Page 4 of 24

1 Introduction The Cloud case scenarios addressed include: o NIST Scenario 2 cloud provider/ cloud carrier provide e2e SLA o NIST Scenario 1 business models Service Broker 1.1 Rationale and purpose This material is based on the the concepts developed within ENSI 1 Business Model Compendium (in preparation) and is included for two reasons: o To provide the necessary background to the Canvas and Business Model Compendium analysis without referenceing that document thus allowing this to be a stand alone document. o So that the cloud scenarios can be considered for inclusion in a future version of the Business Model Compendium. Strategy defines how a firm creates economic value and maintains competitive advantage in a specific maket. Getting a strategy right or finding a sustainable strategic position is the most difficult task for a firm. Business Models are the framework for implementing strategies. The picture below is from Alexander Osterwalder, PhD Thesis [Osterwalder 2] shows that the relationship between Strategy and Business Processes (here exemplified for Enterprises adopting IT and Internet technologies) can be better understood, and consequently the implementation of a strategy better controlled, if business models are formulated. Figure 1 Strategy, Business Models and Business Process In other words [Wikipedia]: The process of business model design is part of formulating a business strategy. The implementation of a company's business model into organizational structures (e.g. 1 ENSI Enabling New Services initiative Activity covering cloud within FY 11-12 TR174 Addendum A Version 1.1 TM Forum 2012 Page 5 of 24

organograms, workflows, human resources) and systems (e.g. information technology architecture, production lines) is part of a company's business operations. It is important to understand that business modeling commonly refers to business process design at the operational level, whereas business models and business model design refer to defining the business logic of a company at the strategic level. Business services within a business model context capture the full technical and operational commitment of one partner in a value chain to another, and hence are the way ECLC requirements are realized by each service provider in a business model. Business Processes are supported by atomic elements that in TM Forum are called Business Services, and mirror to a certain extent the IT concept of SOA Service. TM Forum s Business Services are more focused on business and operational needs. Frameworx Business Service (aka Contract) represents a specification of system capability to achieve a stated business purpose. A Business Service includes a defined interface and may also define pre- and post-conditions, semantics for using the service(s), policies affecting the configuration, use, and operation of the service. A Business Service implements one or more use cases (task level processes). The Companion Business Model Compendium formalizes business models within the continuum of business strategies between traditional value chain (aka Telco 1.0) and complex value creation networks (aka Telco 2.0 and cross-industry ecosystems). By formalizing those business models the impact of operationalizing those business models and transforming the enterprise from one business strategy to another can be easily derived. The chosen tool for formalizing business models is business model canvas defined by Alexander Osterwalder [Osterwalder 1] see http://www. alexosterwalder.com/) that has been extended to fit the purposes above. TR174 Addendum A Version 1.1 TM Forum 2012 Page 6 of 24

2 Cloud business model inventory This chapter provides a detailed inventory of the relevant cloud business models. In this chapter, all business models are described from the Service Providers perspective. The Business Model Canvas from Alexander Osterwalder was chosen for formalizing business models. The Canvas has been extended for the analysis in this document, to cover all relevant information, needed for the purpose of the business model compendium and this document. Some aspect of business models in Osterwalder s model such as cost structure are not addressed as these are not appropriate or necessary for this requirements analysis. The table below describes the intended content of each canvas element: Element Sub-element Semantics Business model Name The name of the business model Short description Short description of the business model [extension to Osterwalder s canvas] Market players/ competition Maturity level Priority Who are the relevant players in the market, running this business model? How competitive is the business model? [extension to Osterwalder s canvas] What is the level of maturity of the business model within the market? (e.g. innovative, well established) [extension to Osterwalder s canvas] What is the priority (relevance, importance) of the business model for the work within the TM Forum from a CSP perspective? [extension to Osterwalder s canvas] TR174 Addendum A Version 1.1 TM Forum 2012 Page 7 of 24

Element Sub-element Semantics Customer/Market Customer Segment What is the customer segment(s), addressed by the business model? Customer Segments define the different groups of people or organizations an enterprise aims to reach and serve. A customer segment is a sub-set of a market made up of people or organizations with one or more characteristics that cause them to demand similar product and/or services based on qualities of those products such as the value of a product, a service or a function. Channel Relationship What are the relevant channels (communication as well as sales & distribution channels) to reach the addressed customers? Channels (communication, distribution & sales channels) comprise a company s interface with customers. Channels are customer touch points that play an important role in the customer experience. What kind of relationship is expected by the customer/needs to be established for the business model? (e.g. self-service, communities, personal assistance). Relationships can range from personal to automated. Product Offering Value proposition What kind of products and services are offered to the customer? What value will be delivered through the business model? The value proposition is the reason why customers turn to one company over another. It solves a customer problem or satisfies a customer need. Each value proposition consists of a selected bundle of products and/or services that caters to the requirements of a specific customer segment. In this sense, the value proposition is an aggregation, or bundle, of benefits that a company offers customers. TR174 Addendum A Version 1.1 TM Forum 2012 Page 8 of 24

Element Sub-element Semantics C2M (Concept to Market) Enterprise Management Key Activities Key Resources Key Partners Cost Structure Key activities are the most important things a company must do to make its business model work. What are the key activities, to launch the offers product/services to the market, to establish the channels, to maintain the customer relationship and to ensure the sales streams? (e.g. development of community site, implementation of new billing concepts). Key resources are the most important assets required to make a business model work. What are the required key resources, to launch the offers product/services to the market, to establish the channels, to maintain the customer relationship and to ensure the sales streams? (e.g. development of community site, implementation of new billing concepts). Who are the key suppliers/partners, what are the key activities and resources, which need to be acquired from those? (e.g. external call center, supplementary content from a content provider) The Cost Structure describes the most important costs incurred to operate the business model. Revenue Streams Revenue Streams are the cash a company generates from each Customer Segment; A business model can involve several different types of Revenue Streams: Transaction revenues resulting from one-time customer payments; Recurring revenues resulting from ongoing payments to either deliver a Value Proposition to customers or provide post-purchase customer support; -Shared Revenue resulting from operations carried out by a B2B partner who uses enterprise s products or services to generate its own revenue from its own end customer but does not pay upfront or recurrent for products/services from the enterprise just a percent of actual revenues; - Third party revenue revenue from a third party to include its own services in the enterprise offerings to its customer segments. TR174 Addendum A Version 1.1 TM Forum 2012 Page 9 of 24

Element Sub-element Semantics Barriers Business related What are the business related barriers, to implement the business model? (e.g. high risk regarding cash flow) [extension to Osterwalder s canvas] Technical What are the technical barriers to implementing the business model? (e.g. high risk due to immature technology) [extension to Osterwalder s canvas] Drivers Strategic portfolio What are the drivers to implement the business model regarding the strategic portfolio planning? (e.g. complementary to the existing portfolio strategy) [extension to Osterwalder s canvas] Touchpoints/Use Cases Revenue Streams Upstream What are the drivers to implement the business model regarding the revenue streams? (e.g. new revenue opportunities to compensate the decline in the value of airtime) [extension to Osterwalder s canvas] What are the key touchpoints/use cases/interaction patterns to interact with upstream customers? (e.g., registering an app in app store).upstream customers are B2B partners/enterprise customers (e.g. retailers, media, advertisers, utilities, finance etc.) [extension to Osterwalder s canvas] Downstream What are the key touchpoint/use cases/interaction patterns to interact with downstream customers? (e.g. end customer billing). Downstream customers are the end users of a product or service, this can be consumers as well as companies [extension to Osterwalder s canvas] Impact on other TM Forum projects Business Process Model Information Model Other projects [extension to Osterwalder s canvas] [extension to Osterwalder s canvas] [extension to Osterwalder s canvas] Each business model is described by a business model canvas in this chapter. TR174 Addendum A Version 1.1 TM Forum 2012 Page 10 of 24

2.1 NIST Scenario 2 Cloud Provider /Carrier SLA The following scenario is taken from the NIST Cloud Computing Reference Architecture, [NIST 1]. NIST Case scenario 2 1. In preparing this description the focus is on SLA and Billing /monetization. 2. Security needs to be considered in a later review. 3. As Cloud Carriers are often subject to regulation there are potential regulatory impacts on the relationship between the Cloud Provider and the Cloud Carrier. 4. In the model we assume a single Cloud provider using a single Cloud Carrier (for simplicity). 5. The Cloud Customer is assumed to be a customer with requirements identical to those captured by the ECLC. 6. It is assumed that the Cloud Provider will provide an on demand service with values that are determined by spot and future demand for capacity (average peak and time interval for computing, storage and network access) the reason for this assumption is that static usage pricing is unlikely to be sufficient and many service e.g. airline ticketing, stocks, are based on dynamic pricing. 7. Some requirements imply that the Cloud Provider must support the identities of individual users (role) and Customer Administration Roles (for policy setting). The analysis of the impact of the ECLC requirements is therefore: TR174 Addendum A Version 1.1 TM Forum 2012 Page 11 of 24

o How the Cloud provider offers a service that matches the ECLC Requirements. o The business relationship established between the Cloud Provider and cloud Carrier with an emphasis on SLA and revenue risk share. TR174 Addendum A Version 1.1 TM Forum 2012 Page 12 of 24

Business model Customer/Market Product Offering Name Short description NIST Cloud Scenario 2: Cloud Provider/Carrier delivers assured SLA In this Business model the Cloud Provider holds the commercial relationship with the Cloud Customer and manages the relationship with the Cloud Carrier. It does this based on the value of Cloud Carrier products and services and SLA guarantees that have values that are set statically or dynamically. Market players/competition Maturity level Priority Cloud Customer Cloud Provider Cloud Carrier immature High ( for NIST) Customer Segment Channel Relationship Government Typical enterprise Policy based Self Large enterprises custom offer Service for user, No channel needed B2B relationships for (operator brand is policy exchange and usually invisible) bulk operations ( e.g. Configuration reporting, SLA Report - Key quality /performance indicators- usage and financial ) Value Proposition To Cloud Customer: complete product to the enterprise; single supplier, one SLA, one point of escalation, and one bill. To Cloud Provider: complete solution to customer( one stop shop), direct control of all contracts to supporting Cloud Carrier(s), no complex coordination with other parties without a direct commercial relationship. C2M Activities Resources Partners One stop shop Cloud Provider: Single point of contact SaaS appropriate B2B to customer need Assume all the risks Computing implicit in customer platform Virtual requirements - machine PaaS especially flexibility, on demand capacity and SLA guarantees. Dynamic Value package linked to capacity and SLA Wholesale Contractual relationship with Cloud Carrier( Iaas/Naas) Wholesale relationship with one of more cloud carriers having managed network access with managed QoS e.g. Possibly metro Ethernet VLAN with managed QoS and DSL services support IPsec VPN with managed QoS with full automated B2B interface for fulfillment and assurance include SLA jeopardy and capacity forecasting /planning. TR174 Addendum A Version 1.1 TM Forum 2012 Page 13 of 24

Enterprise Management Barriers Cost structure For Cloud Provider: Enterprise bespoke service bid costs Cost of outsourced access service to meet varying capacity demands and stringent SLA guarantees over a wide range of applied demands on the access service Cloud Carrier: Managing capacity to meet SLA and financial penalties agreed with CP. Business related For CP: Very difficult to compete with access provide due to heavy CAPEX investment and operational skills needed. In any geography may only be one supplier. Negotiating the SLA risk can be difficult. Cloud Carrier: Has many opportunities for scale and efficiency gains for averaging demand across multiple customers, multiple customer segments and trading SLA demands from multiple customers and service types in real time. Pricing model for these types of models are unknown and high risk. Revenue streams Consumer pays Cloud Provider Cloud Provider pays wholesale access cost with guaranteed SLA over a range of access capacity demand ( average and peak bit rate) Transaction revenues: Pay on demand, SLA on demand. Recurring revenues o Option 1: Cloud Provider takes SLA rebate risk if SLA not met. o Option 2: Cloud Carrier takes SLA risk if access SLA not met. Shared Revenue: Revenues and SLA risk split Technical Customers want complete flexibility of on demand service provision together with guaranteed SLAs. Typically SLAs are guaranteed against some form of predicted applied demand. Usually technical solutions imply capacity forecasting and commitment process especially where Physical infrastructure is needs. Normally these are manual processes. However for newer access technologies such as MEF VLAN capacity, QoS and automated management solutions to on demand capacity is more feasible. For on demand capacity demand forecasting and ordering process needs to be automated with automated B2B interfaces or APIs; and real time pricing reminiscent of marketplace trading systems. Drivers Strategic portfolio New Sustainable revenue source and creating stickiness for government and enterprise customers. Revenue streams Although services is on demand nature of customer leads to committed long term stable revenues and some on demand wholesale revenue. TR174 Addendum A Version 1.1 TM Forum 2012 Page 14 of 24

Touchpoints/Use Cases Upstream For Cloud Carrier: Service negotiation On demand pricing package Automated o Product catalogues and lists that describe the potential cost of services and products, fulfillment, o assurance, o billing and o capacity forecasting and demand process supported by B2B interfaces or APIs. Downstream Touchpoints for Cloud Provider to End Customer Self Service B2B processes SLA reports Billing reports suitable for internal accounting. Provision of selfservice with customer s end users can provide departmental and individual SLA and Billing reports. Increases stickiness Impact on other TM Forum teams (Critical issues etc.) Business Process Model (aka etom) B2B Touchpoints: fulfillment, assurance billing and capacity forecasting and demand Product service catalogue with dynamic pricing Other teams SES, SLAM, Revenue Management Information Model (aka SID) Models for Cloud Service as defined by industry taxonomies and policy e.g. NIST. 2.2 NIST Scenario 1 business models Service Broker The following scenario is taken form the NIST Cloud Computing Reference Architecture, [NIST 1]. TR174 Addendum A Version 1.1 TM Forum 2012 Page 15 of 24

NIST Case scenario 2 1. In preparing this description the focus is on SLA and Billing /monetization. 2. Security needs to be considered in a later review. 3. Because the Service Broker hides the details of the cloud providers and cloud carriers supporting it the scenario sis nearly identical to Scenario 2 earlier. Note italic text shows where the requirement in this example are differ from Scenario 2. Business model Customer/Market Name Short description NIST scenario 1 Service Broker In this Business model the Service Broker Service Broker delivers assumed SLA holds the commercial relationship with the Cloud Customer and manages the relationship with the Cloud Providers and Carrier. It does this based on the value of Cloud Provider and Cloud Carrier products and services and SLA guarantees that have values that are set statically or dynamically. Market players/competition Maturity level Priority Cloud Broker Cloud Customer Cloud Provider Cloud Carrier Immature High (for NIST) Customer Segment Channel Relationship Government Typical enterprise Policy based Self Large enterprises custom offer by Service Service for user, Broker B2B relationships for No channel needed policy exchange and (operator brand is bulk operations ( e.g. usually invisible) Configuration reporting, SLA Report - Key quality /performance indicators- usage and financial ) TR174 Addendum A Version 1.1 TM Forum 2012 Page 16 of 24

Product Offering C2M Value Proposition To Cloud Customer: complete product to the enterprise; single supplier, one SLA, one point of escalation, and one bill. Cloud Broker mediates the gap between the Customer needs and the current capabilities of Providers and Carriers (mainly operational). Cloud Broker is the focal point for establishing the trust and settlement relationship between the Providers and the customer. To Cloud Provider: and Cloud Carriers can restrict their product offerings to their key competences based on assets they currently have. Reduces barriers and lowers risks to each participating in end to end services with guaranteed SLAs Activities Resources Partners One stop shop Service Broker: Wholesale relationship with Single point of contact one of more cloud carriers Wholesale B2B having managed network Contractual Assume all the risks access with managed QoS relationship with implicit in customer Cloud Providers requirements - and Cloud Carrier especially flexibility, on demand capacity and SLA guarantees. Dynamic Value package linked to capacity and SLA Trust settlement and operational management (jeopardy, SLA, incident resolution) services. Cloud Provider : SaaS appropriate to current capabilities Computing platform Virtual machine PaaS Cloud Carrier Iaas/Naas) tailored to current capabilities TR174 Addendum A Version 1.1 TM Forum 2012 Page 17 of 24

Enterprise Management Barriers Cost structure For Cloud Broker: Enterprise bespoke service bid costs Cost of outsourced access service to meet varying capacity demands and stringent SLA guarantees over a wide range of applied demands on the access service Managing capacity to meet SLA and financial penalties agreed with CP. CAPEX on platform. OPEX on business growth related operations. Cloud Carrier and Provider: Standard product offer and tailored SLA /QoS cost and rebate structure Business related For Service Broker: Platform for trust and settlements and operational processes not easy to construct. ( know how barrier) For CP: Cloud Carrier: Lowers barriers to serving Enterprise customers cloud needs. Tailored SLA s may be unfamiliar Very difficult to compete with access Negotiating the SLA risk can be difficult. Has many opportunities for scale and efficiency gains for averaging demand across multiple customers, multiple customer segments and trading SLA demands from multiple customers and service types in real time. Pricing model for these types of models are unknown and high risk. Revenue streams Consumer pays Service Broker Service Broker pays Cloud Carrier wholesale access cost with guaranteed SLA over a range of access capacity demand ( average and peak bit rate) Service Broker pays Cloud Provider and Carrier wholesale cost with guaranteed SLA over a range of platform capacity demand ( average and peak bit rate) Transaction revenues: Pay on demand, SLA on demand. Recurring revenues o Option 1: Cloud Broker takes SLA rebate risk if SLA not met. o Option 2: Cloud Broker backs off Part of SLA risk to Cloud Provider and Carrier for their part of e2e service. Note some residual risk will lie with SB. Shared Revenue: o Revenues and SLA risk split Technical Customers want complete flexibility of on demand service provision together with guaranteed SLAs. Typically SLAs are guaranteed against some form of predicted applied demand. Usually technical solutions imply capacity forecasting and commitment process especially where Physical infrastructure is needs. Normally these are manual processes. However for newer access technologies such as MEF VLAN capacity, QoS and automated management solutions to on demand capacity is more feasible. For on demand capacity demand forecasting and ordering process needs to be automated with automated B2B interfaces or APIs; and real time pricing reminiscent of marketplace trading systems. TR174 Addendum A Version 1.1 TM Forum 2012 Page 18 of 24

Drivers Strategic portfolio New Sustainable revenue source and creating stickiness for government and enterprise customers. Revenue streams Although services is on demand nature of customer leads to committed long term stable revenues and some on demand wholesale revenue. Touchpoints/Use Cases Impact on other TM Forum teams (Critical issues etc.) Upstream Downstream For Service Broker: Touchpoints for Service Broker to End Service negotiation Customer On demand pricing package Self Service Automated Policy o Product catalogues and Product Catalogue lists that describe the B2B processes potential cost of services SLA reports and products, fulfillment, Cloud Service composition o assurance, Billing reports suitable for internal o billing and accounting. Provision of self-service with o capacity forecasting and customer s end users can provide demand process departmental and individual SLA and supported by B2B interfaces or APIs. Billing reports. Increases stickiness. Business Process Model Information Model (aka etom) (aka SID) TDB TBD Other teams TBD TR174 Addendum A Version 1.1 TM Forum 2012 Page 19 of 24

3 References 3.1 References Reference Description Source Brief Use Summary Project Charter Link To Models Osterwalder 1 Osterwalder 2 Wikipedia NIST 1 <<PROJECT name>> Project Charter << Hyperlinks to or location of associated models>> Phd Thesis THE BUSINESS MODEL ONTOLOGY http://www.alexosterwalder.co m/ and http://www.hec.unil.ch/aosterw a/phd/ Business Model Generation, Wiley, ISBN 978-0-470-87641- 1, 2010 http://en.wikipedia.org/wiki/bus iness_model_canvas NIST Special Publication 500-292, NIST Cloud Computing Reference Architecture, Sept 2011 http://collaborate.nist.gov/twikicloudcomputing/pub/cloudcomputin g/referencearchitecturetaxon omy/nist_sp_500-292_- _090611.pdf HEC Lausanne Wiley Wikipedia NIST <<summary>> <<summary>> Initial introduction to CANVAS and BBML Hands on manual showing practically how to define Business Models<<summary>> Wikipedia introduction to CANVAS Current US governance view of the key architectural components for Cloud services. TR174 Addendum A Version 1.1 TM Forum 2012 Page 20 of 24

4 Glossary business model channel communication channel concept to market cost structure customer segment downstream customer interaction patterns key activities key partners key resources relationship A business model describes the rationale of how an organization creates, delivers and captures value. Channels (communication, distribution, and sales channels) comprise a company s interface with customers. Channels are customer touch points that play an important role in the customer experience. Medium through which a message is transmitted to its intended audience or through which communication takes place between different partners. Concept to market is all about getting an idea into an executable form where it can then be developed, produced and sold in the marketplace. The Cost Structure describes the most important costs incurred to operate the business model. The Customer Segments define the different groups of people or organizations an enterprise aims to reach and serve. A customer segment is a sub-set of a market made up of people or organizations with one or more characteristics that cause them to demand similar products and/or services based on qualities of those products such as their value or function. A true customer segment meets all of the following criteria: it is distinct from other segments (different segments have different needs), it is homogeneous within the segment (exhibits common needs); it responds similarly to a market stimulus, and it can be reached by a market intervention. Downstream customers are the end users of a product or service, this can be consumers as well as companies. Interaction patterns document a generic sequence of interactions between different partners. Illustrates the most important things a company must do to make its business model work. The network of suppliers and partners needed to make the business model work. The most important assets required to make a business model work. Every business model requires Key Resources. These resources allow an enterprise to create and offer a value proposition, reach markets, maintain relationships with Customer Segments, and earn revenues. Describes the types of relationships a company establishes with specific Customer Segments. Relationships can range from personal to automated. TR174 Addendum A Version 1.1 TM Forum 2012 Page 21 of 24

revenue stream sales and distribution channel touchpoints upstream customer use case value proposition The cash a company generates from each Customer Segment; A business model can involve two different types of Revenue Streams: Transaction revenues resulting from one-time customer payments. Recurring revenues resulting from ongoing payments to either deliver a Value Proposition to customers or provide post-purchase customer support. Path or 'pipeline' through which goods and services are sold or delivered. A distribution channel can be as short as being direct from the vendor to the customer/consumer or may include several interconnected (usually independent but mutually dependent) intermediaries such as wholesalers, distributors, agents and retailers. Touchpoints describe how an enterprise running such a business model interacts with their upstream and downstream customers. Upstream customers are B2B partners/enterprise customers (e.g. retailers, media, advertisers, utilities, finance etc.) A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios. The value proposition is the reason why customers turn to one company over another. It solves a customer problem or satisfies a customer need. Each value proposition consists of a selected bundle of products and/or services that caters to the requirements of a specific customer segment. In this sense, the value proposition is an aggregation, or bundle, of benefits that a company offers customers. sources: Business Model Generation Handbook of Alexander Osterwalder Writing Effective Use Cases Alistair Cockburn Humans and Technology Wikipedia online TR174 Addendum A Version 1.1 TM Forum 2012 Page 22 of 24

5 Administrative Appendix This Appendix provides additional background material about the TM Forum and this document. In general, sections may be included or omitted as desired, however a Document History must always be included. 5.1 About this document This is a TM Forum Guidebook. The guidebook format is used when: o The document lays out a core part of TM Forum s approach to automating business processes. Such guidebooks would include the Telecom Operations Map and the Technology Integration Map, but not the detailed specifications that are developed in support of the approach. o Information about TM Forum policy, or goals or programs is provided, such as the Strategic Plan or Operating Plan. o Information about the marketplace is provided, as in the report on the size of the OSS market. 5.2 Document History 5.2.1 Version History Version Number Date Modified Modified by: Description of changes 1.0 2 nd JUL 2011 Dave Milham Initial content 1.1 12 th March 2012 Dave Milham updated Scenario 2 plus references 5.2.2. Release History <This section records the changes between this and the previous Official document release> Release Number Date Modified Modified by: Description of changes Release Number 1 April 4, 2012 Mary Amalfitano First Issue of Document TR174 Addendum A Version 1.1 TM Forum 2012 Page 23 of 24

5.3 Company Contact Details Telecom Italia Company Team Member Representative Cecilia Maria Corbi and Massimo Banzi, Service Layer Standards Coordination MediaanABS Deutschland GmbH TM Forum TM Forum Email: ceciliamaria.corbi@telecomitalia.it; massimo.banzi@telecomitalia.it Phone 39 011 2286129 Fax Dirk Rejahl Director Email: dirk.rejahl@mediaan.com or dirk.rejahl@mediaan.nl Phone: 49 211 250 510 32 Fax Dave Milham Chief Architect Email dmilham@tmforum.org Phone Fax Robert B. Cohen, PhD, Director, Enterprise Cloud Leadership Council Email: bcohen@tmforum.org Fax 5.4 Acknowledgments This document was prepared by the members of the TM Forum SPLC ECLC TIGER team: o David Milham and Robert Cohen, :TMForum, Editors o Cecilia Maria Corbi and Massimo Banzi, Telecom Italia, and o Dirk Rejahl, Director, MediaanABS Deutschland GmbH TR174 Addendum A Version 1.1 TM Forum 2012 Page 24 of 24