As a proof of concept, Nielsen developed an Alexa Skill that lets a user ask Amazon Echo questions such as, “What are the five best selling brands of tea in the U.K.?” Other examples of Alexa Skills include setting a timer or a thermostat, ordering a pizza and calling an Uber.
The Nielsen Alexa Skill may be a party trick at the moment, but the potential for a data interface that “just works” for business users, instead of them having to adapt their behavior to satisfy the interface, is too good to ignore.
The user interface is impressive, but the skill relies on the underlying API (application programming interface). For a long time, no one outside IT showed much interest in APIs, but MIT research shows that the most successful digital companies make above-average investments in APIs (1); these companies know that APIs are fundamental to their strategic success. Why do they think that?
Gartner estimates that by 2019, three quarters of an enterprise’s analytics will combine enterprise data with 10 or more data sources that belong to partners or third-party data providers outside the enterprise (2) These data sources include Twitter, Facebook, econometrics data, weather, market research and others.
Big data, combined with the rapid turnover of data sources as companies rise and fall, will eventually overwhelm even the capacity of the data lake, constrained as it is by the need to copy data into a centralized repository. APIs that connect to data remotely are the best tools we have for assembling a broad span of digital data in a timely and responsive manner.
APIs are not just a way to connect to data; they connect companies. It’s estimated that by 2018, more than 75% of new multi-enterprise processes, such as supply chains, will be implemented as distributed, composite apps. Integration Brokers, Integration Software as a Service (iSaaS) and Integration Platform as a Service (iPaaS) providers offer tools for wiring up the virtual enterprise—using APIs.
APIs are also the foundation of digital innovation and agility. The core competencies of an enterprise evolve slowly. Banks will always look after credits, debits and transactions—that’s what make them banks. But the way they make those services available to customers, and combine them with third-party services, needs to evolve rapidly. APIs are a means of exposing core capabilities in a variety of ways: through online and mobile banking, contactless payments using cards and mobile devices, integration with blockchain-based trading systems and so on. The API both separates and connects; it lets the user experience of managing a bank account evolve rapidly and cheaply, independently of the business-critical, slowly changing core processes of the bank.
To be successful, an API must satisfy both the needs of its primary consumers, developers and the needs of its ultimate customer, the business.
Developers are no different than their non-technical counterparts; they want an API that’s easy to use. But they have a multiplicity of requirements that are not part of standard user experience (UX) design—for example the ability of the API to integrate with their favorite programming language. For this reason, some UX practitioners identify a unique problem domain, which they call “developer experience” (DX). Good developer experience, including the availability of a software development kit, documentation, sample code and so on, will do a lot to promote the adoption of an API.
But even an excellent developer experience doesn’t guarantee success; the ultimate consumer of an API is the business, not the developer. APIs that simply expose an intelligence-free connection to a data source are unlikely to be successful. Good APIs add value by presenting data in a generally understandable form, for example based on industry norms, rather than a company’s proprietary view of the world. They make it easy to integrate data into external business processes.
HOW DO YOU DESIGN A COMPELLING API?
One way to create a compelling API is to capitalize the ability of APIs to deliver intelligence and business value. A company with an extensive database of map data could create an API that allowed them to sell maps. Third parties would be able to grab a map and build their own navigation or routing algorithms on top. The map API is useful, but adds no value or intelligence.
A more enterprising company would offer an API that provides turn-by-turn directions for a journey, rather than just a map. It’s possible to update the map as roads get built and improve the routing algorithm without changing the API—and disrupting the software using it.
This sort of API could beget an ecosystem by encouraging the creation of supplementary services: showing the location of nearby hotels and gas stations, plus the availability of rooms and the price of gas, for example. An analysis of journeys taken using the API, and traffic information inferred from this, could further improve the service. By being thoughtfully designed, the API has engendered an ecosystem.
Another pattern that’s proven successful in the real world is having foundational or universal APIs and using these as the basis for creating an API tailored to an individual client. Netflix has popularized these "Experience APIs" that tailor the API "experience" to the needs of each consumer.
These are a few pointers, but the use of public APIs is still in its infancy among traditional businesses. There is no proven playbook for creating digital APIs, and companies are struggling to invent solutions. Eventually best practice will crystallize and things will improve, but until then we’re in for a bumpy ride. There is no doubt, however, that APIs are the foundation needed to connect independent systems and processes. And without the ability to connect, nothing else can happen in the digital economy.
Being able to connect data and processes is, of course, only the first step in understanding the environment in which the enterprise exists and realizing the value of these connections. Being able to connect to a myriad of different data sources does nothing to resolve the heterogeneity in the underlying data sources, where the same real-world entity may be identified and described in a multiplicity of different ways and must be reconciled in order to perform any kind of meaningful integration.
Written by Tom Edwards, SVP, Technology at Nielsen