---
published: true
layout: post
title: I Do Not Believe There Is One Tool or Approach to Solve API Governance
image: https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/i-do-not-believe-there-is-one-tool-or-approach-to-solve-api-governance.png
date: 2026-06-25
author: Kin Lane
tags:
  - API Governance
  - Tooling
  - Open Standards
  - OpenAPI
  - APIs
---
I know that many in the tech world believe there is always a universal approach to doing software, and that all business processes scale. For some processes this may hold true, but when it comes to producing and consuming APIs, I just do not believe there is one tool or approach to solving API governance. There are common standards and tooling that can be applied in common ways, but enterprises operate in wildly different ways and have made very different decisions in the past that change how they do business today.

The differences begin with software choices like do they use GitHub, GitLab, or BitBucket. But then they extend into the education and training teams have had over the years, but also how open or closed an organization is, and what teams have been exposed to when it comes to the web and the API shift in the landscape. In technology we just believe that these enterprises can change behavior, adopt new technologies, and voila! they can find themselves on a better path. I guess that might be possible for some businesses, but the majority will continue to struggle with a patchwork of teams, tribes, tools, and levels of education and awareness that will make the standardization and governance of APIs challenging.

As a vendor, I know we dream of a single team adopting our services and tools, and leadership mandating the usage of our tools. But after years of watching enterprise push to replace IBM with Apigee, and now Apigee with Kong, and Postman with Bruno, I just can't help but smile at our perpetual belief that "this" tool is the one that is gonna fix this sprawling problem. I am not saying we shouldn't be selling, buying, and adopting tools to accomplish the different aspects of managing and governing our APIs. I am saying that we should be making sure they tools have APIs, and support the input and output of common artifacts and standards that help us maintain our platforms when these tools come and go. And that API governance requires a toolbox, not just a single tool.

I am guessing you have been kicking the tires on some of the new API governance tooling while you are also looking to replace some of the legacy API governance tooling that was recently acquired, or where the roadmap has slowed or maybe moved in a direction that doesn't fit what you are looking to accomplish. I encourage you to step back and look at the entirety of API governance and consider the role that OpenAPI, AsyncAPI, Arazzo, Overlays, and JSON Schema plays, as well as take the time to assess the APIs offered by your API service providers. Then take what you learn and help codify and standardize as part of the process when you are evaluating new commercial services and open-source tooling. Services and tooling will come and go, but the artifacts they consume and produce are your key to truly tackling API governance and moving in the direction you need.