Module 1: What an Architect Really Does

Mini-project: diagnose and redesign the architect role at Mercado

Next →

Overview

This is the module's capstone. Over seven lessons you dismantled the four false images of the role and assembled the four real ones: the architect doesn't draw the blueprint and leave, but is present (lesson 2); doesn't live in the penthouse, but goes down to the code (lesson 3); doesn't sell certainties, but reversible decisions with their why (lesson 4); doesn't dictate, but enables with guardrails (lesson 5); doesn't become the bottleneck everything passes through (lesson 6); and doesn't commit BDUF, but decides at the last responsible moment (lesson 7). Now you apply all of that end to end to a real case: Mercado's current architect, who works badly —as many real people do— and whom you're going to diagnose and redesign.

The project's work is the real work of an architect who arrives at an organization and finds the role poorly practiced: diagnose what pathologies the current way of working suffers, measure their cost, and redesign the role so it works. Notice the frontier, which is deliberate: this project does not restructure the teams in depth (that's Conway, module 2), does not produce the C4 communication diagram (module 3), does not develop the techniques of leadership without authority (module 4). It produces what goes before all that: the diagnosis of the role and its redesign in a role charter —what the architect owns, what they delegate, how they enable— with the coordination cost measured before and after. It's the architect's "who does what", the base on which the following modules build.

Connection with the module. It's the integration of the seven lessons into a single executed deliverable. The ownership map uses lesson 1's classification; the diagnosis uses the four false images of lessons 2 to 7; the coordination cost uses lesson 6's queuing simulation; and the charter uses lesson 5's gardener model. On finishing it, you'll have the artifact that opens the architect's work in any organization: a role diagnosed and redesigned, with numbers. The next step —how to structure the teams to achieve the desired architecture— is literally module 2 (Conway).

The case: Mercado's current architect

Meet Alex, Mercado's current architect. Alex is brilliant and hardworking —not the villain of the story, but the majority of well-intentioned architects—. But they work like this:

  • They drew a highly detailed diagram of Mercado's "target architecture" eight months ago, presented it, and since then work off that diagram without updating it, even though the system no longer resembles it.
  • They haven't opened the repository in half a year; they decide and estimate from the meetings. Last week they estimated that moving orders to asynchronous communication "takes about three days".
  • They personally review and approve every technical decision from the five squads —"so quality doesn't drop"—, so the squads live waiting for their sign-off.
  • They want all of Mercado's decisions resolved in advance in their diagram, including the ones that depend on data that doesn't exist yet (the real load, how the catalog will split off).

Your job is to diagnose what pathologies Alex's role has, measure the cost of their way of working, and propose the redesign.

The reference solution, executed

We'll build the solution in a single program that does three steps: maps the ownership of the decisions, measures the coordination cost before and after the redesign, and emits the role charter. All with fixed data, reproducible.

Part 1 — The data: Mercado's typical week

We receive, per squad, how many decisions it generates in a typical week and how many of them cross squads (are architect-level). The rest are local:

# Project M1: diagnose the ROLE of Mercado's current architect and redesign it.
# Input: the decisions of a typical week per squad (total and cross-team) and
# how the CURRENT architect works (everything passes through them = bottleneck).
WEEKLY = {
    # squad -> (total, cross_team)
    "catalog":  (12, 1),
    "orders":   (10, 2),
    "payments": (8, 1),
    "shipping": (9, 1),
    "platform": (7, 2),
}
ARCHITECT_CAPACITY = 20
WEEKS = 8

Part 2 — The complete program

The three steps, chained. The ownership map (lesson 1), the coordination cost before (bottleneck, lesson 6) against after (guardrails, lesson 5), and the role charter:

total = sum(t for t, _ in WEEKLY.values())
cross = sum(c for _, c in WEEKLY.values())
local = total - cross

# Step 1: ownership map (who decides what).
print("=== Step 1: ownership map ===")
print(f"{'squad':<10}{'total':>7}{'cross->architect':>18}{'local->squad':>14}")
print("-" * 49)
for squad, (t, c) in WEEKLY.items():
    print(f"{squad:<10}{t:>7}{c:>18}{t - c:>14}")
print("-" * 49)
print(f"{'TOTAL':<10}{total:>7}{cross:>18}{local:>14}")


# Step 2: coordination cost BEFORE (bottleneck) vs AFTER (guardrails).
def simulate(arrivals, capacity, weeks):
    backlog = total_wait = 0
    for _ in range(weeks):
        backlog += arrivals
        backlog -= min(backlog, capacity)
        total_wait += backlog
    return backlog, total_wait


before_backlog, before_wait = simulate(total, ARCHITECT_CAPACITY, WEEKS)
after_backlog, after_wait = simulate(cross, ARCHITECT_CAPACITY, WEEKS)

print()
print(f"=== Step 2: coordination cost over {WEEKS} weeks ===")
print(f"{'role':<28}{'backlog':>10}{'wait(dec-wk)':>17}")
print("-" * 55)
print(f"{'BEFORE (all to the architect)':<28}{before_backlog:>10}{before_wait:>17}")
print(f"{'AFTER  (only cross-team)':<28}{after_backlog:>10}{after_wait:>17}")
print()
saved = before_wait - after_wait
print(f"Redesigning the role saves {saved} decision-weeks of wait and eliminates the backlog.")

# Step 3: role charter (what it owns, what it delegates, how it enables).
print()
print("=== Step 3: role charter of Mercado's architect ===")
print(f"OWNS    : the {cross} cross-team decisions/week (contracts between squads,")
print("          quality attributes, service limits).")
print(f"DELEGATES: the {local} local decisions/week to the owning squad, with guardrails.")
print("ENABLES : clear guardrails (internal REST, postgres, SLOs) + the why in an ADR.")
print("IS NOT  : ivory tower (goes down to the code), nor dictator, nor bottleneck.")

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

=== Step 1: ownership map ===
squad       total  cross->architect  local->squad
-------------------------------------------------
catalog        12                 1            11
orders         10                 2             8
payments        8                 1             7
shipping        9                 1             8
platform        7                 2             5
-------------------------------------------------
TOTAL          46                 7            39

=== Step 2: coordination cost over 8 weeks ===
role                           backlog     wait(dec-wk)
-------------------------------------------------------
BEFORE (all to the architect)      208              936
AFTER  (only cross-team)             0                0

Redesigning the role saves 936 decision-weeks of wait and eliminates the backlog.

=== Step 3: role charter of Mercado's architect ===
OWNS    : the 7 cross-team decisions/week (contracts between squads,
          quality attributes, service limits).
DELEGATES: the 39 local decisions/week to the owning squad, with guardrails.
ENABLES : clear guardrails (internal REST, postgres, SLOs) + the why in an ADR.
IS NOT  : ivory tower (goes down to the code), nor dictator, nor bottleneck.

Part 3 — The diagnosis, read from the run itself

Step 1, the ownership map. Of Mercado's 46 weekly decisions, only 7 cross squads —the contracts between services, the quality attributes, the service limits— and 39 are local, belonging to the squad that lives with them. This split is the root diagnosis of Alex's role: they treat the 46 as theirs ("I review and approve every technical decision"), when their level is 7. They're getting their hands into 39 decisions the squads make better than them, because they're closer to the problem. The map already says, with no further analysis, where the problem is: Alex confused "some decisions need my view" with "all of them pass through me".

Step 2, the coordination cost. Here the diagnosis becomes a number. With Alex's current role —the 46 decisions passing through them, capacity of 20/week— in 8 weeks a backlog of 208 stuck decisions and 936 decision-weeks of wait accumulates: the five squads spend a huge part of their time waiting for Alex's sign-off, who can't keep up no matter how hard they work. With the redesigned role —only the 7 cross-team ones go up, the 39 local ones the squads decide with guardrails— the backlog is 0 and the wait is 0. The redesign saves 936 decision-weeks and eliminates the jam. And the essential point, which you already know from lesson 6: the difference isn't that Alex works more or less —their capacity is 20 in both cases— it's how much work is made to pass through them. The redesign doesn't ask Alex to try harder; it asks them to stop being the mandatory step for the 39 decisions that aren't theirs.

Alex's four pathologies, named. The case describes an architect who suffers the four false images at once —not by chance, because they tend to come together—:

  • Ivory tower (lesson 2): they drew the diagram eight months ago and don't update it even though the system no longer resembles it. The blueprint stopped being a living hypothesis and became a dead document.
  • Detached from the code (lesson 3): half a year without opening the repository, and they estimate orders async at "three days" from the penthouse —the classic optimistic underestimation; the real change is around three weeks—.
  • Dictator and bottleneck (lessons 5 and 6): they review and approve every decision from the five squads, generating the 936 decision-weeks of wait step 2 measured.
  • BDUF (lesson 7): they want all decisions resolved in advance in their diagram, including the ones that depend on data that doesn't exist yet.

Step 3, the role charter. The redesign crystallizes into a four-line charter that splits the role. Alex owns the 7 cross-team decisions —where their cross-cutting view is unique and irreplaceable—. Delegates the 39 local ones to the owning squad, with guardrails. Enables with clear guardrails ("internal REST, Postgres, these SLOs") plus the why recorded in an ADR, so the squads decide their own with autonomy and judgment. And is not any of the four false images: goes down to the code (against the ivory tower and the penthouse), doesn't dictate nor is a bottleneck. That charter is the central deliverable: it turns the diagnosis into a concrete and executable role, with the measured cost that justifies the change.

This project is the step 0 of the craft in any organization. The charter doesn't close the architect's work; it launches it through the rest of the guide:

flowchart LR
    P["Project M1<br/>diagnosis + role charter<br/>(step 0: what the architect does)"] --> M2["M2<br/>Conway: structure<br/>the teams"]
    M2 --> M3["M3<br/>C4: communicate<br/>the architecture"]
    M3 --> M4["M4<br/>leadership without<br/>authority"]

Read it like this: here you define what the architect does and redesign their role; from there on, the guide teaches you to structure the teams to achieve the architecture (Conway), to communicate it (C4), and to lead without authority so the redesign holds.

Your delivery

Reproduce and adapt the reference solution. Your delivery has three pieces:

  1. The executed ownership map: the week's decisions split between the architect-level ones (cross-team) and the local ones, with the literal output of your program. You can use the example's data or —better— adjust one or two squads' decisions with your own numbers and see how the split changes.
  2. The diagnosis: name which of the four false images Alex suffers and with what evidence from the case, and present the coordination cost before/after (backlog and accumulated wait). The number —the 936 decision-weeks saved— is the argument for the redesign.
  3. The role charter: the four lines —OWNS / DELEGATES / ENABLES / IS NOT— adapted to Mercado. Be concrete in the guardrails you propose (not "do things well", but "internal REST, these SLOs, logs in JSON").

Common mistakes

Diagnosing Alex as a "bad architect" instead of naming structural pathologies. What happens: the delivery becomes a character judgment —"Alex is controlling, doesn't trust people"— instead of a diagnosis of the four false images with their measured cost. Why it happens: it's easier to blame the person than to analyze the structure, and the poorly-practiced role feels like a personal defect. How to spot it: if your diagnosis doesn't name the concrete pathologies (ivory tower, penthouse, bottleneck, BDUF) or measure their cost, it's a judgment, not a diagnosis. How to fix it: remember lesson 6 —the bottleneck is structural, not a character defect—. Alex is brilliant and hardworking; the problem isn't who they are but how their role is structured. A good diagnosis names the pathology, shows its cost (the 936 decision-weeks), and proposes the structural change (the charter), with no need to blame anyone. That, besides, is the only thing Alex can accept without getting defensive.

Producing a charter that "enables" but leaves Alex approving everything just the same. What happens: the charter says the right words ("delegates, enables with guardrails") but in practice proposes that Alex keeps reviewing everything "just to be sure", so the bottleneck survives under another name. Why it happens: it's tempting to soften the redesign so Alex doesn't "lose control", but that empties the charter of effect. How to spot it: if in your design the 39 local decisions still pass through Alex somehow (a "light" review, a "quick" OK), you redesigned nothing —the backlog would come back—. How to fix it: make the charter real: the 39 local ones the squads decide without passing through Alex, guaranteed by guardrails, not by their review. The lesson 5 muscle —tolerating decisions different from one's own— is what makes the charter true. A redesign where the architect remains the mandatory step isn't a redesign; it's the same funnel with new language.

Jumping from the diagnosis to solving Mercado's architecture. What happens: the delivery drifts into "and besides Mercado should split the catalog this way and use events over there", designing the system instead of redesigning the role. Why it happens: designing the system is every architect's reflex, and it's more "fun" than analyzing the role. How to spot it: if your delivery starts proposing Mercado's technical architecture (which service, which protocol), you left the project. How to fix it: remember the frontier. This project redesigns the architect's role —who decides what, at what cost—, not the system's architecture. How to structure the teams to achieve the architecture is module 2 (Conway); how to decide the protocol between orders and shipping is the sister guide. Here the object of design is the role, not the system.

Exercises

Exercise 1 — Adjust the week and re-measure. Mercado grows and adds a sixth squad, search, which generates 8 weekly decisions, 2 of them cross-team. Add it to the data, re-run the program mentally (or in code), and say how the total decisions, the ones going up to the architect, and —qualitatively— the current role's backlog change.

See solution

With search (8 total, 2 cross-team), the new numbers:

  • Total decisions: 46 + 8 = 54 per week.
  • Cross-team (to the architect): 7 + 2 = 9.
  • Local (to the squads): 39 + 6 = 45.

The redesigned role stays healthy: 9 arrive at the architect against a capacity of 20, so the backlog stays at 0. Adding a squad doesn't break the distributed model, because each squad absorbs its own local decisions with guardrails; only the few cross-team ones go up, and 9 is still well below 20.

The current role (bottleneck) clearly worsens: now 54 arrive at the architect against 20 of capacity, so 34 accumulate per week (before 26). The backlog grows faster and the accumulated wait rises. This illustrates the most important point of the redesign: the bottleneck model degrades with each squad added —it doesn't scale—, while the distributed model absorbs the growth without a problem. A funnel-architect becomes more unsustainable as the organization grows; a gardener-architect scales with it. That's why the redesign isn't just "more efficient today": it's the only thing that survives Mercado's growth. (How to structure that new squad and its boundaries is module 2, Conway.)

Exercise 2 — Write the guardrails that replace Alex's review. The charter says Alex "enables with guardrails" so the 39 local decisions don't pass through them. Choose three types of recurring local decision in Mercado and write, for each, the concrete guardrail that would let the squad decide alone —remembering lesson 5: define the what, not the how—.

See solution

Three concrete guardrails, each defining the what (the boundary where the decision affects others) and leaving the how to the squad:

  1. Decision: how a service exposes its internal API. Guardrail: "All communication between services is over REST on HTTP, with versioning in the path and responses in JSON." What it leaves to the squad: how it designs its resources, which endpoints, what internal structure of the responses, how it paginates. Why it enables: it guarantees interoperability (what affects other squads) without dictating the API design (which is the squad's).

  2. Decision: how a service handles its performance. Guardrail: "Each service meets an SLO of 99.9% availability and under 200ms p99 latency; above that, it's the squad's business." What it leaves to the squad: whether it uses cache, replicas, indexes, queues —any technique— to meet the SLO. Why it enables: it fixes the result that matters to Mercado (the quality attribute) and leaves the how to achieve it completely free. It's the best kind of guardrail (lesson 5).

  3. Decision: how a service emits its logs. Guardrail: "All logs are structured JSON with these minimum fields (timestamp, service, trace_id, level) so cross-cutting observability works." What it leaves to the squad: which logging library it uses, what extra fields it adds, how it structures them internally. Why it enables: it ensures the platform can correlate logs between services (cross-cutting) without dictating the tool (local).

With these three guardrails, dozens of decisions that used to pass through Alex —how I design my endpoint, which cache I use, which logs library— the squad makes alone, knowing that as long as it stays in the lane it's fine. The guardrails replace Alex's case-by-case review with a clear and stable boundary. Notice none of them says "do things well" (ambiguous, forces asking) nor fixes the how (disguised dictation); each puts the boundary exactly where the decision stops being local.

Exercise 3 — The conversation with Alex. You're going to present Alex with the diagnosis and the charter. Alex is brilliant, hardworking, and well-intentioned, and their probable first reaction is defensive ("I review everything because I care about quality"). Sketch how you'd present the redesign so they accept it, leaning on the number (the 936 decision-weeks) and without attacking them.

See solution

The key is that Alex isn't the villain —they're brilliant and they care—, so the redesign shouldn't sound like "you're doing it wrong" but like "there's a way for your concern for quality to scale". Something like:

Start by acknowledging their intention, which is good. "I know you review every decision because you care that Mercado's quality doesn't drop, and that concern is correct —in fact it's what a good architect must have—." This disarms the defensiveness: you're not attacking their value, you're validating it.

Show the number, not the blame. "The problem isn't you or your effort —you're already maxed out—. It's that the five squads generate 46 decisions a week and no one person can review all that; the arithmetic doesn't allow it. Look: with the current role, 208 stuck decisions and 936 decision-weeks of wait accumulate in two months. The squads spend that time waiting for you. It's not that you work little; it's that the structure makes you the mandatory step for more than fits in one person." The number depersonalizes: the enemy is the structure, not Alex.

Offer that their concern is met better, not less. "The quality you care about doesn't drop if you stop reviewing the 39 local ones; it rises, because the squads make them better than anyone —they're closer to the problem— and you focus on the 7 that really need your cross-cutting view, where you're irreplaceable. The guardrails guarantee the quality of the local ones without you having to review them one by one. Your concern for quality doesn't disappear; it becomes scalable." This reframes the redesign as meeting their objective better, not abandoning it.

Close with what Alex gains. "And this gives you something back: you'll be able to go down to the code again, do the spikes that make you estimate well, take vacations without Mercado stalling. You stop being the bottleneck and go back to being the architect."

The general principle: lean on the number so the enemy is the structure (not the person), reframe the redesign as meeting their value (quality) better instead of giving it up, and offer them what they gain. A brilliant, well-intentioned architect accepts a redesign that shows them, with evidence, that their intention is met better another way. (How to hold this kind of conversation that changes an architecture —the load-bearing conversations— and how to influence without authority is exactly module 4.)

Summary and next step

You closed the module by applying its complete content to a real case. You took Alex, Mercado's current architect —brilliant, hardworking, and trapped in the four false images at once—, and produced the artifact that opens the architect's work in any organization: an ownership map that separates the 7 architect-level decisions from the 39 local ones; a diagnosis that names the four pathologies (ivory tower, penthouse, bottleneck, BDUF) and measures their cost —936 decision-weeks of wait the redesign eliminates—; and a role charter that splits what the architect owns, delegates, and enables. You didn't redesign Mercado's architecture or its teams: you did the step 0 that defines what the architect does and at what cost.

With this, module 1 ends. You now know what the role is: not the one who draws the blueprint and leaves, but the one who is present, goes down to the code, sells reversible decisions with their why, enables with guardrails, avoids being the bottleneck, and decides at the last responsible moment. What follows in the guide is practicing that role. Module 2 attacks the craft's first tool: Conway's law —how the organization's communication structure shapes that of the system, and how the architect uses the inverse Conway maneuver to structure the teams and obtain the architecture they want—. The charter you just wrote says who decides what; Conway teaches you to structure the teams themselves so the desired architecture emerges from that structure. Then come communication (C4, module 3) and leadership without authority (module 4), which make the role you diagnosed here actually hold.

Resources

  • Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. The contrast between the architect who decides everything and the one who enables, which your charter formalizes. The reading that sums up the whole module. In English.
  • Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd ed. (O'Reilly, 2020), ch. 1–2 and 21–22 — what the role is and how an effective architect works with the teams instead of above them. The framework of this project's diagnosis and charter. In English.
  • Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020) — on the architect who connects floors, goes down to the code, and multiplies the team; the "IS NOT ivory tower nor penthouse" of your charter comes from here. In English.
  • Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019) — the framework of guardrails, enabled teams, and platforms that underpins the charter's "ENABLES", and the door to module 2 (Conway and the team types). In English.
← PreviousBDUF versus the last responsible momentNext →1. Module introduction: you ship your org chart