The Business of Telecom APIs – Capturing Future Revenue Growth                                              By Geoff Holli...
Why Do We Need API’s now? – To Address Markets beyond traditional direct communicationsThe telecom industry has been expos...
Figure 2 – Courtesy of Alan QuayleThis approach is identical to the new generation of internet players and service provide...
important to understand the difference between them.Access Dependent API’s can expose network value but only to customers ...
The application (or service) is the result of the developer that then is placed into operation and generates API trafficth...
Appendix A – Fictitious Case Study of Enabling Phedex Shipping ServiceThis fictitious engagement by operator AB&B shall be...
The Solution Design and in Operation Cross Carrier FlowAs stated the solution has to secure realtime quality communication...
Appendix B - The Generic Life Time Journey of a Developer in OperationA developer is looking for capabilities or a develop...
•    Analytics support of usage to enable better application roadmap planning, targeting of new users and in-         serv...
Depending on API type, local caching of result may be possible. Results should be cached where possible andcaching should ...
Figure 4 - Indicative One Transaction OpportunityThe transaction is created and for simplicity let us say the value placed...
3    •    Southbound delivering API URL and responseThe operator chooses to take part in an inter-operable transaction. By...
Upcoming SlideShare
Loading in …5

The business of telecom ap is capturing future revenue growth


Published on

The telecommunications sector is the next industry to receive massive levels of innovation, disruption and none traditional growth. Be prepared!

Just as in the recording, film and newspaper industries before it, the telecommunication industry is being disrupted by the massive innovation and change in business model the Internet provides. Business and technical reengineering of how telecom creates and captures value above basic IP connectivity is required. Those that can respond to and anticipate the market requirements from the developer and application community shall be best positioned to win. Delivery shall require the market requirements be delivered via simple to use interoperable (where necessary) Application Programming Interfaces (APIs). Those that can deliver these APIs with best end user performance and network performance shall win.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The business of telecom ap is capturing future revenue growth

  1. 1. The Business of Telecom APIs – Capturing Future Revenue Growth By Geoff HollingworthHypothesis – The telecommunications sector is the next industry toreceive massive levels of innovation, disruption and none traditional The telecommunication sector is the nextgrowth. Be prepared! industry to receive massive levels ofJust as in the recording, film and newspaper industries before it, the innovation, disruption and none traditionaltelecommunication industry is being disrupted by the massive innovation growth. Be prepared!and change in business model the Internet provides. Business andtechnical reengineering of how telecom creates and captures value abovebasic IP connectivity is required. Those that can respond to and anticipate the market requirements from thedeveloper and application community shall be best positioned to win. Delivery shall require the market requirementsbe delivered via simple to use interoperable (where necessary) Application Programming Interfaces (APIs). Thosethat can deliver these APIs with best end user performance and network performance shall win.IntroductionTelecom operators have provided communication services to consumers and enterprises for the last 130 years. Thishas lead to the creation of a global 2.4 trillion dollar telecommunication industry. Growth has largely been driventhrough an industry-closed eco-system delivering limited device choice, service choice and experience choice. In thelate 1990’s the Internet and associated software approach started to create alternative experiences. In 2007 applestarted to bring this experience to the telecom eco-system with the launch of the iPhone. The rest is history. Therehas been more innovation and experience creation in “telecom” in the last 5 years than in the previous 30. It is justnot being lead by the traditional telecom industry players – either vendors or carriers. This is seriously challengingthe long-term growth potential of the telecom industry. Alternative service providers implementing new platforms andnew services/experiences are capturing the new revenues. This scenario is well described in the concept of “PeakTelephony” by Martin Geddes [ref].However the long-term outlook is anything but grim. As stated by JulianGenachowski at CTIA Wireless 2011 - “By 2015, the “apps economy,” is projected ”By 2015 the apps economyto generate $38 billion in sales” [ref]. The combination of mobility, broadband and is projected to generatecloud is driving lower price points and a transformation in society and business $38 billion in sales”where anything benefiting from a connection will have one. This changes theaddressable market for telecom operators from one constrained by connectingpeople (in developed countries an already saturated market) to one constrained by connecting everything foranything. This new market is exponentially bigger than the people market by a factor of 10, the same way connectingpeople (5 billion) was exponentially bigger than connecting locations (fixed telephony – 1 billion). At the same timespeed of adoption is accelerating. It took 100 years to connect 1 billion locations, approximately 30 years to connect5 billion people and it is predicted it will take 10 years to connect 50 billion devices.A new operational and business model is required however, to address these opportunities and enable the traditionaltelecom players (both carriers and vendors) to take part in the revenue growth that is being created above thenetworks. The opportunity is to take part above the connectivity layer, to take part in new business value creationand capture. 1|Page
  2. 2. Why Do We Need API’s now? – To Address Markets beyond traditional direct communicationsThe telecom industry has been exposing API’s for ten years or more and it has largely been irrelevant. What issuddenly more important now? We must look to the Internet software model to understand both the change inbusiness models and required change in operations to deliver on the opportunity. But first let us understand ourtraditional business, its strengths and inherent weaknesses going forward.The traditional target market for telecom has been high margin services voice andmessaging (up to 70% gross profit margin). These have primarily been delivered A global inter-operability modelthrough a closed eco-system of network providers and device manufacturers. exists with aligned globalThese services have been delivered as a direct sales model, both to consumers or 1enterprises . A global inter-operability model exists with aligned global settlement settlement process. This way ofprocess, which has enabled the largest inter-operable machine to exist in the world. working is an industry asset thatThis way of working is an industry asset that needs leveraging in the new economy.Each operator competes according to independent business plans but any success needs leveraging in the newhas secured the growth of the overall industry through inter-operator settlements. economyThe traditional model only addresses the communication market however, whichrepresents less than 10% of the total addressable needs market (see Figure 1). As we view the future, theopportunity for the next generation of network services is to address all othermarkets and adjacent industries, with communication services and also other We call these new servicesnetwork beneficial services. We call these new services “Network As a PlatformServices”. They target the new addressable markets, which are diverse from a “Network as a Platform Services”.business value, business model, and business process point of view. Devices and They target the new addressableclient needs are disparate even within the same industries. For example there is nosuch thing as a healthcare industry. Each healthcare organization, hospital, markets beyond directinsurance provider etc works according to their own operating procedures and their communication spendown perceived competitive advantage. The current opportunity and what willmotivate spend of the trillion dollars the enterprise market currently has in the bank is to help them create newcompetitive advantages. For example electronic healthcare records simply replace documents and files. But theadvantages of electronic healthcare records are much more than storage, retrieval, cost and speed. As a resultmultiple healthcare professionals can treatthe same patient at the same time, frommany locations, which optimizes cost, careand well-being of the patient that could notbe imagined before. AT&T is pioneering thisspace [ref].Scaling the embedding of relevant networkservices and values within these eco-systems can only be achieved by exposingthe network value in easy to use APIexposure. These API’s can then be usedboth internally and if wanted externally.The most successful API driven companiesare those that use the same API’s internally(just a superset of what is made public) asnoted by this insight into Amazon, quotefrom Jeff Bezos, 2002 around using API’s.“Anyone who doesn’t do this will be fired. Thank you; have a nice day!” [ref]Note the delta between which API’s are Figure 1- Courtesy of Vision Mobileavailable internally and which API’s areexposed externally defines the core business of the operator and thus is strategically highly important to understandin advance and to expose accordingly.1 Note for later reference in this paper. The real growth in these services happened after the services became inter-operable, thus releasing the network effect across the market and industry. 2|Page
  3. 3. Figure 2 – Courtesy of Alan QuayleThis approach is identical to the new generation of internet players and service providers, such as Netflix etc (seefigure 2). Scale and affordable reach of their core business into a disparate consumption landscape is driven by APIexposure and management. The telecom industry should embrace the leading companies and practices from thisspace.Key Telecom API ConceptsIt is important to recognize telecomhas been using the concept of APIs Service Exposureever since communications moved to Key Principles – From Old to newdigital. The traditional architecturethat for example created SMS, has Closed Traditional Bus iness Architecturebeen closed from an API, client point C lose d Pla tform Clos ed API Inte r-opof view and has followed telecom SMS Client N etwor k Ne twork sstandards. However it is API driven,just not “open web” API driven and Open Business Architecture 1 - Access Dependantthere are fundamental business “Open” Plat for m Public API R e-use s ame N etwor koperations that were created to Inte rne t Clie nt a ppr oa chsupport the closed eco-system, whichcan be replicated in the open eco- Open Business Architecture 2 – Access Inter-operablesystem. These are global inter- “Open” Plat for m Inte rne t Clie nt Public API N etwor k Inte r-op Ne twork soperability and associated globalsettlement. Open Business Architecture 3 - Access Independent or “Telco-OTT” “Open” Plat for m Public API A cce ss AgnosticIn the new service exposure world to Inte rne t Clie nt Se rvice Exposureaddress the new markets there are N etwor k IP Ne twork sthree complementary types of API. It is 3|Page
  4. 4. important to understand the difference between them.Access Dependent API’s can expose network value but only to customers of the access network. This is the leastinteresting scenario and shall not be the main focus of this whitepaper (it is assumed an operation that can manageinteroperable and independent APIs can also support access dependant APIs as a sub-set of capability).Addressable market is limited to an individual operator reach and any addressable enterprise, wholesale partnerspans more than one operator’s population. This type of exposure can enable differentiated finished services to theexisting operator’s consumer market to create value add services for direct revenue (history of failing) or morecommonly value add services to increase customer retention, stickiness, brand value. At the end of the dayconsumers are looking to spend less for more experience and the OTT players with different business models aredelivering to this need. As for enterprise and wholesale partner markets, these normally span more than oneoperator’s population. Interestingly currently most M2M management solutions and associated enablers fall into thiscategory of capability exposure (for example Jasper Wireless, nPhase, Ericsson Connected Device Platform). This isnot by desire of the enterprise network, which would prefer an access inter-operable approach. Also the majority ofconnected devices projected will not be wide area connected and thus their management will also not be facilitatedby these services. For any global company it is very difficult to deploy one M2M solution that will meet the needs oftheir total addressable market with this approach.Access Inter-operable API’s can expose network value to any customerirrespective of access network. This is enabled using similar network operations as Access inter-operable API’s are thecan be found in the traditional telecom services domain of SMS and voice, usinginter-operability agreements and associated settlement. This model enables most complicated but alsounique network value to be exposed to the total market. In the past we have seen potentially the most lucrative andthis to be the stimulus for exponential revenue growth that only the networkoperators can provide. By copying existing operational models it also allows for differentiated type of API and thusopen competition in the marketplace (e.g. avoiding any regulatory concerns) while is the main focus of this paper.driving overall wealth generation into the total telecom eco-system. Challenges inthis model to date have been time to market and cross operator businessagreements in the “none-standardized” web API world. The opportunity is to resolve these challenges and build afast time to market operating model that embraces the new paradigm (see later). This is the most complicated butalso potentially the most lucrative and differentiated type of API and thus is the main focus of this paper.Access Independent API’s expose capability to the total market where the capability has no connection to accessnetwork capability. For example AT&T offers an API for sharing HIPPA compliant health care records. Clearly thishas nothing to do with their traditional network business. However it leverages its other innate strengths such assecurity and trust (and deep pockets in case of litigation). The operator takes the same role as an OTT player andthe term “Telco-OTT” has been coined by Dean Bubbly and his paper “Telco OTT Strategies and Case Studies” ishighly recommended for a more detailed understanding [2].A combination of different API types will deliver the maximum value creation and value capture for any operator. Torealize the opportunity, one architecture and operation should be designed to allow maximum potential for inter-operability combined with maximum business independence to compete in the open market.Building a Successful Operation to Deliver Future API Success and Revenue GenerationIn the appendix this paper shall use a fictitious case study and propose a blueprintof ideal operational approach and technical architecture for operator plus industry The winning landscape shall becollaboration to deliver on the next generation of revenue growth. The blueprintshall revolve around 3 key actors and their lifetime journey through the telecom defined by those who can deliveroperator API eco-system. APIs, which respond to andThese are anticipate the market requirements from the developer and • The developer (or developing company) applications community, • The Application (or service) • The Inter-operability and Settlement entity independently of access networkThe developer (or developing company) is the entity that will create the new finished application or service, using thepublished APIs. 4|Page
  5. 5. The application (or service) is the result of the developer that then is placed into operation and generates API trafficthat must be managed appropriatelyThe settlement operating entity handles any required inter-operability routing and any associated financial settlementaccording to inter-operator agreements.Understanding the Business ModelIn this section we shall repeatedly talk about accelerating time to “money” for both the developer and the APIpublisher. It is important to understand that payback on API can come in many forms, depending on the API beingexposed. Amongst the alternatives are • Increased reach (measured in traffic) to increase distribution of content, data and/or brand value • Lowered cost and time to market for new services on new platforms • Release of 3pp innovation to embed/differentiate core offering in experiences beyond the reach of the core business • Deep integration into enterprise VARs/ISVs for stickiness • Direct revenues for additional services or indirect revenues for market differentiation (bundled in existing offering)[ref]This paper suggests the opportunity for the telecom operator is to • Cost-effectively create new experiences for the consumer channel that lowers churn, increases opportunity for cross sell and differentiates the operator in the saturated market from a brand value perspective. Probably finished services are required with trusted partners using any exposed API’s • Own the enterprise from an end to end networking needs perspective, from outsourcing existing operations to the cloud and also embedding the network capabilities into the enterprise business model to create new market capabilities and differentiation for the enterprise. Inter-operable, Independent APIs are a pre- requisite. • Wholesale partners embedding network capability into their platform offerings for further consumption by their application developer community. Inter-operable, Independent APIs are a pre-requisite.ConclusionThe next generation of value creation and value capture in the network businessshall follow very different business models that are more in line with best practice Understanding the API-leadsoftware transaction models used by the leading internet software companies oftoday. The future market opportunity is far from grim” [ref]. To date the telecom economy and how to place APIindustry has only addressed 10% of possible spend. The future market driven business practice intoopportunity allows network services to address the other 90% as well. We call operation is key to enablingthese new services “Network as a Platform” services. The required operationalmodel and approach needs to be very different from today and needs to be any organization to be able toprepared to scale to the same levels as the Internet leaders already see. The deliver on the future growthoperational delivery model is based around performance managed API’s in thescale of billions of calls. Telecom has spoken to APIs for the last 10 years. potential beyond directHowever to address the new growth opportunities with disparate client and value communication.creation, API’s become the key delivery mechanism that scales with cost. Thereis a market demand for interoperability of these services across individualoperator networks. Re-using existing operational models can achieve this but there is a need to re-position them withfaster time to market best practice and open API collaboration. Orchestration of the industry using new interworkingapproaches will drive time to money both for driving participants as well as following participants. Understanding theAPI-lead economy and how to place API driven business practice into operation is key in enabling any organization tobe able to deliver on the future growth potential beyond direct communication. 5|Page
  6. 6. Appendix A – Fictitious Case Study of Enabling Phedex Shipping ServiceThis fictitious engagement by operator AB&B shall be used to highlight a likely future API engagement scenario.The Opportunity StatementPhedex Shipping is in the business of logistics planning and management for its customers. It ensures packages aredelivered as specified and can be traced through the whole operations flow.It currently has a customer service satisfaction problem. It has very complicated package tracking capabilities thatcan locate any package in real time but it has no capabilities to initiate communication directly with the closestemployee to the package at any time. They wish to offer a new premium service to its most valuable customers –“Change on Demand”. Irrespective of where any package is at any time a customer can call and Phedex can locatethe package, speak to the Phedex person closest to the package, initiate real time checking, changing, dialogue. Thepackage can be shown to the customer live if wanted. Customers will pay a premium fee for this new level of flexibleservice that will change expectations in the industry on what is possible or not.Of course the communication needs to be secure and needs to work with quality and reliability – Phedex’s corebusiness will be dependant on the service working. They wish to implement this capability, initially for internal use butpotentially to expose the capability in the future for direct customer use.Phedex uses two service providers for its communication services and access – AB&B and Horizon.AB&B has pro-actively approached Phedex to see if they can assist in improving Phedex’s business in any way,unaware of Phedex’s current situation and wanted solution.The SolutionPhedex explains it needs to AB&B. AB&B has recently joined the API inter-operability forum where it has secured itsability to deliver quality voice, cross carrier for a termination fee to be paid to the other access operator. Horizon isalso a member of the inter-operability forum.AB&B presents its capabilities to Phedex. It explains “Network as a Platform” services, its corresponding APIcapability set and its ability to integrate real time quality communications into Phedex’s business processes andoperations.AB&B presents its secure identity service. For such a service as this to work devices, people and processes have toreach end points independently of the access network or solution provider they reside upon. The provider of such anidentity service has to be completely trustworthy, secure and committed to not sharing any information involved in theprocess. All participants, independently of access, device type, address, register with the secure identity service,announcing their availability and where/how they can be reached.Two potential solutions existAB&B offers to support Phedex’s IT/VAR organization with the integration of AB&B’ssecure identity service andquality call API set. The end solution can either be integrated into an existing application that Phedex alreadyoperates or if no such client exists, AB&B can help Phedex secure the right partner to deliver such a communicationapplication.AB&B offers to provide an end to end fully hosted client application solution. AB&B just needs to provide who needsto communicate with who and the solution can be simply embedded in any website or on any common smart phoneor tablet device.Phedex and AB&B realize through these discussions this is only one of many potential collaborations the twoorganizations could work on together, that could completely change the way the company works in real time, bothinside the company employee to employee and also outside the company – customer to company and company tocustomer. Phedex enter strategic relationships with AB&B to explore outsourcing of all real time communicationneeds and also re-engineering of real time business processes. This re-structures the relationship and discussionacross all IT, wireless and communications needs. 6|Page
  7. 7. The Solution Design and in Operation Cross Carrier FlowAs stated the solution has to secure realtime quality communication across bothAB&B and Horizon devices.Phedex IT organization (or AB&Bsolutions people themselves) use thefollowing AB&B API in their solution:<the_secure _identity_of_B>The device making the API call can be adesktop, laptop, tablet or smart phone.Since Phedex uses either AB&B orHorizon for connectivity, the traffic shallcome from one of those networks. Theperson/device we are connecting tosimilarly shall be connected via one ofthose networks.All API traffic is routed back to AB&B’sService Exposure traffic node,irrespective of access network used toconnect the originating device. If boththe requesting device and terminatingdevice are AB&B access customers then AB&B establishes the quality connect internally. If either or both of thedevices are not AB&B access customers then each request is passed onto the brokering/routing/settlement processto establish the quality connect over the other operators access network. AB&B will settle all inter-operability chargesrelated to Phedex since AB&B are the sole billers and hold the total business relationship with Phedex. Therefore atthe end of the agreed billing cycle between Phedex and AB&B, Phedex pays AB&B. At the end of the settlementbilling cycle, AB&B settles with both its P2P partners directly (if any exist) and any hub connectivity partners (if anyexist).The service is delivered. The billing cycles are completely independent as are the chosen business models. Horizoncould choose to purely be an inter-operable operator and receive revenue just from P2P and/or hub relationships (asshown here). Or it too could choose to have a network exposure business and also have directB2B/wholesale/developer clients, if it is willing to make the investment. 7|Page
  8. 8. Appendix B - The Generic Life Time Journey of a Developer in OperationA developer is looking for capabilities or a developer has been targeted with a capability that may be useful to them.They go to the developer portal supporting the API. This portal could be run by • a telecom operator directly, • an operating entity working on behalf of many operators (aggregator), • a specific development environment (platform independent [cdp] and/or platform specific [ios, android]) • a wholesale partner of either an operator or aggregatorIt is important to understand an API is exactly the same as a product and from a business point of view there will becontracts between any operator and any channel partner the operator chooses to utilize to increase their reach. Anyreseller shall be on-boarded to the host operator re-using the existing business management processes as for adirect consumer. This optimizes the re-use of tools and operational processes and analytics reporting, consumptionmanagement.The developer registers with the developer site. The developerenters their business identity information (business name, taxidentity, company information, developer information). The accountis then validated for being able to receive any settlement from theAPI usage or payment for the API usage (if the API is not zerorated). The legal relationship is always between the developer andthe operating entity that runs the developer portal. To comply withdifferent country’s privacy laws, the personal developer data mustbe stored in compliance to that person’s country of residenceprivacy laws. For example a German citizen cannot have their datastored in the USA.Once a developer is registered and financially validated they canstart developing towards the published API’s. To accelerate time to“money”, both for developers and API publishers, any API shouldbe best of class at • Simple value it exposes • Ease of use 2 • Business Model for usage Figure 3 - BlueVia Required Tax InformationAll three aspects should be as simple as possible. Developerloyalty is tremendously shallow and massive choice combined witheasy discovery (internet search) leads to the need to be the best inclass. Telecom should embrace and partner with the existing bestin class internet API companies in operation that already haveyears of collective experience. A more detailed analysis of suchcompanies and the capabilities they offer is beyond the scope ofthis paper but can be made available on request.Assuming the developer completes the application/service withAPI’s embedded, the developer must distribute their application.Depending on the target audience desired distribution, discoverytechniques and management channels will vary. All however willshare the same fundamental needs • Reduction of distance between application publishing and user discovery • Access/usage management of downloaded/accessed applications2 Note the most optimal answer for all 3 is very dependent on the capability being exposed 8|Page
  9. 9. • Analytics support of usage to enable better application roadmap planning, targeting of new users and in- service performance/quality of service.The more a developer offering can assist with the above, the more the developer will use the services and the fasterthe time to “money” for both the developer and the API publisher.At billing period end the developer must either receive a bill for payment or a money settlement for deposit. Theoperator should re-use their existing business process mechanisms for third party content settlement if they havethem.Appendix C - The Generic Life Time Journey of an Application in OperationThis section covers the life of the application once it has been discovered, installed and placed into operation. Allapplication’s end performance depend on the combined performance of the underlying API’s performances it calls.Good application design should use parallel asynchronous coding methods as much as possible then the overallapplication performance has closer relation to the worst performing API. Obviously any API publisher does not wantto be the worst performing API.Let us re-visit the three different API types and analyze each in turn. • An access dependant API is limited by the geographic footprint the access network covers • An access inter-operable API can be called from anywhere but the response may involve interworking with other network’s capabilities and associated settlement • An access independent API can be called from anywhere and the response may be able to be delivered from anywhereA correctly architectured API delivery network shall maximize performance in all three scenarios. Maximalperformance should be measured in terms of • Quality of experience (lowest possible latency, maximal quality of payload) • Network Yield (minimal usage of network resources to deliver required result) • Monetization of traffic (maximal transactional settlement opportunity for traffic and maximal post traffic analytics)Telecom operators are uniquely positioned to deliver these results. An API delivery network consists of API incomingtraffic management and API result orchestration and delivery. API incoming traffic should be served from a servingnode geographically as close as possible to the requesting client. Each operator should have their own serving nodeto maximize their opportunity for yield management in their own access network and to allow independent operationinside their private footprint, aligned with their own unique operations and business roadmaps. The architectureallows for managed serving nodes however, to accelerate short term time to market if necessary or desired. In asimilar way to CDN networks this architecture potentially lowers latency and increases probability of a locally cachedresponse being available, thus effectively increasing quality of experience and effective network yield. Service nodescould be leased inter-operator as part of the settlement process, to increase global performance, lower operatingcosts, equitable compensation for investment.If a locally cached result is possible then the result is should be delivered directly from the serving node. If no cachedresponse is found then the serving node must identify whether the requesting subscriber is a subscriber of thisnetwork. If yes then the request is channeled to the home network and the result is delivered back. If no then therequest is forwarded to the interoperability node. If the owning network is not integrated then the interoperability nodereturns an error message otherwise it returns the result that can be delivered in responseNote each operator can choose different interoperability nodes per API if desired or implement their owninteroperability node to achieve control of full market coverage and time to market. This might be a viable strategy forwell known API sets such as location and messaging. A centralized interoperability node could also use existingaggregators and may be able to leverage larger buying power as a representative of the collective operatorcommunity. For new API sets (such as network performance) a time to market advantage may exist if there is onecentral operating entity orchestrating inter-operability, settlement agreements and software integration. The centraloperating entity would be driven to best practice on boarding and operation in the space of inter-operable APIs (seenext section). 9|Page
  10. 10. Depending on API type, local caching of result may be possible. Results should be cached where possible andcaching should follow existing best practice ETag caching rules as implemented in browser/CDN/client architectures.On completion of any API request the serving node shall log the result information for analytics and also send anysettlement information necessary to the settlement entity (see next section).Appendix D - The Generic Life Time Journey of Interoperability and SettlementInteroperability and associated settlement has always driven revenue growth in the telecommunications industry.The second largest revenue source for any operator is other operators. The model allows open competition in themarket place for enterprises and consumers alongside fair payment for others resources used in delivering the endsolutions. The interoperable API market offers similar (and exponentially larger) opportunities for all participantschoosing to take part. The more aggressive members of the industry will directly capture new revenues from otherindustries. One side effect of this will be the influx of new revenue across the total telecom eco-system and allowothers to integrate into the eco-system and also gain benefit from the increased money flow and wealth. This in turnwill increase the total market interoperability helping the total industry proposition more and thus driving greatermarket opportunity (say from national to regional to global coverage). The value of interoperability should not beunderestimated. Prior to SMS interoperability in 2001 general discourse explained the lack of use in the USA being acultural difference/issue. There are now over seven billion SMS messages sent every month in the USA [ref].The challenges and thus barriers for creating an interoperable API eco-system that replicates the previous industrysuccess are an operational model that allows fast collaboration and time to market without formal standards orbodies. Proposed key success factors are – • Fast agreement on interoperable transactions, independent of market offering • A distributed integration model that allows existing business practices to be re-used in the delivery and settlement process • Online self service management following internet model best practiceWe recommend the creation of a centralized operating entity that manages the above to accelerate and secure themarket opportunity. For the purposes of this paper let us use the example of quality voice exposure and study the lifetime journey from this perspective.The consortium agrees to create the “quality of voice” transaction. The quality of voice transaction enables an in-application call to be established across the interoperability community. See below figure for indicative simplemodeling of market size in North America alone. 10 | P a g e
  11. 11. Figure 4 - Indicative One Transaction OpportunityThe transaction is created and for simplicity let us say the value placed on such a transaction is 10 cents. E.g.operator A enables an enterprise that has both operator “A” subscribers and operator “B” subscribers. When the“create quality call” API is called to an operator “B” subscriber, the API orchestration enables an end to end qualitycall and operator “B” receives 10 cents for terminating such a call from operator “A”. Operator A can choose tocharge the enterprise according to whatever business model they choose. For example they could charge 20 centsper call and make on average 100% margin (depending on mix of operator “A” subscribers versus operator “B”subscribers). Or they could hide the cost in the total enterprise enablement package they provide, the value of theenterprise account being larger than the direct revenue from any API call. Operator “B” could use the same quality ofvoice transaction but bundle with an advertising pre-roll capability that would allow them to take the same capability,charge nothing, but enforce a 30 second pre-roll to generate revenue. The key points are – • Participating operators can continue to compete with complete freedom of business model to target customer. • Differentiation and upside revenue exists from participation even if no direct business channel is created (“all boats rise” as more money enters the eco-system. In the above scenario operator “B” is a differentiated provider simply by supporting the quality of voice transaction and it receives 10 cents per indirect activation). • Existing business processes and operations can be followedOn boardingThe operator wishing to participate in the interoperability ecosystem registers and is business validated with thecentralized operating entity, in a similar manner to the on boarding process of a developer/company.Once successfully validated, the operator can view the interoperable transactions currently available. The operatorcan propose new transactions they would like to have as interoperable.Each transaction in the system has the following attributes – • Description • Transaction price point • Northbound requesting API URL and response 11 | P a g e
  12. 12. 3 • Southbound delivering API URL and responseThe operator chooses to take part in an inter-operable transaction. By selecting the transaction they commit to 4having implemented the south bound API and associated response . The centralized operating entity tests theexposed interfaces and when validated, adds the routing to the ongoing traffic operation. To accelerate time tomarket the centralized operating entity can provide translation services in case the operator exposes the capabilitybut not according to the interoperable specification. There would then exist a simple translation proxy. It may also bethe case that the required capability has not been engineered to be exposed in the network. The operating entityagain could assist any operator in realizing the exposure the most effective and efficient way.Once the implementation had been validated it would be placed “live” in operation. As explained in the previoussection traffic would then begin to be routed to the participating operator. Settlement and analytics information wouldbe sent to the central operating system to enable end of cycle payment and performance feedback. All informationwould be available to the participating operator through the same self service interface.And to repeat, for existing capability exposure existing aggregators may be leveraged to accelerate initial time tomarket. However this does not focus on the real new opportunity of finding new transactions that are valuable toexpose.3 Goal should be that the Northbound API is identical to the Southbound API and the interoperability node istransparent in the execution4 It is recommended the operator tries to re-use existing local exposure business processes and engines to aligntotal operation irrespective of interoperability or not 12 | P a g e