Modularity and Integration: Fit Against Flexibility
There are two fundamentally different ways to build a complex product.
Integrated: one organisation controls every part and how they connect. Nothing is interchangeable, and every piece can be tuned against every other piece. The fit is as tight as the designers can make it.
Modular: the system is divided at defined interfaces, and any component meeting the interface specification can be swapped in. Many organisations can supply parts, buyers can mix and match, and the fit is as good as the interface allows — no better.
Neither is correct in general. Which one wins depends on a single question about the market, and the answer to that question changes over time in a fairly predictable way.
What each one buys you
Integration buys performance and coherence. When one organisation controls all the pieces, it can make trade-offs across boundaries that a modular design cannot. It can change two components together, tune one around the quirks of another, and avoid the compromises a general-purpose interface imposes. Where the last increment of performance matters, this wins.
It also buys a coherent experience. Things designed together behave consistently, because nobody had to negotiate.
The cost is that you must be good at everything, you carry all the fixed cost, and you cannot benefit from anyone else's specialisation.
Modularity buys variety, price and speed of improvement. Once interfaces are standardised, many suppliers compete for each slot, prices fall, and each component improves on its own schedule without waiting for the whole system. Buyers can combine parts to suit needs no single integrated vendor would have served.
The cost is that the interface constrains everything. A standard sufficient for many uses is optimal for none, and improvements requiring changes on both sides of an interface become slow, because they need agreement between independent parties.
Why the answer changes over time
The decisive question is whether customers still feel the product is not good enough.
While the answer is yes — while people would pay for more performance and are frustrated by what is available — integration is rewarded, because it is the only way to extract the last increments. Early in any product category, interfaces are unsettled, components are immature, and coordinating across organisations is slower than doing everything internally.
Once the product becomes good enough for most buyers, their attention shifts. Extra performance stops commanding a premium, and price, choice, and convenience start deciding purchases. That is when modular systems win, because they are cheaper and more varied — and the performance gap that integration provides has stopped mattering.
This is why so many industries follow the same path: integrated early, modular later. It is also the mechanism connecting this to the Innovator's Dilemma — the integrated incumbent is optimising a dimension customers have stopped caring about, while modular entrants compete on the dimensions that have become decisive.
And the pendulum can swing back. A new technology resets the situation: interfaces are unsettled again, performance is scarce again, and integration wins again for that new layer. Which is why the same industry can oscillate over decades and why the argument never settles permanently.
Using this in practice
Ask whether your customers think the product is good enough. If they are still frustrated by performance, integration is likely rewarded. If they have started asking about price and options, the market has moved and integration is becoming an expensive way to deliver something people no longer notice.
Expect the boundary to move, and design for it. Systems that assume today's split will hold indefinitely tend to be painful to change. Where you can, keep interfaces explicit even inside an integrated system — it costs a little now and preserves the option later.
Notice that this operates at every level. The same question applies to a product, a company's supply chain — which is vertical integration — and a software architecture, where it is the recurring monolith-versus-services debate. The underlying trade is identical in all three: coordination cost and fit against flexibility and independent improvement.
Beware doing both badly. The failure mode is a system that is neither properly integrated nor properly modular — components that are theoretically separable but too entangled to swap, with interfaces that constrain without delivering interchangeability. This is common, usually arrives by accident during growth, and combines the costs of both approaches with the benefits of neither.
That last case is worth watching for specifically, because it rarely results from a decision. It results from an integrated system slowly acquiring boundaries as teams divide — which is Conway's Law producing a modular structure without anyone doing the work to make the modules genuinely independent.
