APIs have changed the game

In competition, speed dominates.  The mantra that you win by “providing the most value at the least cost” isn’t complete until you add “in the least amount of time.”

This can be easy to forget this during periods in which companies jockey for a slight edge by tweaking established operating models that are largely similar.

But at times disruptive innovation changes the game.  Even the best practitioners of the old ways can’t match those who embrace the new.

Modern APIs are driving one such change now.  But we’ll better appreciate the implications if we consider this in light of a previous change of similar magnitude.

After World War II American automobile companies dominated the global industry.  But in the late 1940s a manager at a small company in Japan, lacking even a fraction of their resources—but also free of preconceptions about how cars should be built—was trying to figure out how to challenge them. His company was called “Toyota.”

In an entire year the whole Japanese auto industry was building just one day’s worth of U.S. production in 1950. By 1980, 22% of passenger cars sold in the U.S. were imported from Japan. U.S. automakers were literally unable explain why the upstarts were able to more quickly deliver a greater variety of higher-quality vehicles that cost less to boot.  There was conjecture the root cause had to be unique to Japan.

Although the “Toyota Production System” had been described (in Japanese) in the 1970s, it took a joint venture between GM and Toyota to reveal the truth. Toyota re-opened a shuttered plant in the U.S. and a rigorous benchmark showed that it achieved 50% greater productivity than comparable plants—while largely re-employing the same workforce and without much new technology. 

A 1988 Sloan Management Review article proclaimed the triumph of what came to be known as “lean” manufacturing.  Its author coined the term to contrast it with the “buffered” approach that had up until then been the state of the art:

• Giving teams responsibility for continuous improvement rather than adding layers of management to oversee and direct them;
• Building a network of suppliers rather than a big, vertically integrated organization;
• Keeping inventories of parts low—a “just in time” or “JIT” approach—rather than keeping large inventories “just in case” something went wrong.

These practices created a virtuous cycle.  Less waste and overhead reduced the time and cost of production, so smaller runs of a wider variety of models were viable. This generated more insight into changing tastes.  Because the supply network was flexible and inventories were low, a firm could address those tastes more nimbly.

The old way of doing things—no matter how well executed—could not  keep pace.

Today practices like “JIT” (just-in-time manufacturing) have become ubiquitous in many industries, but early on those who applied lean principles earliest gained a disruptive advantage.  

Walmart’s blistering speed was highlighted in the 1990 management classic Competing Against Time: How Time Based Competition is Reshaping Global Markets.

At the time, Walmart was replenishing the stock in its stores four times faster than its competitors. As a result, it could provide the same selection to customers for 25 percent of the inventory investment; offer its customers four times the selection for the same investment, or a mix of both.  It was growing three times faster than its sector and its return on capital employed (ROCE) was twice the industry average.

Walmart subsequently had a great run—but let’s turn to APIs, today’s game-changing, disruptive innovation.

On July 23, 2015 Amazon’s market cap surpassed Walmart’s.  Amazon has not slowed down winning a steadily increasing share of U.S. retail.

While Amazon has earned a reputation for a relentless focus on efficiency and speed, Walmart’s reputation for the same hasn’t wavered. If my hypothesis that APIs have changed the game has merit, we ought to be able to find a material difference in the use of APIs that might explain how this upstart is disrupting the master of the old ways.

Thanks to some powerful visualization by Rahul Basole and Peter Evans at the Center for Global Enterprise, we don’t have to speculate. We can see it.

Basole and Evans wanted to explore how companies were participating in what some call “the API economy.”  So they assembled data on thousands of public APIs and their re-use in apps alongside other APIs (what Basole and Evans call a “mash-up”).  Visual analytics show that Amazon’s 33 open APIs have been combined with others to create over 300 mash-ups.  By contrast, Walmart’s single API has yielded only one.

Amazon APIs are not only greater in number but also the center of an “API ecosystem” of partners building third-party apps that use those APIs.

Amazon’s APIs include cloud infrastructure APIs as well as those offering retail functionality. I take this as a “tip of the iceberg” peek into what I suspect is a vast number of internal APIs built after Jeff Bezos’ famous “Yegge Rant” in 2002 mandating that all internal systems had to be built to be externablizable (something I discussed in a previous post). 

This implies that Amazon has a massive API ecosystem war chest that has also been accelerating innovation inside the company.  John Donovan—AT&T’s Senior Vice-President of Technology and Network Operations—explains this well in an interview titled “APIs: an architecture for speed at AT&T”:

“The use of APIs and their impact is not just for outreach to the external developer community. It changes how you operate. You literally put APIs everywhere. That’s how you do internal development, that’s how the IT shop works, that’s how your provider should do development for you, that’s how your offshore stuff lands into your environment, and that’s how you build services.”

What does this mean for every CIO? (And I mean “every:” how many Fortune 500 companies are there today who didn’t  “learn from lean?”)

It means a visualization of your IT systems—internal as well as external—ought to look like that of Amazon’s: lots of APIs, lots of mash-ups, measurable network centrality.

And your culture and practices need to adapt accordingly:

• Give “two pizza”-sized teams autonomy to innovate using those APIs rather than trying to plan and direct it “top down”
• Build an ecosystem of third-party innovators rather trying to “do it all yourself”
• Use the modularity of APIs to continuously try lots of “small bets” that you “fail or scale” rather than limiting your options to a few monolithic projects.

(Disclosure: AT&T is a customer of my employer, Apigee.)