CHAPTER DEEP READ · ACCELERATE · CH 5

Architecture

Accelerate: The Science of Lean Software and DevOps · Ch 5 · Forsgren, Humble & Kim · 2018

What is this chapter about?

The previous chapter said: shipping fast and safely comes from merging daily and having automated checks you trust. Plenty of teams object — we'd love to ship daily, but we physically can't. Change one line and you wait for seven other groups to line up, then for the one release window that opens each month. Chapter 5 asks what is actually blocking them. The answer is a surprise: not effort. The shape of the building.

Start with something strange

The researchers expected teams building phone apps to be faster than teams tending a decades-old system. The data says otherwise: old systems, bought-off-the-shelf software, firmware baked into a device — the type of system you build barely shows up as a difference in speed. Teams working on machines older than they are still land in the fastest group.

Why the old world was hard

Picture an apartment building where every unit shares one water main and there are no shutoff valves. To replace your own faucet you have to notify the whole building, schedule a night when the water goes off for everyone, and have all of it inspected together. Replacing a faucet isn't hard. "Everyone has to do it at once" is hard.

Software is full of buildings with no valves: to check whether your small change is right, you first have to assemble everyone else's systems into one complete setup; to go live, you wait for everyone to be ready. The more people, the harder the scheduling — so adding people makes it slower.

The core mechanism: install the valves

The chapter says you can judge the shape of a system with two very plain questions:

One: can I check it on my own? Without assembling everyone else's pieces into one complete setup, I can verify most of my change. In practice, you give the neighbors a stand-in — something that answers the way they agreed to answer — and you test only your own side.

Two: can I ship it on my own? Without waiting for anyone, without a shared window, I release my part whenever I want. That works only if the neighbors and I have a written agreement about how we talk to each other, one that doesn't shift under us.

Once those two hold, something lovely happens: the amount of talking goes down. All those cross-team coordination meetings were, in effect, interest payments on the missing valves. Install the valves and each small group can finish its own work.

What it buys you

The finding worth remembering is about what happens when you hire. In well-shaped teams, more people means output per person still goes up. In badly shaped ones, more people means output per person goes down — the new arrivals spend most of their time waiting and meeting. So architecture doesn't really decide how modern your technology is. It decides whether the people you add turn into capacity or into coordination cost.

There's also a note for managers: don't dictate everyone's tools. This chapter found that teams allowed to pick their own tools do better — because only the people using something every day know whether it's any good.

Remember one thing

To judge a system's shape, don't look at how pretty the diagram is or how fashionable the technology is. Ask two questions: can I finish testing on my own? can I ship on my own? Two yeses and most of the rest follows. The honest cost: valves aren't free. The more you split things apart, the more pieces and agreements you have to maintain — split too far and you've simply traded meetings for debugging.

Want the mechanisms, the research findings, and the diagrams? → Switch to the deep read

In one sentence

You think the architecture question is "which technology, and should we go microservices." This chapter reframes it with data: the type of system you build — mainframe, packaged software, embedded, greenfield — barely predicts delivery performance, while testability and deployability predict it strongly. Architecture's real output isn't a topology diagram but an observable organizational fact: can a team get work from design to production without asking anyone's permission? It is also this book's answer to the oldest question in software management — why adding people doesn't make things go faster.

Glossary

Coupling: whether a change to A forces B to change, test, and ship along with it. More entanglement is tight coupling; less is loose coupling. This chapter cares about only one consequence of it: how many people you have to move to get one thing done.
Deployability: the first criterion — can you deploy or release your application independently of the other applications and services it depends on.
Testability: the second criterion — can you do most of your testing without an integrated environment that assembles every system together.
Integrated environment: a test environment with all upstream and downstream systems deployed together. Usually scarce, queued for, and broken for everyone when one piece breaks.
Test double: a fake implementation that answers according to an agreed contract, so you can test only your own side. Mocks, stubs and fakes are all test doubles.
API and versioned API: an API is the agreed way two systems call each other; versioning keeps the old shape alive for a while so consumers migrate on their own schedule instead of being forced to ship simultaneously.
Bounded context: the domain-driven-design idea of drawing a firm boundary around a slice of the business — the model inside is self-consistent, and traffic across the boundary goes through explicit interfaces. It's what tells you where to cut.
Monolith: the whole application ships as one deployment unit. Note that monolith ≠ tightly coupled: a well-modularized monolith can satisfy both criteria above.
Microservices / SOA: splitting a system into independently deployable services. Independent deployability is the goal; splitting is the means.
Distributed monolith: the industry's name for services that were split apart but must still be tested, released, and rolled back together — all the cost of distribution, none of the independence.
Systems of record / systems of engagement: the former are ledger-like, correctness-critical, slow-changing; the latter are user-facing and fast-iterating. The industry once argued these should be run at two different speeds ("bimodal IT").
Delivery performance: the four key metrics from Chapter 2 — deployment frequency, lead time for changes, change failure rate, time to restore service.
Conway's law: Melvin Conway's 1968 observation that a system's structure comes to mirror the communication structure of the organization that built it.

Where it sits

This is Chapter 5 of Part I ("What We Found"). It follows Chapter 4, which broke continuous delivery into measurable capabilities, and leads into Chapter 6 on integrating infosec. It answers the awkward question Chapter 4 leaves behind: we understand the practices, but our system does not permit them — now what? In today's terms it is the empirical basis under "monolith or microservices," "should we build a platform team," and "why did hiring make us slower." DORA has since frozen it into two standalone capabilities: loosely coupled architecture and loosely coupled teams.

The problem this chapter attacks

Chapter 4's conclusion is firm: merge to trunk daily, keep automated tests you trust, keep trunk releasable. But a real team's day often looks like this — change one config value; request the company's single integrated test environment (three days of queue); discover another system in it is broken (two more days); finish testing; wait for the monthly release window; on the night of the window, seven teams go live together; when something breaks, spend two hours establishing whose change it was. Inside that structure, "deploy once a day" isn't a discipline problem. It's physically impossible.

So the chapter asks: does continuous delivery have prerequisites, and is one of them "be a new company building a new system"? The answer decides whether two popular positions hold: "this doesn't apply to us" (we maintain a twenty-year-old mainframe core / packaged software / firmware in a device; that stuff is for internet companies), and "microservices will fix it" (split the monolith and speed follows).

What happens if nobody answers? Two kinds of waste, one on each side. The first locks itself into annual releases in the name of being a special industry. The second spends two years splitting a monolith into 80 services and then discovers that all 80 must still be tested and released together — every cost of distribution paid, not one release of independence collected. The chapter's job is to turn "is our architecture good" from a matter of taste into two characteristics you can score on a survey and test statistically against performance.

The core, in depth

1. The counterintuitive finding: the type of system barely matters

The research sorted respondents' systems into many categories: greenfield systems, user-facing systems of engagement, ledger-like systems of record, software developed in-house, custom software developed by another company, packaged commercial software (COTS), software running in a data center you control, software installed on users' devices, firmware embedded in a hardware product, and mainframe software. Then it asked which category was more likely to be a high performer.

The answer: essentially all of them can be. No significant difference showed up between system type and delivery performance — mainframe teams land in the high-performing group too. That single result contradicts the then-fashionable bimodal IT proposal of running "fast systems of innovation" and "slow systems of record" at separate speeds. The data says slow is not the destiny of a system of record; it's a result of architecture and practice.

There are two exceptions, and they point at the same mechanism: low performers were more likely to be building custom software developed by another company (i.e. outsourced), and more likely to be working on mainframe systems. Read that carefully — it isn't a claim that outsourced teams are weaker or mainframe technology is bad. Both situations tend to share one feature: the change you need isn't under your control. The code belongs to another company, or the change has to travel through someone else's approval and schedule. Either way, more people must move. What this chapter measures is never the technology; it's how many people have to move.

Figure 1 · The chapter replaces a vague question with two scorable characteristics: not what kind of system you build, but whether you can test and release it alone.

2. The two criteria: testability and deployability

Architecture is operationalized as two almost conversational survey items any team can answer on the spot:

"We can do most of our testing without requiring an integrated environment."
"We can and do deploy or release our application independently of the other applications and services it depends on."

Note the phrase that is easy to skim past in the second one — "can and do." Being architecturally capable of an independent release while in practice always shipping with the convoy does not count. That is the chapter's sharpest cut: it measures the accomplished fact, not the design intent. Plenty of organizations that consider themselves microserviced die on that half-sentence.

Why do these two work so well? Because they sit on continuous delivery's two bottlenecks. Testability sets how fast feedback is: checks you can run on your own machine against test doubles come back in minutes; checks that queue for an integrated environment come back in days. Once feedback degrades from minutes to days, teams instinctively batch changes before testing — the batch grows, and you are back on the superlinear conflict curve from Chapter 4. Deployability sets how big the batch is: as long as you must ship with everyone else, your deployment batch is the sum of everyone's changes, and when something breaks the first task isn't fixing it but establishing whose change it was.

Figure 2 · The same one-line change, walked through both structures: tight coupling imposes batch size and waiting on you; loose coupling shrinks the batch back to "my change."

3. The other half of architecture is the team

Architecture and team boundaries are two faces of one thing — the modern statement of Conway's law. Beyond the two technical characteristics, the chapter's notion of "loosely coupled" includes a set of items about autonomy: can a team

make large-scale changes to the design of its system without permission from outside the team;
complete its work without fine-grained communication and coordination with people outside the team;
make changes without creating significant work for other teams;
deploy and release on demand, independently of the services it depends on;
do most of its testing on demand, without an integrated test environment;
perform deployments during normal business hours with negligible downtime.

That last one gets dismissed as a detail; it's actually the assay for the whole set. A team only dares to release at 2 a.m. on a Saturday precisely because it can neither verify alone nor ship alone — daylight failures pull in too many people. "Would you deploy at 3 p.m. on a Tuesday?" is a coupling reading you can take without ever opening the architecture diagram.

Note too that not one of these items asks you to split your system into dozens of services. They all ask the same thing: how many people must move to get one thing done. What this chapter opposes is not the monolith but every arrangement that institutionalizes moving together: the single integrated environment, the company-wide release train, joint cross-system acceptance sign-off, changes that must ride another team's roadmap.

4. Why this decides whether hiring helps at all

The chapter's most damaging chart puts deploys per day per developer on the vertical axis and number of developers on the horizontal:

High performers: it increases with team size — added people become added output;
Medium performers: roughly flat — added people scale output proportionally;
Low performers: it decreases — added people slow everyone down.

This is the mechanism behind the old Mythical Man-Month result. In a tightly coupled system, communication paths grow roughly quadratically with headcount — n people have n(n-1)/2 pairwise paths, which in plain words means doubling the team nearly quadruples the relationships to keep aligned. Loose coupling cuts that fully connected mesh into small groups — high bandwidth inside, interfaces only between — so a new hire is absorbed into one group instead of spread across the global coordination mesh. It's also the most practical self-test in the book: if you went from 20 engineers to 60 and delivery didn't get faster, you didn't hire badly — your architecture hit its ceiling.

Figure 3 · The chapter's most damaging curve: architecture decides whether new hands become capacity or coordination cost. The three groups nearly coincide while teams are small, then diverge with scale.

5. What architects should watch: engineers and outcomes, not tools

One section is addressed to architects and technical leaders, and its conclusion stings: architects should focus on engineers and outcomes, not tools or technologies. However advanced a tool is, if the people who must use it hate it, or if it doesn't produce the outcomes we actually care about (test alone, ship alone), it is an irrelevant variable. The matching finding: teams that could choose their own tools did better at continuous delivery, and in turn at delivery performance — only the people using something daily hold first-hand information about whether it works.

This gets misread as "use whatever you like," so add the calibration: what it opposes is a central group far from the work dictating the choice, not standards as such. The pragmatic balance is usually: standardize infrastructure and the security baseline (otherwise every team rebuilds operations), and leave languages and frameworks to teams — with every standard judged by one question: does it make teams more able to test and ship alone, or less?

The enabling techniques it names are the conventional ones: bounded contexts and APIs to cut a large domain into loosely coupled units, and test doubles and virtualization so services can be tested in isolation. What they share is that they all reduce the occasions when everything must be assembled before anyone can work.

Trade-offs and how to choose

The two criteria are the goal, not the plan. Several routes reach them at different prices, and the classic wrong turn produces the outcome everyone has heard about: two years of splitting, still releasing once a month.

Table 1 · Four common shapes: who actually gets independent testing and shipping

	Test alone?	Ship alone?	The honest cost	Fits
Tightly coupled monolith	No — needs the full environment	No — everything ships together	Batch and coordination cost rise with headcount; the release window becomes the bottleneck	Small teams (`< 10`) early on, before architecture constrains speed
Modular monolith	Yes — modules test in isolation	Ships together, but as one unit with no cross-team coordination	Boundaries held by discipline, not process isolation; one bad corner erodes the rest; each deploy is still whole-app	Mid-size org, business boundaries still moving; wants independence without the distributed bill
Loosely coupled services	Yes — doubles plus contract tests	Yes — deploy on demand	Operational surface multiplies: observability, version compatibility and distributed debugging all cost real money	Many parallel teams; scale has made coordination the dominant bottleneck
Distributed monolith	No — still needs the integrated env	No — still ships together	The worst square: every cost of distribution plus every constraint of the monolith	None — a state to recognize and exit

Table 2 · Symptom → what it means → what to fix first

What you observe	What it tells you	Priority action
You only dare release at weekends / at night	Blast radius is uncontrolled and several parties must be present	Get to "deployable in business hours, quickly reversible" — the fastest-moving needle on the coupling gauge
The integrated environment is queued and often broken	Testability fails; feedback degraded from minutes to days	Introduce test doubles and contract testing; minimize occasions that need everything assembled
Releasing requires a cross-team meeting	Deployability fails; your batch is everyone's changes	Versioned, backward-compatible APIs so consumers migrate on their own schedule
You hired and nothing got faster	Communication paths already growing quadratically	Redraw team boundaries along bounded contexts so a new hire lands inside one group
Changing your own design needs outside approval	Autonomy is missing — the architecture problem is an org problem	Push the decision down to the team; keep central control to infrastructure and the security baseline

Table 3 · Tool and technology choice: central mandate vs team choice

	Centrally mandated	Chosen by the team (what the chapter favors)
Relation to performance	No evidence it does better	Associated with better CD and delivery performance
Mechanism	Deciders sit far from the work, without first-hand information	Users know whether it works, and will invest in making it work
Cost	Easy to maintain a standard — which may standardize the wrong thing	Stack sprawl, higher hiring and rotation cost, duplicated wheels
Pragmatic balance	Standardize infrastructure and the security baseline; leave languages and frameworks to teams. One test only: does this standard make teams more able to test and ship alone, or less?

A sequencing suggestion: fix testability first, deployability second. If you can test alone but still ship with the convoy, you at least have minute-scale feedback. The reverse — shipping alone without being able to verify alone — just pushes unverified work into production faster. That isn't acceleration; it's a faster walk into the minefield.

Why it matters / in real systems

This chapter is the most quotable piece of evidence in the microservices argument, because it moves the standard from form (how many services you have) to outcome (can you test and ship alone). DORA has since frozen it into two capabilities — loosely coupled architecture and loosely coupled teams — for teams to self-assess against. It's also the underlying case for platform engineering: a platform's value isn't that it standardized the technology, it's that product teams have to ask fewer people for things.

For the interview staple "would you split this monolith into microservices," the chapter supplies the counter-questions: which steps today require assembling every system? how many teams does a release move? would those two properties get better or worse after the split? Someone who can say "after the split we'd still have to ship together, so first remove the integration-test dependency, then reconsider" understands this a layer deeper than someone reciting the benefits of microservices.

EVIDENCE FROM INDUSTRY · not the book's claims — what these companies said publicly

Amazon's CTO Werner Vogels described this architecture–organization binding publicly as early as 2006: services encapsulate data together with the business logic over it, accessible only through a published service interface, with no direct access to a service's database from outside; and alongside it the line quoted ever since — "You build it, you run it." — set explicitly against the traditional model of throwing software over the wall between development and operations. That is the industrial prototype of this chapter's two criteria: boundaries by interface, responsibility follows the team."A Conversation with Werner Vogels," ACM Queue, 2006 ↗
Counter-evidence 1: Segment published a retrospective saying that after splitting a monolith into 140+ microservices with a repository each, shared-library versioning, testing and operational load overwhelmed the team — so they merged back into a monolith. The post is titled "Goodbye Microservices." The most honest account there is that splitting is not itself the goal.A. Noonan, "Goodbye Microservices: From 100s of problem children to 1 superstar," Segment Engineering, 2018 ↗
Counter-evidence 2: Uber reports that after growing to roughly 2,200 critical microservices it ran into the trade-offs of that architecture, and grouped services into a few dozen domains (DOMA) to contain the complexity; by cutting the number of touchpoints needed to onboard a new feature, they report onboarding time down 25%–50%. Finer-grained is not the same as loosely coupled — where the boundary sits is what matters.Uber Engineering, "Introducing Domain-Oriented Microservice Architecture" ↗
A different road: Shopify disclosed that its core is a giant Rails monolith of about 2.8 million lines of Ruby and 500,000 commits, and that rather than splitting into microservices it classified roughly 6,000 classes one by one and reorganized them into a componentized modular monolith, establishing boundaries first. Exactly the chapter's point: decoupling is the goal; monolith and services are two routes to it.K. Westerlind, "Deconstructing the Monolith," Shopify Engineering, 2019 ↗
The sequel: DORA maintains "loosely coupled architecture" as a standalone capability, in wording directly descended from this chapter: when the architecture lets teams test, deploy and change systems without depending on other teams, teams need little communication to get work done.DORA, "Capabilities: Loosely coupled architecture" ↗

Misreadings and open questions

Reading the chapter as "microservices win." Not one criterion asks you to split services. It asks for independent testability and deployability — a well-modularized monolith scores, and 200 services that must ship together score zero.
Skipping the words "and do." The item asks can and do. Being able to release independently while always shipping with the convoy does not count. That phrasing is the chapter's defense against self-deception.
Reading "system type doesn't matter" as "technology doesn't matter." The finding is that the category a system belongs to doesn't predict performance — not that your database or design is irrelevant. Those choices should be judged by whether they strengthen independent testing and shipping, not by fashion.
Reading the outsourcing and mainframe exception as a hierarchy of worth. The mechanism the data points at is control and coordination cost, not practitioner skill; an in-house team hostage to someone else's schedule lands in the low-performing group too. Likewise, "teams choose their tools" is not anarchy: what's opposed is a central mandate far from the work, not standards as such.
The cost of splitting is systematically underestimated. The chapter is honest but not exhaustive here: decoupling moves complexity out of the code and into the network — distributed transactions, version compatibility, observability, fault localization are all new long-term costs. The Segment and Uber retrospectives are that bill at market price.
The methodological caveat (the whole book's): conclusions come from a voluntary industry survey with self-reported measures; the authors use latent-variable modeling and inferential predictive analysis to support directional claims — stronger than plain correlation, but still not a randomized controlled trial. For "architecture → performance" in particular, reverse causality (high performers have more slack to improve their architecture) is almost certainly present at the same time.
Period limits: written in 2018, before service meshes, platform engineering, monorepo tooling and the modular-monolith revival had fully played out. The two criteria have survived all of it — they ask about outcomes, not form.

Takeaways

1. In one line: architecture isn't judged by which category of system it is or which technology it uses, but by two things — can you test alone, can you ship alone.

2. The counterintuitive finding: system type (mainframe / packaged / embedded / greenfield) shows no significant difference in delivery performance, which directly refutes bimodal IT — slow is not the destiny of a system of record.

3. The exceptions point at one mechanism: low performers are more likely to be building outsourced custom software and mainframe systems — both mean the control isn't yours.

4. The two operational criteria: most testing without an integrated environment; can and do deploy independently of the services you depend on. Note "and do" — it measures the accomplished fact, not the intent.

5. The other half is team autonomy: change your own design without outside permission, finish work without fine-grained cross-team coordination, deploy in business hours with negligible downtime — the last is the cheapest coupling reading available.

6. The scaling result is the most damaging data here: deploys per day per developer rise for high performers, stay flat for medium, fall for low. The mechanism is quadratic growth of communication paths under tight coupling (n(n-1)/2); loose coupling cuts the mesh into groups with high bandwidth inside and interfaces between.

7. Architects should focus on engineers and outcomes, not tools and technologies; teams that pick their own tools do better — which is not a case for abolishing standards, only for judging each by whether it strengthens independent testing and shipping.

8. The techniques are conventional: bounded contexts plus versioned APIs for boundaries, test doubles and virtualization to remove the dependence on integrated environments. Services are one route; a modular monolith qualifies too.

9. The failure mode worth memorizing is the distributed monolith: split into services that still test and ship together — all the cost of distribution, none of the independence. Practically, fix testability first, deployability second: shipping alone without verifying alone just pushes unverified work to production faster.

10. Calibration: voluntary survey plus inferential predictive analysis — directionally strong, not a randomized controlled trial; "architecture → performance" is very likely causal in both directions.