The Four Horsemen of the API Apocalypse  

I was in a restaurant recently and the above photograph that was on the wall caught my eye. Four riders on scooters wearing “API” on their backs. Immediately I joked to myself that these are the “four riders” of the API Apocalypse. In biblical terms, the four horsemen refer to Pestilence, War, Famine, and Death and they bring forth the cataclysm of the apocalypse. So, for your API program, who are the four riders who could help damage or destroy your API program?

1. The Business

Do all your organization’s stakeholders understand what criteria will make your API successful? Have you aligned with the business? If you haven’t, it will run you over!

Here’s some food for thought. What is the Key Performance Indicator (KPI) for your business? Is it to establish new revenue streams? New channels to engage with customers/partners? Visibility into the “who/where/what/why” of access to your data?

Ask yourself, is your API helping address business goals or are you exposing an API for technical kicks? Do you track more than technical metrics (transactions per second, latency, etc.)? What about business metrics? Consumer churn/attrition?

2. The API

The creation of an API should not just be a Jira task. Taking this approach will propagate apocalyptic results similar to a virus:

When designing your API, you should adopt a product mindset. After all, the API is intended for use by someone else. Whether you think of it that way or not and whether you actually sell it or not, you have a product on your hands intended for use by someone else. As such, this product will have a lifecycle and success criteria. Your API should have a Product Manager assigned to help.

Reach out to your API consumers before you implement them. Are you engaged with your API ecosystem? Does your ecosystem have access to the road map for your API? In API Design—Beauty Is in the Eye of the Beholder I highlight that “API creation is the art of telling another human what one wants the system to do”—does a human understand your API?

In addition, internally within your organization, you should be seeing an explosion of APIs that can be utilized. This explosion will be seen in microservice architecture but also from existing systems that are being API enabled with a mediation layer. You should think if something doesn’t have an API, then it doesn’t exist. See mining for APIs: There’s gold in them thar hills.

3. The Developer

The next rider is the “Developer” or possibly the lack of developer; especially, if you haven’t considered developer experience and engagement. Developers have high expectations and needs; remember they’re normally trying to move fast and are engaged in agile sprints etc. Anything that slows them down or disrupts them will cause friction and lower the NPS of your API. Is it easy for a developer to onboard to your API? How quickly can they understand what the API does and find the appropriate endpoints they need? Is your documentation adequate? Is your authentication standards-based? How long do they need to wait for API key provisioning? How quickly can they move from your Developer portal and be back to their IDE using your services? Seconds? Minutes? Hours? If they struggle at any point in using your API can they get help or support quickly?

4. The Future

Welcome to the Future which you need to consider today. If your APIs are live and being consumed, what are the implications of a breaking change; or how should the API be evolved from the existing version to a newer version, etc.

If we extrapolate what is happening today into the future, would we see that the REST API market share is declining? Would your API strategy survive a visit from the Future intact? Are you prepared for event-based APIs?  Are you still REST-ing? Are you sure that REST is what your consumers are looking for? Is your API chatty?  Could GraphQL help? Is your API internal? gRPC anyone? Is your internal architecture so complex that change is difficult? Has your technical architecture been built based on resume/CV architecture rather than the needs of the business? Read about the future from David McKenna in API is dead—long live the APIs.

So, we have seen the four riders who could help damage or destroy your API program, but it’s not all doom and gloom. Just like with Coronavirus there will be a vaccine or the summer months will burn it out. There are vaccines to rid yourself of the horsemen, the most obvious vaccine is to treat your API as a product where you have business KPIs, life-cycle, packaging, UX and architecture considerations.