1. Capstone presentation: the craft as one single movement

Overview

You've reached the end of the guide, and this module is different from the seven before it. The others each taught you one piece of the craft: what an architect really does (M1), Conway's Law and its inverse maneuver (M2), communicating with the C4 and the ADR (M3), leading without authority (M4), translating business goals into quality attributes (M5), designing for change (M6), and documenting so it survives (M7). Each closed with its own project, and in each project you exercised that piece alone. This module doesn't add a new piece: it joins the six into a single movement. Because the architect's real work doesn't arrive in labeled pieces —no one asks you to "apply the inverse Conway maneuver for me"—; it arrives as a business change that demands all the pieces at once, in order, chained. The capstone is where you verify that the craft is one single thing.

This module's journey is a return: instead of advancing toward a new topic, you're going to travel the seven you already know, but now seeing them as what they are —links in a single chain—. You're going to take a real Mercado change, the leadership's flagship bet —opening the marketplace to external sellers via API and growing 10x—, and you're going to produce, step by step, the deliverable a real architect would put on the table: the map of which decisions are theirs and which they delegate, the quality attributes derived from the goal, the organization redesigned with the inverse Conway maneuver and its friction measured, the C4 and the ADR that communicate the decision, the plan for the rollout without authority, the evolution plan, the documentation that holds it up, and the script of the conversation with the VP who approves the budget. All together, sewn by a single thread.

Connection with the module: this lesson is the map of the capstone. It doesn't build any piece of the deliverable yet —that's what lessons 2 to 7 do, one piece per lesson— but it shows the thread that unites them, so that when you build each part you know where it comes from and what it feeds into. Lesson 2 frames the role and the assignment (M1); lesson 3 derives the attributes (M5); lesson 4 applies the inverse maneuver (M2); lesson 5 produces the C4 and the ADR (M3); lesson 6 leads the rollout (M4); lesson 7 plans the evolution and the documentation (M6+M7); and lesson 8 assembles everything in the integrated dossier, evaluates it with a rubric, and closes the whole guide pointing toward the ecosystem. Here you only look at the whole from above, before going down to each piece.

The surgeon who isn't six specialists

Imagine you go into an operating room to be operated on. Inside there's a surgeon. That surgeon, in the hour the operation lasts, does many different things: reads the images and decides where to cut (diagnosis), opens with precision (surgical technique), handles the bleeding if something goes wrong (crisis control), coordinates the scrub nurse and the anesthesiologist (team leadership), decides on the fly if the plan changes (real-time judgment), and leaves the operative notes for the doctor who attends you afterward (documentation). Each of those things is a specialty the surgeon studied separately, in different years of their training: anatomy one year, surgical technique another, complications management another.

But in the operating room there aren't six people, one per specialty. There's a single one, who exercises the six in a single continuous operation, where each one feeds the next: the diagnosis decides where to cut, the cut reveals what has to be controlled, the control demands coordinating the team, the coordination depends on the judgment, and everything ends in the note that survives. A surgeon who knew perfect anatomy but couldn't coordinate the team would kill the patient. One who operated with impeccable technique but without the judgment to change the plan when the unexpected appears, likewise. Competence isn't knowing the six specialties separately; it's exercising them as a single thing, in sequence, under pressure, on a real patient.

The architect facing a business change is that surgeon. You studied the six specialties of the craft in separate modules —one per module, as the surgeon studies anatomy and technique in different years—. But the change "open Mercado to external sellers" doesn't arrive divided in six: it arrives as a single operation where deriving the attributes decides what structure you need, the structure decides what to communicate, the communication decides what to lead, and everything ends in the documentation that survives. This capstone is your first complete operation: not six separate exams, a single surgery end to end.

Worked example: the thread, from the business sentence to the deliverable

Before building each piece, it's worth seeing the complete chain at a glance: how a single business sentence turns, step by step, into a deliverable, and how each step's output is the next one's input. This code doesn't compute anything new —the numbers come from the lessons ahead—; its only job is to show the thread, so you know where you're going.

# TEASER of the capstone: the craft as ONE SINGLE thread. We don't compute anything new yet;
# we only show how a business sentence turns, step by step, into a deliverable.
# Each step is a module of the guide, and one step's output is the next one's input.

business_sentence = "Open Mercado to external sellers via API and grow 10x."

craft = [
    ("M1", "frame the role and the assignment",
     "the sentence -> 46 decisions; the architect owns 8, delegates 38"),
    ("M5", "derive the attributes from the goal",
     "top = scalability (38); governing conflict = scalability vs cost (57)"),
    ("M2", "apply the inverse Conway maneuver",
     "one new stream-aligned team; friction 21 -> 7 pairs (-67%)"),
    ("M3", "produce the C4 and the ADR",
     "the diagram (what) for the VP and the dev + the ADR (why) for the future"),
    ("M4", "lead the rollout without authority",
     "genuine adoption 6.0/6 vs mandate 0.4/6; load 6 vs 48 PRs"),
    ("M6+M7", "plan the evolution and document",
     "3 now + 2 sacrificial + 3 deferred; bus factor 1 -> 3"),
]

print(f"ASSIGNMENT: {business_sentence}")
print("=" * 68)
for i, (mod, step, result) in enumerate(craft, 1):
    arrow = "   |" if i < len(craft) else "   v"
    print(f"step {i}  [{mod:<6}]  {step}")
    print(f"          -> {result}")
    print(arrow)
print("DELIVERABLE: the architect's dossier -- goal, structure, C4, ADR,")
print("             rollout, evolution and the conversation with the VP, integrated.")
print("=" * 68)
print("Watch the chain: each step's output FEEDS the next. The goal commands the")
print("attribute; the attribute asks for the structure; the structure is communicated;")
print("the communication is adopted; what's adopted is evolved and documented. The six")
print("modules you studied separately are, in real work, one single movement.")

What to expect. Running it:

ASSIGNMENT: Open Mercado to external sellers via API and grow 10x.
====================================================================
step 1  [M1    ]  frame the role and the assignment
          -> the sentence -> 46 decisions; the architect owns 8, delegates 38
   |
step 2  [M5    ]  derive the attributes from the goal
          -> top = scalability (38); governing conflict = scalability vs cost (57)
   |
step 3  [M2    ]  apply the inverse Conway maneuver
          -> one new stream-aligned team; friction 21 -> 7 pairs (-67%)
   |
step 4  [M3    ]  produce the C4 and the ADR
          -> the diagram (what) for the VP and the dev + the ADR (why) for the future
   |
step 5  [M4    ]  lead the rollout without authority
          -> genuine adoption 6.0/6 vs mandate 0.4/6; load 6 vs 48 PRs
   |
step 6  [M6+M7 ]  plan the evolution and document
          -> 3 now + 2 sacrificial + 3 deferred; bus factor 1 -> 3
   v
DELIVERABLE: the architect's dossier -- goal, structure, C4, ADR,
             rollout, evolution and the conversation with the VP, integrated.
====================================================================
Watch the chain: each step's output FEEDS the next. 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. The six
modules you studied separately are, in real work, one single movement.

Read the output as the index of everything you're going to build. Each step N line is one of the lessons that follow, and each -> arrow is what you'll produce in that lesson. But what matters isn't the numbers —those you'll derive yourself, one by one—; what matters are the vertical bars between steps. Each | is a dependency: the step below can't start without the output of the one above. You can't derive the attributes (step 2) without having framed the assignment (step 1); you can't structure the teams (step 3) without knowing scalability is the governing attribute (step 2); you can't communicate the decision (step 4) without having decided the structure (step 3). The craft isn't a menu you pick loose pieces from: it's a chain, and the order matters because each link hangs from the previous one.

Notice link 2, which is the heart of the thread. The attribute that leads —scalability with 38— wasn't chosen by the architect because they like to scale; it came from the goal ("grow 10x", "open to external sellers"). And that attribute, once derived, dictates step 3: if scalability is what weighs most, the structure has to produce a sellers surface that scales independently, and that's why step 3 creates a team that owns that surface. If step 2 had given another governing attribute —say security, as in the installment payments project of module 5—, step 3 would have designed another organization. The thread is causal: the goal commands downward, not the reverse. An architect who started with step 3 (structuring teams) without having done step 2 (deriving the attributes) would be reorganizing blind —the exact anti-pattern that module 2 called "perpetual reorganization"—.

And notice the destination: the deliverable isn't any of the six loose pieces, it's the dossier that integrates them —a single snapshot where you see how the goal produced the structure that produced the communication that was adopted and documented—. That's what a real architect delivers, and what you're going to assemble in lesson 8. Lessons 2 to 7 build each piece; lesson 8 sews them together and defends them before the VP.

Why the capstone matters more than the sum of its parts

You might ask: if you already did the six projects of the previous modules, what does doing one that joins them add? The answer is that integration is a skill in itself, distinct from each piece, and it's the one that truly separates an architect from someone who studied architecture. Three reasons.

First, the pieces constrain each other, and you only see it when you join them. In isolation, each piece has freedom: in module 5 you could derive any ranking of attributes; in module 2, design any organization. But in the capstone, step 2's output ties down step 3's input: if you derived scalability as governing, you're no longer free to structure the teams however you want —you have to structure them to produce a system that scales—. The coherence between pieces is a constraint that doesn't exist when you practice a single one. An architect who derives scalability and then designs an organization that doesn't produce it made a mistake that no isolated module project could reveal, because the mistake lives in the joint between two pieces, not inside any one of them.

Second, the order is part of the craft, and the capstone is where it's practiced. The modules were studied in a pedagogical order (first the role, then Conway, then communication...), but the order in which the craft is exercised facing a real change is the one you saw in the teaser: first the assignment, then the attributes, then the structure, then the communication, then the leadership, then the evolution. That order isn't arbitrary: it's the order of the dependencies. Starting with communicating (drawing the C4) before having derived the attributes and decided the structure is drawing an architecture you haven't decided yet —putting the diagram before the decision, the classic mistake of the architect who loves boxes—. The capstone forces you to exercise the craft in the right order, which is a learning no loose module gives.

Third, the thread ends in a person, not an artifact. The six technical steps produce artifacts (a ranking, a diagram, an ADR), but the capstone ends where the architect's real work ends: in the conversation with the VP who approves —or not— the budget for all this. That last step sews the whole craft back to the business it came from: the architect explains to the VP, in their language, that "grow 10x" (their goal) implies a trade-off against "don't triple the bill" (their other goal), and that they can't have both at maximum. All the technical work —the attributes, the structure, the communication— exists to make that conversation possible with evidence. The capstone doesn't end in a pretty diagram; it ends in a human saying yes, which is where an architecture really begins.

Common mistakes

Treating the capstone as six projects glued together instead of one single one (of loose pieces). What happens: the student does each piece as if it were an independent mini-project —derives some attributes, designs some organization, draws some C4— without verifying that each one derives from the previous one. The result is a "deliverable" where the pieces don't talk: attributes that say scalability and an organization that doesn't produce it. Why it happens: it's what was practiced six times, so the reflex is to treat each part alone. How to spot it: if you can change one step's output without any of the following ones changing, there's no thread —you have six islands—. How to fix it: at each step, ask yourself "which output of the previous step does this depend on?" and make it explicit; the correct deliverable is a chain where each link cites the previous one.

Skipping the assignment and starting by drawing (of the architect who loves boxes). What happens: the excitement of a big change pushes you to open the diagram editor and draw the target architecture immediately, before having framed the role or derived the attributes. Why it happens: drawing feels like progress and is the most fun part of the craft. How to spot it: if you have a C4 before having the ranking of attributes, you drew an architecture you didn't decide with method. How to fix it: respect the order of the thread —the C4 is step 4, not step 1—; first frame the assignment (step 1) and derive the attributes (step 2), because they're what tell you what architecture to draw. The diagram communicates a decision; first you have to make it.

Forgetting that the thread ends in a conversation, not an artifact (of the deliverable with no destination). What happens: the student produces impeccable technical artifacts —ranking, C4, ADR— but never prepares the conversation with the VP, as if the architect's work ended in the document. Why it happens: the artifacts are tangible and the conversation feels "soft", secondary. How to spot it: if your deliverable doesn't include how you'd explain the main trade-off to the stakeholder who pays, you stopped halfway through the craft. How to fix it: remember that all the technical work exists to enable the business decision; the script of the conversation with the VP isn't decoration, it's the link that turns the diagram into an approved system. A perfect dossier that no one approves builds nothing.

Exercises

Exercise 1 — Name the thread's dependencies. The teaser shows six chained steps. For three of the arrows between steps, explain what information travels from one step to the next: (a) from step 2 (attributes) to step 3 (structure); (b) from step 3 (structure) to step 4 (communication); (c) from step 5 (rollout) to step 6 (evolution/documentation).

See solution

• (a) From step 2 to step 3 travels the governing attribute and the conflict. That scalability is the attribute that weighs most (38) is what tells step 3 what architecture to produce: one where the sellers surface can scale independently. If step 2 had given security as governing, step 3 would design another organization (teams around isolation and auditing, not around scale). The structure isn't decided in a vacuum; it's decided to produce the attribute the goal prioritized.

• (b) From step 3 to step 4 travels the structural decision that has to be communicated. Step 3 decides to create a stream-aligned team that owns the sellers surface and to turn the platform into a service. That decision is exactly what step 4 communicates: the C4 shows the new surface and its boundaries (the what), and the ADR explains why that team and that service were created (the why). Without step 3's decision, step 4 would have nothing to draw or justify —communicating precedes an already-made decision, it doesn't invent it—.

• (c) From step 5 to step 6 travels what was really adopted and who owns it. Step 5 (rollout) produces the genuine adoption of the contract and the map of which team ended up owning what. Step 6 uses that: it plans the evolution of what was really built and adopted (not the imagined), and measures the bus factor over the real ownership map that came out of the rollout. You can't document or plan the evolution of something no one adopted; first it's adopted (step 5), then it's evolved and documented (step 6).

The lesson of the exercise: each arrow of the thread carries concrete information, and that information is what makes the deliverable coherent instead of six loose pieces. Naming the dependencies is understanding the craft as a chain.

Exercise 2 — Change the goal, predict the thread. Suppose Mercado's change weren't "open to external sellers + grow 10x" but "comply with the new financial data protection regulation before an audit in six months". Without doing the calculations, predict how the thread would change: what attribute would probably lead step 2, and how that would change step 3's structure.

See solution

Step 2's governing attribute would change from scalability to security (and auditability). "Comply with the financial data regulation" is a goal of a completely different nature than "grow 10x": it doesn't push scale, it pushes security, privacy, and auditability. The goal→attribute mapping would give a ranking where security dominates and scalability barely appears —exactly the contrast that module 5's project showed with installment payments—. The thread is faithful to the goal, and this goal is another.

Step 3's structure would change accordingly. If the governing attribute is security/auditability instead of scalability, the inverse Conway maneuver would no longer design a team to scale a sellers surface, but perhaps a team (or a cross-cutting capability) around compliance and auditing —where the financial data lives, who touches it, how each access is logged—. The organization is designed to produce the attribute the goal prioritized, so a different governing attribute produces a different organization.

And downward, the whole thread would rearrange: the C4 and the ADR would communicate the compliance decision (not the sellers surface one); the rollout would lead the adoption of the audit controls; the evolution and the documentation would center on what the audit demands. The method (the thread) is the same; the content of each link changes because the goal changed. That's what transfers from the capstone: not the answers (scalability 38, friction 21→7), but the chain that produces them from any goal.

Exercise 3 — What's missing if you skip a link? A Mercado architect, in a hurry, does steps 2, 3, and 4 (derives attributes, structures teams, draws the C4 and the ADR) but skips step 5 (the rollout without authority): hands the diagram and the ADR to the VP and leaves, confident the teams "will implement it because it's well designed". Predict what's going to happen, drawing on what you learned in the guide.

See solution

What's going to happen is that the architecture isn't built —or is built deformed—, no matter how impeccable the diagram is. Step 5 (leading the rollout without authority) is the one that turns a decision into a real system, and skipping it is the central mistake that module 4 dismantled: believing that "being right is having power", that a well-designed architecture implements itself. It doesn't implement itself. The five squads don't report to the architect; if no one leads the adoption —seeding in the early adopter, giving the guardrail that makes it cheap, handling the objections, building the consensus—, each squad will keep to its priorities, the new team (seller_platform) won't form, and the platform-as-a-service contracts won't be adopted. The diagram will stay in a document no one executes —the ivory tower of module 1—.

Worse still, without step 5, Conway's Law (module 2) operates against: since the organization wasn't really restructured (only the restructuring was drawn), the sellers surface will keep being touched by several squads by proximity, and the code will reflect that old organization, not the diagram's. In a few months, the real system won't look like the C4 —the architect drew a new channel but didn't change the terrain, so the river returned to its bend—.

The lesson: the thread has no optional links. Steps 2-4 produce the decision and its communication; step 5 makes it happen. An architect who hands over the diagram and leaves did the easier half and skipped the half that really decides whether something gets built. The craft ends when the organization executes, not when the diagram is pretty.

Summary and next step

In this lesson you saw the capstone from above: not a new topic, but the six you already know seen as a single movement. With the surgeon who isn't six specialists but a single one exercising six specialties in a single operation, you understood that the architect's competence isn't knowing the pieces separately, but exercising them chained on a real change. You ran the teaser of the thread —from the business sentence "open Mercado to external sellers and grow 10x" to the integrated dossier— and saw that each step feeds the next: 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 the conversation with the VP. And you understood why the capstone matters more than the sum of its parts: the pieces constrain each other, the order is part of the craft, and the thread ends in a person, not an artifact.

Before moving on you should be able to: name the six steps of the thread in order and what module contributes each one; explain why the order matters (each link depends on the previous one); and say what information travels from one step to the next.

What follows is going down from the map to the terrain and building the first piece. Lesson 2 does step 1: framing the role and the assignment. Before deriving a single attribute or drawing a single box, the architect has to understand what their role is in this change and how not to become the bottleneck everything has to pass through. You're going to take the sentence "open to external sellers + grow 10x", translate it into the set of decisions it unleashes, and separate the few the architect owns from the many they delegate —measuring, executed, the coordination cost of doing it wrong—. It's the step 0 of any change: knowing what falls to you before touching the architecture.

Resources

• Mark Richards & Neal Ford — Fundamentals of Software Architecture — the book that treats the architect's role as the integration of many responsibilities (technical, communication, leadership) into a single person; the direct backing of the thesis of "the craft as a single movement".
• Gregor Hohpe — The Software Architect Elevator — the image of the architect who goes up and down between the business and engineering is exactly the thread of this capstone: from the VP's goal to the system and back to the conversation with the VP.
• Martin Fowler — "Who Needs an Architect?" — the essay that frames the architect's role as something more than drawing diagrams; useful for understanding why the capstone ends in a conversation and not in an artifact.
• Simon Brown — The C4 model — the reference for the communication piece (step 4) you'll see integrated in the thread; here it's worth having on hand because the capstone uses it as one piece among six, not as the end in itself.