Concept/Systems Thinking/No. 0623
Modularity
Modularity is the division of a system into parts with defined interfaces that limit how changes spread. In systems design, Herbert Simon and David Parnas helped explain how such parts can be changed, tested or replaced while keeping much of the wider system stable.
- Evidence
- Well established
- Read
- 6 min
- Links
- 11 connections
01You've seen this when…
- in life
Your bike gets a puncture. You replace the inner tube and ride away with the same frame, brakes and gears.
- at work
A team changes the pricing panel in an app. Three unrelated screens break because they all depend on the same internal data format.
- out in the world
A transit agency wants to replace ticket machines while keeping existing fare cards. The purchase hinges on whether a new machine can communicate with the existing fare system.
02The idea
Some systems let you replace one part while leaving most of the rest alone. A charger connects through a specified plug and supplies a specified voltage. The laptop can use it without depending on the arrangement of components inside it.
That boundary is an interface: what a component accepts, what it supplies, and the rules both sides must follow. Interfaces can be physical connectors, software operations, file formats or agreements between teams.
Modularity puts changeable details behind these boundaries. A module’s users depend on its promised behavior. Its internal design can change within those promises. David Parnas called this information hiding: keeping a design decision private to the component responsible for it. Here, hiding means limiting dependencies on that decision.
The useful question is which changes a boundary can contain. A payment component might accommodate a new payment provider while leaving the shopping cart untouched. It may still require widespread changes when the business introduces a new currency, because currency affects prices, taxes, receipts and refunds.
Abstraction supplies a simplified view of a component. Loose coupling describes how little components depend on one another. Modularity organizes the parts and their interfaces; the independence achieved depends on the details.
03Why it matters
- Changes can stay local. A team can alter the implementation behind an interface while preserving what other components rely on. This reduces the amount of code, equipment or work that must be reconsidered together.
- Experiments become easier to contain. A replaceable component creates somewhere to try another supplier, algorithm or material. Comparison becomes cheaper when the surrounding system can remain stable.
- Work can proceed in parallel. People can develop separate parts against agreed interfaces. They still need shared tests and coordination when those agreements change.
- Some failures can be contained. Boundaries designed to limit fault propagation can reduce cascading failure and support graceful degradation. A broken recommendation service might leave search and checkout available.
The last benefit requires extra design. A module boundary alone does not block electrical surges, corrupted data or an overload on a shared database. Change isolation and fault isolation each need their own checks.
04A worked example
In his 1972 paper, David Parnas compared ways to build a keyword-in-context index. The program takes lines of text, produces versions starting at each word, and sorts them alphabetically. For example, city bus timetable yields rotations including bus timetable city and timetable city bus.
What it looks like A straightforward processing pipeline. One module reads the text, another generates rotations, another sorts them, and another produces the output. Each stage has a recognizable job.
What’s actually going on In Parnas’s first decomposition, those stages depend on shared choices about how the text is represented. Changing those choices can require changes across several modules. His alternative groups responsibilities around design decisions that might change, including how lines are stored. Other modules access the text through defined operations, reducing their dependence on its layout in memory.
What would have helped Before assigning the stages to programmers, identify the decisions most likely to change and give each a protected boundary. A new storage representation can then be handled inside the responsible module, provided it preserves the operations other modules use. Sorting still depends on those operations behaving as promised.
Parnas’s example is a published comparison of designs. It demonstrates how dependencies differ; it does not provide a measured productivity gain from a deployed product.
05Where people trip up
- Shared internals bypass the interface. Two components may have separate names and owners while both reaching into the same database tables. A table change then pulls both into the work. Trace one plausible change through the system and count every component that must understand it.
- The org chart determines every boundary. Conway’s law describes how systems tend to reflect the communication structures of their builders. Existing team boundaries can make coordination convenient while splitting a responsibility that needs to stay together. Assign ownership around coherent decisions, and explicitly coordinate responsibilities that cross teams.
- Interfaces become premature promises. Early in a project, people are still learning what each part needs. Freezing a broad interface too soon can lock awkward assumptions into every component. Start with a small contract, test it with working parts, and agree how revisions will be handled.
- Integration gets postponed. Each module passes its own tests, then the assembled system fails on timing, units, permissions or unexpected inputs. Connect representative parts early. Test their interaction under ordinary use, overload and failure.
Every boundary also adds work: adapters, documentation, version management and negotiation. In organizations, some of this appears as transaction costs. Count that work alongside the changes the boundary is expected to contain.
06Where it doesn’t earn its keep
A tightly integrated design can be a good choice when performance depends on close coordination among parts. A compact device may share space, cooling and structural supports so extensively that making every component interchangeable would add size and weight.
Modularity also has limited value when the proposed boundaries keep moving. During early exploration, changing several parts together may be faster than preserving interfaces built around guesses. Stable boundaries become more useful as recurring patterns emerge.
The right degree of modularity depends on the changes expected, the cost of coordinating them, and the performance sacrificed to keep parts independent.
07Roots
Herbert Simon imagined two watchmakers whose work kept being interrupted by phone calls. In the parable, one assembled a watch through a long sequence that fell apart when interrupted. The other built stable subassemblies, so each interruption destroyed much less progress. Simon used the story in his 1962 essay, The Architecture of Complexity, to explain why complex systems often have a hierarchy of parts within parts.
He also described nearly decomposable systems: interactions are stronger within their parts than between them. This offered a way to understand complexity without treating every connection as equally important.
A decade later, David Parnas addressed a practical software question: how should programmers decide where one module ends and another begins? Dividing a program along its processing steps was an obvious approach. His indexing example showed the advantages of placing boundaries around design decisions likely to change. That principle became a foundation of software architecture.
Together, these accounts explain two enduring attractions of modularity: stable intermediate pieces make complex construction manageable, and carefully chosen boundaries can keep future changes from spreading everywhere.
08How solid is this?
Foundational systems and software analyses explain how stable subassemblies and hidden design decisions can localize work. Benefits depend on the chosen boundaries, shared dependencies and integration costs; modularity alone does not establish fault isolation or faster development.
09Connections
- Often confused withSeparation of Concerns
- Helps counter Brooks’s Law, Cascading Failure, Technical Debt
- In tension withTight Coupling
- Can lead toLoose Coupling
- See also Conway’s Law, Gall’s Law, Graceful Degradation, Transaction Costs, Abstraction
+ 1 more in the list
10Origin and sources
Herbert Simon described hierarchical and nearly decomposable systems in The Architecture of Complexity (1962). David Parnas developed the information-hiding criterion for software modularization in 1972.
- [1]Simon, H. A. (1962). The Architecture of Complexity. Proceedings of the American Philosophical Society, 106(6), 467–482.
- [2]Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058.
Suggest an edit· Updated 2026-10-02