The idea of “eating one’s own dog food,” or dog fooding, goes back a long way–most notably, with companies using their own software to demonstrate the technology’s performance and value. Today, many companies are dogfooding their APIs, not only to demonstrate the APIs’ benefits but also to put the technology through its paces over time.
I recently sat down with National Public Radio’s (NPR’s) Javaun Moradi, product manager of APIs, to discuss the concept of dogfooding and explore how engineering teams that develop APIs can stay at the cutting edge within their organizations. Joining us for part of the interview was Irakli Nadareishvili, NPR’s director of engineering, digital media.
While there are different schools of thought around companies consuming their own APIs, Moradi’s stance is clear: “We have pretty strong opinions that you need to be the consumer of your API.”
Moradi’s position is based mainly on two principles.
First, an API needs to be consumed internally for the API to stay at the forefront of the organization. “If it doesn’t scale, if there are bugs in it, if the critical applications aren’t using it, then [the developers] don’t care, so nobody in the business cares,” said Moradi.
Second, internal users know how to maximize the value of the API and the data it provides, leading to a better API over the longer term. “If your organization is writing APIs for your own purposes, it’s a fallacy to assume that if you can’t think of what to do with that data or service, then somebody else will, because you know the most about your business, your organization, and the market landscape,” said Moradi. “If it’s not valuable to you, it’s not valuable to anybody else.”
Nadareishvili summed up this last point a single sentence: “If you cannot figure out what to do with your data, you shouldn’t always expect somebody else to figure it out.”
Moradi and Nadareishvili said businesses must be very clear about the intended use of and audience for their APIs.
According to Moradi, APIs should be created when there’s a business use; organizations shouldn’t be developing public APIs for the sake of being public, unless that’s actually part of the organization’s mission.
Nadareishvili noted that there is a “broad spectrum” of use cases for developing APIs: At one extreme is liberating data through APIs, and at the other extreme is APIs as a business. He pointed to the World Bank, which provides access to more than 8,000 country and development indicators through its API, as an example of the former. Twilio, a company that enables a gamut of cellular voice, messaging, and other functionality through its set of APIs, is an example of the latter.
Moradi noted that because NPR is a public trust, “there will always be a public component [to our APIs], and to the extent that we can release content, we will and we should.”
At the same time, there is a dichotomy between public interest in NPR’s APIs and actual usage: “If you look at our API over the years, probably 95% of the keys are public keys, and the other 5% are NPR and stations; but if you look at the usage, it’s exactly flipped: 95% of the usage is NPR stations, and 5% is the public,” said Moradi.
In the process of trying to maintain and improve an API, feedback from the public and from internal groups can be complementary. Given that many of NPR’s APIs are (or were) private for a long time before being released to the public, the most valuable public feedback is often not related to new use cases or to bugs. Instead, Moradi said, the public can pose valuable questions about API design, highlight areas that might be confusing, or emphasize the need for better documentation.
One of the most interesting elements in our discussion was the question of how API teams can remain at the cutting edge within their organizations. For Moradi and Nadareishvili, this goal is so entwined with “eating your own” that it can, in fact, almost be viewed as part of the same larger process.
Moradi explained that, at one point, the NPR development team was much more focused on the public: “Let’s unleash the masses and let a thousand flowers bloom, and see what people will think of.”
And although that model is valuable, Moradi said, most of the innovation for an API happens internally. The internal constituency knows the business, and there is no substitute for that. For example, he said, any user can learn an API in 15 minutes or so, but an internal user will use the API with all of the knowledge and context that comes from working for the company.
Staying at the cutting edge involves more than internal consumption, however.
“It’s not just eating your own; it’s having an API-centric architecture, which is: If something is valuable, build the API first,” Moradi said.
He recalled a situation in which NPR’s digital media team was looking to implement search functionality on top of an existing library database. The database already contained a wealth of metadata about who had spoken on what NPR shows, the topics the shows had featured, and other related information. The search application would have linked directly to this dataset, and members of the digital media group were prepared to move forward with that proposition, while also considering the development of an API as a parallel activity. But Moradi and his team intercepted the process, successfully promoting the idea that the API should be built first, with the search application as the initial consumer of the API.
“That API is solid,” Moradi said. “The biggest use of this is every producer and reporter in the building.” Every query against the database that occurs each day is going through the API, and although the API is not public, it’s created a standardized interface that may, at some point, be leveraged for other use cases.
In line with his overall theme, though, Moradi is convinced that the most important use has already been found: “It’s possible that there will be a more important user of that API, but I don’t think so.”
In general, most of NPR’s APIs begin as private, internal endeavors. But Moradi stressed that no matter who the intended audience, all of NPR’s APIs are held up to a high standard, with developers striving to provide ease of use: “If we hold it to that public level of usability, APIs can be beautiful. … The plus side, if we do decide to open it up [to the public], is it’s ready to go. We write everything as an API first: We consume it, and we become its first customer. Rarely do you ever do something and need it in just one place; so that’s a rule for us.”
A second component of staying at the cutting edge, once an API is being used, is the ability to provide stability and to adjust to changing business and organizational needs. “Once you’re at the cutting edge, you have to keep it up; you think, ‘OK, don’t break anything,” said Moradi.
At the same time, there are periods when users will need new functionality, and they will need it on a timeline that syncs with product release schedules. Supporting these requirements–and more–will help IT and development teams to not only support the business but also to drive the business.
“If all you are is the stability people, and [the business side says,] ‘We need this feature, we need this locator … How long will it take to do this?’ If you tell them two months, a month, or sometimes even more than a week, they bypass you. You have a choice as an API provider: You’re always going to be stability pipes, but you have a chance–and it’s a huge chance–to lead the organization.”
Moradi notes that API developers can go even a step further and actually be a part of the design and user interface process.
He described occasions when other teams were designing the look of audio listening apps–sketching on paper, drawing layout and buttons. Moradi and his team listened to these ideas and thought about the necessary data back end: New or existing API services that spanned user login, ratings, location and content delivery.
In these instances, the API team provided a commitment to supply the services within the necessary timeframe, allowing them not only to serve their constituency, but to hold an important seat at the table.
“The API team is saying, ‘These are the four services that are going to be created, the new endpoints, by the time you’re ready to ship,’ and that is a beautiful place to be,” said Moradi. “At that point, you are no longer just going to the mobile team and saying, ‘We can hit your deadline.’ When it works like that, you’re where every API team should strive to be.”