The API landscape is the full territory that governance has to cover, and mapping it is the precondition for everything else. Before you can govern your APIs, you have to know what you have — where the APIs are, who owns them, what they do, how they’re built, what teams are involved, and what operational reality surrounds them. This is the landscape, and the uncomfortable truth I’ve stated many times is that most organizations have no idea what their landscape actually looks like. They can’t see their own APIs. And you cannot govern, secure, rationalize, or improve a landscape you can’t see. Landscape mapping — the unglamorous, foundational work of surveying and documenting the API territory — is where API governance begins, because governance applied to an unmapped landscape is governance applied to a fantasy.
The “it’s Monday morning, do you know where all your APIs are?” question is the one I keep asking, because the answer reveals everything. I wrote it as a post title in 2024, and the reason it lands is that for almost every organization, the honest answer is no. Large enterprises routinely have hundreds or thousands of APIs scattered across teams, built over years, undocumented, unowned, half-forgotten — and nobody has a complete picture. I’ve framed my own work, only half-jokingly, as being just an API surveyor and assessor — because the survey work, the patient mapping of what exists, is so foundational and so neglected. You have to know where all your APIs are before you can deliver on governance, as I wrote in 2018, and that knowing is harder than it sounds. The landscape is the answer to the Monday-morning question, and producing that answer is the first real act of governance.
The landscape is more than just a list of APIs, which is the deeper insight I’ve developed about it. When I broke down where to begin with governance by mapping the landscape, I mapped multiple landscapes: the API landscape itself, the operational landscape that surrounds the APIs, the people landscape of who builds and owns them, the policy landscape of what rules apply, the business landscape, the engineering platform landscape, and the experience landscape. The full landscape isn’t just the APIs — it’s the whole socio-technical territory: the artifacts, the teams, the tools, the policies, the business context, and the human relationships. Governance has to cover all of it, because an API doesn’t exist in isolation; it exists in an organizational context, built by people, using platforms, under policies, serving business goals. Mapping the landscape means mapping that whole context, not just inventorying endpoints.
The visibility problem is what makes landscape mapping genuinely hard, and it’s why so much governance fails at the start. APIs proliferate faster than anyone documents them. Teams build APIs without registering them centrally. Acquisitions bring in whole API estates nobody understands. Shadow APIs run without anyone in governance knowing they exist. Making the API landscape visible and tangible, as I wrote about, is real work that requires real investment — scanning code repositories, searching for evidence of APIs, aggregating definitions, building catalogs, and keeping all of it current as the landscape constantly shifts. The landscape is not static; it changes every day as teams ship new APIs and retire old ones. So landscape mapping isn’t a one-time project but an ongoing discipline of maintaining an accurate picture of a moving target. The organizations that treat it as a one-time inventory discover their map is stale within months.
The humbling honest truth I’ve had to confront is that nobody can fully know the entire landscape, and governance has to be designed around that limit. I wrote in 2024 that almost nobody will care about, or be able to comprehend, the entire API landscape — it’s too big, too dynamic, too distributed for any single person or system to hold completely. This is a real constraint with real governance implications. If complete, omniscient knowledge of the landscape is impossible, then governance can’t depend on it. Instead, governance has to work with partial, contextual, continuously-refreshed views — giving each team visibility into the part of the landscape relevant to them, rather than pretending anyone can see the whole thing. The 2024 reframe that API sprawl is good, embrace it, was my way of making peace with this: you’re not going to eliminate the sprawl or fully map it, so design your governance to work with a sprawling, partially-known landscape rather than fighting for an impossible total visibility.
The landscape connects directly to discovery, to evidence, and to the whole epistemology of governance, which is why it’s so central. Mapping the landscape is fundamentally a discovery problem — finding the APIs — and a knowledge problem — knowing what’s true about them. The question of whether you or a vendor will complete the map of your API resources and capabilities, which I raised in 2025, is a real strategic decision, because the mapping can be done internally or outsourced, manually or with tooling, and the choice shapes how current and complete the map stays. The landscape is the governance-relevant view of everything discovery surfaces and everything the organization knows about its own APIs. When I tie landscape mapping to governance, I’m making the argument that governance is downstream of visibility: you map the landscape, then you can govern it. Skip the mapping, and your governance rules apply to an imaginary set of well-behaved APIs while the real, messy, sprawling landscape goes ungoverned. The landscape is the ground truth that governance has to be built on. Map it honestly — including its sprawl, its gaps, and the limits of what you can know — and governance has something real to work with. Pretend you already know your landscape, and your governance is theater performed for an audience of APIs you can’t actually see.
References
- API Evangelism Strategy: Landscape Analysis
- You Have To Know Where All Your APIs Are Before You Can Deliver On API Governance
- Mapping Out The API Landscape
- Conducting An API Landscape Analysis
- It Is Monday Morning, Do You Know Where All Of Your APIs Are
- Almost Nobody Will Care About The Entire API Landscape
- API Sprawl Is Good, Embrace It
- Just An API Surveyor And Assessor
- Where Do I Begin With API Governance: Mapping The API Landscape
- Will You Or A Vendor Complete The Map Of Your API Resources And Capabilities
