An API (Application Program Interface) is a great way to expose services or data from your company for use by your company, customers, partners and independent innovators, that is across the tail as discussed in the SDP Asia article.  Doing cool stuff isn’t limited to people who code for a living which the term developer implies, I prefer the more inclusive phrase of independent innovators or simply innovators when used in context.  APIs are really ‘the grease’ that helps businesses lower costs; or generate new revenues; or lower barriers to entry to enable new services, new business models, or new value.

Examples of how APIs grease the wheels of business include:

• Amazon Web Services and AT&T expose their cloud services to customers through APIs so they do not need a to use the console to provision services, lowering cost of operations for their customers and expanding service adoption to create new revenue;
• BART (Bay Area Rapid Transit) and SLTA (Singapore Land Transport Authority, see the CloudAsia review article) expose timetables for innovators to embed that info for their customers so they have easy access to their transport services (generating additional revenues, and improving customer satisfaction at minimal cost);
• The Guardian newspaper exposes an API for nOtice, its community bulletin board, so innovators can mine the data and create new services and value;
• Netflix using APIs to embed its service in hundreds of devices (lowering development costs and expanding the customer base for additional revenues); and
• Telenor exposes M2M provisioning and management APIs so its enterprise customers can easily manage their devices, lowering costs and expanding M2M use to drive additional revenues.

There’s excellent thought-leadership and advocacy work in raising the importance of APIs across all businesses.  But the term API has become shorthand to mean the value (e.g. payment service), the demand (e.g. merchants wanting to use the payment service), and the delivery of that value to meet demand (e.g. payment API).  Without value and demand, delivery is worthless, a bridge from and to nowhere.  I make this distinction as I’m seeing lots of buzz on the concept of API aggregation (delivery aggregation), which I think makes sense, but must be examined from the perspective of the 3 elements of: demand, value and delivery.

Twilio generates demand through excellent community management and extensive how-tos and aggregates operator APIs (delivery aggregation), Twilio’s reviewed here.  Technocom and Loc-aid similarly generate demand through direct sales to enterprises of their location and messaging enhanced products (where they aggregate APIs and other databases).

Can API aggregation (delivery aggregation) exist as an independent business?   Is API aggregation so hard?  At a technical level a simple Java switch statement does the job, granted this ignores the business model and API management issues.  Operators can do API aggregation themselves given the platforms they’ve bought.  Cloud service providers will likely aggregate APIs to make their cloud development platforms more compelling, for example like Microsoft Azure and Twilio.  My contention is the market will settle on 2 forms of API aggregation: those that generate demand and aggregate wholesale APIs from telcos (e.g. Twilio, Technocom and Loc-aid), and telcos that work directly with their customers (e.g. AT&T and Telenor).

The traditional ‘pre-ordained aggregator’ business we saw in SMS is likely not relevant in the longer term as APIs have greased the wheels to make the value of such delivery aggregation slight, so it will more likely be bundled into other business models.  Today the hard part with telco APIs is in generating demand, which companies like Technocom, Loc-aid and Twilio are addressing.