• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Independent review of telecom ap is pre conference workshop
 

Independent review of telecom ap is pre conference workshop

on

  • 1,818 views

Independent Review of Telecom APIs presented at the pre-conference workshop at the Telecom API event

Independent Review of Telecom APIs presented at the pre-conference workshop at the Telecom API event

Statistics

Views

Total Views
1,818
Views on SlideShare
1,226
Embed Views
592

Actions

Likes
4
Downloads
72
Comments
1

8 Embeds 592

http://alanquayle.com 544
http://feedly.com 17
http://reader.aol.com 11
http://www.newsblur.com 9
http://newsblur.com 8
http://www.linkedin.com 1
https://twitter.com 1
http://cloud.feedly.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Independent review of telecom ap is pre conference workshop Independent review of telecom ap is pre conference workshop Presentation Transcript

    • Independent Review of Telecom APIs Nov 11th 2013
    • 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
    • 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
    • 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
    • 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
    • No developed market telco has successfully engaged mobile application developers with Telecom APIs
    • BUT Telecom API successes have come from using APIs internally
    • AND Telecom API successes have come from using APIs with existing partners
    • APIs reduce business friction. This means the value is not ‘in the API’ it’s in the service or data delivered through the API.
    • 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
    • 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.
    • 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.
    • 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
    • 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.
    • Revenue Defining what is meant by Telecom App Developer Internal Telco Developers Partner Developers Telecom App Developers Mobile App Developers Long Tail Developers Product
    • Revenue This Is A More Accurate Representation Internal Telco Developers Partner Developers Telecom App Developers Mobile App Developers Long Tail Developers Product
    • 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
    • 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
    • www.tadsummit.com
    • No Gatekeeper Focus Motivation
    • Why? graphic
    • 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
    • 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
    • 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
    • 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
    • Show me the money? graphic
    • 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)
    • Mobile Payments Prediction from BI Intelligence Receipts Revenues
    • 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
    • MBA BS!
    • 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
    • Bait and Switch graphic
    • 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.
    • Reality graphic
    • 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
    • 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
    • AT&T Graphic
    • 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.
    • 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
    • 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.
    • 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
    • Developer Portal
    • 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.
    • Telecom Italia Graphic
    • 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).
    • 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.
    • Telefonica Logo
    • 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.
    • 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.
    • Verizon Logo
    • 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.
    • Mapping graphic
    • 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.
    • mapping telcos across the API implementation landscape Organizational Focus of APIs Internal APIs Business Use of APIs Experiment Focused Broad Both External APIs
    • 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
    • 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
    • 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
    • Brown-Nosed Middle Manager!
    • Market Chatter is Monopolized
    • Mobile Everything, WebRTC
    • Customers Services
    • 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
    • Make Telecoms an Essential Spice for every Business Recipe
    • Do more VAS!
    • 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?
    • 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?
    • No. A feature of your service overlaps with an existing. What do you think of this service idea?
    • 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?
    • 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?
    • 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?
    • No. It must work across all devices, even though most devices will never use it. What do you think of this service idea?
    • No. We need additional (random) features included before we could consider it. What do you think of this service idea?
    • No. It must work on IMS (even though it doesn’t need to). What do you think of this service idea?
    • 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?
    • 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?
    • 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?
    • 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?
    • 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?
    • 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?
    • No. We just don’t have the bandwidth, to do our job. What do you think of this service idea?
    • 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?
    • No. Bob has left the business and we’re waiting on his replacement, who never comes. What do you think of this service idea?
    • 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?
    • No. We’re reorganizing again this year. What do you think of this service idea?
    • No. Someone in the organization doesn’t like such services. What do you think of this service idea?
    • No. That cannot be implemented without changing our IN / product catalog / CRM / billing / network. What do you think of this service idea?
    • No. We cannot bill / sell services under $5 per month. What do you think of this service idea?
    • 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?
    • 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?
    • 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?
    • Revenue Defining what is meant by Developer Internal Telco Developers Partner Developers Telecom App Developers Mobile App Developers Long Tail Developers Product
    • Revenue This Is A More Accurate Representation Internal Telco Developers Partner Developers Telecom App Developers Mobile App Developers Long Tail Developers Product
    • 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
    • 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
    • www.tadsummit.com