Why a successful API strategy involves eating your own API dog food

It can be inferred that some of Amazon's success is from the API strategy CEO Jeff Bezos announced more than a decade ago.

Are you using APIs internally? In a 2003 notification to his employees, Amazon CEO Jeff Bezos issued these marching orders (as recalled by a former employee; edited slightly for length):

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of interprocess communication allowed. The only communication allowed is via service interface calls over the network.
  • All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Ten years ago, Amazon was already a huge company with a market capitalization of $7.2 billion. As of January 2014, that number increased to $183 billion. Of course, not all of that success can be attributed to public APIs. Nevertheless, APIs are the underpinning of Amazon's dominance in the infrastructure and cloud services space.

Considerations for developing an API strategy

If the CEO of another company copies and pastes Bezos's message, does that guarantee a 25x increase in 10 years? Unfortunately not, but it does raise a few questions that need to be thought of when drafting an API strategy.

The first thing to understand is that an API strategy is not necessarily a product strategy. While Amazon was ultimately able to leverage its huge infrastructure as the basis for a new revenue stream, the initial intention was to make the systems they were building during a hyper-growth stage more scalable and maintainable. Only Bezos's last point mentions that services must be externalizable. The immediate need is clearly to reduce architectural complexity and integration hacks. The lesson here is to consider internal API usage as a first priority, before focusing on external usage. In other words, eat your own API dog food.

Another way to view this issue is to recognize that most external-facing APIs supplement or support an existing application. EBay's API for bulk product listing, or Netflix's movie discovery API (sadly, scheduled for retirement) are two prime examples. They extend the principle functionality of the service, rather than expose some fundamentally new offering.

In further contrast to Amazon, recognize that the majority of companies are not startups. These firms already have a mature business model, and it may be supported by hundreds or thousands of applications that have been built up over a lengthy period. The decision to dedicate resources to moving to a services-based architecture can have huge time and cost implications. The notion of making all services externalizable is also not realistic for all industries. Security and confidentiality considerations usurp the notion of public APIs.

Should current discussions about APIs be ignored if an organization already has tons of applications to maintain and certain proprietary or confidential data to safeguard? Yes, but only if it's desirable to keep re-inventing the wheel, developing brittle integrations, and unnecessarily dragging out development timelines.

A firm is not going to re-engineer its entire application portfolio en masse, but when a system is going to be modified or enhanced, take that as an opportunity to ask the following questions:

  • Is the information exposed a duplicate/subset/superset of data available elsewhere? Is there one canonical system of record? If so, is there a way to expose this information in a more universally consumable (and secure) way that would potentially simplify the internal environment? There may not be an immediate appetite for consumption, but without an API in place, there won't be adopters.
  • Is the system meeting the customers' information needs? If people are combining the data with information from other sources, the application might be an accessory to "swivel chair" integration. The reduction in work and potential human error may be enough to justify the case for creating new APIs.
  • How are customers consuming the data? The application might have a thick or thin client, dump data into database, or create files that are later transmitted and parsed by a different system. Does this create any infrastructure or protocol dependencies? Does it limit flexibility? Can information be made more accessible to facilitate the creation of rapid prototypes?

APIs are getting a lot of attention lately, and that's a good thing. APIs by themselves, though, are not always the end product. Becoming internal consumers first -- eating your own dog food -- may not make a firm the next Amazon, but it will help reduce risk and complexity. This puts an organization in a better position should the decision be made to expose parts of the infrastructure externally.

About the author:
Michael Ogrinz (
@mogrinz) is the author of Mashup Patterns: Designs and Examples for the Modern Enterprise. He is also principal architect for global markets at one of the world's largest financial institutions.

Follow us on Twitter @SearchSOA and like us on Facebook.

This was first published in August 2014

Dig deeper on Application programming interface (APIs)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Related Discussions

Michael Ogrinz asks:

Is your organization using APIs internally?

0  Responses So Far

Join the Discussion

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close