Editor’s note: Written in 2013. Revisited now because, while technology has changed, the problems stayed the same.*
Most large systems do not fall short of expectations because the technology was wrong. It is because the teams assumed everything belonged to one system.
That assumption still shows up today, in architecture diagrams, platform roadmaps, and “integration plans” that promise coherence at scale. What they usually deliver is fragility.
When working in large distributed systems, it is better to aim for interoperability than integration. The difference sounds small. It is not.
Integration for a single system
The Merriam-Webster Online Dictionary defines integration as:
…the combining and coordinating of separate parts or elements into a unified whole…
This definition makes sense when you actually have a single system.
Unfortunately, many large distributed systems are incorrectly designed as if they were one. Internal platforms spanning teams, regions, and years are treated as a “whole system,” even when nothing about their operation supports that fiction.
Bad idea.
These “whole systems” are really closed systems, giant mono-repo blobs pretending to be loosely-coupled. Teams attempt to enforce shared models, shared assumptions, and shared timelines across components that were built at different times, by different people, for different reasons.
At small scale, this can appear to work. At real scale, it does not.
Why do teams fall into this trap? Mostly because it feels easier. Treating everything as “your system” reduces cognitive load. Tooling reinforces this illusion. Many tools assume locality, shared schemas, and synchronized change, and reward teams for designing as if those assumptions were true.
They rarely are.
This is why integration is an anti-pattern on the web. It is not a durable mental model for systems that must evolve, survive turnover, or operate over long periods of time (as in decades).
Interoperability for working with other systems
Interoperability starts from a different premise.
Merriam-Webster defines it as:
Ability of a system … to work with or use the parts or equipment of another system
The interoperability mindset treats systems as peers, not components. Parts are interchangeable, replaceable, and often only partially understood. That is not a flaw. It is the point.
Fun historical note. Merriam-Webster records the first use of interoperability in 1977. Integration dates back to 1620. The older idea is also the more brittle one.
Interoperable systems do not need deep mutual understanding. They rely on shared signals, stable interfaces, and loose coupling. This makes it easier to replace vendors, reuse components in new contexts, or adapt systems without coordinated rewrites.
These advantages matter even more today, when systems are consumed not only by humans but by automation, agents, and long-lived clients that cannot be easily updated in lockstep.
The cost is real. Interoperability demands discipline and restraint. There are fewer tools that “do it for you.” Much of the work still happens in the heads of engineers who understand boundaries and failure modes.
But the payoff compounds over time.
The web itself runs on this bargain. DNS, HTTP, HTML, and related standards assume variation, disagreement, and independent evolution. They work because they were designed to interoperate, not integrate.
Treat the network space as a collection of other systems
A useful mental shift is this: Treat everything in your network space as someone else’s system.
Not hostile. Not incompetent. Just independent.
When you do that, you stop trying to make everyone store data the same way, model resources the same way, or adopt the same internal abstractions. Instead, you focus on sharing information across boundaries using stable, well-understood contracts.
Large organizations benefit enormously from this approach. Teams gain freedom to innovate locally and move quickly while remaining compatible globally. Change becomes survivable rather than catastrophic.
There are many benefits to adopting interoperability as a long-term goal, but the practical takeaway is simple.
The rule
Treat your implementations as exercises in interoperability, not integration.
