This article originally posted by Scott Fulton on ReadWriteWeb on January 28, 2012

The first place I had ever seen an API actually at work was as part of an operating system. It was a strange OS at that, a permutation of CP/M that used a graphical front end called GEM, which would later be ported to the Atari ST. The definition was explained to me like this: An “interface,” as everyone knows, is a specification for how electrical components interconnect. Well, now it’s possible for an application program – the part that does what users need – to interconnect with the operating system, which does what the computer needs. This way the operating functions don’t have to be built into every program, they can just be handed off to the OS and the connection will look seamless. The principle was called a layer of abstraction. It was 1984, and it was the first time I’d heard the term.

It would be wrong to call the concept “revolutionary,” unless you measure time in units of eons. Nearly three decades after its introduction, only recently have businesses come to realize how widely this architectural principle could be applied. No longer do complex processes have to be bound to precise, policy-intrinsic procedures. If teams can work independently, and computer resources devised to suit each team individually, then all that needs to be specified is the exchange of information between them.

So it is that a software designer ends up becoming one of the public faces of the ideal of API architecture as a business tool. Daniel Jacobson is the lead API engineer for Netflix – arguably the largest single consumer of bandwidth on the entire Internet. His O’Reilly book, APIs: A Strategy Guide, co-authored with Apigee CTO Greg Brail and research editor Dan Wood, deals with the implementation of APIs not so much for software’s own exclusive purposes, but moreover as a means of realigning and renovating business’ resources overall.

“APIs should not be geeky ‘science projects,’” reads the first paragraph of Chapter 4. “They are critical business tools. Successful APIs need clear objectives that relate directly to business objectives and track closely to key performance indicators for the business at large.”

More open on the inside

We’ve written here in ReadWriteWeb in the past about the value of APIs in providing transparency and accessibility to businesses, mainly through enabling them to develop mobile apps that connect more directly to their customers. Jacobson has a different perspective, which derives from his experience with Netflix, and earlier as the creator of the API for NPR. It was in 2002 that Jacobson and his NPR team made discoveries that he describes as part logic, part luck.

“At that time, a lot of publishers would be buying these CMSes, off-the-shelf products like Interwoven or Vignette,” Jacobson relates to RWW. “And the flexibility, and the opportunity for thinking in these [new] kinds of ways, was somewhat limited.”

Subsisting sometimes from month to month on public and government funding, NPR didn’t have the budget to go big and invest in a colossal, support-intensive CMS like Vignette – an investment which, at that time, often cost bigger businesses tens if not hundreds of thousands per year, after including maintenance costs. Faced with no other obvious option, NPR was forced to go it alone, building its own CMS. And in recognizing the need to maximize its efficiency, Jacobson and his colleagues decided that their system had to be designed from the beginning to be flexible enough to publish to any platform, including those that had not yet been created.

So NPR adopted a design philosophy called COPE: Create Once, Publish Everywhere.

“That was the really fortunate decision that we made… We didn’t think about iPhones and tablets, and things like that, in 2002. But we were thinking that we could imagine a case somewhere down the road where the Web site would need to change again, or we’re going to do another redesign… It was really important for us to have this COPE model, so we can actually capture all the metadata that’s important to us in a very modularized way so that, regardless of what the display is going to look like, we can publish to it very easily. So conceptually, we separated the idea of capturing the data from presenting the data.”

It was NPR’s first abstraction layer. But it was not yet an API, mainly because the CMS and the database were still tightly bound. To this day, businesses that invested in content management systems around the year 2000 are wrestling with the headaches of data portability, because their CMS is too tightly bound to its database, and the database has become a rusty, misbehaving vault.

The interface as publishing

It was 2007. While NPR had a system that could publish anywhere, the create-once part was giving it problems. The creation was becoming a frightful mess.

“It was that moment in 2007, I think, when we said, we’ll need another abstraction layer to separate out the direct access from the presentation layer to the database, even though we had conceptualized them as being different, that binding to the database was still there. That’s when we created this new abstraction layer of the API, and shortly after that, [we realized] we could open this thing up quickly.”

The process of integrating the abstraction layer was entirely internal, and its goals were focused on how NPR could retool itself. But in making that change, the organization realized it could effectively publish the benefits of that abstraction in a way that was entirely in keeping with the goals of its COPE methodology. Dan Jacobson tells us that, in this phase of the project, he incorporated another important ethic, this time straight from the world of broadcasting: Know your audience. More specifically, build each component of the system in tune with the needs of its consumer.

Jacobson’s API project enabled NPR to publish stories and excerpts through its own cross-platform app, entitled “Infinite Radio.”

Jacobson’s book suggests that more businesses either nurture or hire someone who can serve as the technologist for their company, and make it this person’s job to know the audience – to understand how data is being consumed and who is doing the consuming. “And then understand what abstraction layer, like an API, needs to be put in place,” he explains, “to basically be the glue between the capturing of the data and the presentation to its users.”

One term Jacobson often borrows from the software development world and applies to the business world is context. He uses it to mean the breadth of a person’s influence in the company, and there are reasons that influence may be limited. But only through understanding the different contexts of business units, he feels, can a developer build an API that enables them to interoperate.

“Publishers are thinking about how can they create an organization that will put them in a position for this kind of rapid growth,” Dan Jacobson continues. “At Netflix now, we have several hundred devices running off our API. Many publishers of various kinds would love to have that kind of distribution. You need your technologists in a position to have the context and the trust of the superiors, and basically everybody on board with making smart decisions and allowing them to execute. The larger the company sometimes, the more bureaucracy there is, and the more they need to have these discussions. They’re basically, potentially, shackling their people… Here, you’re putting them in a position to make decisions for you.”

Fate has an interesting way of making itself appear coincidental. Had NPR not been so constrained by its own budget limitations, it might never have hired the team that designed their CMS and that implemented COPE in the first place. And it might still be bound by the same tight, complex information architecture that binds so many bigger commercial enterprises to this day.

“I think it’s the confluence of a range of things – the financial restrictions, having good people, good context, good control of the situation, and making smart decisions – and a little bit of luck,” says Jacobson. “We could have made some smart decisions at the time that weren’t quite as lucky down the road. We were very fortunate.”

This presentation was from the App Dev Conference in Santa Clara, CA on October, 27, 2011.

API programs, typically thought of as a public program to see what public developer communities can build with a company’s data, are becoming more and more critical to the success of mobile and device strategies. This presentation takes a look at Netflix’s and NPR’s strategies that lead to tremendous growth and discusses how Netflix plans to take this internal API strategy to the next level.

This is my presentation from the Business of APIs Conference in SF, held by Mashery (http://www.apiconference.com). This talk talks briefly about the history of the Netflix API, then goes into three main categories of scaling:

• 1. Using the cloud to scale in size and internationally
• 2. Using Webkit to scale application development in parallel to the flexibility afforded by the API
• 3. Redesigning the API to improve performance and to downscale the infrastructure as the system scales

When viewing these slides, please note that they are almost entirely image-based, so I have added notes for each slide to detail the talking points.

This presentation was original given at OSCON in July, 2011. It was my first OSCON presenting on behalf of Netflix.

The Netflix API was originally launched 3 years ago to expose Netflix metadata and services to developers and build applications. It now handles over 1 billion requests per day from over 20,000 developers and 13,000 applications. However, Netflix has undergone many business changes and the API needs to be redesigned to focus on its core streaming business and support international growth. The new design will build a scalable data distribution pipeline to deliver customized, optimized metadata and services to each streaming client and platform. It will use wrappers and response handlers to customize the response for each device and isolate problems. This will allow faster development and reduce the need for versioning across many client types and interfaces.

I was invited to Bristol, CT in May, 2011 to give this presentation to ESPN’s Digital Media team, focusing on the trajectory of the Netflix API. I also discussed Netflix’s device implementation strategy and how it enables rapid development and robust A/B testing.