API Lifecycle Management

You Are API-First

39views

I am really struggling on a number of calls lately with people at companies who are doing really interesting things with APIs, having fully committed themselves to prioritizing APIs across the organization, but are reluctant to say they are API-first publicly as part of some storytelling. Out of some insecurity around the shortcomings that exist across operations, and an inability to convince every team to perfectly follow some perceived API-first process, people are nervous about agreeing to declare we are API-first. Despite having invested years into prioritizing APIs across operations, and having become more proficient in delivering APIs across a known API lifecycle. I struggle with reconciling people’s desire to be API-first with their reluctance to declare they are API-first, and I’d like to understand this better, then refine how I talk about API-first to help address more in the future.

First, what is API-first. I am very opinionated here. API-first is simply the prioritization of producing and consuming APIs over the application of digital resources and capabilities. API design first is API-first. API code first is API-first. API-first is not every single team and API within your organization following some spiritual path of API perfection and enlightenment. Being API-first means that as an organization you have made the commitment to prioritize APIs over the application of digital resources and capabilities. It means you are committed to doing the work to invest in your API strategy, follow and known API lifecycle, and bring the necessary reliability, observability, and governance to your operations. API-first is a journey, and not a destination. If you view API-first as some sort of complete state of API utopia, you will never get there. If you are committed to prioritizing APIs, and doing the work as an organization, then you are API-first.

I had three separate conversations around this yesterday, beginning with a live stream on the subject, where there was reluctance around declaring that Postman was API-first, and ending with another discussion with engineering leadership from a top tier technology company who is known for API-first leadership, who described themselves as working towards API-first, and that it was a goal. I confidently declare Postman as API-first. I consider the top-tier tech company I spoke with solidly API-first. API-first does not mean complete. It is not a finished state. There is no API-first utopia. There is just an API-first world where you begin realizing the benefits of prioritizing APIs, something that only gets better as you evolving along your journey. Ultimately I feel like reluctance to admit you are API-first is less about prioritizing APIs, and more dwelling on our operations being anything less than perfect. We have such a high bar in our head when it comes to technological perfection, that we find it difficult to accept our very human imperfection.

I can’t help but feel like this is all tangled up with our belief in technology, and our lack of belief in people. I know that my failure around this involves me not effectively explaining to people what API-first means, and what it is. In my storytelling, I tend to point to the outcomes of API-first, using them as a carrot, but ultimately setting the precedent that API-first is a destination. I think I want to focus on the human aspects of this more than the technical elements. Better articulate the small incremental things you can do to strengthen your commitment to doing APIs, and help better draw the line between what is API-last and what is API-first. I want to help folks not feel so helpless, and feel that API-first is always just out of reach of their teams. I want the believers to feel like they are confidently API-first if they have made the commitment to prioritizing APIs, even if all APIs still don’t follow the enlightened path. I need to work my way through many different ways of helping everyone see that they are API-first, and it is something to celebrate as we perpetually work to refine how we deliver APIs as an organization.

This article originally appeared here.

Kin Lane
Kin Lane is a writer, storyteller, and recovering technologists. Kin is the Chief Evangelist at Postman, and is helping share the story of how Postman is the next generation of API development environment (ADE), while also continuing to tell API stories on API Evangelist about what is happening across the API sector.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture