Module 8: Capstone Project — Be Mercado's Architect Through a Change

2. Frame the role and the assignment

Overview

This is step 1 of the deliverable, and it's the one almost everyone skips: before deriving an attribute, drawing a box, or structuring a team, the architect has to frame two things —what their role is in this change and what the assignment is—. It sounds obvious, but it's the step where you decide whether the change will have an architect who enables or a bottleneck who chokes. The leadership sentence —"open Mercado to external sellers via API and grow 10x"— isn't an instruction the architect executes with their own hands: it's an assignment that unleashes a wave of decisions, and the architect's job isn't to make them all, but to separate the few that are theirs (those that cross teams, shape the structure, define contracts) from the many they delegate (the local ones, which the owning squad makes better because it's closer to the problem). By the end of this lesson you'll have the deliverable's first artifact: the ownership map of the change, with the coordination cost measured of doing it well against doing it wrong.

This matters because the biggest risk of a big change isn't technical, it's structural in the architect's role: the temptation to "review everything so quality doesn't drop" turns the architect into the mandatory step of every decision, and with that it kills the change in two ways at once —it slows it (everything waits for their approval) and it worsens it (the squads, which knew more, stop deciding)—. Module 1 taught you this in the abstract with Álex, Mercado's architect trapped in the four false images. Here you apply it to the concrete change: a change that touches all five squads and adds new actors generates dozens of decisions per week, and no single person can be the funnel for all of them without becoming the bottleneck that module 1 itself swore to avoid. Framing the role well is what makes everything else possible: only an architect who isn't drowning in 46 weekly decisions has the time and the head to derive attributes, structure teams, and lead the rollout.

Connection with the module: this lesson does step 1 of the thread you saw in lesson 1, and contributes the M1 piece to the capstone. It's deliberately first, because it frames the role with which you'll do everything else: if here you decide to be the funnel, you won't reach step 3 alive. This lesson's output —the map of what the architect owns and what they delegate— feeds directly into lesson 4 (the inverse Conway maneuver): the local decisions you delegate here are the ones that there become the responsibility of teams with clear boundaries. And it prepares lesson 6 (the rollout without authority): the architect who here defines themselves as a gardener is the one who there will be able to lead without being the door. Here you don't derive attributes yet (that's lesson 3); here you decide who decides what in the change.

The site manager who doesn't lay the bricks

Think of the construction of a big building. There's a site manager, and there are many trades: masons, electricians, plumbers, carpenters, each an expert in their own. The client's assignment is a sentence: "I want a ten-story office building, ready in eighteen months". From that sentence come thousands of decisions: what gauge of cable on each floor, how the third-level bathroom pipe is routed, what kind of hinge on the doors, where each outlet goes. A novice site manager, anxious for "everything to come out perfect", tries to approve every one of those decisions: no electrician connects a cable without their approval, no plumber welds a joint without them reviewing it. What happens? The site stops. The trades spend the day waiting for the manager, who runs from floor to floor unable to keep up, and since he's neither an electrician nor a plumber, his approvals don't even improve the decisions —they only delay them—.

The site manager who knows their craft does the opposite. They recognize that of those thousands of decisions, only a few are theirs: where the load-bearing walls go (because they affect the whole building), how the systems connect between floors (because they cross trades), which safety codes are non-negotiable (because they're high-risk). Those they own, because they have a view of the whole that no trade has. All the others —the cable gauge, the pipe route, the hinge— they delegate to the expert trade, giving them a clear rule ("every cable meets this code", "every pipe holds this pressure") instead of reviewing each joint. So the site flows: the trades decide their own with autonomy within the rules, and the manager concentrates on the few structural decisions where their view of the whole is irreplaceable.

The architect facing "open Mercado to external sellers" is that site manager. The assignment unleashes dozens of decisions per week, and the trap is wanting to approve them all "so quality doesn't drop". The craft is separating the load-bearing walls —the contracts between services, the boundaries of the Seller API, the quality attributes, the security of third-party data— that the architect owns, from the hinges —how each squad implements its own internals— that they delegate with guardrails. This lesson is drawing that map and measuring, with numbers, how much it costs to get the role wrong.

Worked example: the ownership map of the change, measured

We're going to frame the assignment in three executed steps. First, translate the change into the set of decisions it generates per week, separating the cross-team ones (architect-level: contracts, service boundaries, attributes) from the local ones (of the owning squad). Second, measure the coordination cost of two ways of exercising the role: the funnel-architect who owns the 46, against the gardener-architect who owns only the 8 cross-team and delegates the 38 with guardrails. And third, show why centralizing doesn't scale —why the architect can't be the single channel everything passes through—.

# Capstone step 1: understand the ROLE and the ASSIGNMENT before designing anything.
# The change "open to external sellers + grow 10x" unleashes a wave of decisions.
# The architect's question is NOT "what do I decide": it's "which ones are MINE (load-bearing,
# cross-team) and which do I delegate to the owning squad with guardrails" -- so I don't become
# the bottleneck the whole change has to pass through.

# Decisions the change generates in a typical week, per squad: (total, cross_team).
# The cross-team ones are architect-level (contracts, service boundaries, attributes);
# the rest are local, of the squad that lives them.
change_decisions = {
    "catalog":  (14, 2),   # the 10x of listings hits the catalog more than anyone
    "checkout": (9, 1),
    "payments": (8, 2),    # payments and payouts to external sellers
    "shipping": (7, 1),
    "platform": (8, 2),    # api gateway, third-party auth, rate limiting
}
ARCHITECT_CAPACITY = 12   # decisions one person can attend to per week
WEEKS = 10                # the rollout horizon

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

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


# Coordination cost: funnel-architect (owns the 46) vs gardener-architect
# (owns only the 8 cross-team, delegates 38 with guardrails). Same capacity in both.
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


bl_bottleneck, wait_bottleneck = simulate(total, ARCHITECT_CAPACITY, WEEKS)
bl_garden, wait_garden = simulate(cross, ARCHITECT_CAPACITY, WEEKS)

print()
print(f"=== Step 2: coordination cost over {WEEKS} weeks ===")
print(f"{'architect role':<30}{'backlog':>10}{'wait(dec-week)':>17}")
print("-" * 57)
print(f"{'FUNNEL    (owns the 46)':<30}{bl_bottleneck:>10}{wait_bottleneck:>17}")
print(f"{'GARDENER  (owns 8 cross-team)':<30}{bl_garden:>10}{wait_garden:>17}")
print()
print(f"Delegating the local saves {wait_bottleneck - wait_garden} decision-weeks and eliminates the backlog.")


# Why centralizing doesn't scale: if EVERYTHING passes through the architect, they're a
# bottleneck with many channels. And the change GROWS the organization (a new squad for the
# sellers surface). The coordination channels between squads grow n(n-1)/2.
def paths(n):
    return n * (n - 1) // 2


print("=== Step 3: why the architect can't be the single channel ===")
for squads in (5, 6):
    print(f"  {squads} squads  ->  {paths(squads)} coordination channels between squads")
print(f"  A mega-team of 12 people ->  {paths(12)} internal channels")
print(f"  Two teams of 6 people    ->  {paths(6)} + {paths(6)} = {paths(6)*2} internal channels")
print("The architect who approves everything becomes the hub ALL the channels pass through:")
print("it doesn't scale. The role is to own the 8 load-bearing decisions and structure teams")
print("(module 2) so the 38 local ones flow without them. That's the assignment, well framed.")

What to expect. Running it:

=== Step 1: ownership map of the change ===
squad       total  cross->architect  local->squad
-------------------------------------------------
catalog        14                 2            12
checkout        9                 1             8
payments        8                 2             6
shipping        7                 1             6
platform        8                 2             6
-------------------------------------------------
TOTAL          46                 8            38

=== Step 2: coordination cost over 10 weeks ===
architect role                   backlog   wait(dec-week)
---------------------------------------------------------
FUNNEL    (owns the 46)              340             1870
GARDENER  (owns 8 cross-team)          0                0

Delegating the local saves 1870 decision-weeks and eliminates the backlog.
=== Step 3: why the architect can't be the single channel ===
  5 squads  ->  10 coordination channels between squads
  6 squads  ->  15 coordination channels between squads
  A mega-team of 12 people ->  66 internal channels
  Two teams of 6 people    ->  15 + 15 = 30 internal channels
The architect who approves everything becomes the hub ALL the channels pass through:
it doesn't scale. The role is to own the 8 load-bearing decisions and structure teams
(module 2) so the 38 local ones flow without them. That's the assignment, well framed.

Read step 1 first, because it's the root diagnosis. The change generates 46 decisions per week, and of them only 8 cross teams —the Seller API contracts, the boundaries between the sellers surface and the catalog, the rate limiting policy, third-party auth, the handling of payouts—. The other 38 are local: how the catalog indexes internally to withstand 10x more listings, what cache the checkout uses, how payments structures its payout tables. That split already tells you what your role is: the 8, not the 46. Notice that the catalog contributes 12 local decisions —it's the squad the 10x of listings hits most— and only 2 cross-team; the architect doesn't need to get into the 12, those catalog decides better than anyone because it lives them. The map separates, without further analysis, the load-bearing walls from the hinges.

Now step 2, where the diagnosis becomes a number and hurts. With the funnel role —the architect owns the 46, capacity of 12 per week— in 10 weeks a backlog of 340 stuck decisions and 1870 decision-weeks of waiting accumulate: the five squads spend a huge part of the rollout waiting for the approval of an architect who can't keep up no matter how hard they work. With the gardener role —only the 8 cross-team go up, the 38 local ones the squads decide with guardrails— the backlog is 0 and the wait is 0. The same capacity (12) in both cases; the only thing that changes is how much work is made to pass through the architect. Delegating the local saves 1870 decision-weeks and eliminates the jam. It's not that the gardener works more; it's that they stopped being the mandatory step of 38 decisions that weren't theirs. This is exactly module 1's result (the bottleneck is structural, not an effort defect), now measured on this change.

And step 3 explains why the funnel trap gets worse precisely when the change grows. The coordination channels between squads grow as n(n-1)/2: with 5 squads it's 10, and since the change adds a new team for the sellers surface (you'll see it in lesson 4), with 6 squads it's 15. If the architect insists on being the single channel, they become the hub all those channels pass through —and that hub doesn't scale: it grows with each squad and each decision—. The last line names the way out: the role is to own the 8 load-bearing decisions and structure the teams (which is step 3, the inverse Conway maneuver) so the 38 local ones flow without them. Notice the data on teams: a mega-team of 12 people has 66 internal channels; two teams of 6 have 30 total —less than half—. That's the seed of why the change needs a new, small team, not inflating an existing one. The assignment, well framed, is "I own 8, I delegate 38, and so the 38 flow without me, I structure the organization" —and that's the bridge to lesson 4—.

Deep dive: what makes a decision the architect's

The map depends on a classification —cross-team vs local— that's worth making precise, because it's the central judgment of this lesson. What makes a decision of the change architect-level and not the squad's? Three tests, the same ones module 5 used for the architecturally-significant requirements, applied here to decisions.

First: does it cross team boundaries? A decision is the architect's if its outcome forces coordinating more than one team or defines how they talk to each other. The Seller API contract is architect-level because everyone who consumes it depends on it; the internal format of the catalog's listings table isn't, because only catalog touches it. The rule: if changing the decision breaks another team, it's load-bearing; if it only affects whoever makes it, it's local. In Mercado's change, the 8 cross-team are precisely the ones that define the boundaries of the new surface with the rest of the system.

Second: does it shape the structure and is it expensive to reverse? A decision is the architect's if it defines a seam that will later be expensive to move. "The Seller API is exposed behind a gateway with a versioned contract" shapes the whole architecture of the surface and is very expensive to change once there are integrated third parties; "the catalog uses this inverted index" is reversible within catalog without anyone outside noticing. The architect puts their energy where the mistake is expensive and permanent, not where it's cheap and local. This test is the one that avoids the other extreme: not every "important" decision is the architect's —many are important to the squad but trivial to the structure—.

Third: is it high cross-cutting risk? A decision is the architect's if a mistake propagates beyond the team that makes it —security of third-party data, a quality attribute everyone must meet, a boundary that if broken brings down the whole system—. The auth of external sellers is architect-level because a failure there compromises the whole platform; the color of the "publish product" button in the seller panel isn't, however visible it is. Cross-cutting risk, not visibility, is what raises a decision to the architect.

With these three tests, the classification stops being by eye. And here's the fine point: most of the decisions of a change, even a big one, are local. In Mercado, 38 of 46. That's not a coincidence of the example; it's the reality of almost any change, and it's liberating —it means the architect doesn't have to (and can't) touch most of the work—. The funnel's mistake is not believing this: feeling that "everything's important, so everything's mine". The gardener's discipline is applying the three tests honestly and discovering that most decisions pass all three with a "no" —they're hinges, not load-bearing walls— and are therefore not theirs.

An honest nuance about the model. The numbers (46 decisions, 8 cross-team, capacity 12) are an illustrative judgment, not a measurement of Mercado, and the queuing model is a simplification —it treats all decisions as equal in cost, when some take minutes and others days—. What the model captures isn't an exact prediction of weeks, but the structure of the problem: making much more work pass through a single person than fits produces a backlog that grows without ceiling, and the remedy isn't for the person to run faster (the capacity is the same in both scenarios) but to make less pass by delegating what isn't theirs. That shape —the funnel's jam against the gardener's flow— is robust even if the exact numbers are debatable.

Common mistakes

Classifying too many decisions as "the architect's" out of fear for quality (of the funnel). What happens: the architect, facing a big and risky change, marks almost all the decisions as cross-team "because this change is delicate", and ends up with a map where they own 30 of 46. The result is the backlog of 340 and the 1870 decision-weeks of waiting. Why it happens: an important change feels as if everything in it were important, and delegating is scary. How to spot it: if your "cross-team" column has more than a handful of decisions per squad, you didn't classify, you got scared. How to fix it: run the three tests (does it cross boundaries?, does it shape and is it expensive to reverse?, cross-cutting risk?) honestly; most decisions of any change are local, and treating them as your own is the mistake that chokes the change, not the one that protects it.

Delegating without guardrails and calling it "empowering" (of abandonment). What happens: the architect, understanding they must delegate, releases the 38 local decisions with no rule —"you decide, I trust you"— and the squads make incompatible decisions among themselves (each exposes its API differently, each logs its own way), and the system fragments. Why it happens: delegating (giving autonomy within a boundary) is confused with abandoning (releasing with no boundary). How to spot it: if you delegated a decision but can't name the guardrail that channels it, you abandoned it. How to fix it: each local delegation comes with a guardrail that fixes the what (the outcome that matters to the whole) and leaves the how to the squad —"all communication between services is via a versioned contract", not "make good APIs"—; the gardener doesn't review each decision, they set the lanes within which the squad decides on its own.

Starting with the architecture without framing the role (of skipping step 1). What happens: the architect, excited about the change, jumps straight to designing the sellers surface without having decided which decisions are theirs, and without realizing they get into deciding local things (how the catalog indexes, what cache the checkout uses) that aren't theirs, reintroducing the funnel through the back door. Why it happens: designing is more attractive than framing the role, which feels bureaucratic. How to spot it: if you're making decisions that only affect one squad internally, you left your role. How to fix it: do step 1 before anything —the ownership map—; it tells you exactly which 8 decisions to get into and which 38 not, and it protects you from reintroducing the funnel while you design.

Exercises

Exercise 1 — Classify five decisions of the change. For each of these decisions that Mercado's change unleashes, say whether it's cross-team (the architect's) or local (the squad's), applying the three tests: (a) the JSON contract schema the Seller API exposes to third parties; (b) what HTTP library the catalog service uses internally to call the database; (c) the policy of how many requests per minute an external seller can make (rate limiting); (d) the column names of payments' internal payouts table; (e) the availability level (SLO) the Seller API must meet.

See solution

(a) The Seller API JSON contract → cross-team (the architect's). It crosses boundaries (all third parties and several internal services depend on it), shapes the structure and is very expensive to change once there are external integrators, and a mistake is high cross-cutting risk. It passes all three tests: it's a load-bearing wall.
(b) The catalog's internal HTTP library → local (the squad's). It doesn't cross boundaries (no one outside catalog sees it), doesn't shape the system's structure (it's reversible within catalog), and a mistake only affects catalog. It fails all three tests: it's a hinge. Catalog decides it.
(c) The rate limiting of external sellers → cross-team. It crosses boundaries (it protects the whole system from a third party's abuse), is high cross-cutting risk (without it, a seller could take down the platform), and is a policy that shapes how the surface is exposed. The architect's.
(d) The column names of the payouts table → local. It's internal to payments, reversible without anyone outside noticing, and a mistake is contained in payments. A hinge. Payments decides it —as long as the payouts contract (cross-team) is well defined; the internal column name isn't—.
(e) The Seller API's SLO → cross-team. It's a quality attribute other teams and third parties take for granted, it crosses boundaries (it defines what those who depend on the API can expect) and is high cross-cutting risk. The architect's, and in fact it connects with step 2 (deriving attributes): the SLO comes from the prioritized attributes.

The pattern: decisions about contracts, cross-cutting policies, and quality attributes are the architect's; decisions about the inside of a service (libraries, internal schemas, implementation techniques) are the squad's. Four of these five turned out easy once the three tests were applied; (d) is the trap —it sounds "data-related, important"— but the internal name of a column doesn't cross boundaries or shape anything outside.

Exercise 2 — The funnel that grows with the change. Step 3 showed that with 6 squads there are 15 coordination channels between teams. Suppose the change turns out so big that Mercado adds two new teams (reaching 7 squads), and the architect keeps insisting on approving each cross-team decision alone. Without running the code, calculate the channels between squads with 7 teams and argue why the funnel problem isn't linear but gets worse with growth.

See solution

Channels with 7 squads: 7 × 6 / 2 = 21 coordination channels between teams. Compared to the 15 of 6 squads and the 10 of 5 squads, the progression is 10 → 15 → 21: each squad that joins adds more channels than the previous one (5, then 6), because the new team has to coordinate with all those already there.

Why the funnel isn't linear. If the architect is the single channel —the hub all the coordination passes through—, their load doesn't grow with the number of squads but with the number of channels, which grows as n(n-1)/2, that is, quadratically. Going from 5 to 7 squads (40% more teams) almost doubles the channels (from 10 to 21). An architect who barely kept up with 5 squads is completely buried with 7, not because there's 40% more work, but because there's more than double the coordination crossing their desk. The funnel degrades faster than the organization grows.

The conclusion for the role. This is exactly why the well-framed assignment doesn't say "the architect approves all cross-team decisions", but "the architect structures the teams so the coordination that really needs to pass through them is minimal". The answer to growth isn't an architect who runs faster (impossible against a quadratic curve), but a designed organization —the inverse Conway maneuver of step 3— where each team owns its surface and coordinates via stable contracts, so the architect isn't in most of the channels. Step 1 (framing the role) and step 3 (structuring) are the two faces of the same defense against the funnel: one decides what isn't yours, the other makes what isn't yours flow without you.

Exercise 3 — Reframe the architect who wants to approve everything. Mercado's architect tells you: "this change exposes third parties and moves real money; it's too risky to delegate. I'm going to personally review every technical decision of the five squads during the rollout, so nothing breaks". With what you measured in this lesson, respond to them: why their plan would achieve the opposite of what they seek, and what you'd propose instead.

See solution

Why their plan achieves the opposite. The architect wants "nothing to break", but reviewing the 46 weekly decisions with a capacity of 12 produces a backlog of 340 stuck decisions and 1870 decision-weeks of waiting in 10 weeks. The effect is double and both go against their goal: (1) the rollout slows —the squads spend time waiting for their approval instead of building—, and a change that doesn't advance is a change at risk, not protected; (2) the quality drops, not rises, because the squads —which know their domain better than they do— stop deciding the local, and the architect reviews 38 decisions they don't understand as well as whoever lives them, adding delay without adding criteria. Wanting to protect the change by reviewing everything is the surest way to suffocate it. The real risk doesn't decrease; it just disguises itself as "everything passed through me".

What to propose instead. Not "delegate and trust blindly" (that would be abandonment), but the gardener role with guardrails, backed by the number:

Let them own the 8 decisions that really are theirs —precisely the ones that make the change risky: the Seller API contract, third-party auth, rate limiting, data security, payouts, quality attributes—. There their cross-cutting view is irreplaceable and their review does add criteria. Eight decisions fit comfortably in their capacity of 12.
Let them delegate the 38 local ones with guardrails, not with review: "all communication between services is via a versioned contract", "every service meets this SLO", "logs go in this format with a trace-id", "no financial data is stored unencrypted". The guardrails guarantee what worries them (that the whole doesn't break) without them having to approve each PR. The risk is controlled with clear lanes, not with a funnel.
Reframe their own goal: "Your concern that nothing breaks is right —it's exactly what a good architect should have—. But reviewing the 46 doesn't fulfill it: it slows it. You fulfill it better by owning the 8 where the real risk lives, and setting guardrails that protect the other 38 without you having to touch them. That way you're left with headspace for what really matters —deriving the attributes well, structuring the teams, leading the adoption— instead of being drowned approving how the catalog indexes."

It's the same move as module 1's project (reframing Álex): the enemy is the structure of the role, not the person; their intention (protecting quality) is good and is fulfilled better another way. The number —1870 decision-weeks of waiting— is what depersonalizes the argument and makes it incontestable.

Summary and next step

In this lesson you did step 1 of the deliverable: framing the role and the assignment. With the site manager who doesn't lay the bricks —who owns the load-bearing walls and delegates the hinges— you understood that the architect's job facing a change isn't to make all the decisions, but to separate the few that are theirs from the many they delegate. You measured it by executing: the change "open to external sellers + grow 10x" unleashes 46 weekly decisions, of which only 8 cross teams (the architect's) and 38 are local (the squads'); the funnel role produces 340 stuck decisions and 1870 decision-weeks of waiting, while the gardener role brings them to zero with the same capacity; and the coordination channels grow n(n-1)/2, so the single-channel architect doesn't scale. You learned the three tests that classify a decision as the architect's (does it cross boundaries?, does it shape and is it expensive to reverse?, cross-cutting risk?), and why most decisions of any change are local.

Before moving on you should be able to: translate a business change into the set of decisions it unleashes; separate the cross-team from the local with the three tests; explain why the funnel role slows and worsens the change it wants to protect; and propose guardrails that delegate the local without abandoning it.

What follows is step 2, and it's the one that gives content to those 8 decisions you just reserved for the architect. You already know how many decisions are yours; lesson 3 teaches you where the most important of them come from —the quality attributes—. You're going to take the goal of the change and derive, executed, the quality attributes it implies, prioritized by their business backing: you're going to see scalability come out on top (because "grow 10x" and "open to sellers" push it), and the scalability-vs-cost conflict as the trade-off that governs the whole change. That ranking is the input the structure you'll design in lesson 4 hangs from: you can't decide what teams to create without first knowing what attribute the system has to produce.

Resources

Martin Fowler — "Who Needs an Architect?" — the contrast between the architect who decides everything and the one who enables, which this ownership map formalizes for a concrete change. The reading that sums up why the gardener role beats the funnel.
Mark Richards & Neal Ford — Fundamentals of Software Architecture — its treatment of the architect's role and of how they work with the teams instead of above them is the direct backing of step 1: what the architect decides and what they delegate.
Matthew Skelton & Manuel Pais — Team Topologies — the framework of a team's cognitive load and of why small teams with clear boundaries beat big ones; it holds up step 3 (the n(n-1)/2 channels) that you only glimpsed here and that lesson 4 develops.
Gregor Hohpe — The Software Architect Elevator — on the architect who multiplies instead of being the bottleneck; the framework of why framing the role well is what makes everything else in the capstone possible.

← Previous1. Capstone presentation: the craft as one single movement Next →3. Derive the quality attributes from the goal