API Governance Isn't Just Rule Automation

Automating API rules isn't the only thing governance is about.

Speccy, Spectral, Vacuum, Zally, you name it. There are plenty of linters and API description validators out there. Commercial, open-source, and everything in between. While being able to enforce the rules for your APIs programmatically is fine, that is not what API Governance is about. At least, that's not all. API Governance is much more than coming up with a list of rules. So, why do some people keep insisting on the rules and their tools? I think I know why. Stay with me.

---

This article is brought to you with the help of our supporter: Speakeasy.

Further expanding its best-in-class API tooling, Speakeasy now empowers teams with open standards. The platform simplifies OpenAPI Overlay adoption so you can focus on building. Click the button below to check out the playground.

---

People like power. The feeling of being the one controlling what others can or can't do is appealing to most of us. And, one of the most powerful positions to be in is the one of the gatekeeper. The one that chooses who can pass through the gate. In this case, the gate is every transition of the API lifecycle. You get to control which APIs can move from the Design to the Implementation stage. Or, which ones can get to the Deploy stage. If this is what you want, then it's natural you'll want to arm yourself with a system of rules and tools to automate their enforcement. If an API breaks any of the rules you control, you won't allow it to move forward on the lifecycle.

Power attracts people. The more power you have, the more enemies you'll have. People might want to steal your power from you. Or, they'll want to be able to bypass your rules. So, what do you do to avoid a confrontation while still owning the gatekeeping system? You show people how complicated and technically difficult it is to manage all the rules. You tell the story of how insurmountable it is to maintain all the rules. You keep showing different tools that are technically difficult to understand. In summary, you focus the communication on the rules and their tools. Not on the people, the business, and their needs.

People need empathy. API governance isn't just about rules. To me, the rules need to be a reflection of what the people and the business need to happen. As I wrote before, "The main goals of API Governance are related to consistency, standardization, security, compliance, performance, agility, and alignment with business goals." The area that has to do with the linting rules we've been discussing is consistency. But all the other areas need care. Especially—I'd argue—the more people-oriented areas of agility and business. Agility has to do with how teams can innovate on their APIs without damaging the experience of consumers. API governance can assist by providing meaningful change management. In this case, API governance can help the developers who maintain the API but also those who consume it. Another area that has to do with innovation is business. The objective, in this case, is to align the goals of the business with the way you operate your API. Here you have two levers you can use. You can reduce the operational costs, and you can also increase the revenue your API generates, even if indirectly. Even if you can't produce new revenue from your API, just reducing its operational cost goes a long way in helping your business succeed.

People love success. And, in the end, that's what API governance is about. It's not about having a bunch of linting rules and automation tools in place. It's not about all the gatekeeping and guard rails you can have. It's not about limiting what developers can do. It's not about controlling who can use your API and what they can do with it. It's about having APIs that are high-quality, aligned with the objectives of your business, and easy to maintain and integrate with. That's what API governance is.

---