Below is a summary analysis of the Open APIs 2.0 session at the May 2009 Telco 2.0 Executive Brainstorm which, for the first time gathered together leaders of the major telco API programmes - GSMA, TM Forum, MEF Smart Pipes, OMTP BONDI, Orange Partners, Alcatel-Lucent - and some of their potential users (BBC, Yahoo, Amazon etc).
The premise we explored was this:
Participants were asked: Which of the following statements best reflects your views on the API efforts of the Telco industry?
- Individual operators and cross-industry bodies are getting things about right and current API programmes will yield significant value to the Telco industry in the next 3 - 5 years.
- Individual operators and cross industry bodies have made a good start with their developer and API programmes but more needs to be done to standardise approaches and to bring commercial thinking to the fore if APIs are going to generate significant value to the Telco industry in the next 3 - 5 years.
- The current developer and API activity by individual operators and cross industry bodies are totally inadequate and are unlikely to create value in the next 3 - 5 years.
APIs are a hot topic in the industry at present and this lively session highlighted three things very clearly:
-
There is a great deal of work being done on APIs by the operator and vendor community. There is a real sense of urgency in the Industry to make a set of cross-operator/platform/bearer/device APIs available to developers quickly.
-
There is a real risk of this API activity being derailed by the emergence of numerous independent “islands” of APIs and developer programmes. It is not uncommon for operators to have 3 or more separate initiatives around “openness” - in the network, on handsets or on home fixed-broadband devices, in the billing system and so on. Various industry bodies have taken prominent roles, usually at the level of setting requirements, rather than developing detailed standards.
Thomas Howe, CEO, Jaduka: ''Standards aren't something we have to wait for! In the web sphere standards were something we did which worked so well that everyone said ‘that’s the standard’ and started using it. This is what happened with AJAX.''
- It is still extremely early days for the commercial model for APIs. This is an area that the Telco 2.0 Initiative is concentrating hard on at present. It is already becoming apparent that a one-size-fits-all solution will be difficult. In line with the previous discussion about piloting Telco 2.0 services, it is important for operators to ensure that API platforms (and the associated revenue mechanisms) can service two distinct classes of user/customer:
- Broad adoption by thousands/millions of developers via automated web interfaces (similar to signing up for Google Adwords or Amazon's cloud storage & computing services);
- Large-scale one-off projects and collaborations, which may require custom or bespoke capabilities (e.g. linked to subscriber data management systems or “semi-closed” / “private” APIs), for example with governments or major media companies.
It seems that certain sets of APIs are quite standalone and perhaps have simpler monetisation models – e.g. location lookups or well-defined authentication tasks. Others, such as granting 3rd-party access to specific “cuts” of subscriber data, may be more difficult to automate.
The fireworks between various panellists also illustrated an important point – there remains considerable tension between those advocating business models which are ‘content’-driven, involving the delivery of packaged entertainment and information to consumers and enterprise customers, versus those which are aimed at facilitating large numbers of new and (mostly) unknown developers who may use the platform to create ‘the next big thing’. Both business models have merit – while there is certainly value in using packaged approaches like “sender-pays data” for well-defined content types, there is also huge potential in becoming the platform of choice for unexpected ‘viral’ web applications that exploit unique Telco assets.
Dean Bubley, Telco 2.0: “I can't believe that people in this room are still referring to their future customers as 'OTT Players' which is as derogatory as calling Telcos 'pipe salesmen', or 'under the floor players'. Unless you show some respect to these companies, do you really think they will prefer to do business with you, rather than destroy you? '
In the short term, work needs to continue on developing the API platform, but also on evolving the attitudes and processes within the operator to support successful future business models:
-
Avoid pre-conceptions about the commercial model for APIs. In particular, revenue-shares and flatrate % commissions are extremely difficult to justify, except for the most commoditised capabilities like payment, or large-scale individually-negotiated contracts;
-
Develop thinking around the commercial model for APIs as getting this right will drive the success of existing industry-wide API initiatives – these technical programmes will fail without input from strategists and marketers on the required frameworks;
-
Most operators are undergoing major programmes of transformation – e.g. around outsourcing or IP network deployment. It is critical that these actions are constantly reviewed for fit against API-type initiatives to ensure they ease their creation, and don't create new bottlenecks or structural silos;
-
Recognise that individual propositions about openness often make sense when viewed in isolation – but need to be seen in a wider strategic context, including all interface points between the operator domain and the Internet/apps world;support a broad set of innovative applications and business models – and may well also appeal to third party developers;
-
Be aware that many developers will not want to have dozens of separate relationships with individual operators – do not force them to duplicate effort. Instead, work with industry-wide groups to address their core needs;
-
Develop a checklist of open API “hygiene factors” that are critical for developers, such as easy app testing mechanisms, transparency in application approval/signing, clear API pricing and so forth;
-
Consider “eating your own dogfood” and use elements of third-party web services and APIs as part of your own offering, at least in the early stages. In particular, this could reduce time-to-market and enhance flexibility.
Event Participants: can access the full presentation transcripts, delegate feedback, and long-term recommendations for action at the event download page (NB. the URL has been emailed to you directly as part of your package).
Executive Briefing Service Members: can do so in a special Executive Briefing here. Non-Members: see here to subscribe.
