Daniel Jacobson is the Director of Engineering (API) at Netflix and author of the book APIs: A Strategy Guide (O‘Reilly Media, 2011). After a long stint as part of and then the leader of NPR’s digital team, Jacobson gained vital experience addressing difficult API technological and business strategy challenges. Netflix took note of his innovative approach and brought him on board to join their staff of technologists. This is the transcribed conversation had by Office of Digital and Design Innovation Director Rob Bole, ODDI Multimedia Blogger/Producer April Deibert and Jacobson about how to strategize internal and public API development.
[Video: What is an API? (Volume I), Source: apigee on YouTube]
Bole: Why write the book and what have you found so far?
Jacobson: The purpose of the book is to focus on the business aspects of API development. There were already a lot of books about the technical aspects, design and best practices of API development. The other authors and I felt that there was no holistic picture about API–about the benefits, about the detriments, about the legal ramifications, and about the security ramifications. We wanted to just step back and think about all the things that you have to consider when you are thinking about an API and how that translates into execution or implementation. So one of the key principles that we try to lay out throughout the entire book is that you should know your audience. For example, if your audience comprised of internal development teams and you don’t open it up publicly, that has different legal ramifications than public developers. We felt that was a really important message that we needed to convey, especially as the API industry is really ramping up.
Bole: In your book, you discuss that the real growth of APIs has been internal (a core business mission) rather than external (crowdsourcing innovation). Do you recommend internal or external strategy first for API development?
Jacobson: Different businesses thrive on different things. I think Twitter has benefited from their public APIs and they wouldn’t be who they are today if they didn’t do that. But, they are changing their strategy now. It really depends on the business. That said, when NPR launched their API and Netflix launched their API, both companies had the idea of “let 1000 flowers bloom”. Meaning, create a field of opportunity and then see what sprouts up around it. Both companies wanted to take advantage of the crowdsourcing opportunity.
However, before I left NPR, it became very clear to me that the public API wasn’t really going to change anything for us in a meaningful way. The major transformation was the internal consumption, such as: building iPhone apps off of the API, distributing to member stations, letting member stations post into the API, then redistributing that information out to other member stations. It is about using your API to create tighter technical relationships with your partners. This was beyond what you would see in the public developer world. Similarly, at Netflix, it’s magnified here. We have a bunch of public developers who work on a bunch of apps, but it pales in comparison to the impact that the Netflix API has had toward our device proliferation strategy. We currently have about 800 different device types. The API is seeing about 2 billion transactions per day through our streaming applications. The public API is doing less than 0.1 percent of the total traffic. That is negligible compared to the impact of our internal API strategy. So, it depends on the company and how that company can leverage the API to support their business.
Bole: What is the API business strategy like at other companies? How do APIs play out in terms of engagement by the business development crew and the engineering teams?
Jacobson: Here’s how I characterize it: some people like to view an API strategy as ‘what is our business strategy for the API?’ I think that’s the wrong approach for that type of model. I think what we’re really saying is, ‘what’s the business strategy and does an API help us satisfy that business strategy?’ So, the business strategy at Netflix, for example, we want to be ubiquitous across all devices and where ever that user is, whatever they have, we want to make sure they can get it. How we can most likely leverage that in a highly effective and efficient way and use the economy of scale to do that?
API is a technical implementation that helps you achieve that. I think that’s, for the internal use case, the way to think about it. And we think about this in terms of our metrics. As an example, I think a lot of people think the metrics that you should care about are how many requests is the API getting, or, how many apps are driven off the API. I think those are the wrong metrics for an internal use case. The right metrics are: how is the traffic that is coming in from the API mesh with the rest of the traffic that you care about? It’s the logging that you care about for your system. Is that representative? Are there things that we can do better within the API to better support the user experiences? Or whatever the engagement is for your business. Don’t think of the API metrics as API metrics, think about them as part of the ecosystem that supports your business strategy.
Bole: How aware is the business development team of API technology and how do you work with them?
Jacobson: They are extremely aware of the API as a way to facilitate partner engagement. Plus, most of the product managers and business development staff are very aware of the role that the API plays in our product development. They think of the API as one of many components of our entire product, but are aware that it is the distribution engine that gets our metadata onto devices in our customers’ homes.
Bole: What is your role in working with the business teams?
Jacobson: The API is in a unique position within the overall product stack, so I think of it as an hourglass. At the top of the hourglass: all the UI’s, all the devices, and all of the product people who think about what we need to deliver as an experience to customers. At the bottom of the hourglass: many of the back end services (like the movie metadata database, the subscriber information, the ratings algorithm, the recommendations, and the search service). The API is in the skinny part in the middle of the hourglass.
My role is to make sure that we can broker the data (between the top and the bottom of the hourglass) in a highly efficient, resilient and scalable way. So we’re involved in quite a bit of the product development for virtually all of our UIs We have to work with the back end services to make sure that the data needed is exposed, or if its not currently exposed, get teams to interface with other teams to build a patch to get it delivered. So my team is kind of a broker in terms of data and in terms of product development; we make sure everything moves. And because the business development teams, partner engagement teams, and product managers drive many of the goals for these UIs, the API teams’ involvement with them is quite high.
[Video: What is an API? (Volume II), Source: apigee on YouTube]
Bole: BBG is a media news organization, so it’s about moving product or content to people’s devices. In your opinion, what is the role of APIs in news organizations now and in the future?
Jacobson: When I was at NPR, they thought of themselves as a journalism organization with a digital media arm. At Netflix, we think of ourselves as a technology company. We staff ourselves accordingly; more than half of our staff are part of product development. We’re certainly in the media space though because the core of what we deliver to people is media, but we’re doing it with a very technology-oriented mindset. That’s an important distinction because it makes the technology part of the DNA of what we do, instead of just delivering videos to people. NPR for example, the staffing is in balanced in the favor of non-technologists. That presents some challenges in terms of capabilities. When I was at NPR and helped to develop the API, I knew that it needed to be highly efficient for what we were doing because we didn’t have the resources to do a lot of experimentation.
Media organizations need to really think about digital strategy. What is the digital strategy and what is the role that it plays within the organization overall? Staff accordingly and get the right skill sets and the right number of people in the right positions. Focus on what the products are that you’re delivering and the API is going to come from whatever that strategy is. If you think it will be a crowdsourcing model, then you will want to focus more on public API developments and doing things that will promote external development of the APIs. If it’s an internal strategy, then you need great technologists with the right skill sets who can build and leverage APIs. If your strategy is all about mobile, then you need people who can work on those products and consume from those APIs. The API is a service that will help you develop your digital products.
Bole: What are some of the companies that are ‘doing it right’? How can one execute against using an API to advance a news or media strategy?
Jacobson: NPR is doing it right. Things have really evolved there in the past few years. While I worked there, we started thinking ‘let’s develop this API and then let’s see what public developers will do with it’. Then Bradley Flubacher built the NPR Addict iPhone app off of our public API and that got us thinking that we should build our own iPhone app which ultimate sat on top of our internal APIs. We realized that we needed to really leverage this great tool so we can work with our member stations and reach the growing number of distribution channels. They are staffed to support that entire ecosystem.
I don’t know enough about the details around some of the other media companies, but I think USA Today launched a public strategy about a year ago and ESPN launched one about 8 months ago. What they have done is try to use API publicly and internally and launch strategies around the same time. When I talk to them about their internal strategies, I think that they’re moving in the right direction. I would possibly question whether or not launching a public API is worth it at that point—based on my experiences–and I think I’ve told them that much. I think that’s part of the evolution, as you’re starting to adopt a strategy, you have to start thinking about the things that are opportunistic for your strategy, over time you’ll learn, and then adjust that. One other key point is that the strategy should be an evolution; it’s not like, okay, we’re doing this for the next five years. You’ll learn pretty quickly–if you’re NPR, or Netflix, or maybe even ESPN or whoever else–that either the public API is going to be worth the effort or not. You should make adjustments based on that and change your strategy. And as your strategy changes, that should impact your staffing as well.
Bole: What’s the future of APIs? Where should BBG aim for in the future? What are the trends that are most important?
Jacobson: The best bet is to think about internal API and to find a discrete use case or two and then have it developed. See how it evolves and grows. I think there’s a strong tendency for people to start with a public API because of the iceberg theory talked about in my book. The tip of the iceberg is above the water and highly visible, representing the public APIs. But the overwhelming mass of the iceberg is not visible below the water, which represents the internal APIs. So people tend to get lured in with the notion of public APIs because they see other companies releasing and evangelizing them. What they don’t realize is that many of these companies are really leveraging APIs mostly for their internal case.
So I would stay clear of the public APIs at the outset for two reasons: 1) I think in many cases, the value proposition is not as great as the value proposition of the internal case; 2) it’s a lot more expensive and harder to get going than an internal case because you have a lot of external considerations. These external considerations can include legal concerns, securing rights to content (making sure you can offer content if you’re getting it from other sources), what does your business want you to deliver, making sure you aren’t going to cannibalize your other business strategies, and how you are going to monetize the distribution of the content for public use. Also once the public API is out there and used by a other people, you can’t easily take it away without upsetting them. So there is a public relations risk there. I think it’s riskier and more challenging go forward with a public strategy, especially if you don’t have a clear value proposition. If public APIs are part of the strategy, then launching first with internal APIs can give you confidence in the development and change process of running an API without the initial risk associated with a large set of external developers depending on it.
Deibert: How would the development of an API affect USIM in the short term and the long term?
Jacobson: It’s hard to differentiate international and U.S. media—with digital, the barriers of proximity are broken down. At NPR, for example, the member stations were how people consumed information in the past because the radio towers were near where they lived. Now digital is coming into play—so you can get your home stream while you’re (on the opposite coast or overseas). I’m sure there are people outside the states that are reading and subscribing to the New York Times, but that’s not something they could have easily done 15 years ago. In the future, the majority of the consumption will be closer where the company is, but I think people should be thinking more about an international strategy if the content has international appeal. APIs offer that. For example, as Netflix broadens and goes to more countries (UK, Latin America, and the Nordic region), APIs play a key role. That’s how we get into people’s homes; location is not the factor, it’s just about having the right pipeline to get there, assuming that is part of the overall business strategy.
For more info:
- – - – -
(Thank you to Daniel Jacobson and Rob Bole for their contributions to this post.)
(The foregoing commentary does not constitute endorsement by the US Government, the Broadcasting Board of Governors, VOA, MBN, OCB, RFA, or RFE/RL of the information products or services discussed.)