By Sven Blumberg, Timo Mauerhoefer, Chandrasekhar Panda, and Henning Soller
APIs have proliferated in numerous industries, becoming a critical interface for connecting systems and data. In the process, APIs are instrumental in the development of solutions across diverse areas such as geospatial positioning, the integration and information exchange of industrial machines, and web and mobile apps. Thanks to this ubiquity, many IT leaders regard APIs as not just a means of communication but also a channel of their own.
As with every new channel, companies must identify best practices and unique selling propositions. Indeed, in many cases APIs have become victims of the typical antipatterns of technology—such as being chosen out of context.
Within the world of APIs, a few myths have taken hold. IT leaders must separate fact from fiction to make the right strategic choices. Typically, we see companies offer as many APIs as possible to the outside world in an effort to monetize APIs on their own. However, we also see that true leaders in this space use APIs more broadly and are more selective in their offerings (exhibit).
Common myths about APIs
Because each myth has its own truths and traditions, we’ll discuss them one by one.
1. Open APIs are better than internal APIs
When open APIs were introduced, many people assumed that increasing the pool of possible app developers would be beneficial. In our experience, the opposite is true: open APIs carry the risk of providing an unwanted interface to outsiders who are either developing a new customer front end for a service provided by your back end or even taking malicious actions. IT leaders must carefully evaluate whether each API provides a service to the outside world that could undermine their company’s customer interface and thereby erode a competitive edge. Similarly, APIs should be evaluated for the potential risks of providing such functionality to external parties.
2. More open APIs are always better
Similarly, we have seen numerous companies measure their success by the number of open APIs online. Such an approach has proven to be very dangerous because it offers the possibility for other entities to provide core functionality and services without ever touching a company’s core customer interface—essentially diverting customers before they engage with the company that is offering the underlying services. Similarly, providing open APIs that are not used or not usable also leads to additional cost because IT has to ensure compatibility and handle maintenance.
3. More APIs are always better
We have often seen statements such as “If some APIs make us strong, more APIs make us stronger.” Despite the fact that APIs provide a standardized integration pattern, the massive proliferation of APIs is as disadvantageous as the growth of web services and even point-to-point interfaces in legacy architectures. To support agile development and facilitate testing of implemented applications, companies need to limit complexity and the total number of interfaces. Therefore, minimizing the number of APIs and optimizing their use are much more important than creating a multitude of them.
4. APIs don’t need any branding
APIs often don’t have a brand, making one geoposition API as good as another, assuming the output is the same. However, an offering can indeed be more personalized—for example, through branding an API’s navigation or payment specifically when it is integrated into a broader application. Attaching your APIs to products, apps, and services that are considered valuable and advanced will also increase your brand value, and vice versa.
5. APIs should be commercialized on their own
The first commercialization options for APIs were based on the fact that their individual usage could be commercialized (for example, paying x cents per usage of a geoposition API). In many cases, we have seen that such simple monetization is not fulfilling an API’s primary purpose—particularly when it comes to increasing sales. In most cases, the potential brand recognition and sales of products and services are much more valuable than the commercialization of an individual API.
6. APIs just need to be offered
Observers often hypothesized that the use of APIs is all about supply: once the business recognizes the value an API could generate, developers will then figure out a way to integrate the functionality into the existing landscape. In reality, the presentation and usability of APIs are big differentiators in the market. The creation of an API portal is essential to enable the users of the APIs (the third-party developers) to harness them easily.
Key learnings
These antipatterns show that developing an effective API strategy requires companies to navigate numerous pitfalls. Developing the right set of APIs, both open and internal, is not easy. Typically, the development of a clear future state of to-be-provided APIs, along with a road map, is helpful to ensure reusability and rationalization from the start. Clear guiding principles should be employed when designing the target picture of the APIs:
- All open APIs should be assessed by their risk of exposure and the possibility of circumventing the customer front end.
- Possibilities for cobranding open APIs should be explored.
- APIs should never be channel specific.
- APIs should pave the way for more business rather than being monetized on their own.
- The number of both open and internal APIs should be minimized while optimizing for reusability.
Following these principles in the design of the future state can help avoid challenges later.
Still, this planning exercise requires time and is often overlooked because of the sheer complexity of the existing interface landscape. Companies that take this time at the outset will be able to drastically reduce their number of APIs.
Sven Blumberg is a senior partner in McKinsey’s Istanbul office; Timo Mauerhoefer is an associate partner in the Frankfurt office, where Henning Soller is a partner; and Chandrasekhar Panda is a senior expert in the Abu Dhabi office.