The document provides an overview of an independent review of telecom APIs. It includes summaries of four presentations: Alan's presentation discusses why telcos need APIs, common API strategies, and predictions about the telecom industry. Luis' presentation features details on the APIDAZE API and case studies. Jean's presentation is about the RestComm platform and a health case study. Sam's presentation provides information on Tropo products and case studies. The document emphasizes that the value of APIs is in the services delivered, not the APIs themselves, and that telecoms need to work with developers to create new services and applications.

1. Independent Review of Telecom APIs
Nov 11th 2013

2. Structure: Alan’s Bit
•
•
•
•
•
•
•
•
•
2
The Painful Facts!
Why do telcos need APIs?
Why all the big numbers?
Beware the Bait and Switch!
Where are the Telco API successes?
Dos and Don’ts of Telco API success
Mapping the API landscape!
Where are Telecom API going?
What needs to change?
© 2010 Alan Quayle Business and Service Development

3. Structure: Luis’s bit
•
APIDAZE: facts & figures
•
Presentation of the APIDAZE REST API
•
Customer case: How a leading European affiliate network increased
its revenue by 15% using APIDAZE
•
APIDAZE & WebRTC
•
WebRTC integration using APIDAZE
3
© 2010 Alan Quayle Business and Service Development

4. Structure: Jean’s Bit
•
TeleStax introduction
•
What is RestComm?
•
HealthSense Case Study: using Telecom APIs to help baby boomers
age safely
•
4
RestComm demo
© 2010 Alan Quayle Business and Service Development

5. Structure: Sam’s bit
•
The Tropo story
•
Tropo's products in a nutshell
•
Some deployed case studies
•
Use cases and other cool stuff
5
© 2010 Alan Quayle Business and Service Development

6. No developed market telco
has successfully engaged
mobile application
developers with Telecom
APIs

7. BUT Telecom API
successes have come from
using APIs internally

8. AND Telecom API
successes have come from
using APIs with existing
partners

9. APIs reduce business
friction. This means the
value is not ‘in the API’ it’s
in the service or data
delivered through the API.

10. Mobile Application Developers
ONLY care about direct access to
a large engaged customer base
that is prepared to pay. Apple
and Android fulfill this need,
Telcos are IRRELEVANT

11. Analysys Mason Prediction on Voice Usage
Telco voice usage will remain significant (74% of usage by 2018). New comms services will be
essential to maintain revenue given price pressure and data revenues not offsetting declines.

12. Analysys Mason Prediction on Messaging and ARPU
Telco messaging will become niche, anticipate rapid revenue decline as SMS moves to data.
Analysys Mason is predicting a >25% ARPU decline by 2018.
Industry needs to find >$100B in new revenues within 5 years.

13. What if a Telcos continue to do nothing?
Telcos become the “path of last resort” as apps use “easy and economical” APIs for
90% of comms, and Telcos for only 10%
Applications and Services
Easy and Economical 90%
Global comms clouds
Laggards 10%
Telco
Customers

14. So What Should Telcos Do?
Work with Developers to
embed communications
into applications, services
and business processes.
Make Comms the ‘essential
spice’ of every business
ecosystem.
Work with Developers to
create new services and
applications using
communications
capabilities. Innovate in
communications else watch
revenue decline.
$40B by 2018 source
Mind Commerce
$35B by 2018 source
Ovum
Telecom Application Developers are now essential to addressing the revenue decline
in communication services.
Previous efforts have failed, corrective action is required urgently.

15. Revenue
Defining what is meant by Telecom App Developer
Internal Telco Developers
Partner Developers
Telecom App Developers
Mobile App Developers
Long Tail Developers
Product

16. Revenue
This Is A More Accurate Representation
Internal Telco Developers
Partner Developers
Telecom App Developers
Mobile App Developers
Long Tail Developers
Product

17. What do we mean by Telecom App Developer?
Developers that recognize
they build telecom apps
today
Hardcore
Telco Software
Infrastructure
(10ks)
IT/Web Programmers building
on FOSS, telecom app
platforms and telecom APIs
(1Ms)
‘Cut and Paste’ web developers using
web-scripting and graphical tools on
app platforms
(10Ms)
All based on IT / Web Technologies and Development Principles

18. TADS is about Building an Ecosystem
Hardcore
Telco Software
Infrastructure
(10ks)
Developers that recognize
they build telecom apps
tomorrow
IT/Web Programmers building
on FOSS, telecom app
platforms and telecom APIs
(1Ms)
‘Cut and Paste’ web developers using
web-scripting and graphical tools on
app platforms
(10Ms)
All based on IT / Web Technologies and Development Principles

19. www.tadsummit.com

20. No Gatekeeper
Focus
Motivation

21. Why? graphic

22. Why do Telcos need APIs?

APIs are just a technology, its all about the services
The money is not ‘in the API,’ it’s in the service delivered by the API. APIs are simply
delivering services more efficiently, which opens up new business opportunities.
— Jose Valles, VP Partner Products at Telefónica Digital

APIs are a global IT trend across all industries
An API strategy is becoming a must…in terms of speed to market with new products,
maximizing business development, and product development opportunities.
— Steve Kurtz, VP Business Development, USA TODAY

APIs will become critical to maintaining Telecom’s customer relevance
Without APIs Telecoms will become irrelevant as Service Providers because
customers will expect communications to be embedded in their experiences.
— Alan Quayle, Independent Telecom Thinker

23. What is an API?
•
http://www.telco.com/api.php?action=remove_friction
APIs reduce business friction by making it easy for software systems to work together
using existing well understood web technology that any IT person can understand

24. Why do Telcos need APIs?
Why do we need a
Web site?
1995
Of course we have
a Web site
2000
2005
New distribution
Accelerate internal projects
Upsell
Innovation
Why do we need
an API?
2010
Device and mobile support
Operational efficiency
Make churn harder
Extend products / services
Of course we have
an API
Increase footprint
Partner opportunities
Process automation
New business
Telecoms is the ‘vital spice’ of any successful business ecosystem

25. What APIs can Telcos offer?
Telco API
Capabilities
billing, rating, charging
calling
location
VAS
messaging
directory
device
CRM
customer profile
customer insight
internal systems
Opportunities
payment services
identity and security
personalization
cloud call centers
fraud management
enterprise cloud
hypervoice
communication enabled
business processes
lower operational costs

26. Show me the money? graphic

27. Where’s the Money in External APIs?
$244B by 2017
$157B by 2018
$18B in 2016
Mobile payments revenue, source BI
Intelligence. Includes Apple,
Android, Square, Visa Mobile, etc.
Total Telecom API revenue, source
Mind Commerce. Payment,
Communications, Identity, Cloud, etc.
Alan Quayle’s view is the revenues
will be $18B and dominated by
payment and communication service
revenues by 2016
Juniper predicts DCB (Direct Carrier
Billing) growing from $2.5B in 2012 to
$13B in 2017 (this assumes only digital
downloads, not goods and services)

28. Mobile Payments Prediction from BI Intelligence
Receipts
Revenues

29. What if a Telco does nothing?
Telco becomes the “path of last
resort” as apps use “easy and
economical” APIs for 90% of
comms
Easy and Economical 90%
Global comms clouds
Applications
Laggards 10%
Telco
Customers

30. MBA
BS!

31. Wholesale that’s a good model!
Consumers
Telco gets commoditized and
detached from customers for
comms services
Business
Offers
services
direct
Offers
services
direct
Easy and Economical 90%
Global comms clouds
Laggards 10%
Telco
Commoditizes
pricing

32. Bait and Switch graphic

33. Market Situation: API Bait and Switch
Roll-up, roll-up, buy my API
software, expose some APIs,
to gain fame and fortune just
like Apple and Google
What is sold
What happens in practice
AT&T is like an old lady that desperately wanted a ‘developer community’ broach. She
paid tens of millions for this broach, and really only got a pale imitation of a developer
community, she also didn’t realize it’s perishable, so is now disintegrating in a drawer.

34. Reality graphic

35. Market Requirements: Why are operators spending
money on API?
•
M2M to support provisioning and management
o
Verizon (Hughes Telematics), Rogers, AT&T, Telefonica, Ericsson
(bought Telenor assets)
o
•
This is generally treated as a silo, and not part of a broader API business
Wishful thinking in building a developer community like Android
and Apple
o
o
•
AT&T, Globe, BlueVia, Deutsche Telekom’s Developer Garden
Market does not yet universally understand this is a failed strategy
Support open innovation and work more easily with partners on
new business models and market opportunities
o
AT&T, Telefonica – this really started only in the last 6-9 months

36. Market Requirements: Why are operators spending
money on API?
•
Support internal innovation, in some cases focused on specific market segments
like enterprise
o
•
Verizon, Telecom Italia, Portugal Telecom
Support open innovation with specific partners targeting specific market
segments
o
•
Experimenting in what APIs could means to their business
o
•
Telus – targeting SMB
SingTel, Rogers
Build specific business opportunities like direct carrier billing (mobile
payments)
o
•
Telefonica and Telenor, Ooredoo, Etisalat
Laziness
o
Brow beaten into doing something by their vendors
o
Copying AT&T
o
Following GSMA and OneAPI Exchange

37. AT&T Graphic

38. Learning
•
It doesn’t matter how much you spend, developers are rationale decision
makers
o
Telcos continue to struggle in engaging long-tail developers, but developers will
happily turn up to events to take AT&T’s generous prize money at hackathons.
•
Telcos have many APIs they can offer beyond voice, messaging, payments
and customer information, including speech processing, authentication,
identity, mHealth, M2M (Machine to Machine), really any service can be
exposed through an API.
o
•
The hard part is building a business around the API, not offering the API.
Long tail is being redefined as light-weight open innovation.
o
That is not trying to build a developer community in competition to Apple and
Google.
o
Instead, exploring with select partners, universities, and friendly developers new
ideas or unique capabilities to telcos, e.g. mHealth, connected car, and M2M.

40. Telus Overview
•
A continuing source of SMS revenue growth comes from the enterprise use of
SMS for alerting and notifications
•
Telus has implemented a focused API program over the past 7 years – targeting
SMB with SMS alerting capabilities
o
o
Value to an enterprise is the ubiquity of communications with its customers in Canada
o
•
•
Through both direct sales people and local system integration partners
Cost is irrelevant as business value far exceeds margin costs of an SMS
Note SMS is both AT&T and Verizon’s largest by volume API
Process is designed to enable Telus to launch more apps and faster with a focus
on SME (Small Medium Enterprise)
o
o
•
Achieved a 4 to 40 annual service launch improvement
Reduce cost by 75% in launching new apps
Profitable within the first year of operation

42. Background
•
The project started on 10th June, 2010
o
o
•
Within 9 months there were 150 running applications in the market and 10600 registered users.
Today the total number of network based services developed & available for consumption is >500
Etisalat has two methods of revenue generation from the services: subscription and on-demand.
o
On-demand basis works on the subscriber being charged for every transaction or messaging that they
receive from a service, for e.g. a subscriber sends a message requesting the current exchange rate of his
local currency and he gets a reply message from the service with the information and is charged for
that message only.
o
•
The developer keeps 90% of the revenue.
Both methods ensure recurring revenue for Etisalat as opposed to one time downloadable fees and
a focus on keeping the customer engaged
•
The Developer portal enables the simplified creation of mobile apps for amateur as well as expert
software developers equipped with standard & open APIs, Software Development Kits (SDKs)
covering the major programming languages, sample apps & user guides to direct them.
•
Their interaction with the solution is through easy to use interfaces enabled by Web Services that
expose the operator service and network capabilities to allow developers to concentrate only on
developing the app without concerning about the complexities of network protocols.
•
Mobile application developers, both amateur and professional, now enjoy a simplified process of
Application Development, deployment and commercialization with mChoiceTM Cloud TAP’s
Mobile Application Developer Portal. Sample Applications, Simulators and Guides help enhance
the application paving the way for the creation of a series of sought after mobile applications.

43. Etisalat Sri Lanka, Emerging Market Telco App Store
USSD API for 100% reach in $1.25 ARPU market
•
•
•
•
•
•
•
Top 5 apps subs 3 months after launch:
Yalu (anon chat)
40,668
Sinhalalen (local) Jokes
33,787
Fun Facts
12,807
Technology News
8,262
Word Puzzle
5,554
Business models supported are per
message and subscription
•
Accounts for 3.5% of ARPU

44. Developer Portal

46. Key Points
•
Developing markets are different – messaging still matters, USSD is a
massive untapped potential for infotainment services in developing
markets.
•
Local matters – content local developers, not localized, locally
originated are proving successful with customers because they identify
with the content.
•
Size doesn’t matter, Etisalat Sri Lanka only has 3 million subscribers
with low ARPU. Yet they engaged developers creating sticky application
and differentiated their offer in the market.
•
The supporting technology is run on a cloud, lowering costs and
allowing greater flexibility.

47. Telecom Italia Graphic

48. Summary
•
•
Program started in 2008, offered SMS APIs to their content partners.
Focused across the demand curve, success remains in using APIs internally and
within Telecom Italia’s existing ecosystem of partners / customers.
•
Revenue of $250M per year made attributed to the platform, this does not
include the revenue retained by the Lines of Business. Roughly 1B transactions
per month.
•
Generally considered within the Telecom community to be the most successful
API implementation of any operator.
o
They are Oracle’s largest OCSG (Oracle Communications Services Gatekeeper, API
platform) deployment.
•
New division formed in July 2013 called “Service Delivery Platform and
NetAPI”, this appears to consolidate some of the lines of business that were
taking most of the revenue generated by the API platform.
o
It is rumored the new division’s annual revenue is >$2B (figure needs to be confirmed).

50. Learning
•
Demonstrates the money is not in long tail developers, rather use API
with partners and internally.
•
Highlights the importance of using APIs across all possible business
models, internal innovation, partner innovation, not simply focusing on
the “long-tail”.
•
Importance of an integrated platform that enables Telecom Italia to
efficiently support high transaction volume partners as well as internal
services enables it to support the relatively high priced solution of
Oracle licenses and Accenture professional service.
•
API standards are purely a baseline; they are adapted to meet specific
needs, which means API standards are useless.
o
Processes around defining new APIs are key for rapid innovation.

51. Telefonica Logo

52. Summary
•
Long history starting in 1998 of attempting to build developer communities, 2-3
year cycle of launching and closing developer initiatives. BlueVia is its longest
running initiative.
•
Internal operational efficiency and long tail developer. Current focus is on the
payment API in cooperation with Telenor and 2 other telcos, targeting partners
and large accounts, not long-tail developers.
•
•
BlueVia has turned around its API business by focusing on the payment API.
Developers consider the BlueVia program to have failed like every other long tail
telco program in the past.
•
Jose Valles, head of BlueVia recently promoted to VP Partner Products at
Telefónica Digital. Focused on build the payment service business, and adding
new APIs particularly in communications.

53. Learning
•
“The money is not in the long tail.” Jose Valles, Head of Blue Via, presented at the
SDP Global Summit . The money for BlueVia is with partners, building powerful
partnerships on Telecom APIs.
•
SMS revenue share failed as a business model as the market moved to buying bundles
of SMS, so customers did not want / expect to pay a full price SMS when using the
services built on BlueVia APIs.
•
Focus on the core capabilities of a telco, the advertising APIs did not work as TEF
lacks the credibility, inventory, and ability to build a business in this domain.
•
Long tail is about light-weight innovation, not trying to build a developer community
in competition to Apple and Google. Instead, exploring with partners, Universities,
friendly developers new ideas / unique capabilities to telcos, e.g. Arduino GSM Shield
for M2M over mobile networks.
•
TEF Digital is going to have to re-invent itself again as its filling with corporate
politicians. For example, the TU Go application is being forced on OpCos based on
the Jahjah platform it bought for $100M, this requires expensive integration for the
OpCos so they are pushing back.

54. Verizon Logo

55. Learning
•
•
Copy Tropo or Twilio if you want to compete in the US in communications APIs.
Don’t chase long tail developers in the back yard of Apple and Google
o
Focus on businesses that need to run on Telecom APIs, or using APIs within your
existing ecosystem (Internally and with partners)
•
Operators cannot credibly engage the long-tail, need to focus of specific
technologies or domains, e.g. in M2M with relevant M2M companies, it’s a more
a focused open innovation model.
•
OneAPI is not relevant to long-tail developers, and looks archaic compared to
modern well-written APIs.
•
Money is not in the APIs, 1c per location dip required 100 million dips a month
to make $1M and no developer will pay 1c location these days.
o
The money is in the services and solutions enabled by APIs.

56. Mapping graphic

57. Mapping Telcos across the API Implementation
Landscape
Organizational Focus of APIs
Internal APIs
Both
External APIs
Business Use of APIs
Experiment
Focused
Likely
Evolution
Path
Broad
Telecom Italia does not have everything right, for example, they lack the focus on
building API-enabled businesses, but its closer than most.

58. mapping telcos across the API implementation landscape
Organizational Focus of APIs
Internal APIs
Business Use of APIs
Experiment
Focused
Broad
Both
External APIs

59. 3. Market Analysis: Mapping vendors across the API
Informational APIs
Transactional APIs
landscape
(e.g. customer profile)
Developer
Community
API Publishers
Tropo, Twilio,
etc.
Developer
Portal
API
Management
e.g. call control
API Management (including API Security)
Intel Software (Mashery), CA (Layer 7), Apigee
API
Services
Network
Gateway
Cloud /
BOSS
Assets
IT /
Service
Assets
Network
Assets
IMS
Assets

60. 3. Market Analysis: Real World Complexity
Informational APIs
Transactional APIs
Developer
Community
Developer
Portal
Apigee, Intel (Mashery),
Layer 7 (CA), SOA Software,
3Scale, IBM, Open Source
API
Management
API
Services
Intel (Aepona),
Ericsson, Huawei,
Oracle, Open Source
Network
Gateway
Cloud /
BOSS
Assets
IT /
Service
Assets
2600Hz, Aculab,
Apidaze,
Bandwidth,
hSenid Mobile,
OnMobile,
OpenCloud,
Plivo, Restcomm,
Solaiemes,
TelAPI, Tropo,
Twilio, etc.
Network
Assets
IMS
Assets

61. Where are External Telco APIs going?
•
External Telecom API Roadmap
o
Communications: across all VAS not just calls, rather Rich Communication
Services, IP clients, messaging, number provision, WebRTC, etc.
o
M2M: If the Telco has an M2M line of business then M2M APIs are essential to
be competitive for provisioning and management of end points
o
Payments: the challenge is gaining the commitment to become a payment
service rather than simply in-app billing within app stores
•
Focus on building a businesses around the APIs rather than publish
and wishful thinking (hackathons are simply PR)
o
Sales, marketing, business development and critically support

64. Brown-Nosed
Middle Manager!

65. Market Chatter
is Monopolized

66. Mobile
Everything,
WebRTC

67. Customers
Services

68. 1-3.3%
0-2%
Threats to Revenue
5.5 to 9%
Over the Top Messaging
hits SMS growth
3 to 4%
Mobile substitution of fixed
broadband with LTE
0 to 2%
OTT substitution,
saturation, competition
-5 to -7%
Mobile and OTT
substitution
Mobile
Data
($275B)
Fixed
Data
($275B)
Mobile
Voice
($615B)
Fixed
Voice
($325B)
3-6%
Regulated
Services
($1.5T)
+
Unregulated
Services
($650B)
Total Telecoms
Services
($2.15T)
=
Sources: operator averages across developed and developing markets, supplier estimates, Alan Quayle
There’s just 2 things we need to focus on

69. Make Telecoms an Essential Spice for every Business Recipe

70. Do more VAS!

71. No. We tried a
similar service in our
market and it failed,
and we’re never ever
going to try again
What do you think of this service idea?

72. No. It will not work in
our market. Because
I’m a 50 year old guy
who understands all
my customers better
than they know
themselves.
What do you think of this service idea?

73. No. A feature of your
service overlaps with
an existing.
What do you think of this service idea?

74. No. We have a
similar service
launched, and are not
going to experiment
to make it better or
address other
customer segments.
What do you think of this service idea?

75. No. Our network can
not support such as
service, even though
such services are
going over the top
today.
What do you think of this service idea?

76. No. It looks a bit like
Joyn, we’re not sure
about it, but because
it looks a bit like
something we may do
in the future we’re not
going to do it.
What do you think of this service idea?

77. No. It must work
across all devices,
even though most
devices will never use
it.
What do you think of this service idea?

78. No. We need
additional (random)
features included
before we could
consider it.
What do you think of this service idea?

79. No. It must work on
IMS (even though it
doesn’t need to).
What do you think of this service idea?

80. No. It must work
across all our
customers from day
one, even though
most will never use it.
What do you think of this service idea?

81. No. It must conform
to our process and
design norms. But
we’re not going to tell
you what they are.
What do you think of this service idea?

82. No. It must integrate
with all our existing
platforms, even
though it can work
fine in the current
configuration.
What do you think of this service idea?

83. No. It must be
delivered through our
preferred SI or NEP,
who will copy / kill
the service
immediately.
What do you think of this service idea?

84. No. You must work
through our app store
/ portal, which we’re
in the process of
closing.
What do you think of this service idea?

85. No. We can only focus on
4 service launches per
year. We only back major
successes like Video
Telephony, Mobile TV,
Push To Talk, See What I
See…
What do you think of this service idea?

86. No. We just don’t
have the bandwidth,
to do our job.
What do you think of this service idea?

87. No. We have a
network lock-down as
we launch LTE so
cannot do anything
for the next 6-9
month.
What do you think of this service idea?

88. No. Bob has left the
business and we’re
waiting on his
replacement, who
never comes.
What do you think of this service idea?

89. No. We’re waiting on
annual budgets to be
confirmed, sometime
in the next 6-12
months.
What do you think of this service idea?

90. No. We’re reorganizing again this
year.
What do you think of this service idea?

91. No. Someone in the
organization doesn’t
like such services.
What do you think of this service idea?

92. No. That cannot be
implemented without
changing our IN /
product catalog /
CRM / billing /
network.
What do you think of this service idea?

93. No. We cannot bill /
sell services under $5
per month.
What do you think of this service idea?

94. No. We have a
backlog of 24 months
on billing updates,
even though the
service doesn’t need
to be in that pipeline.
What do you think of this service idea?

95. No. You must work
through our
innovation group who
we all hate and ignore
as they’re parasites on
our business.
What do you think of this service idea?

96. No. You must talk with
Bob who will then pass
you to Bill, who will then
pass you to Mary, who
will then pass you to
Paul, who will then pass
you back to Bob.
What do you think of this service idea?

100. Revenue
Defining what is meant by Developer
Internal Telco Developers
Partner Developers
Telecom App Developers
Mobile App Developers
Long Tail Developers
Product

101. Revenue
This Is A More Accurate Representation
Internal Telco Developers
Partner Developers
Telecom App Developers
Mobile App Developers
Long Tail Developers
Product

102. What do we mean by Telecom App Developer?
Developers that recognize
they build telecom apps
today
Hardcore
Telco Software
Infrastructure
(10ks)
IT/Web Programmers building
on FOSS, telecom app
platforms and telecom APIs
(1Ms)
‘Cut and Paste’ web developers using
web-scripting and graphical tools on
app platforms
(10Ms)
All based on IT / Web Technologies and Development Principles

103. TADS is about Building an Ecosystem
Hardcore
Telco Software
Infrastructure
(10ks)
Developers that recognize
they build telecom apps
tomorrow
IT/Web Programmers building
on FOSS, telecom app
platforms and telecom APIs
(1Ms)
‘Cut and Paste’ web developers using
web-scripting and graphical tools on
app platforms
(10Ms)
All based on IT / Web Technologies and Development Principles

104. www.tadsummit.com