"If you are the person in your company trying to define the business case for an API to the executive team, there is a big hurdle to overcome, because business executives tend to see an API as a cost center and want to know how to measure the pay-off."
Laura Merling, VP Developer Platform & Programs at Alcatel-Lucent
Over the past decade there have been numerous attempts at opening telecom infrastructures to developers. As each attempt evolves to the next, there is an equal desire to monetise the exposure of telecom capabilities using traditional and well understood mechanisms: charge for necessary equipment upgrades and license the application programming interfaces (APIs) on a per-invocation or "block of simultaneous invocations" basis. However, the various vendors and development companies involved in creating applications with embedded communications capabilities have had to re-examine their business and technology models in an increasingly competitive applications market where the rate of applications failing to gain market traction far outweighs the rate of success.
This article looks at the history of telecommunications APIs and the predominant business models that have accompanied those interfaces. By analysing the history of telecom APIs and recognising the gradual shift from a strongly vendor controlled environment to a highly accessible component of information technology (IT) networks, we can recognise the shift in revenue generation from a typical monetisation model to a value based model. Additionally, we can examine how incumbents and new entrants are dealing with the more unpredictable business models and emerging methods for de-risking value based revenue opportunities.
APIs as a Monetisation Mechanism
Early programmatic interfaces such as computer-telephony interfaces (CTIs) permitted service providers and network equipment providers to develop and augment communications centric applications without waiting for the next revision of the communications system software. CTIs tended to be proprietary to the network equipment provider, creating difficulties for application and service providers to build capabilities that reached across the network equipment provider's infrastructures. Moreover, building developer skill-sets in cross-vendor APIs was challenging, leading to dependence on the equipment vendor's development services.
As a result, later efforts such as intelligent networking protocols were targeted at alleviating this dependance by focusing on heavily standardised APIs. These service provider targeted APIs tended to be targeted at telecommunications centric developers with in-depth knowledge of how communications systems function. However, the rigid standardisation of the APIs permitted building cross-vendor skills in organisations that were not controlled by the network equipment vendors. Similarly, enterprise communications equipment vendors adopted standardised interfaces such as computer-supported telecommunications applications at the behest of their customers.
The primary effects of this progressive opening of the communications system was two-fold:
equipment vendors developed an additional revenue stream by charging for access to the APIs on their communications equipment
companies specialising in application nodes were able to develop capabilities attractive to service providers and applicable across the multi-equipment vendor network
In many ways, the two outcomes of opening the communications networks became intertwined. Many network equipment providers such as Ericsson, Lucent, and Alcatel operated successful solution lines offering both service nodes and communications network interfaces. Such companies offered services and a coupled service creation environment on their service nodes, thereby controlling the use of the communications APIs to a known set of use cases. The enterprise communications environment similarly unfolded with Lucent, Cisco and Nortel offering APIs to their communications infrastructure and selling application and application creation environments leveraging the interfaces of their equipment.
For network equipment providers, the APIs became a monetisation mechanism. They either designed the applications or dealt with application developers that were direct customers. The business of enabling communications APIs became centred around how to generate the maximum revenue from the one-time sale of an application and the recurrent use of APIs by many applications.
Vendors who specialised in application nodes, such as Telcordia and Genesys, were at the mercy of the network communications provider both from the API implementation (whether the vendor elected to implement all of the standard or a subset) and from the API prices (a factor of both right-to-use licensing costs and hardware investment). They were forced to differentiate their applications from the network equipment provider's application while using the APIs implemented by those same providers. Network equipment providers did not take objection to the application vendors, given that they generated far more revenue from API licenses than from application sales. Thus, even when not selling the application directly, the network equipment providers were capturing the largest share of revenue for each voice application deployed against their network equipment.
The Emergence of Unified Communications
This business model for voice services and voice related applications persisted throughout much of the digital switching and digital PBX era. Communication networks continued to evolve, giving rise to Voice over Packet technologies. These technologies caused users, providers and administrators to think about communications differently; no longer was the communications device a digital terminal attached to a closed copper loop. Instead, communications devices were becoming another computer accessible over the same network as other modes of communication and collaboration. As the voice communications device became simply another extension of the computer network, a new class of applications began to arise.
Voice over Packet gave rise to the class of integrated desktop applications now typically referred to as Unified Communications. While Unified Communications leverages Voice over Packet as an integrated component of the unified experience, many companies developed solutions to integrate legacy voice communications solutions. Key to integration was leveraging the APIs that had evolved as part of the digital equipment revolution, as well as leveraging Session Initiation Protocol (SIP) interfaces which had been added to the legacy equipment.
Given that the central focus of Unified Communications was to unite the variety of devices and communications mechanisms such as voice, email, instant messaging, video, presence, and mobility, there was no longer a tendency to rely upon the voice communications provider as the source of the applications. The most logical providers of Unified Communications were those vendors who were already part of the substantial desktop investment such as IBM and Microsoft. Many enterprises and service providers were able to leverage already purchased licenses for APIs into the voice communications systems for the new Unified Communications applications. Even when new licenses were required, the network equipment providers were no longer being engaged for new API functionality and were no longer able to demand premium prices for API licenses. Many of the network equipment vendors struck partnerships with the Unified Communications application vendors as a means to drive additional API license sales through sales of the existing API capabilities and incremental capabilities added to the API portfolios. The network equipment providers were able to retain a revenue stream based around monitising their API portfolios, though not as deep as that revenue stream had been in the past.
Service Delivery Platforms
The rise of Unified Communications began to signal a shift in the communications-centric applications development model. As the application distribution control shifted to more IT centric companies, the portion of application developers with deep knowledge of voice communications network functionality declined. Developers were versed in development models consistent with the desktop software they were integrating communication with, as well as Services Oriented Architecture (SOA) and Web 2.0 principles and methodologies. The APIs provided by the voice communications infrastructure did not lend well to these development models. Additionally, despite standards for many of the API formats, the disparity of implementation and the broad variety of available API standards had led to fragmentation in customers networks. As a result, service providers, enterprise administrators and application vendors began to leverage new platforms which both simplified the communications network APIs as well as provided a unifying translating gateway between applications and the communications networks.
Service Delivery Platforms (SDPs) are a combination of service creation environments, service execution environments, media control, and interface integration capabilities. They offer an integrated environment for developing and deploying applications. For application developers, SDPs provide a means to develop using telecommunications capabilities while avoiding complex APIs in favour of the simplified APIs provided by the delivery platforms. However, for service providers, enterprise IT administrators, network equipment vendors, and even SDP vendors, SDP is a difficult business case to rationalise against the existing business model.
SDPs are by design a middleware product. They consume APIs from the communications networks, consolidate, and re-publish APIs towards applications. In the model prior to SDPs, network equipment vendors licensed APIs while application vendors provided applications using those APIs. As the value model shifted to applications, particularly those offered as a service, the opportunity to monitise just the APIs diminished. The service model further pressured the telecom API business as new licenses could be acquired only as needed. SDP vendors offered a consistent, consolidated platform for the creation and deployment of services with security, reliability and availability. Organizations requiring new functionality or compliance to new standards looked to the middleware vendors first.
Application development is not a guaranteed business. For every successful application that captures the attention of consumers and business users, there are dozens of failed applications. Capturing wallet-share with applications has increased in difficulty, with the consumer market in particular becoming more attached to the free and freemium pricing models. The business model for further API capability became more difficult for several reasons:
1. Network equipment vendors have become adverse to investing in new APIs or evolving existing APIs directly on their network elements. Given their distance from the applications, both in participating in the requirements and taking share of revenue, vendors are reluctant to make investments in capability that enabled the applications without having a near-guaranteed business case predicting the application's success.
2. SDP vendors are faced with the problem of designing to a multitude of existing communications network elements and developing mechanisms to deal with the function disparity in many of those elements. There is also an increase in the number and complexity of web centric APIs and standards being exposed to application developers.
3. Service providers and enterprise administrators are unlikely to make significant investment in broad middleware platforms or incremental investment in evolving legacy, operationally-complex communications infrastructures without a monetisation model that justifies the investment.
Other Revenue Models
As a result of the complexity of applying typical monetisation models to the exposure of communications APIs, the technically favourable nature of SDPs, and the dependence of application vendors on the SDP for simplified access to communications capabilities, many vendors have adopted different revenue models.
The model most closely aligned with previous monetisation methods has begun to play out in the Communications Enabled Applications (CEA) industry. Application vendors have begun to vertically integrate their solutions with the necessary SDP capabilities for their solution. By example, IBM leverages their WebSphere Product Family for its application capability and deployment mechanisms and enables WebSphere with capabilities common to SDPs for service creation and interworking with communications networks. Similarly, large IT application companies have built or acquired SDP capabilities to enable them to vertically integrate communications capabilities with application suites. Two significant examples of consolidation to facilitate vertical integration are:
Oracle acquired BEA, Sun and Convergin, providing them the ability to integrate the BEA WebLogic SDP, Sun's extensive platform capabilities and Convergin's legacy and next-generation communications network interfaces
Amadocs acquired long running SDP vendor JNetX as an integration point between their applications and both legacy and next-generation communications networks
By focusing on the vertical integration of applications with the underlying required systems, application vendors are able to monetise the communications capabilities from within their applications. Although they are no longer monetising the APIs directly, the net effect is the same: invocation of communications features results in an invocation of communications APIs from within the integrated infrastructure. Service providers and enterprise administrators are now paying for the value of the API, not the API itself. This permits application vendors to justify new API functionality and incremental API functionality developed on their integrated SDPs as part of the overall application. This approach is especially pragmatic for application vendors when they are re-using the same API for different end-user value propositions. Given the integrated nature of the system, service providers and enterprise administrators are able to focus on the value of the application and the cost of the application as an integrated unit, not as a cost of several disparate capabilities secured from multiple vendors.
This value-based model is still a monetisation of the APIs, but monetisation is not the primary focus. Application providers are able to focus on their core businesses and the APIs become a means-to-an-ends for their value proposition. However, vertical application integration remains a difficult goal for: i) application vendors without the size to acquire or develop their own in-house SDP capability; ii) remaining independent SDP vendors; and iii) network equipment vendors providing their own SDP equivalent offerings or APIs directly from a suite of communications products. Large application vendors wishing to offer vertically integrated capability outside of their core domains of application expertise face the challenge of identifying application opportunities that will lead to successful revenue generation, especially when APIs need to be added or augmented to fulfill the application requirements.
The more substantial number of opportunities that exist outside of vertically integrated solutions is driving a new means of identifying and realising end-user valuable CEAs: CEA developer ecosystems. While providing a developer's community around APIs is not a new concept, several companies and organisations have taken to community focused collaboration around making capabilities available to other application developers.
An example of such a community is the Coral CEA ecosystem based in Ottawa, Ontario. With founders such as IBM, Nortel, Carleton University, Eclipse, and the Information Technology Association of Canada, Coral CEA offers access to the communication APIs of IBM, Nortel and open source initiatives to members of the ecosystem. Member companies have the opportunity to leverage APIs and expertise in the CEA functional domain so that the member companies can determine the best viable value proposition to end-users. Member companies use the CEA APIs and expertise to augment existing applications or to derive entirely new CEAs. The key value to the ecosystem founders is that they are able to provide existing standards-based capability to member companies to create new value-propositions. The founders may in-turn provide assistance to the members to commercialise new services by channeling the new application/capability to market, joint marketing, or providing a known cost as a service set of capabilities that the member may leverage for commercial sale of their own application. This provides an opportunity to founders or member companies to monetise existing communications APIs; however, it is via the identification and sale of the value-proposition, not the APIs themselves. Member companies are provided a low-risk opportunity to identify valuable applications and prove them to potential customers without the need of procuring costly CEA capabilities and without the risk of attempting to drive the sale of substantial middleware platforms to their potential customers for applications not yet proven. While there are other examples of such CEA ecosystems, the nature of Coral CEA as a vendor neutral facilitator that provides access to capability based on best fit and low risk development and trialling capability, has permitted it to quickly reach a broad base of companies and establish itself as a reliable keystone in the Ottawa region for CEAs.
By examining the continued evolution of the exposure of communications capabilities to applications providers, it is clear that the model of monetising APIs via licensing and transactional based sales can no longer be maintained as the prime means of offering such services. The applications industry has shifted to a value based model, where communications capabilities are a facilitating function, not the defining function. As a result, application vendors, middleware vendors, service providers, enterprise administrators and network equipment providers must continue to define new end-user value propositions, develop and validate them, and bring them to market. By moving to a value based revenue model, and by leveraging vendor neutral business ecosystems, these providers are able to realise revenues more quickly, with more certainty and less risk than by relying on the fading model of building capability and hoping it will be leveraged.