API Evangelist API Evangelist
Guidance
API Learnings
APIs
API Governance
API Solutions
API Discovery
API Building Blocks
API Evangelist LLC

Platforms

The underlying infrastructure and tooling on which API programs are built

The API platform is the business infrastructure that turns a collection of APIs into a coherent, governed, sustainable operation, and building one well is one of the most consequential business decisions an organization makes. Where an individual API is a single capability exposed through an interface, a platform is the whole apparatus — the tooling, the infrastructure, the processes, the governance, and the developer experience — through which an organization produces, manages, and operates APIs at scale. I’ve spent years studying what makes an API platform succeed as a business, and the recurring lesson is that the platform is a strategic asset, not just a technical one. The companies that think of their API operation as a platform — a durable, reusable foundation that the business builds on — get fundamentally different and better outcomes than those who treat each API as a one-off project.

The early platform-thinking work established the strategic frame, and I’ve returned to it throughout my career. I wrote in 2011 about three potential types of API platforms — Platform as a Service, the extension model, and the Trojan Horse — recognizing early that a platform isn’t one thing but a strategic choice about how the API operation relates to the business. The anatomy of a self-service application platform that I wrote about in 2011 laid out the structural components that a platform needs to function as a business: the developer onboarding, the access management, the documentation, the support, all integrated into a coherent whole. The deepest early insight, which I articulated in 2013, was that an API is research and development for your business model — the platform is where you learn what your business could become by watching what developers actually do with your capabilities. The platform isn’t just infrastructure; it’s a strategic instrument for understanding and extending the business.

The well-thought-out platform is distinguished from the ad-hoc one by deliberate design, and I’ve emphasized this distinction repeatedly. I wrote in 2017 about what a well-thought-out API platform looks like — one where the business model, the developer experience, the governance, the support, and the operations are all designed coherently rather than assembled piecemeal. The difference between a platform that succeeds as a business and one that struggles is usually this coherence: whether the pieces were designed to work together in service of a clear strategy, or whether they accreted over time without intention. A public API platform can be a genuine competitive advantage, as I argued in 2018 — but only if it’s built deliberately as a platform, with the strategic clarity to know why it exists, who it serves, and how it sustains itself. The platform is a business that has to be designed as a business.

The platform-versus-management distinction is a business clarification I’ve found important, and it cuts against vendor framing. I wrote in 2023 about the API platform versus full-lifecycle API management — because there’s a real difference between buying a vendor’s bundled “full lifecycle” product and building a genuine platform tailored to your organization. The vendor’s full-lifecycle management suite is a product you purchase; the platform is something you build, often from a combination of tools, that’s specific to your organization’s needs, governance, and strategy. Properly defining your API platform, which I wrote about in 2024, is the strategic work of deciding what your platform actually is — what it includes, what it standardizes, what it leaves to teams — rather than just adopting a vendor’s definition. Having a clear API vendor strategy, which I also wrote about in 2024, is part of this: the platform is bigger than any single vendor’s product, and treating it as a strategic asset means not letting vendor lock-in define your platform for you.

The future-oriented platform is built for durability and change, which is the business challenge that matters most over time. I wrote in 2021 about building an API platform that will support the future — because the platform is a long-term investment, and the platforms that succeed are the ones designed to evolve rather than the ones optimized for a single moment. A platform built around a specific vendor, a specific architecture, or a specific moment in the technology cycle becomes a liability when things change. A platform built around durable principles — clear governance, machine-readable definitions, good developer experience, vendor-flexible architecture — adapts as the technology and the business evolve. The platform is where the organization’s API strategy is made durable, and building it for the future rather than for the present is the strategic discipline that separates platforms that last from platforms that have to be rebuilt every few years.

The honest assessment of the enterprise platform business is that it’s harder and more strategic than most organizations appreciate, and I’ve tracked that reality closely. The current state of the business of enterprise APIs, which I wrote about in 2025, is one where the platform is increasingly recognized as essential but still frequently under-resourced and under-strategized. The internal developer platform movement reflects a broader recognition that the platform — the reusable foundation that teams build on — is a genuine business asset worth investing in. The throughline across fifteen years of platform thinking is that the API platform is the business infrastructure that makes APIs sustainable and strategic rather than scattered and tactical. The companies that build genuine platforms — coherent, deliberate, durable, vendor-flexible foundations for producing and operating APIs — turn their API operation into a competitive advantage and a strategic asset. The ones that treat APIs as a series of disconnected projects, with no platform underneath, end up with sprawl, inconsistency, and a perpetual sense of starting over. The platform is the difference between an API operation that compounds in value over time and one that fragments. Building it well, as a business and not just as technical infrastructure, is one of the most important and most underappreciated strategic decisions in the entire API economy.

References