8. Proyecto: sé el arquitecto de Mercado ante el cambio

Descripción

Esta es tu graduación —no de un módulo, sino de toda la guía—. Durante siete módulos aprendiste el oficio del arquitecto en piezas: qué hace de verdad (M1), la Ley de Conway y su maniobra inversa (M2), comunicar con el C4 y el ADR (M3), liderar sin autoridad (M4), derivar atributos de calidad desde el negocio (M5), diseñar para el cambio (M6) y documentar de forma que sobreviva (M7). Y en las siete lecciones anteriores de este capstone recorriste esas piezas otra vez, encadenadas sobre un cambio real: enmarcaste el rol, derivaste los atributos, aplicaste la maniobra inversa, produjiste el C4 y el ADR, lideraste el rollout, y planeaste la evolución y la documentación. Ahora te toca a ti, de principio a fin: ensamblar las seis piezas en un solo dossier integrado, defenderlo ante el VP, y comprobar que el oficio es uno solo.

La razón de hacerlo tú, completo, es la de siempre y es dura: si te dejara repetir los ejemplos de las lecciones, no sabría si aprendiste el oficio o memorizaste las respuestas. El entregable de este proyecto no es ninguna pieza suelta —esas ya las construiste—; es el dossier del arquitecto: el documento coherente donde se ve cómo la meta produjo los atributos que produjeron la estructura que se comunicó, se adoptó, se evolucionó y se documentó, coronado por la conversación con el VP que cose el oficio de vuelta al negocio. Y para probar que aprendiste el método y no la receta, el proyecto termina con ejercicios de transferencia que te lanzan un giro nuevo del negocio —una meta que cambia a mitad de camino— y te piden recorrer el hilo otra vez. Constrúyelo tú primero; leer la solución de referencia sin haberlo intentado es como leer el marcador de un partido que no jugaste.

Conexión con el módulo, y con la guía entera: este proyecto cierra el arco del capstone y de la guía. Las lecciones 2 a 7 te dieron cada pieza con su medición ejecutada; aquí las integras en un dossier con tus manos, de principio a fin, y le agregas la única pieza que faltaba —la conversación con el VP—. Y con esta lección se cierra todo: al final está el resumen de la guía completa (los siete módulos como un solo oficio) y el puente hacia dónde seguir —el ecosistema de guías que te da el método de decidir (architecture-decisions-and-tradeoffs) y las opciones técnicas (los patrones) sobre las que el arquitecto que ahora eres tomará sus decisiones—.

El caso del proyecto: el cambio insignia de Mercado

La situación —tuya para resolver, de punta a punta— es la que recorriste en el capstone:

El liderazgo de Mercado apostó por su cambio insignia de los próximos 18 meses: abrir el marketplace a vendedores externos vía API y crecer 10x. Dejar que terceros vendan en la plataforma integrando por una Seller API, y prepararse para diez veces el catálogo y el tráfico. Tú eres el arquitecto de Mercado. Tu trabajo no es escribir el código del surface de vendedores —eso lo harán las squads—; es conducir el cambio como arquitecto: derivar los atributos desde la meta, estructurar los equipos con la maniobra inversa de Conway, comunicar la decisión con el C4 y el ADR, liderar su adopción sin autoridad, planear su evolución y documentarla, y —al final— sentarte con el VP de producto a explicarle el trade-off que gobierna todo esto, en su idioma, para que apruebe el presupuesto.

El entregable es el dossier del arquitecto: un solo documento integrado, con siete artefactos encadenados. No requiere construir el sistema: es puro trabajo de arquitecto —derivar, estructurar, comunicar, liderar, planear, documentar, conversar—, que es justo lo que separa al arquitecto que conduce un cambio del que solo dibuja cajas. La disciplina del proyecto es que cada artefacto cite al anterior: el dossier no son siete islas, es una cadena donde cada eslabón se deriva del previo.

Lo que tienes que entregar

Sigue el hilo en orden; cada artefacto se apoya en el anterior.

Artefacto 1 — El rol y el encargo enmarcados (M1)

El mapa de ownership del cambio: las decisiones que desata, separadas en las cross-team que el arquitecto posee y las locales que delega con guardrails, con el costo de coordinación ejecutado (embudo vs jardinero). Nombra por qué el arquitecto no puede ser el canal único.

Artefacto 2 — Los atributos de calidad derivados (M5)

El mapeo ejecutado peso × fuerza de las metas del cambio a atributos priorizados, con el ranking corrido y el conflicto rector nombrado. Este es el insumo del que cuelga todo lo demás.

Artefacto 3 — La maniobra inversa de Conway, medida (M2)

La organización rediseñada para producir la arquitectura que el atributo rector exige —el equipo stream-aligned dueño del surface, la plataforma como servicio—, con la fricción de coordinación medida antes y después. Justifica la estructura con el atributo rector del artefacto 2.

Artefacto 4 — El C4 y el ADR (M3)

El C4 del cambio (Context para el VP, Container para el dev) en mermaid, y el ADR redactado completo que empaqueta el porqué —citando el atributo rector (artefacto 2) y la fricción medida (artefacto 3), y nombrando el precio consciente—.

Artefacto 5 — El plan del rollout, medido (M4)

El plan de adopción squad por squad (early adopter, guardrail, objeción legítima, consenso) y la medición ejecutada de la adopción genuina (influencia vs mandato) y la carga del arquitecto. Usa el C4 y el ADR como herramientas de influencia.

Artefacto 6 — El plan de evolución y la documentación (M6+M7)

El plan de fases (ahora / sacrificial / diferido-con-costura) que resuelve el conflicto rector en el tiempo, y la medición del bus factor antes y después de la documentación que sobrevive.

Artefacto 7 — El guion de la conversación con el VP (M5)

Cómo le explicas al VP el conflicto rector en su idioma, y cómo le dices "no puedo darte todo al máximo" con la priorización que sí cabe. Es donde el oficio técnico se cose de vuelta al negocio que lo pidió.

La rúbrica

Así se evalúa el dossier. No es por extensión ni por elegancia: es por si el hilo está bien cosido y cada pieza bien hecha, con evidencia.

Criterio	No cumple	Cumple	Sobresale
Rol y atributos (art. 1-2)	Trata todas las decisiones como propias; ranking inventado	Separa cross-team de local; ranking corrido con peso × fuerza	Además nombra el conflicto rector y lo conecta con la estructura
Estructura medida (art. 3)	Reorganiza sin medir o sin justificar	Aplica la maniobra inversa con la fricción medida antes/después	Además justifica la organización con el atributo rector y distingue costura genuina de artificial
Comunicación (art. 4)	Solo diagrama, o ADR de trámite	C4 a dos niveles + ADR que comunica el porqué	Además el ADR cita los artefactos 2-3 y nombra el precio consciente
Rollout medido (art. 5)	"Mando un correo" o "los convenzo"	Plan por squad + adopción y carga corridas en Python	Además usa el C4/ADR como evidencia y maneja la objeción legítima
Evolución y docs (art. 6)	Construye todo el futuro o no deja costuras	Plan de fases + bus factor medido	Además resuelve el conflicto rector en el tiempo
Conversación con el VP (art. 7)	Jerga técnica o promete todo al máximo	Traduce el conflicto rector a su idioma	Además dice "no al máximo" con la priorización que sí cabe
Integración (todo)	Siete islas sin relación	Cada artefacto cita al anterior	El dossier se lee como un solo movimiento

El criterio que más pesa, y el que separa a un arquitecto de alguien que estudió arquitectura, es la integración: si entregas siete artefactos impecables pero que no se hablan —atributos que dicen scalability y una estructura que no la produce—, no hiciste el capstone; hiciste seis proyectos de módulo otra vez. El dossier tiene que leerse como una cadena donde cada eslabón cuelga del anterior.

La solución de referencia

Intenta el proyecto entero antes de seguir. Lo que viene es una solución correcta, no la única —sobre todo en los juicios (pesos, fuerzas, clasificaciones), que son discutibles—.

El dossier ejecutado, de un vistazo

Lo primero es un programa que enlaza los seis pasos y emite el dossier integrado —la prueba de que el hilo es uno solo, con cada número derivado del anterior—. Reusa los motores de las lecciones 2 a 7.

# EL ENTREGABLE INTEGRADO: el dossier del arquitecto de Mercado para el cambio
# "abrir a vendedores externos por API + crecer 10x". Un solo pipeline que enlaza los
# seis pasos del oficio: meta -> atributo -> estructura -> comunicacion -> rollout -> evolucion.
from itertools import combinations

# ---------- Paso 2 (M5): la meta -> los atributos priorizados ----------
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]]

# ---------- Paso 3 (M2): la maniobra inversa de Conway (mismo modelo del paso 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"})

# ---------- Paso 5 (M4): el rollout sin autoridad ----------
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

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

# ---------- EL DOSSIER ----------
print("=" * 64)
print("DOSSIER DEL ARQUITECTO -- Mercado abre a vendedores externos (10x)")
print("=" * 64)
print(f"1. META -> ATRIBUTO   : top = {ranking[0]} ({score[ranking[0]]}); "
      f"conflicto rector = {top_tension[0]} vs {top_tension[1]} ({top_combined})")
print(f"2. ESTRUCTURA (Conway): friccion {f_before} -> {f_after} pares "
      f"({(1 - f_after / f_before) * 100:.0f}%) creando 1 equipo stream-aligned")
print(f"3. COMUNICACION       : C4 (Context 6 / Container 12 elems) + ADR-021 (el porque)")
print(f"4. ROLLOUT (sin auth) : adopcion {inf:.1f}/6 real vs {man:.1f}/6 por mandato; "
      f"carga arquitecto {guardrail} vs {gate} PRs")
print(f"5. EVOLUCION          : {now} ahora + {sacrificial} sacrificial + {deferred} diferidas")
print(f"6. DOCUMENTACION      : bus factor {bus_before} -> {bus_after} (docs-as-code)")
print("=" * 64)
print("Un solo hilo: la meta manda el atributo; el atributo pide la estructura; la")
print("estructura se comunica; la comunicacion se adopta; lo adoptado se evoluciona y")
print("se documenta. Eso es el OFICIO -- no seis trucos, un solo movimiento.")

Qué esperar. Al correrlo:

================================================================
DOSSIER DEL ARQUITECTO -- Mercado abre a vendedores externos (10x)
================================================================
1. META -> ATRIBUTO   : top = scalability (38); conflicto rector = scalability vs cost (57)
2. ESTRUCTURA (Conway): friccion 21 -> 7 pares (67%) creando 1 equipo stream-aligned
3. COMUNICACION       : C4 (Context 6 / Container 12 elems) + ADR-021 (el porque)
4. ROLLOUT (sin auth) : adopcion 6.0/6 real vs 0.4/6 por mandato; carga arquitecto 6 vs 48 PRs
5. EVOLUCION          : 3 ahora + 2 sacrificial + 3 diferidas
6. DOCUMENTACION      : bus factor 1 -> 3 (docs-as-code)
================================================================
Un solo hilo: la meta manda el atributo; el atributo pide la estructura; la
estructura se comunica; la comunicacion se adopta; lo adoptado se evoluciona y
se documenta. Eso es el OFICIO -- no seis trucos, un solo movimiento.

Lee el dossier de arriba abajo y sigue la causalidad, que es lo que la rúbrica premia. La línea 1 dice que scalability (38) es el atributo rector y que scalability-vs-cost (57) es el conflicto que gobierna el cambio. La línea 2 se deriva de la 1: como scalability manda, la estructura crea un equipo stream-aligned que hace escalable el surface, y eso baja la fricción de 21 a 7. La línea 3 comunica la 2: el C4 muestra la estructura, el ADR-021 la justifica citando el atributo rector. La línea 4 ejecuta la 3: el rollout adopta la arquitectura comunicada, y gana con influencia (6.0/6) donde el mandato pierde (0.4/6). La línea 5 evoluciona la 4: difiere la maquinaria del 10x resolviendo el conflicto de la línea 1 en el tiempo. Y la línea 6 documenta todo: sube el bus factor de 1 a 3. Cada línea cuelga de la anterior —esa es la integración—. Si cambiaras la línea 1 (otro atributo rector), todas las de abajo cambiarían. El dossier no es una tabla de seis números sueltos: es una cadena causal.

Los artefactos, ensamblados

El dossier de arriba es el resumen; el entregable completo desarrolla cada artefacto. Aquí están, cosidos:

Ver el dossier completo, artefacto por artefacto

Artefacto 1 — Rol y encargo (M1, lección 2). El cambio desata 46 decisiones semanales; el arquitecto posee las 8 cross-team (el contrato de la Seller API, la auth de terceros, el rate limiting, los payouts, los atributos de calidad, los límites del surface) y delega las 38 locales con guardrails. El rol embudo produciría 340 decisiones atascadas y 1870 decision-semanas de espera; el rol jardinero las lleva a cero. El arquitecto no puede ser el canal único: los canales crecen n(n-1)/2, así que la salida es estructurar los equipos (artefacto 3), no aprobarlo todo.

Artefacto 2 — Atributos derivados (M5, lección 3). Ranking corrido: scalability 38, security 30, availability 25, performance 23, cost 19. Conflicto rector: scalability vs cost (57) —"crecer 10x" contra "no triplicar la factura"—. Todo lo de abajo se justifica con este ranking.

Artefacto 3 — Estructura medida (M2, lección 4). Para producir un surface que escale (lo que scalability exige), se crea el equipo stream-aligned seller_platform, dueño del surface completo (seller_api, seller_onboarding, listing_ingestion, payout_processing), y auth + notifications + payment_processing se vuelven servicios de plataforma. Fricción: 21 → 7 pares (−67%) sin tocar el código; seller_api pasa de 6 pares de coordinación a 0. Quedan dos costuras genuinas (import listings ↔ catalog, payouts ↔ payments), que se vuelven contratos.

Artefacto 4 — C4 y ADR (M3, lección 5). El C4: Context (6 elementos, con el vendedor externo que integra por API) y Container (12 elementos, con el Seller API Gateway y seller_platform). El ADR-021 ("Exponer a los vendedores externos con una Seller API dedicada y un equipo seller_platform") cita el atributo rector (scalability 38, security 30) y la fricción medida (21), y nombra el precio consciente: el equipo nuevo que montar, la latencia del gateway que choca con instant_checkout, y las dos costuras.

Artefacto 5 — Rollout medido (M4, lección 6). Plan por squad: sembrar en seller_platform (early adopter) y platform; la load-bearing conversation con payments (objeción legítima de cumplimiento en los payouts) antes de pedir adopción; difundir con evidencia a catalog y orders; y la junta de consenso que ratifica. Medición: adopción genuina 6.0/6 con influencia+guardrail vs 0.4/6 con mandato; carga del arquitecto 6 revisiones (guardrail) vs 48 (puerta). El C4 y el ADR son las herramientas de influencia.

Artefacto 6 — Evolución y docs (M6+M7, lección 7). Plan de fases: 3 ahora (las costuras estructurales: contrato de la Seller API, frontera de seller_platform, contratos de plataforma), 2 sacrificiales (risk scoring e ingesta, versiones simples que se reemplazan con datos reales), 3 diferidas (el sharding del 10x y multi-región con costura; el dashboard por YAGNI). Difiere la maquinaria cara del 10x resolviendo el conflicto cost-vs-scalability en el tiempo. Bus factor del surface: 1 → 3 con docs-as-code (README + C4 + ADR-021 versionados).

Artefacto 7 — La conversación con el VP. (Ver abajo, porque es la pieza que cose el oficio de vuelta al negocio.)

Artefacto 7 — El guion de la conversación con el VP

El VP de producto quiere "crecer 10x" y también dijo "no podemos triplicar la factura de infra". El conflicto rector (scalability vs cost, 57) es exactamente esa contradicción. Se lo explico en su idioma —negocio y dinero—, y le digo "no al máximo en ambos":

"Quiero contarte cómo vamos a construir el cambio de vendedores externos, porque hay una tensión que te va a importar directamente y prefiero que la decidas tú, con los números, en vez de que te sorprenda después.

Tu meta insignia es crecer 10x, y me la tomé en serio: derivé, con las metas que me diste, qué es lo que más importa técnicamente, y salió claro que es la capacidad de escalar —tres de tus metas la empujan, dos de ellas las más estratégicas—. Por eso la pieza central de la arquitectura es un equipo dedicado, dueño de toda la Seller API, que puede hacerla crecer sin tener que coordinar con las otras cuatro áreas cada vez. Eso es lo que nos deja llegar a 10x sin que el sistema se vuelva un nudo.

Pero aquí está la tensión, y es tu propia meta hablando: tú también me dijiste 'no tripliquemos la factura de infra'. Y resulta que 'escalar a 10x' y 'no gastar de más' tiran de frente —construir hoy toda la maquinaria para diez veces el tráfico cuesta mucho dinero, y ahora mismo no tenemos ese tráfico; apenas vamos a abrir a los primeros vendedores—. No podemos tener las dos al máximo hoy: escalar completo para un volumen que aún no existe es quemar dinero en cuartos vacíos.

Lo que propongo no es elegir una y sacrificar la otra, sino resolverlas en el tiempo. Ahora construimos las 'tuberías y cimientos' —el contrato de la Seller API, el equipo dueño, las conexiones limpias entre áreas— que son caras de agregar después y baratas de poner ahora, y que son lo que hace posible escalar más adelante sin demoler. Pero diferimos la infraestructura cara del 10x —el particionado masivo de datos, el multi-región— hasta que el volumen real de vendedores la justifique. Dejamos la costura preparada para agregarla el día que la necesitemos, pero no gastamos en ella hoy. Así protejo tu factura ahora y tu crecimiento después, cada uno en su momento correcto.

Y quiero ser honesto sobre lo que no estamos optimizando en esta primera fase. Priorizamos poder escalar limpio y la seguridad de meter a terceros a la plataforma, que es donde está el riesgo y la apuesta. No estamos exprimiendo el costo al mínimo ni construyendo para el pico máximo imaginable —esas no son las prioridades de arrancar—. Cuando el volumen despegue, volvemos a esta mesa con datos reales y decidimos cuánto invertir en escalar, y cuánto cuesta. Te puedo mostrar, para cada fase, qué construimos, qué difiere, y cuánto cuesta cada opción, para que la raya la pongas tú viendo los dos lados —el crecimiento y la factura—, no solo uno."

Por qué funciona. Traduce el conflicto scalability-vs-cost a lo que el VP entiende (crecer contra gastar), nombra que las dos son sus propias metas en tensión (no un capricho técnico), propone resolverlo en el tiempo (diferir la maquinaria cara con costura) en vez de un máximo imposible, dice explícitamente qué no se prioriza para que no haya sorpresas, y devuelve la decisión con los números —la doble traducción del módulo 5, el "no al máximo" del oficio, y el respeto de la frontera: el arquitecto presenta, el negocio decide—. La resolución rigurosa de cuánto escalar y con qué opción técnica, cuando llegue el momento, es el método de architecture-decisions; aquí el trabajo del arquitecto fue detectar el conflicto, secuenciarlo, y conducir la conversación.

Ejercicios de transferencia

Estos ejercicios te lanzan un giro nuevo del negocio para confirmar que aprendiste el hilo, no las respuestas de este caso.

Ejercicio 1 — El VP cambia la meta a mitad de camino. Seis meses después de arrancar, el negocio pivota: la prioridad ya no es "crecer 10x" sino "cumplir una certificación de seguridad financiera para poder integrar bancos como vendedores en la plataforma", con un plazo regulatorio duro. Recorre el hilo y predice qué cambia en cada eslabón: (a) el atributo rector; (b) la estructura; (c) el énfasis del ADR; (d) la conversación con el VP.

Ver solución

• (a) El atributo rector cambia de scalability a security (y auditabilidad). "Cumplir una certificación de seguridad financiera" es una meta de naturaleza opuesta a "crecer 10x": no empuja la escala, empuja seguridad, privacidad, auditabilidad y cumplimiento. El mapeo peso × fuerza daría un ranking donde security domina y scalability cae —el mismo contraste que el proyecto del módulo 5 mostró con los pagos a plazos—. El hilo es fiel a la meta, y la meta cambió.

• (b) La estructura cambia. Con security como rector, la maniobra inversa de Conway ya no diseña solo un equipo-que-escala; probablemente agrega una capacidad de plataforma de seguridad (auth robusta, gestión de secretos, auditoría, aislamiento de datos como servicios) que seller_platform y las demás squads consumen, y quizás un equipo enabling temporal para alcanzar el nivel de la certificación. La organización se diseña para producir el atributo que ahora manda.

• (c) El énfasis del ADR cambia. El nuevo ADR (superseding o complementando el ADR-021) tendría un contexto centrado en el cumplimiento y el plazo regulatorio, una decisión sobre cómo se aíslan y auditan los datos financieros, y consecuencias donde el precio consciente incluye el costo de la certificación y quizás una latencia extra por los controles de seguridad. El diagrama mostraría los nuevos límites de seguridad.

• (d) La conversación con el VP cambia de idioma. Ya no es "escalar contra gastar"; es "cumplir la certificación a tiempo contra el costo y la velocidad de lanzamiento". El arquitecto traduciría el nuevo conflicto rector (probablemente security vs performance o security vs time-to-market) al idioma del VP —"cumplir la certeza regulatoria nos protege de una multa que vale X, pero cada control agrega tiempo; esto es lo que sí llega para el plazo"—.

La lección: el hilo es el mismo (los seis pasos, en el mismo orden); el contenido de cada eslabón cambia porque la meta cambió. Eso es lo que se transfiere del capstone —el método, no la receta—. Un arquitecto que llegara a esta nueva meta con "en Mercado lo que importa es escalar" (la conclusión del caso anterior) priorizaría exactamente lo que la certificación no necesita. El método existe para impedir eso: obliga a re-derivar desde la meta de hoy.

Ejercicio 2 — El eslabón que alguien quiere saltarse. Un director técnico impaciente te dice: "olvídate del rollout y de la documentación; con el C4 y el ADR bien hechos, los equipos ya sabrán qué construir. Vamos directo a codear". Argumenta, con lo que mediste en el capstone, por qué saltarse los pasos 5 y 6 haría fracasar el cambio aunque los pasos 1-4 estén perfectos.

Ver solución

Saltarse el paso 5 (rollout) haría que la arquitectura no se construya —o nazca deforme—. El C4 y el ADR comunican una decisión, pero no la ejecutan. Las seis squads no le reportan al arquitecto; sin liderar la adopción, cada una seguirá con sus prioridades, seller_platform no se formará, y los contratos no se adoptarán. El número del paso 5 lo mostró: sin el método de influencia, la adopción real cae (el mandato llega a 0.4/6). Y peor, la Ley de Conway operaría en contra: como la organización no se reestructuró de verdad, el surface lo seguirían tocando varios equipos, y el código reflejaría esa organización vieja, no el diagrama —la fricción volvería a 21, no a 7—. El diagrama quedaría como una foto que el sistema real desmiente.

Saltarse el paso 6 (evolución y documentación) haría que el cambio se sobre-construya y luego se pierda. Sin el plan de evolución, el reflejo ante "crecer 10x" es construir toda la maquinaria del 10x hoy (over-engineering), retrasando el lanzamiento y disparando el costo —violando la meta del CFO—. Y sin la documentación, el bus factor se queda en 1: el surface más importante del año dependería de la cabeza de quien lo construyó, y cuando esa persona se fuera, nadie sabría por qué el gateway existe ni dónde está la costura del sharding diferido. El cambio quedaría frágil y huérfano.

La lección: el hilo no tiene eslabones opcionales. Los pasos 1-4 producen y comunican la decisión; el paso 5 la hace pasar; el paso 6 la hace sostenible y evolucionable. "Vamos directo a codear" es el mito de que tener razón (un buen diseño) es tener poder (que se construya). No lo es. El oficio termina cuando la organización ejecuta y puede seguir evolucionando el sistema, no cuando el diagrama está bonito.

Ejercicio 3 — Tu propio cambio, tu propio hilo. Elige un cambio de negocio distinto para Mercado (por ejemplo: "lanzar envíos el mismo día en las tres ciudades principales", o "abrir Mercado como una app de terceros con un programa de desarrolladores"). Sin ejecutar todo el código, recorre el hilo en prosa: nombra la meta, predice el atributo rector probable, la decisión estructural que ese atributo pediría, y el conflicto que probablemente gobernaría la conversación con el VP. El objetivo es que puedas conducir el hilo sobre un caso nuevo.

Ver solución

Una solución para "lanzar envíos el mismo día en las tres ciudades principales" (el juicio es discutible, esa es la gracia):

• La meta y sus sub-metas: entrega el mismo día (peso 5), cobertura en tres ciudades (peso 4), no disparar el costo logístico (peso 4), no fallar una entrega prometida (peso 5, porque prometer y fallar daña la marca).

• El atributo rector probable: reliability / availability (que la promesa de "hoy" se cumpla siempre) y performance (la logística tiene que ser rápida), con cost en fuerte tensión (la entrega el mismo día es cara). Scalability importa menos aquí que en el caso de vendedores —no es un problema de volumen 10x, es un problema de cumplir una promesa de tiempo—. Nota que el atributo rector es distinto porque la meta es distinta.

• La decisión estructural que ese atributo pediría: un atributo rector de reliability/performance en logística probablemente pide un equipo stream-aligned dueño del flujo de entrega same-day (routing, asignación de repartidores, tracking en tiempo real), y quizás integrar la capacidad logística como un servicio con SLOs estrictos. La maniobra inversa crearía el equipo que posee ese flujo de punta a punta para que pueda optimizar la promesa de tiempo sin coordinar con medio sistema.

• El conflicto que gobernaría la conversación con el VP: reliability/performance vs cost. "Entregar el mismo día siempre" (reliability + performance) contra "no disparar el costo logístico" (cost). El arquitecto le diría al VP: "cumplir la promesa de 'hoy' el 100% de las veces exige capacidad logística de sobra, que es cara; podemos cumplirla al 95% con un costo razonable, o acercarnos al 100% pagando mucho más por el último 5%. ¿Dónde ponemos la raya —qué nivel de promesa vale su costo—?". Es el "no al máximo" aplicado a otro conflicto.

La lección: recorriste el hilo entero sobre un caso que nunca viste, y funcionó —derivaste un atributo rector distinto (reliability, no scalability), una estructura distinta (equipo de logística, no de vendedores), y un conflicto distinto (reliability vs cost, no scalability vs cost)—. Eso es tener el oficio: no las respuestas de Mercado-vendedores, sino la capacidad de conducir el hilo sobre cualquier meta. El método se transfiere; las respuestas son fieles a cada negocio.

Cierre de la guía: el oficio, completo

Con este proyecto cierras no un módulo, sino toda la guía del oficio del arquitecto. Vale la pena recorrer de vuelta lo que aprendiste, porque ahora lo ves como lo que es: un solo oficio.

Empezaste sabiendo qué es el rol (M1): no el que dibuja el plano perfecto y se va, sino el que habilita, hace reversibles las decisiones caras, baja al código, y —sobre todo— no se vuelve el cuello de botella. Aprendiste que la arquitectura la hace una organización de personas, y que la Ley de Conway (M2) hace que el sistema copie la estructura de comunicación de esa organización —y que la maniobra inversa te deja moldear los equipos para obtener la arquitectura que quieres—. Aprendiste a comunicar (M3): el C4 para mostrar el sistema al nivel correcto de cada audiencia, y el ADR para que el porqué viaje en el tiempo hasta quien llegue después. Aprendiste a liderar sin autoridad (M4): que tener razón no es tener poder, y que la adopción genuina se consigue influyendo, dando guardrails y construyendo consenso, no ordenando. Aprendiste a traducir el negocio (M5): de las metas del stakeholder a los atributos de calidad priorizados, y de los trade-offs de vuelta al idioma del negocio, sabiendo decir no. Aprendiste a diseñar para el cambio (M6): construir las costuras caras, diferir lo incierto, evitar tanto el over- como el under-engineering. Y aprendiste a documentar de forma que sobreviva (M7): docs-as-code, el C4 y el ADR versionados, el bus factor que no depende de una sola cabeza.

Y en este capstone comprobaste la tesis que atraviesa toda la guía: esos siete no son siete temas, son un solo oficio. Un cambio de negocio real —abrir Mercado a vendedores externos— no llega en piezas: llega como una operación donde la meta manda el atributo, el atributo pide la estructura, la estructura se comunica, la comunicación se adopta, lo adoptado se evoluciona y se documenta, y todo termina en una conversación con un humano que aprueba. Lo mediste de punta a punta —scalability 38, fricción 21→7, adopción 6.0/6, bus factor 1→3— y lo cosiste en un dossier donde cada número cuelga del anterior. El mayor apalancamiento del arquitecto no resultó ser técnico, sino social: qué conversaciones tiene, cómo estructura los equipos, cómo comunica un trade-off. Eso es el oficio.

Hacia dónde seguir: el ecosistema

Esta guía te enseñó el oficio de conducir un cambio. Pero un arquitecto que conduce toma decisiones técnicas —¿un gateway o integración directa?, ¿un servicio o un módulo?, ¿síncrono o por eventos?, ¿este patrón de resiliencia o aquel?—, y esta guía deliberadamente no las enseñó: las nombró y remitió a quien sí. Dos direcciones para seguir.

El método de decidir: architecture-decisions-and-tradeoffs. Cada vez que el capstone detectó un trade-off (scalability vs cost) o eligió una opción (el gateway, el servicio seller_platform), se apoyó en el método de decidir sin re-enseñarlo. Esa guía es la caja de herramientas del método: la matriz de decisión ponderada para elegir entre opciones, la mecánica completa del ADR, la fitness function que vigila que una decisión se mantenga, y la reversibilidad y el último momento responsable como técnica. Es la compañera directa de esta guía —el humano que hace pasar la decisión (aquí) y el método con que la decide (allá)—. Si el capstone te dejó con ganas de saber cómo se resuelve rigurosamente el conflicto scalability-vs-cost que solo detectaste, esa es la puerta.

Las opciones técnicas: el ecosistema de patrones. El arquitecto que ahora eres decide sobre un menú de opciones técnicas, y cada familia de opciones tiene su guía:

• architectural-styles-and-boundaries — monolito, microservicios, y dónde poner las fronteras (justo lo que la maniobra de Conway produjo como equipos, aquí como estilos de sistema).
• event-driven-architecture — cuándo comunicar por eventos en vez de llamadas síncronas (las costuras que dejaste como contratos podrían ser eventos).
• resilience-and-reliability — cómo el sistema aguanta fallos (el atributo availability que priorizaste, hecho patrones).
• api-design-and-integration — cómo se diseñan los contratos (la Seller API y los contratos de plataforma que el rollout adoptó).
• system-design — cómo se dimensiona un sistema para escala (el 10x que difieres, hecho diseño).
• legacy-modernization-and-migration — cómo se moderniza lo que ya existe sin romperlo (el monolito de Mercado, hecho migración).

La imagen para quedarte: esta guía te dio al arquitecto —el humano que entiende su rol, deriva los atributos, estructura los equipos, comunica, lidera, evoluciona y documenta—. architecture-decisions le da su método de decidir. Y el ecosistema de patrones le da sus opciones técnicas. El arquitecto conduce; el método le dice cómo elegir; los patrones son entre qué elige. Ahora tienes el primero, sabes dónde está el segundo, y tienes el mapa del tercero. El oficio está completo; lo que sigue es ejercerlo.

Recursos

• Mark Richards & Neal Ford — Fundamentals of Software Architecture — el cierre natural de la guía: el libro que trata el rol del arquitecto como la integración de todas estas responsabilidades en una sola persona, que es exactamente lo que ensamblaste en el dossier.
• Gregor Hohpe — The Software Architect Elevator — el arquitecto que sube y baja entre el negocio y la ingeniería; el marco del hilo entero, de la meta del VP al sistema y de vuelta a la conversación con el VP que cerró el proyecto.
• Matthew Skelton & Manuel Pais — Team Topologies — el respaldo de la estructura (el equipo stream-aligned, la plataforma como servicio) que la maniobra inversa produjo, y de por qué la organización es la palanca del sistema.
• Simon Brown — The C4 model y Michael Nygard — "Documenting Architecture Decisions" — las dos piezas de comunicación (diagrama + ADR) que produjiste y que, versionadas, subieron el bus factor; las herramientas que el arquitecto usa dos veces (comunicar y documentar).
• Melvin Conway — "How Do Committees Invent?" (1968) — el artículo fundacional de la ley que hace que estructurar la organización sea estructurar el sistema; el corazón de por qué el oficio del arquitecto es, antes que técnico, organizacional.