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

8. Project: be Mercado's architect facing the change

Overview

This is your graduation —not from a module, but from the whole guide—. Over seven modules you learned the architect's craft in pieces: what they really do (M1), Conway's Law and its inverse maneuver (M2), communicating with the C4 and the ADR (M3), leading without authority (M4), deriving quality attributes from the business (M5), designing for change (M6), and documenting so it survives (M7). And in the previous seven lessons of this capstone you traveled those pieces again, chained on a real change: you framed the role, derived the attributes, applied the inverse maneuver, produced the C4 and the ADR, led the rollout, and planned the evolution and the documentation. Now it's your turn, from start to finish: assemble the six pieces into a single integrated dossier, defend it before the VP, and verify that the craft is one single thing.

The reason for doing it yourself, complete, is the usual one and it's hard: if I let you repeat the lessons' examples, I wouldn't know if you learned the craft or memorized the answers. This project's deliverable isn't any loose piece —those you already built—; it's the architect's dossier: the coherent document where you see how the goal produced the attributes that produced the structure that was communicated, adopted, evolved, and documented, crowned by the conversation with the VP that sews the craft back to the business. And to prove you learned the method and not the recipe, the project ends with transfer exercises that throw you a new twist of the business —a goal that changes midway— and ask you to travel the thread again. Build it yourself first; reading the reference solution without having tried it is like reading the score of a match you didn't play.

Connection with the module, and with the whole guide: this project closes the arc of the capstone and of the guide. Lessons 2 to 7 gave you each piece with its executed measurement; here you integrate them into a dossier with your own hands, from start to finish, and add the only piece that was missing —the conversation with the VP—. And with this lesson everything closes: at the end is the summary of the complete guide (the seven modules as a single craft) and the bridge toward where to go next —the ecosystem of guides that gives you the deciding method (architecture-decisions-and-tradeoffs) and the technical options (the patterns) on which the architect you now are will make their decisions—.

The project case: Mercado's flagship change

The situation —yours to solve, end to end— is the one you traveled in the capstone:

Mercado's leadership bet on its flagship change of the next 18 months: open the marketplace to external sellers via API and grow 10x. Let third parties sell on the platform by integrating via a Seller API, and prepare for ten times the catalog and the traffic. You are Mercado's architect. Your job isn't to write the code of the sellers surface —the squads will do that—; it's to conduct the change as an architect: derive the attributes from the goal, structure the teams with the inverse Conway maneuver, communicate the decision with the C4 and the ADR, lead its adoption without authority, plan its evolution and document it, and —at the end— sit down with the VP of product to explain the trade-off that governs all this, in their language, so they approve the budget.

The deliverable is the architect's dossier: a single integrated document, with seven chained artifacts. It doesn't require building the system: it's pure architect work —deriving, structuring, communicating, leading, planning, documenting, conversing—, which is precisely what separates the architect who conducts a change from the one who only draws boxes. The project's discipline is that each artifact cite the previous one: the dossier isn't seven islands, it's a chain where each link derives from the prior.

What you have to deliver

Follow the thread in order; each artifact leans on the previous one.

Artifact 1 — The framed role and assignment (M1)

The ownership map of the change: the decisions it unleashes, separated into the cross-team ones the architect owns and the local ones they delegate with guardrails, with the coordination cost executed (funnel vs gardener). Name why the architect can't be the single channel.

Artifact 2 — The derived quality attributes (M5)

The executed weight × strength mapping of the change's goals to prioritized attributes, with the ranking run and the governing conflict named. This is the input everything else hangs from.

Artifact 3 — The inverse Conway maneuver, measured (M2)

The organization redesigned to produce the architecture the governing attribute demands —the stream-aligned team owning the surface, the platform as a service—, with the coordination friction measured before and after. Justify the structure with the governing attribute of artifact 2.

Artifact 4 — The C4 and the ADR (M3)

The C4 of the change (Context for the VP, Container for the dev) in mermaid, and the complete written ADR that packages the why —citing the governing attribute (artifact 2) and the measured friction (artifact 3), and naming the conscious price—.

Artifact 5 — The rollout plan, measured (M4)

The adoption plan squad by squad (early adopter, guardrail, legitimate objection, consensus) and the executed measurement of the genuine adoption (influence vs mandate) and the architect's load. Use the C4 and the ADR as tools of influence.

Artifact 6 — The evolution plan and the documentation (M6+M7)

The phases plan (now / sacrificial / deferred-with-seam) that resolves the governing conflict in time, and the measurement of the bus factor before and after the documentation that survives.

Artifact 7 — The script of the conversation with the VP (M5)

How you explain the governing conflict to the VP in their language, and how you tell them "I can't give you everything at maximum" with the prioritization that does fit. It's where the technical craft is sewn back to the business that asked for it.

The rubric

This is how the dossier is evaluated. It's not by length or by elegance: it's by whether the thread is well sewn and each piece well made, with evidence.

CriterionDoesn't meetMeetsExcels
Role and attributes (art. 1-2)Treats all decisions as its own; invented rankingSeparates cross-team from local; ranking run with weight × strengthAlso names the governing conflict and connects it with the structure
Measured structure (art. 3)Reorganizes without measuring or without justifyingApplies the inverse maneuver with the friction measured before/afterAlso justifies the organization with the governing attribute and distinguishes genuine seam from artificial
Communication (art. 4)Only diagram, or formality ADRTwo-level C4 + ADR that communicates the whyAlso the ADR cites artifacts 2-3 and names the conscious price
Measured rollout (art. 5)"I send an email" or "I convince them"Plan per squad + adoption and load run in PythonAlso uses the C4/ADR as evidence and handles the legitimate objection
Evolution and docs (art. 6)Builds the whole future or leaves no seamsPhases plan + bus factor measuredAlso resolves the governing conflict in time
Conversation with the VP (art. 7)Technical jargon or promises everything at maximumTranslates the governing conflict to their languageAlso says "not at maximum" with the prioritization that does fit
Integration (all)Seven islands with no relationEach artifact cites the previous oneThe dossier reads as a single movement

The criterion that weighs most, and the one that separates an architect from someone who studied architecture, is the integration: if you deliver seven impeccable artifacts that don't talk to each other —attributes that say scalability and a structure that doesn't produce it—, you didn't do the capstone; you did six module projects again. The dossier has to read as a chain where each link hangs from the previous one.

The reference solution

Try the whole project before continuing. What follows is one correct solution, not the only one —especially in the judgments (weights, strengths, classifications), which are debatable—.

The executed dossier, at a glance

The first thing is a program that links the six steps and emits the integrated dossier —the proof that the thread is one single thing, with each number derived from the previous one—. It reuses the engines of lessons 2 to 7.

# THE INTEGRATED DELIVERABLE: the dossier of Mercado's architect for the change
# "open to external sellers via API + grow 10x". A single pipeline that links the
# six steps of the craft: goal -> attribute -> structure -> communication -> rollout -> evolution.
from itertools import combinations

# ---------- Step 2 (M5): the goal -> the prioritized attributes ----------
business_goals = {"open_to_external_sellers": 5, "grow_10x": 5, "survive_black_friday": 4,
                  "protect_payment_data": 5, "keep_infra_costs_flat": 3, "instant_checkout": 3}
implies = {
    "open_to_external_sellers": {"scalability": 3, "security": 3, "availability": 2},
    "grow_10x": {"scalability": 3, "performance": 2, "cost": 2},
    "survive_black_friday": {"availability": 3, "scalability": 2, "performance": 1},
    "protect_payment_data": {"security": 3}, "keep_infra_costs_flat": {"cost": 3},
    "instant_checkout": {"performance": 3, "availability": 1}}
attrs = ["scalability", "availability", "security", "performance", "cost"]
score = {a: 0 for a in attrs}
for g, w in business_goals.items():
    for a, s in implies[g].items():
        score[a] += w * s
ranking = sorted(attrs, key=lambda a: score[a], reverse=True)
tensions = [("scalability", "cost"), ("security", "performance"),
            ("availability", "performance"), ("availability", "cost")]
top_tension = max(tensions, key=lambda p: score[p[0]] + score[p[1]])
top_combined = score[top_tension[0]] + score[top_tension[1]]

# ---------- Step 3 (M2): the inverse Conway maneuver (same model as step 3) ----------
deps = {"search": ["product_catalog"], "cart": ["product_catalog"],
        "checkout": ["cart", "payment_processing", "shipping_labels", "notifications", "order_processing"],
        "order_processing": ["shipping_labels", "auth"], "payment_processing": ["invoicing", "auth"],
        "invoicing": ["notifications"], "shipping_labels": ["delivery_tracking"],
        "seller_api": ["seller_onboarding", "listing_ingestion", "payout_processing", "auth"],
        "seller_onboarding": ["auth", "notifications"], "listing_ingestion": ["product_catalog", "search"],
        "payout_processing": ["payment_processing", "invoicing"]}
seller_mods = ["seller_api", "seller_onboarding", "listing_ingestion", "payout_processing"]
all_mods = ["product_catalog", "search", "cart", "order_processing", "checkout",
            "payment_processing", "invoicing", "shipping_labels", "delivery_tracking",
            "auth", "notifications"] + seller_mods


def friction(owners, service):
    t = 0
    for m in all_mods:
        room = set(owners[m])
        for d in deps.get(m, []):
            if d not in service:
                room |= owners[d]
        t += len(list(combinations(room, 2)))
    return t


base = {"product_catalog": {"catalog"}, "search": {"catalog"}, "cart": {"orders"},
        "order_processing": {"orders"}, "checkout": {"orders", "payments"},
        "payment_processing": {"payments"}, "invoicing": {"payments"},
        "shipping_labels": {"shipping"}, "delivery_tracking": {"shipping"},
        "auth": {"platform"}, "notifications": {"platform"}}
before = {**base, "seller_api": {"platform", "orders"}, "seller_onboarding": {"platform", "orders"},
          "listing_ingestion": {"catalog", "platform"}, "payout_processing": {"payments", "platform"}}
after = {**base, **{m: {"seller_platform"} for m in seller_mods}}
f_before = friction(before, set())
f_after = friction(after, {"auth", "notifications", "payment_processing"})

# ---------- Step 5 (M4): the rollout without authority ----------
SQUADS, WEEKS = 6, 12
inf = 1.0
for _ in range(WEEKS):
    inf = min(SQUADS, inf + 0.70 * inf * ((SQUADS - inf) / SQUADS))
man = 2.0
for _ in range(WEEKS):
    man = max(0.0, man - 0.12 * man)
gate, guardrail = SQUADS * 8, 6

# ---------- Step 6 (M6+M7): evolution + bus factor ----------
now, sacrificial, deferred = 3, 2, 3
bus_before, bus_after = 1, 3

# ---------- THE DOSSIER ----------
print("=" * 64)
print("ARCHITECT'S DOSSIER -- Mercado opens to external sellers (10x)")
print("=" * 64)
print(f"1. GOAL -> ATTRIBUTE  : top = {ranking[0]} ({score[ranking[0]]}); "
      f"governing conflict = {top_tension[0]} vs {top_tension[1]} ({top_combined})")
print(f"2. STRUCTURE (Conway) : friction {f_before} -> {f_after} pairs "
      f"({(1 - f_after / f_before) * 100:.0f}%) creating 1 stream-aligned team")
print(f"3. COMMUNICATION      : C4 (Context 6 / Container 12 elems) + ADR-021 (the why)")
print(f"4. ROLLOUT (no auth)  : adoption {inf:.1f}/6 real vs {man:.1f}/6 by mandate; "
      f"architect load {guardrail} vs {gate} PRs")
print(f"5. EVOLUTION          : {now} now + {sacrificial} sacrificial + {deferred} deferred")
print(f"6. DOCUMENTATION      : bus factor {bus_before} -> {bus_after} (docs-as-code)")
print("=" * 64)
print("A single thread: the goal commands the attribute; the attribute asks for the structure;")
print("the structure is communicated; the communication is adopted; what's adopted is evolved and")
print("documented. That's the CRAFT -- not six tricks, a single movement.")

What to expect. Running it:

================================================================
ARCHITECT'S DOSSIER -- Mercado opens to external sellers (10x)
================================================================
1. GOAL -> ATTRIBUTE  : top = scalability (38); governing conflict = scalability vs cost (57)
2. STRUCTURE (Conway) : friction 21 -> 7 pairs (67%) creating 1 stream-aligned team
3. COMMUNICATION      : C4 (Context 6 / Container 12 elems) + ADR-021 (the why)
4. ROLLOUT (no auth)  : adoption 6.0/6 real vs 0.4/6 by mandate; architect load 6 vs 48 PRs
5. EVOLUTION          : 3 now + 2 sacrificial + 3 deferred
6. DOCUMENTATION      : bus factor 1 -> 3 (docs-as-code)
================================================================
A single thread: the goal commands the attribute; the attribute asks for the structure;
the structure is communicated; the communication is adopted; what's adopted is evolved and
documented. That's the CRAFT -- not six tricks, a single movement.

Read the dossier top to bottom and follow the causality, which is what the rubric rewards. Line 1 says scalability (38) is the governing attribute and that scalability-vs-cost (57) is the conflict that governs the change. Line 2 derives from line 1: since scalability commands, the structure creates a stream-aligned team that makes the surface scalable, and that drops the friction from 21 to 7. Line 3 communicates line 2: the C4 shows the structure, the ADR-021 justifies it by citing the governing attribute. Line 4 executes line 3: the rollout adopts the communicated architecture, and wins with influence (6.0/6) where the mandate loses (0.4/6). Line 5 evolves line 4: it defers the machinery of the 10x resolving the conflict of line 1 in time. And line 6 documents everything: it raises the bus factor from 1 to 3. Each line hangs from the previous one —that's the integration—. If you changed line 1 (another governing attribute), all the ones below would change. The dossier isn't a table of six loose numbers: it's a causal chain.

The artifacts, assembled

The dossier above is the summary; the complete deliverable develops each artifact. Here they are, sewn:

See the complete dossier, artifact by artifact

Artifact 1 — Role and assignment (M1, lesson 2). The change unleashes 46 weekly decisions; the architect owns the 8 cross-team ones (the Seller API contract, third-party auth, rate limiting, payouts, the quality attributes, the surface boundaries) and delegates the 38 local ones with guardrails. The funnel role would produce 340 stuck decisions and 1870 decision-weeks of waiting; the gardener role brings them to zero. The architect can't be the single channel: the channels grow n(n-1)/2, so the way out is to structure the teams (artifact 3), not to approve everything.

Artifact 2 — Derived attributes (M5, lesson 3). Ranking run: scalability 38, security 30, availability 25, performance 23, cost 19. Governing conflict: scalability vs cost (57) —"grow 10x" against "don't triple the bill"—. Everything below is justified with this ranking.

Artifact 3 — Measured structure (M2, lesson 4). To produce a surface that scales (what scalability demands), the stream-aligned team seller_platform is created, owner of the complete surface (seller_api, seller_onboarding, listing_ingestion, payout_processing), and auth + notifications + payment_processing become platform services. Friction: 21 → 7 pairs (−67%) without touching the code; seller_api goes from 6 pairs of coordination to 0. Two genuine seams remain (import listings ↔ catalog, payouts ↔ payments), which become contracts.

Artifact 4 — C4 and ADR (M3, lesson 5). The C4: Context (6 elements, with the external seller integrating via API) and Container (12 elements, with the Seller API Gateway and seller_platform). The ADR-021 ("Expose external sellers with a dedicated Seller API and a seller_platform team") cites the governing attribute (scalability 38, security 30) and the measured friction (21), and names the conscious price: the new team to set up, the gateway latency that clashes with instant_checkout, and the two seams.

Artifact 5 — Measured rollout (M4, lesson 6). Plan per squad: seed in seller_platform (early adopter) and platform; the load-bearing conversation with payments (legitimate compliance objection on the payouts) before asking for adoption; spread with evidence to catalog and orders; and the consensus meeting that ratifies. Measurement: genuine adoption 6.0/6 with influence+guardrail vs 0.4/6 with mandate; architect's load 6 reviews (guardrail) vs 48 (gate). The C4 and the ADR are the tools of influence.

Artifact 6 — Evolution and docs (M6+M7, lesson 7). Phases plan: 3 now (the structural seams: Seller API contract, seller_platform boundary, platform contracts), 2 sacrificial (risk scoring and ingestion, simple versions replaced with real data), 3 deferred (the 10x sharding and multi-region with seam; the dashboard by YAGNI). Defers the expensive machinery of the 10x resolving the cost-vs-scalability conflict in time. Bus factor of the surface: 1 → 3 with docs-as-code (README + C4 + ADR-021 versioned).

Artifact 7 — The conversation with the VP. (See below, because it's the piece that sews the craft back to the business.)

Artifact 7 — The script of the conversation with the VP

The VP of product wants to "grow 10x" and also said "we can't triple the infra bill". The governing conflict (scalability vs cost, 57) is exactly that contradiction. I explain it in their language —business and money—, and I tell them "not at maximum on both":

"I want to tell you how we're going to build the external sellers change, because there's a tension that's going to matter to you directly and I'd rather you decide it, with the numbers, instead of it surprising you later.

Your flagship goal is to grow 10x, and I took it seriously: I derived, from the goals you gave me, what matters most technically, and it came out clearly that it's the ability to scale —three of your goals push it, two of them the most strategic—. That's why the central piece of the architecture is a dedicated team, owner of the whole Seller API, that can grow it without having to coordinate with the other four areas every time. That's what lets us reach 10x without the system becoming a knot.

But here's the tension, and it's your own goal speaking: you also told me 'let's not triple the infra bill'. And it turns out that 'scale to 10x' and 'not overspend' pull head-on —building today all the machinery for ten times the traffic costs a lot of money, and right now we don't have that traffic; we're barely about to open to the first sellers—. We can't have both at maximum today: scaling completely for a volume that doesn't exist yet is burning money on empty rooms.

What I propose isn't to choose one and sacrifice the other, but to resolve them in time. Now we build the 'pipes and foundations' —the Seller API contract, the owning team, the clean connections between areas— that are expensive to add later and cheap to put in now, and that are what makes it possible to scale later without demolishing. But we defer the expensive infrastructure of the 10x —the massive data partitioning, the multi-region— until the real sellers volume justifies it. We leave the seam prepared to add it the day we need it, but we don't spend on it today. That way I protect your bill now and your growth later, each at its right moment.

And I want to be honest about what we're not optimizing in this first phase. We prioritized being able to scale cleanly and the security of bringing third parties into the platform, which is where the risk and the bet are. We're not squeezing the cost to the minimum or building for the maximum imaginable peak —those aren't the priorities of starting—. When the volume takes off, we come back to this table with real data and decide how much to invest in scaling, and how much it costs. I can show you, for each phase, what we build, what we defer, and how much each option costs, so you draw the line seeing both sides —the growth and the bill—, not just one."

Why it works. It translates the scalability-vs-cost conflict into what the VP understands (growing against spending), names that both are their own goals in tension (not a technical whim), proposes resolving it in time (defer the expensive machinery with seam) instead of an impossible maximum, explicitly says what is not prioritized so there are no surprises, and returns the decision with the numbers —module 5's double translation, the "not at maximum" of the craft, and the respect of the frontier: the architect presents, the business decides—. The rigorous resolution of how much to scale and with which technical option, when the moment arrives, is the method of architecture-decisions; here the architect's job was to detect the conflict, sequence it, and conduct the conversation.

Transfer exercises

These exercises throw you a new twist of the business to confirm you learned the thread, not the answers of this case.

Exercise 1 — The VP changes the goal midway. Six months after starting, the business pivots: the priority is no longer "grow 10x" but "meet a financial security certification to be able to integrate banks as sellers on the platform", with a hard regulatory deadline. Travel the thread and predict what changes in each link: (a) the governing attribute; (b) the structure; (c) the ADR's emphasis; (d) the conversation with the VP.

See solution

  • (a) The governing attribute changes from scalability to security (and auditability). "Meet a financial security certification" is a goal of the opposite nature to "grow 10x": it doesn't push scale, it pushes security, privacy, auditability, and compliance. The weight × strength mapping would give a ranking where security dominates and scalability falls —the same contrast module 5's project showed with installment payments—. The thread is faithful to the goal, and the goal changed.

  • (b) The structure changes. With security as governing, the inverse Conway maneuver no longer designs only a team-that-scales; it probably adds a security platform capability (robust auth, secrets management, auditing, data isolation as services) that seller_platform and the other squads consume, and perhaps a temporary enabling team to reach the certification's level. The organization is designed to produce the attribute that now commands.

  • (c) The ADR's emphasis changes. The new ADR (superseding or complementing ADR-021) would have a context centered on compliance and the regulatory deadline, a decision about how the financial data is isolated and audited, and consequences where the conscious price includes the certification cost and perhaps an extra latency from the security controls. The diagram would show the new security boundaries.

  • (d) The conversation with the VP changes language. It's no longer "scaling against spending"; it's "meeting the certification on time against the cost and the launch speed". The architect would translate the new governing conflict (probably security vs performance or security vs time-to-market) into the VP's language —"meeting the regulatory certainty protects us from a fine worth X, but each control adds time; this is what does arrive for the deadline"—.

The lesson: the thread is the same (the six steps, in the same order); the content of each link changes because the goal changed. That's what transfers from the capstone —the method, not the recipe—. An architect who arrived at this new goal with "in Mercado what matters is scaling" (the conclusion of the previous case) would prioritize exactly what the certification doesn't need. The method exists to prevent that: it forces re-deriving from today's goal.

Exercise 2 — The link someone wants to skip. An impatient technical director tells you: "forget the rollout and the documentation; with the C4 and the ADR well made, the teams will already know what to build. Let's go straight to coding". Argue, with what you measured in the capstone, why skipping steps 5 and 6 would make the change fail even if steps 1-4 are perfect.

See solution

Skipping step 5 (rollout) would make the architecture not get built —or born deformed—. The C4 and the ADR communicate a decision, but they don't execute it. The six squads don't report to the architect; without leading the adoption, each will keep to its priorities, seller_platform won't form, and the contracts won't be adopted. Step 5's number showed it: without the influence method, real adoption falls (the mandate reaches 0.4/6). And worse, Conway's Law would operate against: since the organization wasn't really restructured, the surface would keep being touched by several teams, and the code would reflect that old organization, not the diagram —the friction would return to 21, not 7—. The diagram would remain a photo the real system contradicts.

Skipping step 6 (evolution and documentation) would make the change over-build and then be lost. Without the evolution plan, the reflex facing "grow 10x" is to build all the machinery of the 10x today (over-engineering), delaying the launch and skyrocketing the cost —violating the CFO's goal—. And without the documentation, the bus factor stays at 1: the most important surface of the year would depend on the head of whoever built it, and when that person left, no one would know why the gateway exists or where the seam for the deferred sharding is. The change would be left fragile and orphaned.

The lesson: the thread has no optional links. Steps 1-4 produce and communicate the decision; step 5 makes it happen; step 6 makes it sustainable and evolvable. "Let's go straight to coding" is the myth that being right (a good design) is having power (that it gets built). It isn't. The craft ends when the organization executes and can keep evolving the system, not when the diagram is pretty.

Exercise 3 — Your own change, your own thread. Choose a different business change for Mercado (for example: "launch same-day shipping in the three main cities", or "open Mercado as a third-party app with a developer program"). Without executing all the code, travel the thread in prose: name the goal, predict the probable governing attribute, the structural decision that attribute would ask for, and the conflict that would probably govern the conversation with the VP. The goal is to be able to conduct the thread over a new case.

See solution

A solution for "launch same-day shipping in the three main cities" (the judgment is debatable, that's the point):

  • The goal and its sub-goals: same-day delivery (weight 5), coverage in three cities (weight 4), don't skyrocket the logistics cost (weight 4), don't fail a promised delivery (weight 5, because promising and failing damages the brand).

  • The probable governing attribute: reliability / availability (that the promise of "today" is always met) and performance (the logistics has to be fast), with cost in strong tension (same-day delivery is expensive). Scalability matters less here than in the sellers case —it's not a 10x volume problem, it's a problem of keeping a time promise—. Notice the governing attribute is different because the goal is different.

  • The structural decision that attribute would ask for: a governing attribute of reliability/performance in logistics probably asks for a stream-aligned team owning the same-day delivery flow (routing, courier assignment, real-time tracking), and perhaps integrating the logistics capability as a service with strict SLOs. The inverse maneuver would create the team that owns that flow end to end so it can optimize the time promise without coordinating with half the system.

  • The conflict that would govern the conversation with the VP: reliability/performance vs cost. "Deliver same-day always" (reliability + performance) against "don't skyrocket the logistics cost" (cost). The architect would tell the VP: "meeting the 'today' promise 100% of the time demands spare logistics capacity, which is expensive; we can meet it at 95% with a reasonable cost, or get close to 100% paying much more for the last 5%. Where do we draw the line —what promise level is worth its cost—?". It's the "not at maximum" applied to another conflict.

The lesson: you traveled the whole thread over a case you never saw, and it worked —you derived a different governing attribute (reliability, not scalability), a different structure (logistics team, not sellers), and a different conflict (reliability vs cost, not scalability vs cost)—. That's having the craft: not the answers of Mercado-sellers, but the ability to conduct the thread over any goal. The method transfers; the answers are faithful to each business.

Closing the guide: the craft, complete

With this project you close not a module, but the whole guide of the architect's craft. It's worth traveling back over what you learned, because now you see it as what it is: a single craft.

You started by knowing what the role is (M1): not the one who draws the perfect blueprint and leaves, but the one who enables, makes the expensive decisions reversible, goes down to the code, and —above all— doesn't become the bottleneck. You learned that architecture is made by an organization of people, and that Conway's Law (M2) makes the system copy the communication structure of that organization —and that the inverse maneuver lets you shape the teams to obtain the architecture you want—. You learned to communicate (M3): the C4 to show the system at the right level for each audience, and the ADR so the why travels through time to whoever comes after. You learned to lead without authority (M4): that being right isn't having power, and that genuine adoption is achieved by influencing, giving guardrails, and building consensus, not by ordering. You learned to translate the business (M5): from the stakeholder's goals to the prioritized quality attributes, and from the trade-offs back to the business's language, knowing how to say no. You learned to design for change (M6): build the expensive seams, defer the uncertain, avoid both over- and under-engineering. And you learned to document so it survives (M7): docs-as-code, the C4 and the ADR versioned, the bus factor that doesn't depend on a single head.

And in this capstone you verified the thesis that runs through the whole guide: those seven aren't seven topics, they're a single craft. A real business change —opening Mercado to external sellers— doesn't arrive in pieces: it arrives as an operation where the goal commands the attribute, the attribute asks for the structure, the structure is communicated, the communication is adopted, what's adopted is evolved and documented, and everything ends in a conversation with a human who approves. You measured it end to end —scalability 38, friction 21→7, adoption 6.0/6, bus factor 1→3— and sewed it into a dossier where each number hangs from the previous one. The architect's greatest leverage turned out not to be technical, but social: what conversations they have, how they structure the teams, how they communicate a trade-off. That's the craft.

Where to go next: the ecosystem

This guide taught you the craft of conducting a change. But an architect who conducts makes technical decisions —a gateway or direct integration?, a service or a module?, synchronous or event-driven?, this resilience pattern or that one?—, and this guide deliberately didn't teach them: it named them and referred to whoever does. Two directions to continue.

The deciding method: architecture-decisions-and-tradeoffs. Every time the capstone detected a trade-off (scalability vs cost) or chose an option (the gateway, the seller_platform service), it leaned on the deciding method without re-teaching it. That guide is the toolbox of the method: the weighted decision matrix to choose between options, the complete mechanics of the ADR, the fitness function that watches that a decision holds, and reversibility and the last responsible moment as a technique. It's the direct companion of this guide —the human who makes the decision happen (here) and the method with which they decide it (there)—. If the capstone left you wanting to know how the scalability-vs-cost conflict you only detected is rigorously resolved, that's the door.

The technical options: the ecosystem of patterns. The architect you now are decides over a menu of technical options, and each family of options has its guide:

The image to keep: this guide gave you the architect —the human who understands their role, derives the attributes, structures the teams, communicates, leads, evolves, and documents—. architecture-decisions gives them their deciding method. And the ecosystem of patterns gives them their technical options. The architect conducts; the method tells them how to choose; the patterns are what they choose between. Now you have the first, you know where the second is, and you have the map of the third. The craft is complete; what follows is exercising it.

Resources

← Previous7. Plan the evolution and the documentation