In the first post of this series I made the case that API sprawl is mostly a systems problem, not a technology problem. So before I get to microservices and multi-cloud, I want to spend a post on the organizational roots, because in my experience this is where most sprawl is actually born. The APIs are just the exhaust. The engine is how teams are structured, coordinated, and standardized–or not. Sprawl is often the byproduct of decentralized development without an overarching management and governance structure, and it usually starts from good intentions: empower the teams, embrace agile, ship independently. That works beautifully right up until it doesn’t.
The first organizational root is poor lifecycle management and a lack of coordination. Without a clear process for registering, discovering, and retiring APIs, teams build new ones without knowing an equivalent already exists. Do this for a few years and you end up with dozens of overlapping APIs serving nearly identical purposes–and no one can tell you which is authoritative, which is still maintained, or which is safe to consume. I have walked into organizations where three different teams each built their own “customer” API because none of them could find the other two. That is not a failure of any one engineer. It is a failure of the connective tissue between them.
Two trends have poured fuel on this. The first is platform engineering. Giving developers self-service platforms to spin up APIs is genuinely good practice–Gartner expects 80% of large software engineering organizations to run internal platforms providing reusable services by 2026. But self-service without a shared catalog and shared standards is a sprawl accelerator. You have made it frictionless to create the twentieth redundant API. The second trend is distributed and remote work. More developers work remotely than ever, and while I am firmly in favor of it, it does mean less incidental communication and coordination. The hallway conversation where someone says “oh, we already built that” happens less often, and siloed development fills the gap. Neither of these trends is the villain. But if you adopt them without investing in discovery and standards, you are building a sprawl machine and handing everyone the keys.
The second organizational root is mergers and acquisitions, and this one is accelerating hard. Technology M&A jumped 66% year-over-year in 2025 by Morrison Foerster’s count. Every acquisition is a collision of two API landscapes, each built to different conventions, and someone now has to make them work as a cohesive whole–eliminating redundancies, reconciling overlapping services, and figuring out which of the two “payments” APIs survives. This is brutal work even when both sides had their houses in order, and they rarely do. Layer on the AI acquisition frenzy–Deloitte notes U.S. software companies spent more acquiring AI companies in 2025 than in the previous three years combined–and it gets worse, because AI agents are voracious API consumers. They pull from many APIs to retrieve, analyze, and act on data, and they hammer those APIs at real-time call frequencies. You are not just merging two API estates; you are merging them and then pointing a fleet of agents at the result.
The third organizational root, and the one I care most about, is the lack of shared standards. Without organizational guidance, teams build and maintain APIs to their own taste, and there are a lot of flavors of API. An IoT team might reach for gRPC and its real-time strengths. A team doing complex data fetching across many resources might prefer GraphQL. Even plain REST, still the most common style, can be built a dozen different ways. And I want to be clear: this variety is not the problem. It is often a strength. Teams should use the style that fits the use case. The problem is when there are no shared conventions for naming, versioning, error formats, and cataloging sitting underneath that variety.
When those shared conventions are missing, discovery and reuse collapse. If every team names things differently, versions differently, and structures endpoints differently, then finding an existing API is harder than building a new one–so teams build a new one. That is the mechanism, stated plainly: the absence of standards makes reuse more expensive than duplication, and rational engineers respond to that incentive exactly the way you would expect. Sprawl is not teams being lazy or careless. Sprawl is teams making the locally rational choice in an environment where the organization never made reuse the easier path. Every redundant API is a small verdict on your standards.
This is why I keep pushing organizations toward a shared, minimal set of standards and a common way to describe APIs–an APIs.json index of your estate, OpenAPI contracts as the default deliverable, a consistent style guide teams can lint against. Not to stamp out the healthy variety of API styles, but to put a common substrate underneath it so that a gRPC service, a GraphQL API, and a REST API are all discoverable, all named predictably, and all findable before someone decides to rebuild them. Standards are not bureaucracy here. They are the thing that makes reuse cheaper than duplication, which is the only durable way to slow sprawl at its organizational source.
In the next post I will turn to the technical roots–microservices, hybrid and multi-cloud, and the rapid release cycles that quietly multiply APIs and endpoints faster than anyone is documenting them. The organizational causes set the stage, but modern architecture is what turns a manageable trickle of new APIs into a flood.
