---
published: true
layout: post
title: There Is No Single Approach or Tool For API Governance
date: 2025-04-18T09:00:00.000Z
tags:
  - Governance
  - Services
  - Tools
  - Education
  - Training
image: https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/america-immigration_dumping-ground-railroad-tracks-rocks.jpeg
---
It is always interesting to come up against the anti-education and anti-skills sentiment that often exists around the tech sector. It is a world where services and tools are valued and prioritized over skills and experience. My approach to APIs is always to try and help increase what people’s knowledge and awareness of APIs as well as how they work, so that they can tackle problems in their world. My approach to APIs is much like my approach to education in general, that we should be teaching people to learn and think for themselves, not just team them how to use specific services and tooling. 

In this environment when I demonstrate how to use a specific Spectral rule, people often say rules don’t matter, or speak to the fact that it is a Spectral rule instead of some other brand of rules, but rarely engage around the history, purpose, and outcomes when you apply the rule. This is where the learning lies. This is where you build experience with the details of doing APIs. The rule doesn’t matter, or the service and tooling you apply the rule with-—it is your awareness and understanding that matters. However, in an environment where there is a desire for a services, tooling, or now AI to just do it for you, there isn’t much appetite for discussion around the technical, business, or other details of API governance-—just an interest in checking the box that it was done.

In this techno solutions realm there is a belief and desire to convince you that there is a single approach to do API governance, when there isn’t. Sure there are plenty of common patterns and anti-patterns involved in doing API governance, but the variety you will encounter on the ground within enterprises across industries will derail even the most diagrammed and thought through solution. There is no single approach or tool to tackle API governance across the enterprise, and this is why I usually pair the phrase API governance with guidance. Common approaches and tooling can and should definitely be used to guide teams forward when producing APIs, but guidance requires deep thought around the culture of an enterprise as well as the industries they operate within. 

When you send your kids to university, do you want them to learn Microsoft Word and Powerpoint, or do you want them to learn to write and produce a coherent narrative? Do you want them do learn about Microsoft Excel and SQL Server, or do you want them to learn about spreadsheets and databases? You can see this scope creep in terms of web development—-meaning, do we learn about HTTP and HTML or do we learn about React? This vendor and technology creep exists across all areas of technology, and you can see the effects in how enterprises approach each wave of technology, but also the behavior of the services and tooling being peddled to them with each wave.

 In the end, you should always be exploring and using the latest services and tooling when it comes to API governance, but you should make sure they 1) support the latest API specifications as inputs and outputs, and 2) you have the control over services and tooling-—otherwise you will end up dependent and trapped, with your vendors governing your APIs, instead of you.