It’s easy to think of large organizations and assume there’s one person overseeing all activity relating to, say, APIs or cloud services. In fact, that’s rarely the case. While the stability and financial backing offered by big companies is invaluable, it can also lead to tangled webs.

That’s definitely the impression we got from Nathan Brock and Rafal Jachimczyk, who we interviewed previously on the blog. They are principal and senior software engineers in BBC’s API Management team. “Every day, in our cloud platform alone, we see 1200 daily deployments,” says Nathan.

When they joined us at our 2018 Platform Summit, they talked about how the BBC went from a scattered approach to API intelligence and took it to a distributed solution that supports various autonomous teams. Along the way, they shared with us plenty of invaluable lessons for companies of any size looking to scale their API(s).

Why API Management?

For those outside of the UK, and maybe even some of those within it, it’s difficult to overstate the size of the BBC. With tens of thousands of staff members and a wide range of services that includes Homepage, News, Radio, Sports, Bitesize, iPlayer and so on, this company is huge.

Nathan illustrates this nicely when he says that the BBC’s video archive grows, more or less, “at a rate of 10TB per day.” With so many services and so much data, we can instantly surmise that the role of API maintainer must be significantly larger than it would be at a smaller company.

For this reason, Nathan says, “API management at the BBC is less about governance and more about support.” Still, Rafal points out, “it’s chaos when everybody builds in silos.” That’s why there was a clear need for a robust API management solution that offers autonomy and flexibility.

Rafal identifies the key tenets of API management at the BBC as follows:

• Discover
• Onboard
• Identify
• Report

Whatever a company’s size, it’s always a good idea to have these concepts at the center of your API philosophy. API developers must be able to discover the API, learn its methods and parameters, identify use cases, and continually verify it behaves properly.

Don’t (Always) Be Afraid Of Off-The-Shelf Solutions

Rafal describes how the BBC used an off-the-shelf API management solution at the beginning of their efforts to unify their approach to APIs, with 2.2 billion transactions a week across 70+ platform APIs.

Some advantages they found in this solution were:

• Simple to set up and roll out – only a few DNS changes
• Limited service impact
• Organization-level analytics
• Simple onboarding process

Unfortunately, Rafal says that given “the size of the organization, things started to deteriorate.” One such example of this is that a misconfigured proxy on the API management layer would lead to outages because of the single point of failure.

In other words, as Rafal puts it, “when it goes wrong, it goes wrong for everybody.” When you’re only dealing with one API or a single designated team, that might not be such a big problem. When you’re dealing with a large number of APIs and a large number of different teams, however, it can be a killer.

It was quickly becoming clear that, for the BBC, an off-the-shelf solution wasn’t going to cut it.

Decentralizing API Management

The answer, in Nathan’s mind, was an independently scalable solution. Plus, he says, they wanted to “give that control back to the teams that know their product best.” After evaluating their needs, the team discovered their management platform must be:

• Reliant
• Configurable
• Extensible
• Cost-effective

Ultimately that meant an entirely new architectural model, with a management solution that sits in front of each of the API services. “Nothing new to you today,” Nathan points out, “but something that was very new 2 or 3 years ago.”

The process didn’t, however, end there. We’ve already seen evidence above to confirm Nathan’s assertion that “the BBC is one BBC, but behind the scenes, it is nearly multiple organizations.”

That’s why it was so important, as we’ve argued before, for the BBC to create a comprehensive developer portal that was integrated with processes and existing authentication.

With a homepage that highlights open source software developed by the BBC, the organisations R&D, their Global Experience Language design framework, and blog posts on technology and creativity within the BBC, it appears (at least as far as us non-staff members can see!) that they’ve done a nice job of doing just that.

Back to the Future

As Nathan says early on in this talk, “the BBC built one of the first video-on-demand platforms in the world.” In other words, it’s an organization that’s built on innovation and embracing new technology. He later describes the tumultuous evolution of API management at the BBC as “pushing boundaries.”

Rafal later comments that “we want to stay relevant, and if we’d carried on with the provided solution maybe we wouldn’t have all of this knowledge.” He also talks about the move away from API keys for identification and the creation of distinct user identities (that differentiate between software and human users), saying that this wouldn’t have been possible had they carried on using an off-the-shelf product.

But let’s highlight an important distinction before we wrap things up: your organization is (probably…) not as large or dense as the BBC. There are plenty of excellent API management solutions that perform well for small to medium organizations.

As for what the future holds, Nathan and Rafal both express their desires to decentralize further. Going forward, the custom API management solution they’ve worked on will be at the core of that. Nathan sums up the BBC’s mindset nicely when he says that “when you’re building something, you’re learning. Using something will only get [us] so far. We think, and hope, that we’re evolving in the right direction.”