The Lifecycle of Application Programming Interfaces (API)

The Lifecycle of Application Programming Interfaces (API)

APIs and their Lifecycle

I wrote about application programming interfaces (APIs) earlier and described their benefit in digital strategy. To build and maintain a successful API it is not enough to only think about the technical implementation but an API needs to be embedded in a wider API program. The API program itself needs to be in line with an organisation's strategy and contribute to its objectives.

To help establishing and running successful API programs, I described the typical API lifecycle and related activities in four stages in dedicated articles:

  1. Plan/Design (main article)
  2. Build/Integrate (main article)
  3. Operate/Manage (main article)
  4. Share/Engage (main article)

The underlying thinking is influenced by agile software engineering methodologies such as Scrum, which recommend producing software incrementally and iteratively. The other influencer is the Lean Startup movement, which advises developing minimum viable products (MVP) in short cycles, testing them on the market, then learning and improving on the product. I described both these ideas in the fourth part of my “five elements of software engineering for mobile” article.

In the concrete case of an API program – with the goal to develop, publish and promote an API – this would recommend a focus on the core features of the API. Once the core features are published, an API provider should constantly review whether the API performs as envisaged and contributes to the organization’s objectives, revising, adding or adapting if necessary. This process is the same for all API scopes (public, partner, or private API).

Complementary to this, the API Evangelist Kin Lane works on a subway map analogy to visualise API lifecycles. This goes beyond my more general description of the API lifecycle and drills down into a deeper level of depth. The subway map can be created by using APIs itself, which allows API providers to create a customized map for their specific API programs. This can be a very useful vehicle to visualise and communicate the API program internally. Externally, it could be used to share lessons-learned with the community. Perhaps over time we could even identify subway map patterns that work especially well.

More details about the API Lifecycle can be here:
Practical Advice for the Stages of the API Lifecycle

I work for 3scale – delivering API Management solutions (@3scale on Twitter). My job involves educating markets about the value of APIs and how to implement effective API programs.

I also curate and comment articles about API strategy and technology for the API Magazine (@API_Mag on Twitter).

To view or add a comment, sign in

Insights from the community

Explore topics