How do you start an API Program?
When it comes to APIs, we generally hear quite a bit about the success of a company’s API, but how do you get there? How do you kick off an API program? We don’t often hear about the inception of the journey and how you get started with an API program.
In this post we’ll learn about…
Getting started with an API program
An organic program
Before a concerted effort is made to formalize an API program, generally there is already an organic API program in place which is creating a number of business issues that is the driving need for a more formalized program.
These business issues can be many and varied, but generally I’ve seen it’s related to scale; the business is out-growing it current way of managing APIs, the increasing number of APIs being produced is causing too much tech debt, or even the spaghetti of back-end systems and ways of integrating are getting out of control.
These underlying issues build to the extent they become a priority for the business to solve in order to keep growing, become more efficient and solve a number of other challenges (e.g. improving the security around it’s data in a more holistic fashion).
All in all the organic program has worked until now, but it’s had it’s day and something needs to change.
The flagship moment
From my experience, the API programs that have been successfully implemented use a flagship moment in the company. Generally it’s around the launch of a new product and more often than not it is providing an API to the public (or external partner community), where that API is a product in and of itself and is pretty central to the product that is being launched.
This is important, as it gets the business behind the idea of an API program - without a good API program our product is on shaky ground, a good program will provide a solid foundation for building and operating a high-quality product.
So the inception for successfully implementing a formalized API program within a business generally has these ingredients;
Business imperative - There is a business imperative to replace the existing organic API program with a more formalized approach as it will solve significant business challenges, typically issues related to scale.
A funded business case - There is a funded external product that will be built, and API is a centerpiece of making that product a success (in fact the API product may be the whole product itself).
Executive support - Senior stakeholders in the business agrees that doing APIs better in a more formalized manner is a priority for the business.
What components make up an initial API program?
What components are needed for an API program to be successful is a key question, but the good news is the answer is generally the same no matter what business you’re in. Depending on your company’s budget and the number of APIs in the company, numerous components may be required for a more efficient and scalable API program, however I’ll only cover what I expect to be the minimum components required for the first iteration of a more formalized API Program. This is from my experience in seeing these programs implemented in a number of businesses.
Here are the 6 core items that should be part of any API program:
Release Management Processes - These are your API management practices, including how APIs are developed, pushed into higher environments, what and how they are tested, how the development of APIs is governed and operational processes. Essentially the end-to-end lifecycle processes for API. These processes should be as automated (and self-serve by API developers) as possible and tie neatly into the CICD tools, API Platform and Developer Portal.
CICD Tools - Working hand-in-hand with your release management processes and the environments you have set-up on your API platform, the CICD tools should allow for the autonomous development of APIs by developers, the application of API standards and governance around the release of APIs. Applying the right tools in the right way should optimize the velocity of your releases, reduce technical debt, ensure high-quality APIs are produced that adhere to your standards.
API Standards - APIs produced by your company should all follow the same standards, formatted the same way and allow developers to intuitively understand how your APIs work. New roads do not have to be paved here, as general standards already exist on how an API should look and how it should respond. All your APIs should follow a pattern, and should accept and respond with a standardised data model. Your intent is to delight developers and reduce the effort in using your APIs. These standards need to be enforced through your Release Management processes and CICD tools.
Strategic API Platform - choosing the right platform and ensuring it is the only platform your APIs are released on underpins the management of all your APIs which are part of the the API program. It helps control the supply (the back-ends), development (API developers) and demand (the front-end APIs) sides of your API program. Importantly it is the main security, experience and business metric layer for your APIs.
Developer Portal - Part of the API platforms, the developer portal is a dedicated interface for API users to discover, learn, use and get support for your API products. Without a developer portal your APIs don’t exist.
API Team (roles and responsibilities) - Formalizing the management of the API program with existing (or new) members of your business is important to ensure the ongoing success of the program. An API program is like a garden: it needs constant weeding, and curating to make sure it runs smoothly. An API team (whether dedicated or virtual) that is focused on ensuring the success of the APIs, who look after API users as real customers and take an API-as-a-product mindset will ensure the best success for a business’s API program.