T-109.4300
Network Service Business Models
Case-analyses of Open Telco/mobile cloud applications Case-analyses of Open Telco/mobile cloud applications
16.2.2011
Vesa Suikkola, B.Sc. (Tech.)
vesa.suikkola@aalto.fi
Presentation overview
• Background
• Case analyses
– GSMA OneAPI
– Event Experience application – Kassi Ridesharing application – Kassi Ridesharing application
• Synthesis and models for the generation of value
• Conclusion
Background
Background
Problems in mobile service development
• Limited computing resources
• Energy consumption
• OS fragmentation
Background
Mobile clouds / mobile cloud computing
• Cloud-computing principles can be considered as the utilization of virtualized, on-demand, server-based IT infrastructure
• Mobile clouds, or mobile cloud computing (MCC), can be defined as an extension of the cloud-computing be defined as an extension of the cloud-computing principles into delivering applications and services for mobile devices
• Open APIs – key enabler for the MCC applications
– IaaS (e.g., Amazon Web Services), PaaS (e.g., Google App Engine)...
Background
Open Telco
...NaaS (Network as a Service)
• Framework for open telecommunication-operator network inferfaces
– Sample capabilities: location, messaging, and payment
• Enables telco mash-ups and Open Innovation in the telco domain Long Tail of mobile services
• Current state: uncertainty and consequent lack of deployments
– Need for revolutionary applications (”killer apps”) to drive the ecosystem forward
Background
Definitions
How is value generated for the providers as well as the
consumers of mobile services in the mobile cloud-
computing domain (by the Open Telco concept)?
Background
Definitions
• Mobile clouds / mobile cloud computing:
Mobile clouds or mobile cloud computing is the
utilization of cloud-computing paradigms in conjunction
with open telecommunications-network application
programming interfaces for delivering applications and
programming interfaces for delivering applications and
services to mobile devices
Background
Definitions
• Value (of technology):
Technological value is the sum of the stand-alone utility of the technology, the value of its installed base of users, and the value of the complementary
Value
Complementary goods
Complementary goods
Complementary goods (of A)
Installed base (of A) value of the complementary
goods available for that technology
M. A. Schilling, Strategic Management
Value
Installed base
Technological utility
Installed base
Technological utility
Technology A Technology B
Installed base (of A)
Technological utility
Technology C
Case analyses
Case analyses
Recap of the STOF model
Business model Service domain,
e.g., value proposition, target group
Organization domain, e.g., division of roles, Technology domain,
e.g., service delivery
Value for customers
S
e.g., division of roles, network strategy e.g., service delivery
system
Finance domain, e.g., revenue
model
Value for service providers
O T
F
Case analysis – GSMA OneAPI
Case analysis
GSMA OneAPI – Service domain
• Complement the existing open APIs
• Provides network capabilities and information (i.e., NaaS)
– OneAPI v.1.0: location, messaging, and payment
• Brings different networks (operators) together,
• Brings different networks (operators) together, increasing the market base
• Decreased development effort for mobile services
• Payment capabilities bring a novel and easy way of
charging customers for the services
Case analysis
GSMA OneAPI – Technology domain
• SOAP and RESTful APIs to access the network capabilities
• Payment capabilities
implemented through PayPal
Partners (ASPs)
OneAPI (SOAP & REST)
PayPal Aepona Universal Service Platform
OneAPI
SMS MMS Location Payment PayPal Web Service Interface
PayPal
SMS MMS Location Payment
TWS Platform SMS MMS Location Payment
PayPal Web Service Interface
Telus Bell Rogers
Parlay X Parlay X Parlay X
SMS, Location, Billing SMS, Location, Billing SMS, Location, Billing
Case analysis
GSMA OneAPI – Organization domain
• Operators can utilize their core assets (network capabilities) as marketable resources
Two-sided ecosystem
• OneAPI acts as a network capability broker
Operators
Operator Operator Broker
capability broker
Operator
Users Service
Case analysis
GSMA OneAPI – Finance domain
• One broker monopoly
• Many brokers benefits of the standard (aggregate market, low-cost integration) are lost
• Operator investment in the range of 1,5 – 2,0 M€
• Transaction fee-based usage of the APIs
• Transaction fee-based usage of the APIs
– Commonly, open APIs are free
– OneAPI: $0,035 messaging, $0,045 location, 30% payment
Case analysis – Event Experience
Case analysis
Event Experience
Alice and Bob find an interesting event on their favorite social networking site. They click to attend and notice the Event Experience service is available for this concert-event. They order the service by specifying their mobile subscriptions to the application and receive admittance and complementary bus tickets by MMS and/or SMS. On the event day, Alice and Bob are heading to the venue well in advance as the service informs them a rush is expected. Their phones alert both at the same time – the concert expected. Their phones alert both at the same time – the concert organizer is guiding them to use Gate B as Gate A is crowded. They get in and find their seats in no time with the area map included in the service. Now it is time to read the latest comments by other visitors from the event wall, and see if any of their friends are located at the concert area. Alice and Bob are also invited to vote for the encore song of the concert. After the event, Bob orders a t- shirt through the Event Experience page; he can conveniently pay for the order by mobile.
Case analysis
Event Experience – Service domain
• Organizer and user application
• Integrated package of event-related services
– Tickets and merchandise
– Pre-, on- and post-event information – Social network services
– Social network services
• Grouping, voting, chat, information sharing…
• Concerts, conferences, exhibitions, sports events, private parties, etc.
• Browser-based application low-effort adoption (no
need to install an application)
Case analysis
Event Experience – Service domain
• Complementary services:
– Information service on the event in which the users receive relevant information about the event, such as the event program, schedule, and seating chart.
– Proactive crowding avoidance at the venue, for example, to avoid crowding some entrances.
– Separate or expedited entrance for Event Experience holders at the venue.
– An event specific blog and media feed through which the users can receive and send messages to other attendees; moreover, the service component could also be utilized to provide live media streams from the event.
be utilized to provide live media streams from the event.
– Polling and voting system, for example, for voting on the encore or rating the previous song at concerts.
– Friend-presence service for checking if a friend is attending the event.
• Supplementary services:
– Public transportation ticket to the venue.
– Navigation service or route instructions to the venue.
– Event-store that offers, for example, video recording of the event, song
downloads, event highlights media, or other event-related merchandise available
Case analysis
Event Experience – Service domain
Feature / Benefit Event Experience Tiketti YLE-Twitter SMS-voting Facebook Mobile ticket
distribution X X
Mobile ticket
purchase X X1
Ticket validation
X X
Context-specific
messaging X X2 X
messaging X X2 X
Sharing context-
specific media X X2 X
Polling and voting
X X
Audience - organizer
interaction X X3 X X
Case analysis
Event Experience – Technology domain
• Application placed wholly in the cloud
• Browser-based application
– Decreased device requirements (processing, battery)
– Decreased effect of OS fragmentation (accessible by mobile and desktop devices)
– Full-blown implementation of the organizer application with a browser-based implementation?
Case analysis
Event Experience – Technology domain
• Prototype implementation
– Integration to Facebook events and social networks
• Features: event wall, SMS/MMS messaging, ticketing and payment mock-ups
– Telco messaging and payment (mock-up) – C.a. 500 hours of development time
– C.a. 500 hours of development time – Challenges:
• Integration to external systems
• Telco API limitations (payment not available, limited transactions)
Case analysis
Event Experience – Organization domain
• Two-sided market (for the service provider)
– Organizers and users
• In addition to utilizing Open Telco APIs, the developer can utilize other open APIs (role
Developer
Service provider
Advertiser
Ticketing office Service component
providers
Open Telco
utilize other open APIs (role labeled ”Service component providers”)
– E.g. Facebook as the
event/social-network platform
User Event organizer
Case analysis
Event Experience – Finance domain
• Revenue streams
– Users and organizers – (Advertisers)
• Utilization of cloud principles
– Cloud hosting
– Browser-based application – Browser-based application – Open Telco capabilities
Only investment is the actual application development
– Risk mitigation through modular architecture
• Able to prioritize the core service features (ticketing, information, and social-networking features)
Case analysis
Event Experience – Finance domain
• Market example
– Total number of users: 2 000 000
– Total number of events attended: 5 per user per annum – Total number of events organized: 1 per user per annum – Average ticket price: 10 €
– Ticket commission: 5%
– Ticket commission: 5%
– Advertisements: 5 ads per event
– Advertisement revenue: 0.10 € per ad
Events attended * avg. ticket price * service commission + advertisements * ad revenue * Events organized
= 6 000 000 € per annum
Case analysis – Kassi Ridesharing
Case analysis
Kassi Ridesharing – Service domain
• Value proposition is targeted for two user groups...
– Users who are planning to drive a route and would be willing to share the ride with another user in order to help them and/or to share travel costs.
– Users who do not have a car and/or are environmentally conscious and would like to be able to find a car-pooling conscious and would like to be able to find a car-pooling
opportunity; that is, find someone driving the same route they would need to travel and willing to share the ride.
• …by decreasing the effort of ridesharing between the
groups in a semi-dynamic environment, where the users
are a part of the Kassi community
Case analysis
Kassi Ridesharing – Service domain
• Concrete service features: Service feature
#1 Browse routes
#2 Offer route
#3 Request route
#4 Match offer to request
• Issues:
– Driver attitudes (e.g., convenience, flexibility, and privacy of driving alone)
– Incentives (e.g. shared cost, environmental benefits) – Substitution (e.g., public transportation)
#5 SMS compensation
Case analysis
Kassi Ridesharing – Service domain
Issue Kassi Ridesharing GreenRiders Kyydit.net
Driver attitudes
+1 +1 -1
Incentives
+2 +1 0
Substitution
+1 0 0
Critical mass
+1 0 +1
Legal and regulatory barriers
-2 0 0
Case analysis
Kassi Ridesharing – Technology domain
• Desktop browser and SMS-based implementation
– Browser-based mobile interface in development
• Telco messaging and location provide high mobility and low effort of use
• Prototype implementation
• Prototype implementation
– Integration to Kassi system with all of the listed features
• Additional feature: dynamic route matches
– Telco messaging and payment (mock-up) – C.a. 450 hours of development time
– Issues:
Case analysis
Kassi Ridesharing – Organization domain
• Relatively simple organizational model
– E.g., in comparison to Event Experience case
• ”Kassi–Open Telco–User”
triangle most critical
– Value proposition related to low
Developer
Kassi Ridesharing
Advertiser
Cloud Open Telco
– Value proposition related to low effort of use
– Critical mass issue
The system must work for all mobile subscriptions
• Advertiser is a potential role enabling advertisement-based
User
Case analysis
Kassi Ridesharing – Finance domain
• Revenue streams
– Users (commission on SMS compensations) – (Advertisers)
• Utilization of cloud principles
– Browser-based application – Browser-based application – Open Telco capabilities
Only investment is the actual application development
• Open Telco payment – 30% revenue share infeasible
– 43% margin on SMS compensation amount required to cover
Case analysis
Kassi Ridesharing – Finance domain
• Market example
– Total number of users: 2 000 000 – Total number of drivers: 25%
– Average yearly mileage: 20 000 km
– Kassi Ridesharing service penetration: 20%
– Percentage of shared rides: 20%
– Average passenger fee: 0,25 € per km – Service commission: 5%
Drivers * mileage * service penetration * shared rides * avg. fee
* service commission = 5 000 000 € per annum
Synthesis and models for the
generation of value
Synthesis
• Benefits
– Standard APIs
• Low-effort integration to mobile capabilities, e.g., with the RESTful APIs (OneAPI, Event, Kassi)
• Attractive technology, e.g., the new NaaS capabilities (OneAPI Kassi, Event)
• Novel business logic through the payment API (OneAPI, Event, Kassi)
• Novel business logic through the payment API (OneAPI, Event, Kassi)
– One market
• Maximal installed base of potential end-users (OneAPI, Event, Kassi)
– Open Innovation
• Enables novel mobile services, which create benefits also for the operators (Event, Kassi)
– Novel applications
• Relative advantage over existing services (Event, Kassi)
Synthesis
• Drawbacks
– Competition in the operator-broker and broker-developer thresholds (OneAPI)
– Rigid API pricing model (OneAPI, Event, Kassi), especially payment infeasible (Event, Kassi)
– Advertisers (OneAPI, Event, Kassi) – Advertisers (OneAPI, Event, Kassi) – Compatibility with adopter needs?
Synthesis
• Critical design issues
– Accommodation of diverse business models for the external service providers
• Aggregation of advertisers to the system
– Accumulation of critical mass
• The system may benefit from ”best price” and ”focus” strategies
• The system may benefit from ”best price” and ”focus” strategies
Models for the generation of value
• Organizational model for optimal generation of value in Open Telco
• Conceptual model(s) for the generation of technological
value
Models for the generation of value
Virtual-broker Model
Virtual Broker
Operator Developer
Service
Advertiser API provider
Network Operator
Operator Operator
User
Service Network
Broker host
Models for the generation of value
Virtual-broker Model revenue flows
Virtual Broker
Operator Developer
Service
Advertiser API provider
Network Operator
Operator Operator
User
Service Network
Broker host
Models for the generation of value
Conceptual model(s) for value generation
Virtual broker
Standards (GSMA OneAPI) End users
Complementary goods
Installed base
Technological utility
Services Operator customers
More users joining Operator specific APIs
Simplification
Spillovers Learning
More services
Direct externalities
Virtual broker
Standards (GSMA OneAPI) End users
Complementary goods
Installed base
Technological utility
Services
Attractive services
Spillovers Competition, spillovers
Attractive technology Attractive market
Attractive technology
Conclusion
Value is generated through...
• Virtual-broker Model
– Effective ecosystem facilitated by co-opetitition – Accomodation of diverse set of business models – Technological utility and spillovers
– Accumulation of critical mass
• OneAPI standard
– Avoids fragmentation – Avoids fragmentation
– Low-effort development of services
• Number/availability of novel services
– Value for the end users
– Technological learning and spillovers
• Installed base of end-users
