I’m often asked what’s the difference between Aepona, Apigee, Twilio, Voxeo?  The diagram below is my attempt to provide a framework to understand the similarities and differences between the 4 suppliers.  This can only present a current snapshot and my view, other frameworks are possible, and of course all 4 suppliers have a future vision which likely overlaps more than I show here.  Please note Apigee disagrees with this analysis and we’re trying to find a framework that works.

One of my assumptions in putting the framework together is that a telco may choose not to build-out a general purpose API infrastructure, for which Apigee is a leading choice.  Some tier 2/3 operators may decide to partner on a reduced set of APIs and business scope.  And want the partner to do most things, even bringing a developer community.  A good analogy presented to me to help understand why the framework can be considered confusing is it’s like I am putting a professional services firm and a Telco in the same graph, the two are very different businesses.

This helped me think about one of my assumptions, as an enterprise can use a managed network service from a telco or a professional services firm; the solution is the same from the enterprise’s perspective even though the roles behind the managed service can be different.  As always the perspective of the viewer can be very different depending on your location in the ecosystem.  This framework is just one view of the many ways the market can be segmented.  Just as API management became critical to the business of APIs in telecom over the passed couple of years, I’m seeing a segment of operators evaluating managed solutions given their limited budgets and resources.

The framework shown below has 5 categories:

• Network Gateway – the traditional network gateway and the core set of network APIs it exposes for example based on OneAPI.
• Derived APIs, Other APIs and API services – this covers two layers in practice.  APIs built on top of OneAPI or exposed from other than the network gateway.  And services necessary for example to make the payment API a viable payment service (business solution), e.g. settlement, currency conversion, etc.
• API management – an API without management is near useless to most developers.
• Developer platform – capabilities to enable developers to create and run their applications using those APIs.
• Developer community – real people using the APIs to solve real business problems.

Within the operator I identify 4 sources of assets that can be exposed by the operator: network assets, IMS assets (broken out as Voxeo can talk directly and its possible QoS (Quality of Service) APIs could be exposed from the PCRF (Policy Control Resource Function) to an API management layer), cloud assets and other operator assets (e.g. business and operational support capabilities.)  And I show a spectrum of APIs from informational (e.g. device type or profile) to transactional (e.g. call control.)

Aepona began as a traditional network gateway, previously known as a parlay gateway, which exposes OneAPI defined APIs, protects the operators’ network, and implements all the policies and security for each developer’s access to each API.  Aepona has expanded over the years to include API creation (beyond OneAPI), mash-up, management and analytics (Agile Service Enablement); and a payments and settlement engine to enable a payment API to become a payment service thanks to its purchase of Valista.  This extends Aepona’s functionality across the “Derived APIs, other APIs, API services”, “API Management” and into “Developer Platform”.

Apigee began in the enterprise API management business and has expanded into telecom API management.  It offers a horizontal capability providing API management (including analytics) so developers can run their business on the APIs provided, and through the acquisition of Usergrid now has developer platform capabilities such as user management, social networking, notifications and storage, which can run from the operator’s cloud.

Twilio aggregates a focused set of operator capabilities covering messaging, call control and number provisioning.  It offers a simple XML descriptive set of API to its developer community. Twilio spends time and resources on developer enablement ensuring that HowTos, helper libraries, GitHub repositories are constantly updated resulting in impressive launch rates.

Voxeo offers more sophisticated communication APIs to its developer community which come from its enterprise call center / PBX business.  Voxeo’s SIP heritage means it can also work directly with IMS (IP Multimedia Subsystem) assets, and its leadership in WebRTC (Real-Time Communications) create a rich communications API environment across traditional operator devices and web browsers.

Twilio and Voxeo address different segments of developers, and demonstrates how the same core set of capabilities can be exposed in quite different ways to drive different lines of business.

Depending on what you have in your network, your API business plan, the types of APIs and addressable market segments will influence who and how much of their solutions you use.  The great thing is operators have choice in suppliers with a rich and rapidly expanding set of capabilities increasingly focused on making money with APIs, rather than simply exposing them.