The Architecture of Independence

Establishing the Grammar of Modularity and the Rule of the Bolt

1. Interface as an Organizational Treaty

A modularization interface is an organizational contract that establishes how a specific business unit or module will interact with the rest of the system. A well-designed interface is what allows teams to operate as entirely separate companies, autonomous and independent, as long as they honor the contract. Interfaces define the boundary of responsibility, and that boundary is what makes a modular system economically viable.

The economic logic behind this approach was formalized before software teams started talking about microservices. As Prof. Clayton Christensen of Harvard Business School explained, every operating business is governed by a “profit formula” that dictates which investments and projects receive priority (Johnson, Christensen & Kagermann, “Reinventing Your Business Model,” HBR 2008). When that formula treats the company as a single unified entity, every project competes for the same scarce resources, and the same lens decides the priority of one module-level investment. This creates the conditions for incompatibilities between business, product, and tech, because the model forces linear prioritization over what should be independent, parallel work. The profit formula is what determines whether the business is structurally modular or structurally monolithic. No amount of refactoring at the code level will change that.

Carliss Baldwin and Kim Clark, in Design Rules, Volume 1: The Power of Modularity (MIT Press, 2000), argued that modularity is the most powerful force in the modern economy precisely because stable interfaces allow decentralized innovation. Their “six modular operators” (splitting, substituting, augmenting, excluding, inverting, and porting) describe how splitting a system into modules with clean interfaces unleashes parallel work. The deeper insight is what they call option value: when a module can be replaced cheaply because the interface holds, the organization can experiment with multiple versions in parallel. The one that wins is kept, and the rest are discarded. This is the source of the speed that high-performing modular companies demonstrate. The discipline is to maintain a clear boundary between visible information (the interface) and hidden information (the module interior), a distinction Baldwin and Clark also formalized in their working paper on the option value of modularity. As long as the interface is honored, the interior can be a masterpiece or a mess. The rest of the system does not care, and does not need to.

A common question in interface design: minimal or extensible? The temptation is to make the interface open-ended so it can absorb any future need. This is how interfaces become bloated, and bloated interfaces become coupled to the modules they were meant to decouple. A better discipline is to bound the interface by what the module is expected to do, not by what the consumer might want from it. Over time, this implies that engineers should classify or categorize interfaces by purpose, so the contract reflects the function rather than the consumer’s appetite.

Let’s illustrate the discipline with a practical example. Consider a company running a single monolith, with checkout, fraud, and settlement logic all interleaved. The first refactor splits out the payment processing concern. Naming the module is not arbitrary. The module is PaymentsProcessor, and the interface it exposes is PaymentProcessing. Every other team codes against that interface. Whether the underlying implementation is a single function, a queue, a distributed system, or even an external service stays hidden behind the interface. Other teams pass a payment_id and receive confirmation. They stay unaware of the database schema or the queue topology inside PaymentsProcessor. If the team later replaces the entire implementation, no other team has to change a line of code. That is the entire economic value of a well-defined interface.

A frequent objection is to point at an OpenAPI specification and ask why that is not enough. OpenAPI documents a different kind of interface. It describes the technical contract between a client and a service, typically at the request-response level. That is useful for engineers wiring two endpoints together. The right question is whether the product can be broken into independent, replaceable, business-aligned modules. Modularity at that level concerns business structure, team topology, and the technical architecture, all sharing the same interface principles Christensen describes in his work on interdependence vs. modularization (Christensen & Raynor, The Innovator’s Solution, 2003; HBS Module Note 420-016, 2019).

2. The Rule of the Bolt: Immutable Identifiers

The stability of a modular system depends on the predictability of its interfaces. The Rule of the Bolt defines the discipline for maintaining true domain responsibility and independence:

• The Identification Joint: The only valid physical connection between independent modules is the Immutable Identifier (The Bolt).
• Responsibility Limits: Interfaces must exchange IDs, such as a User ID, not complex, state-heavy objects.
• Encapsulation: As long as the data type of the Bolt remains unchanged, the internal properties, constraints, or metadata of the module can evolve daily without disrupting the composite system.
• Independence: Cross-module function calls and shared internal types are welded joints that prevent a system from being broken into truly separate modules; independence requires that modules communicate only through their declared interfaces.

3. Timing: The Good Enough Pivot

Modularization is a capital allocation decision rather than a default.

• Early Stage: Prioritize raw performance, feature delivery, and finding product-market fit. Modularization during this phase can create unnecessary overhead and detract from the core focus on performance.
• Sustaining Market: Once the product reaches good enough performance and serves demanding customers in a competitive tier, the competence shifts from performance to flexibility and speed. Modularization at this stage is a critical requirement to avoid the Sync Tax and ensure future innovation speed. Christensen and Raynor make the same pivot explicit in The Innovator’s Solution: once a product overshoots what customers can use, the basis of competition moves to convenience, customization, and speed, which demands modular architecture.

4. Measuring the Human Cost of Architecture

Traditional metrics miss the human cost of poor architecture. Two simple views of the codebase tell the story.

The first view plots the number of releases a team ships against the total man-hours the team spends in meetings with other teams during that same period. In a well-modularized system, these two numbers move in opposite directions. Feature work scales, release count grows, and meeting hours stay flat or fall, because each team codes against stable interfaces and rarely needs to negotiate with anyone. When feature work and meeting hours both climb at the same time, the architecture is broken no matter how clean the code looks. A team that needs three meetings to ship a small change is paying for somebody else’s shortcut.

The second view compares two kinds of complexity over time. Business model complexity counts the number of unique logic paths the product has to support. These are the distinct conditions a customer can fall into that change how the system behaves: different jurisdictions, account tiers, edge cases in pricing, refund rules, fraud signals. Technical complexity counts the corresponding load on the codebase, the branches, integrations, exceptions, and special cases the engineering team has to maintain. In a healthy modular system, the two lines grow together. New business rules add new logic paths, and the codebase absorbs them at roughly the same rate, one module at a time. When the technical line starts climbing faster than the business line, the architecture is leaking. A small new rule, a new country, a new customer tier, should require a proportional change in the code, not a step change. When the code explodes for a small business change, the Sync Tax is already eating the margin.

When the code explodes for a small business change, the Sync Tax is already eating the margin.

Both views gain their full meaning with the right economic framing. The Sync Tax is called a tax because it behaves like one. Taxes, in any economy, are regressive. They shrink the productive base without ever growing it, taking a disproportionate share from the most constrained resource and returning nothing. That is precisely what the Sync Tax does to a software business. It consumes the engineering hours the team should reinvest in new features, and it returns only friction.

Some of these syncs came into the codebase as “temporary” measures. They were a quick fix to keep a feature moving when the architecture would not allow it. The team that introduced them intended to come back and clean them up. They never did. The pattern is identical to what any government does when it adds a “temporary” tax to fund an emergency. They never had the intention of removing it because they love other people’s wealth, while in the case of a product, upper management might never have the intention to approve time to cleanup the product architecture. Milton Friedman captured the dynamic in Tyranny of the Status Quo (1984, p. 115): “Nothing is so permanent as a temporary government program.” The political class that benefits from the tax has no incentive to remove it. Their power depends on the tax base. So they lie when they call it temporary. By the time a generation has passed, the “temporary” tax is permanent, the original emergency fades from memory, and anyone who tries to remove it gets labelled a radical. The Sync Tax follows the same logic. Each “temporary” sync compounds with the next, and the architecture teams originally intended as transitional becomes the only architecture anyone remembers.

Nothing is so permanent as a temporary government program.

5. Where to Start Decoupling

For legacy systems with heavy interdependence, leadership must deliberately remove the Sync Tax. The principle is the same as paying off debt, a metaphor Ward Cunningham introduced in his OOPSLA ‘92 experience report on the WyCash portfolio system. Rank every coupling by how much pain it causes, and pay down the worst ones first. Start with the syncs that trigger the most incidents and consume the most meeting hours. Cheaper, less painful couplings can wait.

The longer-term direction is to move away from rigid, predefined contracts between modules. A module should be able to ask the rest of the system what it needs and get a usable answer, instead of depending on a fixed schema that breaks the moment someone adds a field. Modules that can negotiate their interactions on the fly are far more resilient to change than modules bound to strict, brittle contracts, and they let teams ship updates without coordinating a meeting.

6. The Crime of Architectural Embezzlement

Management must be vigilant against Architectural Embezzlement. This occurs when engineers or managers implement “cheap” solutions, such as reaching into a foreign domain to grab data, to satisfy immediate pressure. The result is the technical equivalent of a politician printing money to pay for today’s subsidies. It creates ‘architectural inflation’ that nobody recognizes as tech debt, debasing the value of every future engineering hour. By the time the bill arrives, the perpetrators have often moved on. What can leadership do? Surface these practices and frame them as a breach of trust and long-term organizational health.

The rule is simple. An engineer should never need to read data from another domain. Where the interface does not expose it, the engineer codes around the gap rather than breaking the contract. Enforcing this rule is a management responsibility. Even with perfect interfaces, the architecture erodes if leadership tolerates shortcuts under pressure.

References

1. Johnson, Mark W., Clayton M. Christensen, and Henning Kagermann. “Reinventing Your Business Model.” Harvard Business Review, December 2008. https://hbr.org/2008/12/reinventing-your-business-model
2. Christensen, Clayton M., and Michael E. Raynor. The Innovator’s Solution: Creating and Sustaining Successful Growth. Harvard Business School Press, 2003. https://www.hbs.edu/faculty/Pages/item.aspx?num=15473
3. Christensen, Clayton M. “Interdependence vs. Modularity: Getting the Scope of the Business Right.” Harvard Business School Module Note 420-016, July 2019. https://www.hbs.edu/faculty/Pages/item.aspx?num=56504
4. Baldwin, Carliss Y., and Kim B. Clark. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. ISBN 0-262-02466-7. https://mitpress.mit.edu/9780262538206/design-rules-volume-1/
5. Baldwin, Carliss Y., and Kim B. Clark. “The Option Value of Modularity in Design.” Harvard NOM Working Paper No. 02-13, 2002. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=312404
6. OpenAPI Initiative. OpenAPI Specification. Linux Foundation. Accessed June 26, 2026. https://www.openapis.org/
7. Friedman, Milton, and Rose D. Friedman. Tyranny of the Status Quo. Harcourt Brace Jovanovich, 1984, p. 115. https://miltonfriedman.hoover.org/objects/57553/tyranny-of-the-status-quo
8. Cunningham, Ward. “The WyCash Portfolio Management System.” OOPSLA ‘92 Experience Report, 1992. http://c2.com/doc/oopsla92.html