Many companies have invested in an API gateway, an integration platform, a developer portal and a security stack. And yet their API landscape is still hard to manage. Sound familiar?
- Different teams follow different standards.
- Nobody is quite sure who owns a given API.
- Some APIs are documented, others exist only in someone’s head.
- Authentication differs from one system to the next.
- Changes are hard to coordinate, so consumers get surprised.
- Partners receive inconsistent interfaces.
Over time the organization also becomes dependent on specific products, vendors and a handful of experts.
The natural reaction is to look for a better API Management platform. In my experience, that rarely fixes it. A platform is a tool; what is missing is an agreed way of working with it. That is what an API Operating Model is.
Why you need one
Nobody designs an API landscape on purpose. It grows. One team introduces an API gateway. Another builds its own authentication. A third creates a partner integration with yet another technology. A new cloud platform brings its own API management tool, while a legacy system keeps exposing APIs directly.
After a few years you have several gateways, several ways to log in, and no single picture of what exists.
Technically, everything may still work. Operationally, the costs start to add up:
- Unclear ownership. Nobody knows who is ultimately responsible for an API.
- Inconsistent security. OAuth 2.0 in one place, API keys, basic authentication or home-made schemes in another.
- Duplicated functionality. Different teams build APIs for the same business capability.
- Poor discoverability. Developers cannot find out which APIs already exist.
- Inconsistent documentation. Some APIs have a proper OpenAPI specification; others exist only in source code and tribal knowledge.
- No lifecycle management. APIs are easy to launch and rarely retired.
- Breaking changes. Consumers find out about a change after it is deployed.
- Vendor dependency. Policies and integration logic become tied to one product.
- Dependency on individuals. Only a few people understand how it all really works.
At this point another tool does not solve the problem. The organization needs a common way of working.
What an API Operating Model is
An API Operating Model answers one practical question: how do we build, secure, publish and run APIs consistently across the whole organization? I find it useful to describe it with five elements, read from top to bottom:
- Business objectives: why you invest in APIs at all.
- Governance: who decides and who owns what, including organization and roles.
- Capabilities: what the organization must be able to do, such as design, secure, publish and retire APIs.
- Technology: the platforms and standards that support those capabilities.
- KPIs: how you know the model is working.
API Operating Model · 5 layers, 1 feedback loop
Each layer follows from the one above it, and the KPIs feed back into the objectives.
The order matters. Technology comes fourth, not first.
1. Business objectives
The first question should not be „Which API gateway should we buy?“ It should be „Why are we investing in API Management?“
Organizations have very different answers:
- Internal integration: teams reuse existing capabilities instead of building point-to-point connections.
- Partner ecosystem: selected APIs are exposed to partners in a controlled, scalable way.
- Digital channels: web and mobile apps get standardized access to backend capabilities.
- Modernization: legacy systems are exposed through stable APIs while the systems behind them are gradually replaced.
- Security and governance: authentication, authorization and traffic policies are controlled centrally.
- API products: APIs are treated as products used by external developers or partners.
Different objectives lead to different models. A company focused on internal integration does not need the same developer portal and product management as one building a large partner ecosystem. So derive the operating model from your business objectives, not from the feature list of a product.
2. Governance
Governance is about decisions and ownership. Done well, it is light: it gives teams clear rules and then gets out of their way.
For most organizations, the model that works best is federated. A central API platform team sets the guardrails; the domain teams keep ownership of their APIs.
The central platform team provides:
- standards and policies (naming, versioning, error handling, documentation);
- the common platform, tooling and monitoring;
- security guardrails;
- the developer portal;
- the governance framework itself, including reviews.
The domain teams stay responsible for their APIs:
- business meaning and API contracts;
- implementation and lifecycle;
- consumer requirements;
- business-level support.
The result is a simple rule: the center decides how APIs are built and run, the domains decide what they offer. Every API has a named owner, and every owner knows which rules apply.
3. Capabilities
Capabilities are the things the organization must be able to do reliably. The most important one is a common API lifecycle. Every API, whoever builds it, goes through the same stages:
- Idea: someone identifies a need for a new API.
- Business requirement: the need and its consumers are clarified; check whether a suitable API already exists.
- API design: the contract is designed first, in an OpenAPI specification, following the common standards.
- Architecture and security review: a short check against the guardrails. Proportionate to risk, not a bureaucratic gate.
- Development: the API is implemented against the agreed contract.
- Testing: functional, security and contract tests.
- Publication: the API is registered in the catalog and documented in the portal so others can find it.
- Operation: monitoring, support and incident handling by the owning team.
- Versioning: changes are managed so that consumers are not broken unexpectedly.
- Deprecation: consumers are told in advance, with a clear timeline.
- Retirement: the API is switched off and removed from the catalog.
Other capabilities worth defining: an API catalog, API security, consumer onboarding, monitoring and support, and documentation standards.
4. Technology
Technology is where the model becomes real: gateway, identity and access management, developer portal, API catalog, monitoring. But here it plays a supporting role. It implements the capabilities above; it does not define them.
Security by API class
Not every API needs the same protection. Define a few API classes, such as internal, partner and external, with low-risk and high-risk variants, and give each class a predefined set of controls. The goal is not one security architecture for everything. The goal is consistent, understandable patterns.
| API type | Typical controls |
| Internal | OAuth 2.0 / OIDC, network controls, monitoring |
| Partner | OAuth 2.0 / OIDC, client registration, quotas, audit |
| External | Strong authentication, authorization, threat protection, rate limiting, monitoring |
| Sensitive | Additional controls, detailed logging, stricter approval |
Choosing a platform, without lock-in
If the starting point is „we need an API Management platform“, the discussion quickly becomes Vendor A vs Vendor B, cloud vs on-premises, gateway features, licensing, Kubernetes, analytics, AI features. These matter, but they are not the first questions. A better sequence:
Business objectives → operating model → required capabilities → architecture principles → technical requirements → platform evaluation → implementation
That changes the conversation. Instead of „What can Product X do?“ you ask „Which solution best supports the way we actually need to work?“ An API platform should fit your architecture and operating model, not force you into the vendor’s way of working.
Open standards, portable API specifications and a clear separation between API contracts, policies and platform-specific implementation keep your options open for years.
5. KPIs
The goal is not to create hundreds of KPIs. The goal is to see whether the operating model produces the improvements you expected. A handful of measures is enough, chosen to match your business objectives. For example:
- share of APIs with a named owner and an OpenAPI specification;
- share of APIs registered in the catalog;
- share of APIs compliant with the security standard for their class;
- time from idea to first published API version;
- number of breaking changes without prior notice;
- reuse: how many consumers use each API;
- time to onboard a new partner or consumer.
From model to practice
A good operating model is more than a diagram of roles and processes. It has to work in your organization, with your architecture, your teams and your objectives.
I provide independent assessments of API Management operating models and target architectures. I help organizations find the gaps in ownership, governance, security, API lifecycle and integration processes, and decide what to do about them.
Typical outcomes:
- an assessment of your current operating model and its key gaps;
- recommendations for governance, ownership and lifecycle processes;
- alignment between IAM, API Management, integration architecture and organizational responsibilities;
- a prioritized roadmap for implementation.
The scope is tailored to you, without unnecessary complexity and without dependence on a specific vendor.
Interested in assessing your API Management setup? Let’s talk about your current challenges and identify the most valuable next steps.