1. Presentación del capstone: el oficio como un solo movimiento

Descripción

Llegaste al final de la guía, y este módulo es distinto de los siete anteriores. Los otros te enseñaron una pieza del oficio cada uno: qué hace de verdad un arquitecto (M1), la Ley de Conway y su maniobra inversa (M2), comunicar con el C4 y el ADR (M3), liderar sin autoridad (M4), traducir metas de negocio a atributos de calidad (M5), diseñar para el cambio (M6) y documentar de forma que sobreviva (M7). Cada uno cerró con su propio proyecto, y en cada proyecto ejercías esa pieza sola. Este módulo no agrega una pieza nueva: junta las seis en un solo movimiento. Porque el trabajo real del arquitecto no llega en piezas etiquetadas —nadie te pide "aplícame la maniobra inversa de Conway"—; llega como un cambio de negocio que exige todas las piezas a la vez, en orden, encadenadas. El capstone es donde compruebas que el oficio es uno solo.

El recorrido de este módulo es de vuelta: en lugar de avanzar hacia un tema nuevo, vas a recorrer los siete que ya conoces, pero ahora viéndolos como lo que son —eslabones de una sola cadena—. Vas a tomar un cambio real de Mercado, la apuesta insignia del liderazgo —abrir el marketplace a vendedores externos por API y crecer 10x—, y vas a producir, paso a paso, el entregable que un arquitecto de verdad pondría sobre la mesa: el mapa de qué decisiones son suyas y cuáles delega, los atributos de calidad derivados de la meta, la organización rediseñada con la maniobra inversa de Conway y su fricción medida, el C4 y el ADR que comunican la decisión, el plan del rollout sin autoridad, el plan de evolución, la documentación que lo sostiene, y el guion de la conversación con el VP que aprueba el presupuesto. Todo junto, cosido por un solo hilo.

Conexión con el módulo: esta lección es el mapa del capstone. No construye todavía ninguna pieza del entregable —eso lo hacen las lecciones 2 a 7, una pieza por lección— sino que muestra el hilo que las une, para que cuando construyas cada parte sepas de dónde viene y hacia dónde alimenta. La lección 2 enmarca el rol y el encargo (M1); la 3 deriva los atributos (M5); la 4 aplica la maniobra inversa (M2); la 5 produce el C4 y el ADR (M3); la 6 lidera el rollout (M4); la 7 planea la evolución y la documentación (M6+M7); y la 8 ensambla todo en el dossier integrado, lo evalúa con una rúbrica, y cierra la guía entera apuntando hacia el ecosistema. Aquí solo miras el conjunto desde arriba, antes de bajar a cada pieza.

El cirujano que no es seis especialistas

Imagina que entras a un quirófano a que te operen. Adentro hay un cirujano. Ese cirujano, en la hora que dura la operación, hace muchas cosas distintas: lee las imágenes y decide dónde cortar (diagnóstico), abre con precisión (técnica quirúrgica), maneja el sangrado si algo se complica (control de crisis), coordina a la enfermera instrumentista y al anestesiólogo (liderazgo del equipo), decide sobre la marcha si el plan cambia (juicio en tiempo real), y deja las notas operatorias para el médico que te atienda después (documentación). Cada una de esas cosas es una especialidad que el cirujano estudió por separado, en años distintos de su formación: anatomía un año, técnica quirúrgica otro, manejo de complicaciones otro.

Pero en el quirófano no hay seis personas, una por especialidad. Hay una sola, que ejerce las seis en una sola operación continua, donde cada una alimenta a la siguiente: el diagnóstico decide dónde cortar, el corte revela lo que hay que controlar, el control exige coordinar al equipo, la coordinación depende del juicio, y todo termina en la nota que sobrevive. Un cirujano que supiera anatomía perfecta pero no pudiera coordinar al equipo mataría al paciente. Uno que operara con técnica impecable pero sin juicio para cambiar el plan cuando aparece lo inesperado, también. La competencia no es saber las seis especialidades por separado; es ejercerlas como una sola cosa, en secuencia, bajo presión, sobre un paciente real.

El arquitecto ante un cambio de negocio es ese cirujano. Estudiaste las seis especialidades del oficio en módulos separados —una por módulo, como el cirujano estudia anatomía y técnica en años distintos—. Pero el cambio "abrir Mercado a vendedores externos" no llega dividido en seis: llega como una sola operación donde derivar los atributos decide qué estructura necesitas, la estructura decide qué comunicar, la comunicación decide qué liderar, y todo termina en la documentación que sobrevive. Este capstone es tu primera operación completa: no seis exámenes separados, una sola cirugía de punta a punta.

Ejemplo trabajado: el hilo, de la frase de negocio al entregable

Antes de construir cada pieza, vale la pena ver la cadena completa de un vistazo: cómo una sola frase de negocio se convierte, paso a paso, en un entregable, y cómo la salida de cada paso es la entrada del siguiente. Este código no calcula nada nuevo —los números salen de las lecciones que vienen—; su único trabajo es mostrar el hilo, para que sepas hacia dónde vas.

# TEASER del capstone: el oficio como UN SOLO hilo. No calculamos nada nuevo todavia;
# solo mostramos como una frase de negocio se convierte, paso a paso, en un entregable.
# Cada paso es un modulo de la guia, y la salida de uno es la entrada del siguiente.

business_sentence = "Abrir Mercado a vendedores externos por API y crecer 10x."

craft = [
    ("M1", "enmarcar el rol y el encargo",
     "la frase -> 46 decisiones; el arquitecto posee 8, delega 38"),
    ("M5", "derivar los atributos desde la meta",
     "top = scalability (38); conflicto rector = scalability vs cost (57)"),
    ("M2", "aplicar la maniobra inversa de Conway",
     "un equipo stream-aligned nuevo; friccion 21 -> 7 pares (-67%)"),
    ("M3", "producir el C4 y el ADR",
     "el diagrama (que) para el VP y el dev + el ADR (por que) para el futuro"),
    ("M4", "liderar el rollout sin autoridad",
     "adopcion genuina 6.0/6 vs mandato 0.4/6; carga 6 vs 48 PRs"),
    ("M6+M7", "planear la evolucion y documentar",
     "3 ahora + 2 sacrificial + 3 diferidas; bus factor 1 -> 3"),
]

print(f"ENCARGO: {business_sentence}")
print("=" * 68)
for i, (mod, step, result) in enumerate(craft, 1):
    arrow = "   |" if i < len(craft) else "   v"
    print(f"paso {i}  [{mod:<6}]  {step}")
    print(f"          -> {result}")
    print(arrow)
print("ENTREGABLE: el dossier del arquitecto -- meta, estructura, C4, ADR,")
print("            rollout, evolucion y la conversacion con el VP, integrados.")
print("=" * 68)
print("Observa la cadena: la salida de cada paso ALIMENTA al siguiente. La meta")
print("manda el atributo; el atributo pide la estructura; la estructura se comunica;")
print("la comunicacion se adopta; lo adoptado se evoluciona y se documenta. Los seis")
print("modulos que estudiaste por separado son, en el trabajo real, un solo movimiento.")

Qué esperar. Al correrlo:

ENCARGO: Abrir Mercado a vendedores externos por API y crecer 10x.
====================================================================
paso 1  [M1    ]  enmarcar el rol y el encargo
          -> la frase -> 46 decisiones; el arquitecto posee 8, delega 38
   |
paso 2  [M5    ]  derivar los atributos desde la meta
          -> top = scalability (38); conflicto rector = scalability vs cost (57)
   |
paso 3  [M2    ]  aplicar la maniobra inversa de Conway
          -> un equipo stream-aligned nuevo; friccion 21 -> 7 pares (-67%)
   |
paso 4  [M3    ]  producir el C4 y el ADR
          -> el diagrama (que) para el VP y el dev + el ADR (por que) para el futuro
   |
paso 5  [M4    ]  liderar el rollout sin autoridad
          -> adopcion genuina 6.0/6 vs mandato 0.4/6; carga 6 vs 48 PRs
   |
paso 6  [M6+M7 ]  planear la evolucion y documentar
          -> 3 ahora + 2 sacrificial + 3 diferidas; bus factor 1 -> 3
   v
ENTREGABLE: el dossier del arquitecto -- meta, estructura, C4, ADR,
            rollout, evolucion y la conversacion con el VP, integrados.
====================================================================
Observa la cadena: la salida de cada paso ALIMENTA al siguiente. 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. Los seis
modulos que estudiaste por separado son, en el trabajo real, un solo movimiento.

Lee la salida como el índice de todo lo que vas a construir. Cada línea paso N es una lección de las que siguen, y cada flecha -> es lo que producirás en esa lección. Pero lo importante no son los números —esos los derivarás tú, uno por uno—; lo importante son las barras verticales entre pasos. Cada | es una dependencia: el paso de abajo no puede empezar sin la salida del de arriba. No puedes derivar los atributos (paso 2) sin haber enmarcado el encargo (paso 1); no puedes estructurar los equipos (paso 3) sin saber que scalability es el atributo rector (paso 2); no puedes comunicar la decisión (paso 4) sin haber decidido la estructura (paso 3). El oficio no es un menú del que eliges piezas sueltas: es una cadena, y el orden importa porque cada eslabón cuelga del anterior.

Fíjate en el eslabón 2, que es el corazón del hilo. El atributo que encabeza —scalability con 38— no lo eligió el arquitecto porque le guste escalar; salió de la meta ("crecer 10x", "abrir a vendedores externos"). Y ese atributo, una vez derivado, dicta el paso 3: si scalability es lo que más pesa, la estructura tiene que producir un surface de vendedores que escale independientemente, y por eso el paso 3 crea un equipo dueño de ese surface. Si el paso 2 hubiera dado otro atributo rector —digamos security, como en el proyecto de pagos a plazos del módulo 5—, el paso 3 habría diseñado otra organización. El hilo es causal: la meta manda hacia abajo, no al revés. Un arquitecto que empezara por el paso 3 (estructurar equipos) sin haber hecho el paso 2 (derivar los atributos) estaría reorganizando a ciegas —el anti-patrón exacto que el módulo 2 llamó "reorganización perpetua"—.

Y fíjate en el destino: el entregable no es ninguna de las seis piezas sueltas, es el dossier que las integra —una sola foto donde se ve cómo la meta produjo la estructura que produjo la comunicación que se adoptó y se documentó—. Eso es lo que un arquitecto real entrega, y lo que vas a ensamblar en la lección 8. Las lecciones 2 a 7 construyen cada pieza; la 8 las cose y las defiende ante el VP.

Por qué el capstone importa más que la suma de sus partes

Podrías preguntarte: si ya hiciste los seis proyectos de los módulos anteriores, ¿qué agrega hacer uno que los junta? La respuesta es que la integración es una habilidad en sí misma, distinta de cada pieza, y es la que de verdad separa a un arquitecto de alguien que estudió arquitectura. Tres razones.

Primera, las piezas se restringen entre sí, y solo lo ves cuando las juntas. En aislamiento, cada pieza tiene libertad: en el módulo 5 podías derivar cualquier ranking de atributos; en el módulo 2, diseñar cualquier organización. Pero en el capstone la salida del paso 2 amarra la entrada del paso 3: si derivaste scalability como rector, ya no eres libre de estructurar los equipos como quieras —tienes que estructurarlos para que produzcan un sistema que escale—. La coherencia entre piezas es una restricción que no existe cuando practicas una sola. Un arquitecto que deriva scalability y luego diseña una organización que no la produce cometió un error que ningún proyecto de módulo aislado podía revelar, porque el error vive en la junta entre dos piezas, no dentro de ninguna.

Segunda, el orden es parte del oficio, y el capstone es donde se practica. Los módulos se estudiaron en un orden pedagógico (primero el rol, luego Conway, luego comunicación...), pero el orden en que se ejerce el oficio ante un cambio real es el que viste en el teaser: primero el encargo, luego los atributos, luego la estructura, luego la comunicación, luego el liderazgo, luego la evolución. Ese orden no es arbitrario: es el orden de las dependencias. Empezar por comunicar (dibujar el C4) antes de haber derivado los atributos y decidido la estructura es dibujar una arquitectura que aún no decidiste —poner el diagrama antes que la decisión, el error clásico del arquitecto que ama las cajas—. El capstone te obliga a ejercer el oficio en el orden correcto, que es un aprendizaje que ningún módulo suelto da.

Tercera, el hilo termina en una persona, no en un artefacto. Los seis pasos técnicos producen artefactos (un ranking, un diagrama, un ADR), pero el capstone termina donde termina el trabajo real del arquitecto: en la conversación con el VP que aprueba —o no— el presupuesto para todo esto. Ese último paso cose el oficio entero de vuelta al negocio de donde salió: el arquitecto le explica al VP, en su idioma, que "crecer 10x" (su meta) implica un trade-off contra "no triplicar la factura" (su otra meta), y que no puede tener las dos al máximo. Todo el trabajo técnico —los atributos, la estructura, la comunicación— existe para hacer posible esa conversación con evidencia. El capstone no termina en un diagrama bonito; termina en un humano diciendo que sí, que es donde de verdad empieza una arquitectura.

Errores comunes

Tratar el capstone como seis proyectos pegados en vez de uno solo (de piezas sueltas). Qué pasa: el alumno hace cada pieza como si fuera un mini-proyecto independiente —deriva unos atributos, diseña una organización cualquiera, dibuja un C4 cualquiera— sin verificar que cada una se derive de la anterior. El resultado es un "entregable" donde las piezas no se hablan: atributos que dicen scalability y una organización que no la produce. Por qué pasa: es lo que se practicó seis veces, así que el reflejo es tratar cada parte sola. Cómo detectarlo: si puedes cambiar la salida de un paso sin que cambie ninguna de las siguientes, no hay hilo —tienes seis islas—. Cómo corregirlo: en cada paso, pregúntate "¿de qué salida del paso anterior depende esto?" y hazlo explícito; el entregable correcto es una cadena donde cada eslabón cita al anterior.

Saltarse el encargo y empezar por dibujar (de arquitecto que ama las cajas). Qué pasa: la emoción de un cambio grande empuja a abrir el editor de diagramas y dibujar la arquitectura objetivo de inmediato, antes de haber enmarcado el rol o derivado los atributos. Por qué pasa: dibujar se siente como progreso y es lo más divertido del oficio. Cómo detectarlo: si tienes un C4 antes de tener el ranking de atributos, dibujaste una arquitectura que no decidiste con método. Cómo corregirlo: respeta el orden del hilo —el C4 es el paso 4, no el 1—; primero enmarca el encargo (paso 1) y deriva los atributos (paso 2), porque son ellos los que te dicen qué arquitectura dibujar. El diagrama comunica una decisión; primero hay que tomarla.

Olvidar que el hilo termina en una conversación, no en un artefacto (de entregable sin destino). Qué pasa: el alumno produce artefactos técnicos impecables —ranking, C4, ADR— pero nunca prepara la conversación con el VP, como si el trabajo del arquitecto terminara en el documento. Por qué pasa: los artefactos son tangibles y la conversación se siente "blanda", accesoria. Cómo detectarlo: si tu entregable no incluye cómo le explicarías el trade-off principal al stakeholder que paga, te quedaste a mitad del oficio. Cómo corregirlo: recuerda que todo el trabajo técnico existe para habilitar la decisión de negocio; el guion de la conversación con el VP no es un adorno, es el eslabón que convierte el diagrama en un sistema aprobado. Un dossier perfecto que nadie aprueba no construye nada.

Ejercicios

Ejercicio 1 — Nombra las dependencias del hilo. El teaser muestra seis pasos encadenados. Para tres de las flechas entre pasos, explica qué información viaja de un paso al siguiente: (a) del paso 2 (atributos) al paso 3 (estructura); (b) del paso 3 (estructura) al paso 4 (comunicación); (c) del paso 5 (rollout) al paso 6 (evolución/documentación).

Ver solución

• (a) Del paso 2 al paso 3 viaja el atributo rector y el conflicto. Que scalability sea el atributo que más pesa (38) es lo que le dice al paso 3 qué arquitectura producir: una donde el surface de vendedores pueda escalar independientemente. Si el paso 2 hubiera dado security como rector, el paso 3 diseñaría otra organización (equipos alrededor del aislamiento y la auditoría, no de la escala). La estructura no se decide en el vacío; se decide para producir el atributo que la meta priorizó.

• (b) Del paso 3 al paso 4 viaja la decisión estructural que hay que comunicar. El paso 3 decide crear un equipo stream-aligned dueño del surface de vendedores y volver la plataforma un servicio. Esa decisión es exactamente lo que el paso 4 comunica: el C4 muestra el surface nuevo y sus fronteras (el qué), y el ADR explica por qué se creó ese equipo y ese servicio (el porqué). Sin la decisión del paso 3, el paso 4 no tendría qué dibujar ni qué justificar —comunicar precede una decisión ya tomada, no la inventa—.

• (c) Del paso 5 al paso 6 viaja qué se adoptó de verdad y quién lo posee. El paso 5 (rollout) produce la adopción genuina del contrato y el mapa de qué equipo terminó dueño de qué. El paso 6 usa eso: planea la evolución de lo que de verdad se construyó y se adoptó (no de lo imaginado), y mide el bus factor sobre el mapa de ownership real que salió del rollout. No puedes documentar ni planear la evolución de algo que nadie adoptó; primero se adopta (paso 5), luego se evoluciona y se documenta (paso 6).

La lección del ejercicio: cada flecha del hilo transporta información concreta, y esa información es lo que hace que el entregable sea coherente en vez de seis piezas sueltas. Nombrar las dependencias es entender el oficio como cadena.

Ejercicio 2 — Cambia la meta, predice el hilo. Supón que el cambio de Mercado no fuera "abrir a vendedores externos + crecer 10x" sino "cumplir la nueva regulación de protección de datos financieros antes de una auditoría en seis meses". Sin hacer los cálculos, predice cómo cambiaría el hilo: qué atributo probablemente encabezaría el paso 2, y cómo eso cambiaría la estructura del paso 3.

Ver solución

El atributo rector del paso 2 cambiaría de scalability a security (y auditabilidad). "Cumplir la regulación de datos financieros" es una meta de naturaleza completamente distinta a "crecer 10x": no empuja la escala, empuja la seguridad, la privacidad y la auditabilidad. El mapeo meta→atributo daría un ranking donde security domina y scalability casi no aparece —exactamente el contraste que el proyecto del módulo 5 mostró con los pagos a plazos—. El hilo es fiel a la meta, y esta meta es otra.

La estructura del paso 3 cambiaría en consecuencia. Si el atributo rector es security/auditabilidad en vez de scalability, la maniobra inversa de Conway ya no diseñaría un equipo para escalar un surface de vendedores, sino quizás un equipo (o una capacidad transversal) alrededor del cumplimiento y la auditoría —dónde viven los datos financieros, quién los toca, cómo se registra cada acceso—. La organización se diseña para producir el atributo que la meta priorizó, así que un atributo rector distinto produce una organización distinta.

Y hacia abajo, todo el hilo se reacomodaría: el C4 y el ADR comunicarían la decisión de cumplimiento (no la del surface de vendedores); el rollout lideraría la adopción de los controles de auditoría; la evolución y la documentación se centrarían en lo que la auditoría exige. El método (el hilo) es el mismo; el contenido de cada eslabón cambia porque la meta cambió. Eso es lo que se transfiere del capstone: no las respuestas (scalability 38, friccion 21→7), sino la cadena que las produce a partir de cualquier meta.

Ejercicio 3 — ¿Qué falta si te saltas un eslabón? Un arquitecto de Mercado, con prisa, hace los pasos 2, 3 y 4 (deriva atributos, estructura equipos, dibuja el C4 y el ADR) pero se salta el paso 5 (el rollout sin autoridad): entrega el diagrama y el ADR al VP y se va, confiado en que los equipos "lo implementarán porque está bien diseñado". Predice qué va a pasar, apoyándote en lo que aprendiste en la guía.

Ver solución

Va a pasar que la arquitectura no se construye —o se construye deforme—, por más impecable que sea el diagrama. El paso 5 (liderar el rollout sin autoridad) es el que convierte una decisión en un sistema real, y saltárselo es el error central que el módulo 4 desmontó: creer que "tener razón es tener poder", que una arquitectura bien diseñada se implementa sola. No se implementa sola. Los cinco squads no le reportan al arquitecto; si nadie lidera la adopción —sembrando en el early adopter, dando el guardrail que la hace barata, manejando las objeciones, construyendo el consenso—, cada squad seguirá con sus prioridades, el equipo nuevo (seller_platform) no se formará, y los contratos de plataforma-como-servicio no se adoptarán. El diagrama quedará en un documento que nadie ejecuta —la torre de marfil del módulo 1—.

Peor aún, sin el paso 5 la Ley de Conway (módulo 2) opera en contra: como la organización no se reestructuró de verdad (solo se dibujó la reestructuración), el surface de vendedores lo seguirán tocando varios squads por proximidad, y el código reflejará esa organización vieja, no la del diagrama. En unos meses, el sistema real no se parecerá al C4 —el arquitecto dibujó un cauce nuevo pero no cambió el terreno, así que el río volvió a su curva—.

La lección: el hilo no tiene eslabones opcionales. Los pasos 2-4 producen la decisión y su comunicación; el paso 5 la hace pasar. Un arquitecto que entrega el diagrama y se va hizo la mitad más fácil y se saltó la mitad que de verdad decide si algo se construye. El oficio termina cuando la organización ejecuta, no cuando el diagrama está bonito.

Resumen y siguiente paso

En esta lección viste el capstone desde arriba: no un tema nuevo, sino los seis que ya conoces vistos como un solo movimiento. Con el cirujano que no es seis especialistas sino uno solo ejerciendo seis especialidades en una sola operación, entendiste que la competencia del arquitecto no es saber las piezas por separado, sino ejercerlas encadenadas sobre un cambio real. Ejecutaste el teaser del hilo —de la frase de negocio "abrir Mercado a vendedores externos y crecer 10x" al dossier integrado— y viste que cada paso alimenta al siguiente: 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 la conversación con el VP. Y entendiste por qué el capstone importa más que la suma de sus partes: las piezas se restringen entre sí, el orden es parte del oficio, y el hilo termina en una persona, no en un artefacto.

Antes de avanzar deberías poder: nombrar los seis pasos del hilo en orden y qué módulo aporta cada uno; explicar por qué el orden importa (cada eslabón depende del anterior); y decir qué información viaja de un paso al siguiente.

Lo que sigue es bajar del mapa al terreno y construir la primera pieza. La lección 2 hace el paso 1: enmarcar el rol y el encargo. Antes de derivar un solo atributo o dibujar una sola caja, el arquitecto tiene que entender qué es su rol en este cambio y cómo no volverse el cuello de botella por el que todo tiene que pasar. Vas a tomar la frase "abrir a vendedores externos + crecer 10x", traducirla al conjunto de decisiones que desata, y separar las pocas que el arquitecto posee de las muchas que delega —midiendo, ejecutado, el costo de coordinación de hacerlo mal—. Es el paso 0 de cualquier cambio: saber qué te toca a ti antes de tocar la arquitectura.

Recursos

• Mark Richards & Neal Ford — Fundamentals of Software Architecture — el libro que trata el rol del arquitecto como la integración de muchas responsabilidades (técnicas, de comunicación, de liderazgo) en una sola persona; el respaldo directo de la tesis de "el oficio como un solo movimiento".
• Gregor Hohpe — The Software Architect Elevator — la imagen del arquitecto que sube y baja entre el negocio y la ingeniería es exactamente el hilo de este capstone: de la meta del VP al sistema y de vuelta a la conversación con el VP.
• Martin Fowler — "Who Needs an Architect?" — el ensayo que enmarca el rol del arquitecto como algo más que dibujar diagramas; útil para entender por qué el capstone termina en una conversación y no en un artefacto.
• Simon Brown — The C4 model — la referencia de la pieza de comunicación (paso 4) que verás integrada en el hilo; aquí conviene tenerla a la mano porque el capstone la usa como una pieza entre seis, no como el fin en sí mismo.