The digital world runs on application programming interfaces (APIs). Take the Uber taxi platform: It fulfills many of its business functions by calling the APIs of other digital service providers. In the case of payment, for example, it calls Stripe's API and uses Stripe's payment platform as a service rather than building a separate capability of its own.

Over the past year, Uber has been connecting to many more APIs: As the result of a Hinge-Uber API hookup, Hinge dating app users can order a taxi while chatting to the person they want to meet; Facebook users can track their driver's progress through Facebook; FourSquare and Goldstar subscribers can summon taxis to take them to the entertainment venues they've identified. Through its API, Uber is becoming the ubiquitous taxi service for the digital economy.

APIs are rapidly becoming the lingua franca of digital business. Don't speak API? Then a whole raft of companies today, and pretty much any enterprise in the future, won't be able to do business with you. Uber and any other born-in-the-cloud company from Twitter to Netflix are at the extreme edge of this business transformation, and are driving it. They demonstrate that you don't need to build and own basic business functions to run a successful business -- you can buy them as services instead via their APIs. This lowers the cost of market entry, provides choice -- you can use PayPal instead of, or as well as, Stripe, for example -- and makes for extreme agility. Through APIs, you can take your company anywhere. It can become an integral capability provided by a third-party partner and increase the time customers engage with you, and that translates into more revenue.

Most operators, of course, are saddled with owning and operating a complete set of business functions and can't unravel them and move to a born-in-the-cloud digital mode of operation overnight. But they can adopt standard APIs to those functions. This is the first step towards modularizing them and eventually, perhaps, being able to decide which of those functions they will keep in-house as a source of competitive advantage and which to buy in from a third-party service provider along the lines of the Uber model.

Which is why the TM Forum's new Open API Map is so significant. The TM Forum's API Map posters were flying off the shelves in Nice, where the initiative was formally announced in early May (see Vodafone, TM Forum & Huawei Join Efforts to Publish Open API MAP). And rightly so, as this is a worthwhile and ambitious attempt to provide open APIs to business functions described in the Frameworx SID data model and participating in the Frameworx eTOM process model: for example, marketing and sales functions, product lifecycle management functions, customer-related functions (such as customer management, product ordering, billing management, shopping cart) and so on.

These functions are generic and don't just apply to the telco industry, of course, which is why the TM Forum expects the Open API map to generate interest from companies in many other sectors that have similar challenges transforming into digital businesses. The Open API map should help, not just telcos selling communications and connectivity services to their customers and each other, but telcos and their partners participating in the multi-industry, digital value chains that are emerging around the Internet of Things.

At a basic level, using common APIs facilitates data exchange between industry partners. In the long term, as the world adopts the digital model pioneered by the cloud service providers, common APIs will encourage the decomposition of today's stacks of business function, endlessly duplicated, company by company. They will allow the emergence of new service providers that focus on delivering smaller sets of function, perhaps to a specific value chain or sector. The Open API Map provides a starting point for at least discussion, if not a transformational move in this direction.

It is TM Forum's eventual intention to provide APIs to specific network management functions -- Level 1 of the Open API map talks generically of "resource"-level functions, where "resource" means the data object used in REST protocol to depict any actual or virtual entity. It follows the standard openness mode of digital partnership in the Internet world.

At the network resource level, the Open API map should and probably will dovetail with the API-building efforts of other organizations that are deeper into the network, such as ETSI NFV, MEF and ONF.

Of course, there are plenty of challenges to overcome if the TM Forum's Open APIs are to become widely adopted, not least around their governance and maintenance and how to encourage their enrichment and innovation while still keeping the APIs stable and usable. Digital businesses show that APIs are most valuable when they have grown up organically around a business proposition, such as Facebook or Uber. Behind the Open API Map is the specter of the GSMA's ill-fated OneAPI program which similarly tried to impose common APIs on the industry, albeit at a different level, to meet an unproven business case and at a time when the power and purpose of APIs was not as well understood.

Time will tell whether the Open API Map is successful but the signs are good: the broad, cross-industry focus is encouraging, collaboration with other API-creating bodies helpful and operator understanding of the need to work with partners and build ecosystems more advanced than in the early days of OneAPI. Telcos understand the need for digital transformation, so any initiative that makes it easier should be welcomed.

This blog is sponsored by Huawei.

— Caroline Chappell, Practice Leader, Cloud & NFV, Heavy Reading