Modular Architecture with Stable Interfaces¶
Architectural method — instantiates Lifecycle Adaptability Design
Draws a system's seams where change is expected and holds the interfaces across them constant, so a part can be replaced or reworked without disturbing its neighbours or the stable core.
Almost anything is separable somewhere; the real question is whether the seams line up with where change will actually arrive. Modular Architecture with Stable Interfaces is the up-front decision of where to cut a system into parts and — the load-bearing half — which interfaces to freeze, so a part can be swapped or rebuilt behind a boundary that does not move. Its defining move is that pairing: a partition that puts a durable, slow-changing core on one side and the volatile change surfaces on the other, plus interfaces held constant on purpose so a change stays contained inside a module instead of rippling across it. A good module is bounded because its responsibility is genuinely self-contained, not because it happened to be built first; a good stable interface is one you can promise to keep even while everything behind it is torn out and replaced.
Example¶
A developer designs a mid-rise office building as shell and core. The structural frame, the elevator and stair cores, and the main services risers are treated as the stable core — a 50-plus-year responsibility that must not move. The interior fit-out — partitions, ceilings, workstations — is a change surface expected to churn every 5–10 years as tenants turn over. The stable interface between them is a raised access floor plus a regular grid of power, data, and HVAC take-off points on a fixed module (say, ≈1.5 m). Any tenant can re-plan a whole floor — add rooms, move walls, change density — by connecting to that grid, without anyone touching structure or risers.
Twelve years on, converting a floor from open-plan offices to wet labs is a fit-out project, not a demolition, because the seam between "building" and "fit-out" was drawn exactly where the change landed and the connection grid never shifted. Contrast the older building next door, where the original HVAC ducts were sized and routed for the first tenant's layout: there is no stable interface, so every re-partition means recutting ductwork, and a small change becomes a structural one. The architecture did not predict what the tenants would want — it predicted that the interior would change, and it put the seam and the frozen interface there.
How it works¶
- Find the change surfaces first, then cut. Draw module boundaries so each plausible change (from the anticipated-change portfolio) falls inside a single module rather than across several.
- Separate durable from volatile. Put the slow-changing, genuinely-invariant responsibility in a protected core; expose the fast-changing parts as bounded surfaces.
- Freeze the interface, hide the insides. Define each module's boundary as a contract you can commit to holding, and hide internal state so neighbours cannot quietly grow to depend on it.
- Keep what crosses each seam small. The less that passes across a boundary, the smaller the blast radius when the module behind it is replaced.
Tuning parameters¶
- Module granularity — fine-grained modules give more independent change but multiply the interfaces you must coordinate and keep stable; coarse modules mean fewer seams but a bigger blast radius per change.
- Where the stable/volatile split falls — how much you bet on what is truly durable; misplace it and the "core" ends up needing to change.
- Interface strictness — how hard you freeze each boundary. A stricter interface insulates neighbours more but constrains what the module behind it can become.
- Coupling budget — how much cross-module dependency you tolerate before a "module" is a module in name only.
- Anticipation horizon — how far-future a change you build a seam for; every seam kept "just in case" has a standing carrying cost.
When it helps, and when it misleads¶
Its strength is containment: it turns whole-system replacement into part replacement and lets different parts of a system evolve at their own rate. The guiding real-world picture is shearing layers — a building endures because its fast layers (space plan, furnishings) can change without disturbing its slow ones (structure, site), and a system designed the same way survives change the same way.[n1]
It misleads when the seams are in the wrong place. The worst case is a design that is neatly modularized where change didn't come, while the change that actually arrives cuts across every module at once — all the interface cost, none of the insulation. Two nearer failures: over-modularization (paying real coordination and indirection cost for flexibility that is never exercised — speculative generality), and leaky interfaces (a boundary advertised as stable that quietly exposes internal state, so it cannot actually be held). The classic misuse is declaring something "modular" on an architecture diagram while hidden couplings make any real swap impossible — modularity that exists only on the slide. The discipline that guards against all three is to derive the seams from a real anticipated-change portfolio, enforce information hiding so interfaces stay honest, and prove a representative swap is possible with a change drill rather than asserting it.
How it implements the components¶
Modular Architecture supplies the archetype's structural backbone — the decomposition the other mechanisms attach to:
stable_core_and_change_surface_partition— its central act: separating the durable core from the plausible change surfaces and drawing the module boundaries around them.bounded_change_unit— each module is a bounded change unit: the smallest thing that can be replaced or reworked behind its own interface.
It draws the seam but does not author the compatibility contract that governs how an interface evolves, nor bridge two interfaces that disagree — interface_and_compatibility_contract is filled by Adapter, Shim, or Translation Layer and by Versioned Interface and Migration Contract. The physical lifecycle_access_and_disassembly_path and the full dependency_and_coupling_map needed to actually reach and separate a module belong to Design-for-Disassembly and Service Access; the standardized connector that lets one unit drop in is Replaceable Unit and Standardized Connector's.
Related¶
- Instantiates: Lifecycle Adaptability Design — Modular Architecture is the structural partition the whole design hangs on.
- Sibling mechanisms: Design-for-Disassembly and Service Access · Adapter, Shim, or Translation Layer · Configuration and Feature Control · Configuration Registry and Decision Log · Lifecycle Scenario and Change Drill · Replaceable Unit and Standardized Connector · Versioned Interface and Migration Contract · Parallel Operation and Staged Cutover · Rollback Checkpoint and Containment Runbook · Spare Capacity, Port, and Space Reservation · Take-Back, Recovery, and Decommission Plan
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Modular Architecture with Stable Interfaces operates as a persistent arrangement of components, resources, interfaces, or technical topology because it draws a system's seams where change is expected and holds the interfaces across them constant, so a part can be replaced or reworked without disturbing its neighbours or the stable core.
Independent corroboration: The frozen evidence defines Modular Architecture with Stable Interfaces as 'Draws a system's seams where change is expected and holds the interfaces across them constant, so a part can be replaced or reworked without disturbing its neighbours or the stable core', so its operative form is Structure, Architecture & Configuration.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Separating fast-changing from slow-changing parts behind stable seams is a canonical engineering approach to lifecycle adaptability.
Related originating lineages:
- Architecture & Urban Planning — Shearing-layer theory in adaptable buildings materially shaped rate-of-change boundary placement.
- Computer Science & Software Engineering — Information hiding and dependency inversion provide a parallel software lineage.
Review resolution: Both independent reviews agree on primary origin engineering_design; reconciliation resolves secondary fields (alternate_origin_disagreement, domain_reach_disagreement). Alternate origins retained (computer_science, architecture_urban_planning) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=convergent records the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves either reviewer's finding that the encyclopedia generalized the mechanism.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Modularity is not free: every seam adds an interface to hold, an indirection to traverse, and coordination cost. It pays only where change actually lands, which is why the partition should follow an anticipated-change portfolio rather than an instinct to "make everything pluggable." Note too that a clean logical partition is necessary but not sufficient — a module you cannot physically reach (Design-for-Disassembly and Service Access) or safely swap is not yet a changeable one.
[n1] Shearing layers — Stewart Brand's account in How Buildings Learn (building on Frank Duffy) that a building is a set of layers changing at very different rates, and that durable design lets the fast layers move without disturbing the slow ones. The same principle governs modular systems generally: put the seam between things that change at different speeds. ↩