Cloud Business Models
B2B Business Model Inventory
Release 1.0
TR174 Addendum A
Version 1.1
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 – 10th Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110
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
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.
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 ENSI1 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.
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.
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
Who are the relevant players in the market, running this business model? How competitive is the business model? [extension to Osterwalder’s canvas]
Maturity level What is the level of maturity of the business model within the market? (e.g. innovative, well established) [extension to Osterwalder’s canvas] Priority 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]
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 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.
Relationship 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.
Element Sub-element Semantics C2M
(Concept to Market)
Key Activities 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 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).
Key Partners 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) Enterprise
Management
Cost Structure 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.
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] Revenue Streams 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]
Touchpoints/Use Cases
Upstream 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
[extension to Osterwalder’s canvas] Information Model [extension to Osterwalder’s canvas] Other projects [extension to Osterwalder’s canvas]
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).
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.
Business model
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/Market
Customer Segment Channel Relationship
Government Large enterprises Typical enterprise custom offer No channel needed (operator brand is usually invisible)
Policy based Self Service for user , B2B relationships for
policy exchange and bulk operations ( e.g. Configuration
reporting, SLA Report -Key quality
/performance
indicators- usage and financial )
Product Offering
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 Single point of contact
B2B
Assume all the risks implicit in customer requirements
-especially flexibility, on demand capacity and SLA guarantees. Dynamic Value package linked to capacity and SLA
Cloud Provider: SaaS appropriate to customer need Computing platform Virtual machine PaaS 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.
Enterprise Management
Cost structure Revenue streams
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.
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
Barriers
Business related Technical
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.
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 Revenue streams
New Sustainable revenue source and creating stickiness for government and enterprise customers.
Although services is on demand nature of customer leads to committed long term stable revenues and some on demand wholesale revenue.
Touchpoints/Use Cases
Upstream Downstream
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.
Touchpoints for Cloud Provider to End Customer
Self Service B2B processes SLA reports
Billing reports suitable for internal accounting. Provision of self-service 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)
Information Model (aka SID)
B2B Touchpoints: fulfillment, assurance billing and capacity forecasting and demand Product service catalogue with
dynamic pricing
Models for Cloud Service as defined by industry taxonomies and policy e.g. NIST.
Other teams
SES, SLAM, Revenue Management
2.2 NIST Scenario 1 business models
Service Broker
The following scenario is taken form 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. 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
Name Short description
NIST scenario 1 Service Broker Service Broker delivers assumed SLA
In this Business model the Service Broker 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/Market
Customer Segment Channel Relationship
Government Large enterprises
Typical enterprise custom offer by Service Broker
No channel needed (operator brand is usually invisible)
Policy based Self Service for user , B2B relationships for
policy exchange and bulk operations ( e.g. Configuration
reporting, SLA Report -Key quality
/performance
indicators- usage and financial )
Product Offering
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
C2M
Activities Resources Partners
One stop shop Single point of contact
B2B
Assume all the risks implicit in customer requirements
-especially flexibility, on demand capacity and SLA guarantees. Dynamic Value package linked to capacity and SLA
Service Broker:
Wholesale Contractual relationship with Cloud Providers and Cloud Carrier
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
Wholesale relationship with one of more cloud carriers having managed network access with managed QoS
Enterprise Management
Cost structure Revenue streams
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
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
Barriers
Business related Technical
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.
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 Revenue streams
New Sustainable revenue source and creating stickiness for government and enterprise customers.
Although services is on demand nature of customer leads to committed long term stable revenues and some on demand wholesale revenue.
Touchpoints/Use Cases
Upstream Downstream
For Service Broker:
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.
Touchpoints for Service Broker to End Customer Self Service Policy Product Catalogue B2B processes SLA reports
Cloud Service composition Billing reports suitable for internal accounting. Provision of self-service 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) Information Model (aka SID) TDB TBD Other teams TBD
3 References
3.1 References
Reference Description Source Brief Use Summary Project Charter <<PROJECT name>> Project
Charter
<<summary>>
Link To Models << Hyperlinks to or location of associated models>>
<<summary>>
Osterwalder 1 Phd Thesis THE BUSINESS MODEL ONTOLOGY http://www.alexosterwalder.co m/ and http://www.hec.unil.ch/aosterw a/phd/ HEC Lausanne
Initial introduction to CANVAS and BBML
Osterwalder 2 Business Model Generation, Wiley, ISBN 978-0-470-87641-1, 2010
Wiley Hands on manual showing practically how to define Business Models<<summary>>
Wikipedia http://en.wikipedia.org/wiki/Bus iness_Model_Canvas
Wikipedia Wikipedia introduction to CANVAS
NIST 1
NIST Special Publication 500-292, NIST Cloud Computing Reference Architecture, Sept 2011 http://collaborate.nist.gov/twiki- cloud-computing/pub/CloudComputin g/ReferenceArchitectureTaxon omy/NIST_SP_500-292_-_090611.pdf
NIST Current US governance view of the key architectural components for Cloud services.
4 Glossary
business model A business model describes the rationale of how an organization creates, delivers and captures value.
channel 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.
communication channel Medium through which a message is transmitted to its intended
audience or through which communication takes place between different partners.
concept to market 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.
cost structure The Cost Structure describes the most important costs incurred to operate the business model.
customer segment 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 customer Downstream customers are the end users of a product or service, this can be consumers as well as companies.
interaction patterns Interaction patterns document a generic sequence of interactions between different partners.
key activities Illustrates the most important things a company must do to make its business model work.
key partners The network of suppliers and partners needed to make the business model work.
key resources 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.
relationship Describes the types of relationships a company establishes with specific Customer Segments. Relationships can range from personal to
revenue stream 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.
sales and distribution channel
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
inter-connected (usually independent but mutually dependent) intermediaries such as wholesalers, distributors, agents and retailers.
touchpoints Touchpoints describe how an enterprise running such a business model interacts with their upstream and downstream customers.
upstream customer Upstream customers are B2B partners/enterprise customers (e.g. retailers, media, advertisers, utilities, finance etc.)
use case 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.
value proposition 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
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 2nd JUL 2011 Dave Milham Initial content
1.1 12th 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
5.3 Company Contact Details
Company Team Member Representative
Telecom Italia Cecilia Maria Corbi and Massimo Banzi, Service Layer Standards Coordination Email: [email protected]; [email protected]
Phone 39 011 2286129 Fax
MediaanABS Deutschland GmbH Dirk Rejahl Director
Email: [email protected] or
Phone: 49 211 250 510 32 Fax
TM Forum Dave Milham Chief Architect
Email [email protected] Phone
Fax
TM Forum Robert B. Cohen, PhD, Director, Enterprise Cloud Leadership Council Email: [email protected] 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