Ever wondered how business looks on APIs?

This year, I visited the APIDays in Zurich to find out. I’m a newcomer to the API Mindset for IT and Business - following are a couple of key principles I picked up at the event.

API-as-a-Product

A very hot topic, and very prevalent in the community.

This is a bit of a mindset shift. The idea is that we should not be viewing APIs as a technical tool to bridge IT systems, but rather as way to offer value to our clients – much like a product does. In this way, an API is a product for developers.

Adopting this mindset means that when building an API, a business has to acquire a customer-centric point of view, and therefore consider the client’s needs before developing the product. This may sound obvious but it stands in contrast to the “traditional” approach that many organizations take when building APIs, which, shaped by company-centric thinking, more closely resembles a “repurposing” of company assets to offer as an API.

For more details, have a look at my friend Amancio’s blog.

Externalizability

Another point that has been made quite a few times, is that organization-internal APIs should be built from the ground up to be externalizable, i.e. publishable at any time.

Despite having no such plans, this practice offers useful benefits. For one, planning to go public some day encourages developers to come up with a solid design, particularly in regards to interfaces & versioning, documentation, security, and scalability.

Another benefit is the customer-centric point of view. You wouldn’t publish an API solving some bizarre and unique edge case of a problem, would you? This mindset forces you to reformulate the value proposition of your service, ultimately increasing its reusability.

How to monetize APIs

The important point to realize here is that typically you don’t make money by charging for API use – that is in fact a common, but short sighted view.

To understand why in many cases good business models look very different, we need to dig deeper and consider all three parties concerned. We have the API provider, who develops an API, the API consumer, who develops an application using the API, and finally, we have the end user of said application. Whatever business strategy you pick, the principle is that it ultimately, it should deliver value to all three!

This also means that the API provider doesn’t have to be the one who gets paid – he might be paying other parties to consume the API, or it might be free of charge for that matter.

Let’s have a look at a couple of examples.

Log-in-with-facebook button and company
Log-in-with-facebook button and company
  • Social media log-ins are free web APIs. The end user gets a simple log-in option, the API consumer gets a higher log-in rate, and the API provider gets end user data & metrics. Therefore everyone profits. Well, in some way or another.
  • Google AdSense: API consumers get paid to show ads via the API.
  • Content acquisition on YouTube: YouTube content can be embedded on third-party websites via API. This leads users back to the platform, where this traffic can be monetized via ads.

John Musser, founder of ProgrammableWeb, categorizes API business models into a taxonomy of Free, Developer Pays, Developer Gets Paid, and Indirect. See more in his slides, or in this White Paper.

"API monetization"
"API monetization"

Conway’s Law

Any organization that designs a system […] will inevitably produce a design whose structure is a copy of the organization’s communication structure.

– Melvin Edward Conway

One implication of this hypothesis is that siloed organizations, with traditional mindsets, a strong focus on hierarchy, and with poor cross-functional team communication, inevitably design tightly coupled monolithic codebases.

From my (arguably short) glimpse into the industry so far, I’d say that in this sense this old quote is still very much relevant today. Everyone wants an agile IT and loosely-coupled, focused, and lightweight microservices – yet many organizations fail to transform and are stuck with tedious, rigid and expensive legacy systems, held back by traditional thinking, rigid hierarchies, isolated teams, and an unwillingness to embrace change.

Conway’s law teaches us that this challenge has to be solved first: an agile organization is the ground an agile IT is built upon. I like this article showing how efficient cross-team interaction might look like.

Eat your own dogfood

A very simple principle: wherever possible, use your products yourself!

This includes public APIs to your applications. Do not develop an independant app and a public API that provide the same underlying value or asset. Be your own customer. Build the app such that it consumes the API. Eat your own dogfood.

The benefits of this approach include:

  • you show confidence in your own products,
  • and it creates a tighter feedback loop than the one that passes via your customers.

Bonus: the Bezos mandate

VERY popular at the API Days. At least 4 times it has been pointed out to me that Amazon applies many of these principles, implying that they contributed to the company’s success. Check out this email from Jeff Bezos from 2002:

All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces.

There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Anyone who doesn’t do this will be fired.

Thank you; have a nice day!

Bezos ain’t messing around!

I thought it was very interesting to see what the business-side view on APIs looks like, and why business people nowadays have to learn what they are and how to use them. Do you miss an important point in my summary? Any disagreements? Let me know in the comments below!