#Issue 69

I once ran an API governance assessment for a client who knew they had issues with their APIs. The assessment revealed several problems with API discovery, security, and testing. Most pressing was how hard APIs were for developers to find. This meant poor reuse or wasted time trying to find which API they needed and how to integrate with it. In one case, a developer built an API only to discover months later that a perfectly good existing API already provided the data he needed.

This case is typical. In large API programmes, API sprawl, poor discovery, unintended breaking changes, high integration lead times, inconsistent design, low reuse, and poor developer experience are the norm. And with AI agents now driving an explosion of new APIs, these problems are accelerating.

The business cost of poor API governance is real: higher operational spend on fixing API issues or on API tooling and infrastructure the organisation does not need, slower time to market, eroded trust with API consumers, missed monetisation and partnership opportunities, and heightened security and privacy risks. Poor API governance at scale is very expensive.

My client was looking for an API catalogue solution they could use. But my assessment revealed a deeper issue. The reason they didn’t have an API catalogue solution in the first place was that no one was in charge of API governance. This is symptomatic of a wider issue – most conversations about API governance focus on tooling such as linters, gateways, and developer portals. But these symptoms point to something deeper: a poor operating model for governing APIs.

An operating model for governance describes the roles, processes, key metrics, policies, and feedback loops (not just the technology) involved in delivering and managing APIs. When organisations narrowly focus on tooling rather than this holistic picture, the same problems keep recurring. What's needed is not another methodology, but a way for organisations to honestly assess their governance posture.

That's exactly what I've built.

I've just published version 1.0 of the IGT-API Framework. It is an outcome-based framework that helps organisations improve their API governance operating model. It's not a governance methodology. It's a diagnostic lens: it maps business value to outcomes, outcomes to measures, measures to capabilities, and capabilities to enablers, so you can see exactly where your governance is breaking and why.

Because of this launch, I'm refocusing this newsletter entirely on the core problem the framework addresses: the operating model side of API governance.

If you've been following my earlier series on API design methodologies, that series is wrapping up. I won’t be continuing with it. Everything from here goes deeper into operating models.

Each week, you'll receive the newsletter in one of three formats:

Deep Dives: Original analysis grounded in the IGT-API framework. This will include capability breakdowns, maturity patterns, and what ‘good’ actually looks like at scale.

Curated Briefings: My commentary on the most relevant links and developments in the API governance space.

From the Field: Practitioner observations from real governance programmes. What's working and what isn't.

Before the next issue lands, here is one practical way to review your API governance operating model.

This is a structured canvas for mapping how governance actually works across eight dimensions: decision rights, API classification, lifecycle management, policies, tooling, and more. It's designed to surface the difference between what's documented and what's practised, which is where most governance breaks down. Download here.

I am running a research project called ‘Beyond the Linter’. The project explores how organisations actually run the people-and-process side of API governance. I am looking for people who work in API governance to take part in the study. Would you be willing to take part? See the full details here.

Book a 30-minute conversation with me.

The Ikenna Consulting Newsletter delivers weekly insights on API governance operating models, helping engineering leaders understand why governance is an operating model problem, not a tooling problem.