One of the biggest benefits from the evolution of the API management over the last decade was the visibility and awareness it gave us around who is using our APIs. While this is something that is playing out over and over as each mainstream company wakes up to the potential of APIs. As I get back to working with companies on their API strategy I’m beginning to realize that a similar type of awareness is beginning to play out internally, but instead of developing an awareness of who is consuming APIs, it is more about gaining visibility into who is building APIs across distributed groups and teams. Helping API leadership within organizations get a better handle on their overall API lifecycle, and begin to establish more meaningful metrics about how valuable API resources are being delivered.
Most of the organizations that I go into do not possess any formal strategy for how APIs are brought to life. Some have API catalogs or directories where you can find APIs, but they are rarely complete, and might provide the basics of API discoverability, but provide little visibility into the teams behind them. Most of the time, APIs do not make it into the catalog until the API makes its way into a production state, leaving it pretty impossible to discover APIs that are being planned, designed, or in the process of being developed, and there isn’t any way to understand which teams are planning APIs, or beginning to work on the development of new resources. Leaving API leadership working to paint a more complete picture of what teams are working on, what processes are I place for developing APIs, and how efficient groups are when it comes to delivering critical resources.
Some of the folks I am talking to are relying on the tooling they’ve adopted to provide them with some of the metrics they require to gain more visibility into how teams operate (ie. GitHub, Postman, etc.). Most API providers have invested in API management infrastructure, which provides a handful of ways to understand what is being developed, depending on how you are using it, but most of these metrics are externally focused on who is consuming these resources. Next, the companies I’m talking with depend on a variety of other developer tools to piece together a fragmented picture of how things are coming together across the earlier phases of the API lifecycle. Similar to 2008 through 2012 with he lack of awareness providers had into who was using their APIs, 2018 through 2022 will be all about gaining awareness of who is building your APIs.
How do you map out your organizational structure as it pertains to API development? How do you keep track of the teams who are planning, defining, designing, and developing your APIs? Do you have any formal process for understand what is being built, and addressing the redundancy of resources and schema being developed? If you have any formal approach, do you have any metrics on team performance, or the speed at which APIs move through the development process? As you can tell, I have a lot of questions regarding our lack of visibility into how APIs are brought to life. I’m looking to understand how companies are investing in being more organized and efficient in how APIs are brought to life. I will be asking folks these questions while at API World in San Jose next week, pushing on API providers to be honest about the visibility they have into what their teams are up to when it comes to delivering API infrastructure.
