Why API? - Business of APIs Conference

No notes for slide

Simon Sinek is the author of the book, “Start with Why”

He has also given a TED Talk on the concepts from his book. His talk is the 2nd most viewed of all time, exceeding over 12M views at the time of my presentation.

In his talk and book, Simon talks about the “Golden Circle”.

The Golden Circle is designed to describe and prescribe how people communicate their ideas to others. Typically, that communication comprises three constructs: Why, How and What.

And most often, people and companies describe things in this order: What, How, then Why.

Another way of thinking about this is that people start with the clearest idea (What), then move to the less clear (How), towards ultimately the very fuzzy (Why).

For example: WHAT = I have this device (iPhone). It has email, calendars, a browser and a ton of apps. HOW = It helps me manage my work and personal life. WHY = It makes my life easier and more manageable. I don’t have the iPhone because it has email, calendars, apps, etc. I have the iPhone because those things make my life easier. It just happens to be an iPhone that achieves my goal.

But the better way to think about this is from the inside out. Focus on making my life easier, by identifying that which better manages my work and life, which could translate into a device like the iPhone.

But it could be that any of these other devices can achieve my goal of making my life easier. If the iPhone no longer makes my life easier, then I won’t use the iPhone anymore. In other words, it will no longer answer my Why.

So, we are at the Business of APIs Conference…

It is therefore important for us to focus on answering this critical question! This is the most important question when entering this space. All other questions follow from this one.

Or it could be to help you better or more quickly achieve greater device proliferation.

The problem, however, is that when most people start considering APIs, they start with the What.

Here is an example of how the What often is the start of an API program. At the top of an iceberg, above the water line, is the smallest part of the iceberg. This represents the open APIs as both are highly visible. For APIs, this is also what most people are aware of. But the majority of the iceberg’s mass is under the water line, where it is not visible. The larger mass underwater equates to the closed APIs, those that you are most likely not aware of account for the vast majority of the APIs that exist along with the vast majority of the traffic and consumption. Because most people are aware of the public APIs (and not the private ones), this is usually the starting point for the API discussion. That, in itself, limits the thinking around APIs. You are already going down the road of the What without establishing a clear Why.

Instead of starting with the public APIs, start with Why API? Then identify who the audiences are for it. Then that should dictate what you should build.

Start with Why, and move outward.

To demonstrate how the Why impacts everything else, I will use Netflix (my current employer) as an example.

The API product then launched with a full REST API, complete with a developer portal, documentation, key management, terms of use, etc.

And it was targeted to support the 1,000 flowers model. That is, we would plant the seeds in the ground (by providing access to our content) and see what flowers sprout up in the myriad fields throughout the US. The 1,000 flowers are public API developers. At the launch of the public API, the content was fully liberated and the bird was set free to fly around in the open world.

And at launch, the API was exclusively targeted towards and consumed by the 1,000 flowers (i.e.. External developers). So all of the API traffic was coming from them.

Some examples of the flowers…

Our streaming application launched shortly before the public API and started gaining steam…

We started introducing more devices over time.

And the API grew to support, not only the public developers, but also many of these devices (some of which were developed internally and others through partnerships).

So our Why started to shift from “Forming a developer community” to “Supporting a range of different types of developers”.

The API was still a product strategy, but with a growing and diversifying audience.

The REST API was still supporting this ecosystem and strategy.

And the number of devices continued to grow.

As did our traffic…

Meanwhile, the balance of requests by audience had completely flipped. Overwhelmingly, the majority of traffic was coming from Netflix-ready devices and a shrinking percentage was from the 1,000 flowers. As a result, the Why proposition has changed significantly.

The new Why is that the API is no longer a product designed to serve a range of different audiences. Rather, it is now a tactic designed to support the streaming application.

It is a tactic to support our millions of subscribers.

To support the system that handles 33% of the peak Internet traffic in the US.

Our content and growing original content strategy.

And our 1,000+ different device types. This is significant because there is so much diversity in 1,000 different device types!

For example, screen size could significantly affect what the API should deliver to the UI. TVs with bigger screens that can potentially fit more titles and more metadata per title than a mobile phone. Do we need to send all of the extra bits for fields or items that are not needed, requiring the device itself to drop items on the floor? Or can we optimize the deliver of those bits on a per-device basis?

Different devices have different controlling functions as well. For devices with swipe technologies, such as the iPad, do we need to pre-load a lot of extra titles in case a user swipes the row quickly to see the last of 500 titles in their queue? Or for up-down-left-right controllers, would devices be more optimized by fetching a few items at a time when they are needed? Other devices support voice or hand gestures or pointer technologies. How might those impact the user experience and therefore the metadata needed to support them?

The technical specs on these devices differ greatly. Some have significant memory space while others do not, impacting how much data can be handled at a given time. Processing power and hard-drive space could also play a role in how the UI performs, in turn potentially influencing the optimal way for fetching content from the API.

Many UI teams needing metadata means many requests to the API team. In the REST world, we essentially needed to funnel these requests and then prioritize them. That means that some teams would need to wait for API work to be done. It also meant that, because they all shared the same endpoints, we were often adding variations to the endpoints resulting in a more complex system as well as a lot of spaghetti code. Make teams wait due to prioritization was exacerbated by the fact that tasks took longer because the technical debt was increasing, causing time to build and test to increase. Moreover, many of the incoming requests were asking us to do more of the same kinds of customizations. This created a spiral that would be very difficult to break out of…

So, the REST API, which served the original Why perfectly…

No longer works for our new model. As a result, we fundamentally redesigned the API away from the REST model to one that more appropriately supports the new Why. That new architecture is the topic of other talks and blog posts, but will not be discussed here.

With the shifting of the Why for Netflix, that also shifted our How and What in significant ways. Ways that more effectively support our growing streaming business.

For Netflix, our API strategy can be discussed in the form of an iceberg. The public API strategy is the prominent, highly visible part of the iceberg that is above water. It is also the smallest part of the iceberg, in terms of mass. Meanwhile, the large mass of ice underwater that you cannot see is the most critical and biggest part of the iceberg. The visible part of the iceberg represents the public API and the part underwater is the internal strategy. Netflix’s strategy over the years has shifted from public to internal.

Why API? - Business of APIs Conference

Daniel Jacobson

Why API? - Business of APIs Conference