The ivory tower myth

Overview

Lesson 1 named the four false images of the role. This one takes apart the first and stickiest: the ivory tower. It's the image of the architect who locks themselves away, produces the system's perfect diagram, presents it as the architecture, and considers their work finished —"there it is, execute it"—. The name comes from the idea of someone who decides from an isolated height, without going down to the ground where things actually happen. And the problem isn't that the architect draws —drawing is useful—; the problem is believing that the drawing was the work, and that once delivered, reality is obliged to resemble it.

This myth is so common because it has an internal logic that sounds impeccable: "if I design the system correctly from the start, we avoid expensive mistakes later". The promise is prevention. But it rests on a false assumption: that at the moment of drawing you have —or can get— enough information to get it right. In a living system with five squads, stakeholders who change their minds, and a market that moves, that information doesn't exist yet when the blueprint is drawn. The day-one diagram isn't wrong out of carelessness; it's incomplete by chronology —it was made before reality spoke—. This lesson proves it with numbers: it measures how much of Mercado's "perfect diagram" survived contact with construction, and how much had to be redone.

Connection with the module. It's the first content lesson, and it attacks the most important false image because almost all the others come out of it. An ivory-tower architect is almost always also detached from the code (lesson 3, because they don't go down to the site), tends toward BDUF (lesson 7, because they believe in complete up-front design), and sometimes toward dictating (lesson 5, because they deliver a plan to execute instead of enabling). Here we install the correction at the root: the diagram is a hypothesis reality corrects, and the architect's work is the presence that corrects it, not the drawing that starts it. Watch the frontier: how to revise a decision when new information arrives (reversibility as a technique) is the sister guide architecture-decisions; here we work the stance —why the blueprint isn't the work—.

An analogy: the blueprint the ground corrects

Return to the building architect of lesson 1, but now look at a concrete build.

The architect delivers the blueprint of a house: the foundation here, the kitchen there, a big window in the living room facing the garden. It's an excellent blueprint —careful proportions, good light, everything in its place—. Then the build begins, and the ground starts to speak.

They dig the foundation and the soil is softer than the soil survey said: the foundations have to be reinforced, which changes the loads, which forces moving a load-bearing wall that was somewhere else in the blueprint. The supplier of the steel beams the blueprint specified is three months behind, so that part has to be redesigned with available material. The owner, seeing the opening of the big living-room window, realizes it faces straight onto the neighbor's brick wall —it looked gorgeous in the blueprint, in reality it's ugly— and asks to reorient it. And halfway through the build, the owner lands a better job in another city and wants an extra room as a home office.

An ivory-tower architect, facing all this, would say: "the blueprint is already signed, those are execution problems". And the house would come out crooked —or not come out at all—, because the blueprint stopped matching reality in the first week. A real architect does the opposite: they're on the site. They adjust the foundation when the soil speaks, rethink the structure when the material doesn't arrive, reorient the window when the real view demands it, redesign to fit the office when the owner changes their life. The blueprint they delivered on day one was a reasonable hypothesis with the information of the time. The house that gets built is the result of dozens of corrections the original blueprint didn't anticipate and couldn't anticipate.

The point is this: the day-one perfect blueprint was, guaranteed, partly wrong —not because it was badly drawn, but because it was premature—. The architect's value wasn't in the initial drawing; it was in the corrections. In software it's identical. Mercado's starting diagram —"catalog and orders share a database, orders calls shipping synchronously, a single payments provider"— is the day-one blueprint. Construction is the ground speaking. And the ivory tower is believing that, if the diagram was good, reality had to obey it.

Worked example: how much of the perfect diagram survives reality

We won't assert that the perfect diagram gets redone; we'll measure it. We take the ten design decisions an ivory-tower architect fixed in Mercado's diagram before building, without touching code, and mark which survived the collision with construction and which had to be redone:

# The "perfect diagram" an ivory-tower architect drew BEFORE building
# Mercado: 10 design decisions fixed on paper, without touching code.
# Weeks later, during the build, reality invalidated several.
# survived = True if the paper decision survived the collision with reality.
UPFRONT_DESIGN = [
    # (design_decision, survived_contact_with_reality)
    ("catalog_and_orders_share_one_db",    False),
    ("sync_call_orders_to_shipping",       False),
    ("single_payments_provider_forever",   False),
    ("search_runs_on_the_main_db",         False),
    ("one_team_owns_everything",           False),
    ("rest_between_internal_services",     True),
    ("postgres_as_the_primary_store",      True),
    ("http_load_balancer_at_the_edge",     True),
    ("daily_batch_for_all_analytics",      False),
    ("sessions_kept_in_app_memory",        False),
]

survived = sum(1 for _, ok in UPFRONT_DESIGN if ok)
total = len(UPFRONT_DESIGN)
pct = round(100 * survived / total)

print(f"{'upfront design decision':<38}{'survived reality?':>18}")
print("-" * 56)
for decision, ok in UPFRONT_DESIGN:
    print(f"{decision:<38}{('yes' if ok else 'NO -> reworked'):>18}")

print()
print(f"{survived} of {total} perfect-diagram decisions survived ({pct}%).")
print(f"{100 - pct}% was redone during the build. The blueprint wasn't the problem;")
print("believing that drawing it ONCE and leaving was the work, was.")

What to expect. Running the file, the output is exactly this:

upfront design decision                survived reality?
--------------------------------------------------------
catalog_and_orders_share_one_db           NO -> reworked
sync_call_orders_to_shipping              NO -> reworked
single_payments_provider_forever          NO -> reworked
search_runs_on_the_main_db                NO -> reworked
one_team_owns_everything                  NO -> reworked
rest_between_internal_services                       yes
postgres_as_the_primary_store                        yes
http_load_balancer_at_the_edge                       yes
daily_batch_for_all_analytics             NO -> reworked
sessions_kept_in_app_memory               NO -> reworked

3 of 10 perfect-diagram decisions survived (30%).
70% was redone during the build. The blueprint wasn't the problem;
believing that drawing it ONCE and leaving was the work, was.

Read the table slowly, because it separates two classes of decision the ivory-tower architect treated the same.

The three that survived —rest_between_internal_services, postgres_as_the_primary_store, http_load_balancer_at_the_edge— have something in common: they're decisions of base technology and broad conventions that didn't depend on knowing the detail of the load or the business. Choosing REST for internal communication, Postgres as the store, an HTTP load balancer at the edge: these are solid bets that almost any later information would have confirmed. The day-one diagram can get this right, because they're decisions whose evidence already existed on day one.

The seven that were redone are another matter. That catalog and orders share a database sounded simple on paper —one database, fewer things to maintain—, but during the build it ran into the two squads stepping on the same tables and blocking each other. That orders called shipping synchronously looked direct in the diagram, until in production a slowness in shipping started taking down checkout. A single payments provider "forever" broke the first day that provider had an outage. Search on the main database held up until the volume brought it to its knees. "One team owns everything" fell apart the moment there were five squads. None of these seven was redone because the architect was bad; they were redone because their evidence didn't exist on day one —it lived in construction, in the real load, in how the squads actually organized—.

And there's the number that gives the lesson its name: 70% of the perfect diagram was redone. Seven of every ten strokes of the initial blueprint didn't survive the ground. I repeat the nuance because it's the heart of everything: that does not mean planning is useless, nor that the architect should have drawn nothing. It means treating the diagram as a finished deliverable —drawing it, presenting it, leaving— was the wrong stance. The diagram is valuable as a starting hypothesis; it's harmful as a prophecy to execute. The difference between the two is whether the architect stays to correct it.

Seen as bars, the split jumps out:

Mercado's perfect diagram: 10 decisions fixed before building
 survived    (3)  |######                          30%
 reworked    (7)  |##############                  70%
                  ─────────────────────────────
 conclusion: the day-one blueprint was 70% hypothesis, not plan.

Deep dive: why the ivory tower is so tempting (and so expensive)

If the perfect diagram gets redone so much, why is the ivory tower still the dominant image of the architect? Because it has three powerful attractions, and it's worth naming them to resist them.

It produces something visible. The architect's real work —being present, adjusting, conversing with the squads, correcting course week by week— is diffuse and doesn't show. A diagram, by contrast, is an artifact: it's printed, stuck on the wall, presented in a meeting with executives who nod. In a culture that rewards "deliverables", the diagram feels like producing, and presence feels like doing nothing concrete. The ivory-tower architect isn't lazy; often they're the most diligent, only diligent at what's seen instead of what works.

It confuses precision with correctness. A detailed diagram —every service, every queue, every database— looks more rigorous than a sketch with three boxes and a note saying "we'll decide this when we know the load". But the drawing's precision has no relation to its correctness: a highly detailed blueprint made without the necessary information is precisely detailed and wrong. Worse: the more detailed the diagram, the more expensive it is to admit it has to be redone, because more work seems to be thrown away. Premature precision isn't rigor; it's commitment to a hypothesis ahead of time (exactly the BDUF myth, lesson 7).

It protects from uncomfortable contact. Going down to the site is uncomfortable: it means discovering your blueprint was wrong, that the orders squad disagrees, that the soil was softer. Staying in the tower —in the high-level meetings, in the slides— avoids that friction. It's more comfortable to defend an abstract diagram than to sit with the payments squad to see why the single provider is wrecking them. The ivory tower, besides prestigious, is comfortable: it isolates from the ground where the architect really gets their hands dirty.

And there's a cadence that distinguishes the two stances. The building architect doesn't visit the site once nor every day: they visit it with a rhythm —when pouring the foundations, when raising the structure, when closing the walls—, at the moments where an early correction saves a late disaster. The software architect is the same: they don't reappear only at the end (ivory tower) nor settle in to code full-time (the opposite error of lesson 3); they establish a rhythmic presence at the milestones where the ground speaks —when a squad implements the contract between orders and shipping, when the catalog splits off, when the real load arrives—. That cadence is what turns "being present" from a good intention into a practice: scheduled moments where the blueprint is checked against what's built and corrected in small increments. Without cadence, presence dilutes and the architect ends up, without meaning to, back in the tower.

The cost of all this is double, and compound. First, the direct rework: the seven decisions that were redone cost time and money that a present architect would have reduced by correcting earlier, in small increments, instead of later, in big ones. Second —and worse— the credibility cost: when an architect delivers a blueprint and disappears, and construction contradicts it, the squads learn that the architect's diagram "doesn't apply in practice", and stop taking it seriously. The ivory-tower architect ends up irrelevant not because their ideas were bad, but because their way of working disconnected them from where ideas become system. The architect's authority doesn't come from the title or the diagram; it comes from being on the ground enough for their word to match reality. That's what the ivory tower destroys.

The practical correction: treat the diagram as a hypothesis with a revision date. Don't stop drawing —the starting sketch orients everyone and is valuable—. Change what you believe it is: instead of "this is the design, execute it", say "this is our best hypothesis with what we know today; these three strokes (the shared database, the synchronous call, the single provider) are the ones I doubt most, and we'll revise them when construction gives us data". Mark on the diagram itself what's firm and what's tentative. And schedule your presence: the real architect blocks time to be on the site —reviewing how construction is going, sitting with the squads— not as an interruption of their "real work", but as their real work. The diagram opens the conversation; it doesn't close it.

Common mistakes

Presenting the diagram and disappearing. What happens: the architect invests weeks in the diagram, presents it in a big meeting, then goes off to design something else while the squads build; they reappear months later, see that what's built doesn't resemble their blueprint, and get frustrated —"they didn't follow the architecture"—. Why it happens: they believe their work was the diagram, so once delivered, they feel finished. How to spot it: if the architect only appears at the start and end of a project, or if there's a big and surprising gap between the diagram and what's built, there was an ivory tower. How to fix it: understand that delivering the diagram is the start of the work, not the end; schedule presence during construction; and expect —and plan for— 70% of the blueprint to be adjusted, correcting it in small increments and on time instead of discovering the whole gap at the end.

Confusing a detailed diagram with good architecture. What happens: the architect's quality is judged by how complete and polished their diagram is —"look how much detail, how professional"—, when that detail was produced without the information to get it right. Why it happens: visual precision reads as rigor, and a full drawing impresses more than one with honest gaps. How to spot it: if the diagram specifies with total certainty things that depend on data that doesn't exist yet (the real load, how the squads will organize, which provider holds up), it's premature precision. How to fix it: prefer a diagram that marks its own uncertainties —"this is firm, this is tentative until we have data X"— over one that fakes certainty in everything. An honest sketch about what isn't known is worth more than a detailed blueprint that will be 70% redone.

Defending the blueprint instead of correcting it. What happens: when construction contradicts the diagram, the architect insists the problem is execution —"the blueprint was fine, they did it wrong"— instead of recognizing that the blueprint found new information. Why it happens: admitting the diagram was wrong feels like admitting incompetence, when in reality it's expected (the 70%). How to spot it: if the architect reacts to construction surprises with "that's not how the design was" instead of "interesting, let's adjust", they're defending the tower. How to fix it: treat every contradiction between blueprint and reality as the site speaking —exactly what the building architect welcomes, not what they fight—. The soft soil isn't the builder's mistake; it's information the blueprint didn't have. Correcting the blueprint in response to it is doing the work, not failing at it.

Exercises

Exercise 1 — Which strokes of the blueprint would you mark as tentative? Of the ten decisions in Mercado's diagram, three survived (rest_between_internal_services, postgres_as_the_primary_store, http_load_balancer_at_the_edge) and seven were redone. If you had to draw that starting diagram well —as an honest hypothesis, not a prophecy—, which would you mark as "firm" and which as "tentative until more data", and by what criterion?

See solution

The criterion is: does the evidence to get this decision right already exist on day one, or does it live in construction?

• I'd mark as firm the three that survived, plus any of the same nature: decisions of base technology and broad convention whose evidence already exists (internal REST, Postgres, HTTP load balancer). They don't depend on knowing the real load or how the squads will organize; they're solid bets construction hardly changes.
• I'd mark as tentative the seven that were redone, because each depends on data that doesn't exist on day one: whether catalog and orders share a database depends on whether they really step on the same tables (learned during the build); synchronous vs. events between orders and shipping depends on behavior under load (learned in production); a single payments provider depends on its real availability; search on the main database depends on volume; "one team owns everything" depends on how many squads end up existing.

The honest diagram doesn't have fewer boxes; it has confidence labels. Firm for what the evidence already supports; tentative for what construction will decide. That turns the blueprint from a prophecy into a hypothesis with marked revision points —exactly the opposite of the ivory tower—.

Exercise 2 — The meeting with the VP. The VP of product sees Mercado's starting diagram, loves it, and says: "perfect, so this is the architecture, let's freeze it and have the teams execute it exactly for the year". As the architect, what do you answer, without sounding like you "don't have a plan"?

See solution

The answer has to do two things at once: not destroy the VP's confidence that there's a direction, and not accept freezing a hypothesis as if it were a plan.

Something like: "I'm glad the diagram communicates the direction well —that's what I drew it for—. And yes, we have a plan, but the plan includes how we're going to adjust it. This diagram is our best hypothesis with what we know today; there are three or four strokes —how orders talks to shipping, whether the catalog stays next to orders— that depend on data only construction will give us. Freezing them now would force us to execute decisions made blind, and we'd pay for them in rework. What I propose is firm on direction and flexible on those points: we move forward, and when construction gives us the data, we revise those specific strokes. That way we're not going without a plan; we're going with a plan that learns."

The key is to reframe "adjusting" not as "not having a plan" but as part of the plan. A VP understands well the idea of a market hypothesis that gets corrected with data; architecture is the same. Freezing the diagram would be the ivory tower agreed with the business, and the squads would pay for it. (How to communicate this with the right diagram for their level is module 3; how to decide those strokes when the data arrives is the sister guide.)

Exercise 3 — Ivory tower vs. presence, in a real decision. The orders squad tells you, mid-construction, that the database shared with catalog (which your diagram fixed) is blocking them: the two squads clash on the same tables. Describe how an ivory-tower architect would react and how a present architect would react, and why the second reaction is the one that does the role.

See solution

Ivory tower: "The design says shared database for a reason —less infrastructure to maintain—. The problem is coordination between the squads; agree not to step on each other. The blueprint is fine." They defend the diagram and hand the problem back as an execution failure. Likely result: the squads keep blocking each other, learn the architect doesn't go down to the ground, and solve it on their own —maybe worse than the architect would have solved it had they been present—.

Present architect: they go down to the site. They sit with the two squads, look at the concrete tables where they clash, and recognize that the shared database —a reasonable hypothesis on paper— found new information: catalog and orders have rhythms and data different enough that sharing a database generates real friction. From there, they help decide the adjustment (separate the data, or define clear limits of which table is whose) with the squads, not above them. They correct the blueprint with the ground that spoke.

The second is the one that does the role for two reasons. First: the shared database was a hypothesis (one of the seven strokes that get redone), and the friction orders reports is exactly construction giving the data that didn't exist on day one —correcting in response to that data is the work, not the failure—. Second: the architect's authority holds only if their word matches reality; defending the blueprint against the evidence makes them irrelevant, while going down to solve it with the squads builds the credibility on which everything else the architect wants to influence depends. (How to compare the separation options is the sister guide; that you have to be there to do it is this lesson.)

Summary and next step

In this lesson you took apart the stickiest false image of the role: the ivory tower, the architect who draws the perfect diagram and leaves. You saw, with the blueprint the ground corrects, that the day-one diagram is a hypothesis made before reality spoke, and that's why it's guaranteed to be incomplete —not out of carelessness, but by chronology—. And you measured it: of the ten decisions in Mercado's starting diagram, only 30% survived the build; 70% was redone. The blueprint wasn't the error; believing that drawing it once and leaving was the work, was. The real architect treats the diagram as a hypothesis with a revision date and does their work in the presence that corrects it.

Before moving on you should be able to: explain why the perfect diagram gets redone so much without that meaning planning is useless; distinguish the decisions that can be gotten right on day one (technological base) from those that depend on construction; and recognize the ivory tower's three attractions (it produces something visible, it confuses precision with correctness, it protects from uncomfortable contact) in order to resist them.

Lesson 3 follows the natural thread: if the architect must be on the site to correct the blueprint, they have to be able to go down to the site —to the code—. We'll see Gregor Hohpe's architect elevator: going up to the business penthouse and down to the code's machine room, and why an architect who stays up top estimates badly and decides about a system that no longer exists. With numbers: how the estimation error grows when the architect detaches from the code.

Resources

• Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. The source of the module's central contrast. The "Architectus Reloadus" who decides from above and expects it to be executed is this lesson's ivory tower. In English.
• Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020) — the whole book is an argument against the ivory tower: the architect who stays in the penthouse loses contact with the machine room and their decisions become unreal. Lesson 3 develops its metaphor. In English.
• Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd ed. (O'Reilly, 2020), ch. 2 "Architectural Thinking" — on why the architect must maintain technical contact and why architecture is a flow of decisions, not a frozen artifact. In English.
• Martin Fowler, "Is Design Dead?" — martinfowler.com/articles/designDead.html. On why evolutionary design beats complete up-front planned design, and how a plan is a hypothesis that gets adjusted. It complements this lesson's thesis and anticipates module 7 (BDUF). In English.