Módulo 1: Qué hace de verdad un arquitecto

Presentación del módulo: qué hace de verdad un arquitecto

Siguiente →

Por qué este módulo existe aquí

Pregúntale a diez personas qué hace un arquitecto de software y nueve te van a describir a la misma persona: alguien que se encierra unas semanas, dibuja el diagrama definitivo del sistema —cajas, flechas, capas, una nube que dice "Kafka"—, lo presenta en una reunión importante, y luego vuelve a su torre a diseñar el siguiente. El diagrama es bonito. La imagen es prestigiosa. Y es, casi por completo, falsa. No falsa porque los arquitectos no dibujen —dibujan—, sino falsa en lo que cree que es el trabajo. El trabajo del arquitecto no es el diagrama; el diagrama es un subproducto. Este módulo desmonta esa imagen y pone en su lugar la que sostiene toda la guía: el arquitecto real no produce diagramas, produce condiciones para que un sistema y una organización evolucionen bien.

Esta guía completa enseña el oficio humano y organizacional de ser arquitecto: cómo la estructura de los equipos moldea la del sistema (la ley de Conway, módulo 2), cómo comunicar la arquitectura para que la entiendan distintas audiencias (el C4, módulo 3), cómo liderar sin autoridad formal (módulo 4), cómo traducir metas de negocio a atributos de calidad (módulo 5), cómo planear para el cambio (módulo 6) y cómo documentar de forma que sobreviva (módulo 7). Todo eso descansa sobre una idea del rol. Si tu idea del rol es "el que dibuja el diagrama perfecto", el resto de la guía no tiene dónde apoyarse. Por eso este módulo va primero: instala qué es el rol —y qué no es— antes de enseñar cómo se ejerce.

Vamos con el caso que nos acompaña toda la guía. Mercado es un marketplace, y aquí no es solo el sistema: es el sistema y su organización. Cinco squads se reparten el trabajo:

  • catalog — el catálogo de productos, la búsqueda, las fichas.
  • orders — el carrito, el checkout, el ciclo de vida del pedido.
  • payments — el cobro, los proveedores de pago, la conciliación.
  • shipping — el envío, las etiquetas, el tracking.
  • platform — lo transversal: autenticación, observabilidad, el CI/CD, la infraestructura compartida.

Además hay stakeholders de negocio —un VP de producto que pide features, finanzas que mira los costos, operaciones que sufre cuando el checkout se cae— y, en medio de todo, un arquitecto que debe alinear cinco squads con metas de negocio sin volverse el embudo por donde pasa cada decisión. Ese es el escenario real del oficio, y es donde este módulo trabaja. Fíjate en lo que no es el escenario: no es un arquitecto solo frente a un lienzo en blanco. Es un arquitecto frente a personas que ya están construyendo, decidiendo y a veces chocando.

Conexión con el módulo. Esta es la lección-mapa. No entra a fondo en ninguna herramienta; instala la tesis (el arquitecto produce decisiones reversibles, un porqué comunicado y equipos habilitados, no diagramas), el vocabulario (decisión de nivel arquitecto vs local, torre de marfil, el elevador, guardrails, cuello de botella, BDUF, último momento responsable) y el mapa de cómo cada lección desarma una imagen falsa y monta una real. La lección 2 desmonta la torre de marfil. La 3 explica por qué el arquitecto sigue cerca del código (el elevador). La 4 define su producto real: decisiones reversibles más el porqué. La 5 lo pone como jardinero que habilita, no dictador. La 6 mide el peligro central: el cuello de botella. La 7 opone el BDUF al último momento responsable. Y la 8 te pone a diagnosticar y rediseñar el rol del arquitecto de Mercado, ejecutado. Cuidado con la frontera, que es deliberada: el método de decidir —cómo comparar opciones con una matriz, la mecánica del ADR, la fitness function, la reversibilidad como técnica— lo enseña la guía hermana architecture-decisions-and-tradeoffs; la ley de Conway es el módulo 2; el C4 es el módulo 3; el liderazgo sin autoridad a fondo es el módulo 4. Aquí solo instalamos qué es el rol y desmontamos sus mitos.

Y una promesa que se cumple en todo el módulo: aunque el tema es humano, lo cuantificable se ejecuta, no se afirma. Cada simulación corre con Python 3.14 y solo la biblioteca estándar, con datos fijos, así que la salida que ves en cada bloque "Qué esperar" es la salida literal de correr el código. Puedes copiarlo y reproducirlo idéntico.

Una analogía: el arquitecto de edificios que no desaparece tras el plano

Piensa en un arquitecto de edificios, el de verdad, el que construye casas. Hay dos maneras de imaginar su trabajo, y solo una es la real.

La imagen falsa. El arquitecto se sienta en su estudio, dibuja los planos perfectos del edificio —cada muro, cada ventana, cada tubería en su sitio—, los enrolla, se los entrega al maestro de obra y se va. A partir de ahí, "es problema de los albañiles". Si algo falla, fue porque no siguieron el plano. En esta imagen, el arquitecto es un productor de documentos: su trabajo empieza y termina en el papel.

La imagen real. Un buen arquitecto de edificios entrega los planos, sí, pero eso es el principio de su trabajo, no el final. Visita la obra. Camina el terreno y descubre que el suelo es más blando de lo que decía el estudio, así que ajusta la cimentación. Habla con los albañiles y aprende que el muro que dibujó en tres días toma dos semanas por cómo llega el material, así que replantea la secuencia. Se para frente al hueco de una ventana, ve que da a un muro feo del vecino, y la reorienta ahí mismo. Cuando el cliente cambia de idea a mitad de obra —"quiero la cocina abierta"—, no dice "el plano ya está firmado"; se sienta y rediseña esa parte. El plano no fue una profecía que la realidad debía obedecer; fue una hipótesis que la realidad fue corrigiendo, y el arquitecto estuvo ahí para corregirla.

Aquí está el punto: el arquitecto real no desaparece tras el plano. Su valor no está en el dibujo perfecto que entregó el día uno —ese dibujo, contra la realidad, siempre estuvo parcialmente equivocado—. Su valor está en seguir presente: bajar a la obra, hablar con quien construye, ajustar cuando el terreno o el cliente lo obligan, y sostener la coherencia del edificio a lo largo de meses de decisiones pequeñas que nadie anotó en el plano original. El arquitecto de software es igual. El diagrama del día uno es una hipótesis. El trabajo es todo lo que viene después: bajar al código (la obra), hablar con las squads (los albañiles), ajustar cuando el negocio cambia (el cliente), y hacerlo sin convertirse en la persona por quien tiene que pasar cada martillazo. Este módulo entrena esa presencia, y desarma, una por una, las cuatro formas de creer que el trabajo era solo el plano.

Ejemplo trabajado: separar las decisiones de nivel arquitecto de las de la squad

Si el arquitecto no dibuja diagramas todo el día, ¿en qué mete las manos? La respuesta empieza por una que casi nadie hace bien: elegir en qué decisiones meterse. Un arquitecto que quiere opinar de todo se ahoga y ahoga al equipo; uno que no opina de nada no aporta. El oficio está en distinguir las pocas decisiones que de verdad son de nivel arquitecto de las muchas que pertenecen a la squad que las vive. Y esa distinción no se hace "a ojo": se puede medir.

Puntuamos cada decisión abierta de Mercado en tres ejes, de 1 a 5:

  • cross_team — a cuántas squads acopla la decisión (5 = a todas). Una decisión que solo toca a una squad es asunto de esa squad; una que obliga a coordinar a varias es, por definición, del arquitecto.
  • reverse_cost — qué tan difícil es revertirla (5 = casi irreversible).
  • blast_radius — a cuánto del sistema afecta (5 = a todo).

La regla es simple: si la suma de los tres es 9 o más, la decisión cruza fronteras, es cara y de radio amplio —es de nivel arquitecto, aunque el arquitecto la decida con la squad, no por encima de ella—. Si no llega a 9, la dueña es la squad, y el arquitecto no se mete:

# Decisiones abiertas de Mercado ante 5 squads (catalog, orders, payments,
# shipping, platform). Cada una puntuada 1-5 en tres ejes:
#   cross_team    = a cuantos squads acopla la decision (5 = a todos)
#   reverse_cost  = que tan dificil es revertirla        (5 = casi irreversible)
#   blast_radius  = a cuanto del sistema afecta           (5 = a todo)
# Regla: si la suma >= 9, es una decision de nivel ARQUITECTO (cruza squads,
# cara, amplia); si no, la DUENA es la squad, y el arquitecto NO se mete.
DECISIONS = [
    # (id, owning_squad, cross_team, reverse_cost, blast_radius)
    ("extract_catalog_to_service",   "catalog",  5, 5, 4),
    ("orders_to_shipping_contract",  "orders",   4, 4, 4),
    ("shared_auth_token_change",     "platform", 5, 4, 5),
    ("add_second_payments_provider", "payments", 3, 4, 3),
    ("catalog_search_page_size",     "catalog",  1, 1, 1),
    ("orders_retry_count",           "orders",   1, 1, 2),
    ("shipping_label_font",          "shipping", 1, 1, 1),
    ("checkout_button_color",        "catalog",  1, 1, 1),
]


def architect_level(cross, reverse, blast):
    # Es de nivel arquitecto cuando cruza squads Y es cara Y de radio amplio.
    return cross + reverse + blast >= 9


print(f"{'decision':<32}{'squad':<10}{'x-team':>7}{'rev':>5}{'blast':>7}  owner")
print("-" * 74)
architect_count = 0
for decision_id, squad, cross, reverse, blast in DECISIONS:
    if architect_level(cross, reverse, blast):
        owner = "ARCHITECT (+ squad)"
        architect_count += 1
    else:
        owner = f"{squad} squad decides"
    print(f"{decision_id:<32}{squad:<10}{cross:>7}{reverse:>5}{blast:>7}  {owner}")

print()
total = len(DECISIONS)
print(f"De {total} decisiones sobre la mesa, solo {architect_count} son de nivel arquitecto.")
print(f"Las otras {total - architect_count} las decide su squad. Un arquitecto que quiere")
print("tocar las 8 se vuelve el cuello de botella de todo Mercado.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

decision                        squad      x-team  rev  blast  owner
--------------------------------------------------------------------------
extract_catalog_to_service      catalog         5    5      4  ARCHITECT (+ squad)
orders_to_shipping_contract     orders          4    4      4  ARCHITECT (+ squad)
shared_auth_token_change        platform        5    4      5  ARCHITECT (+ squad)
add_second_payments_provider    payments        3    4      3  ARCHITECT (+ squad)
catalog_search_page_size        catalog         1    1      1  catalog squad decides
orders_retry_count              orders          1    1      2  orders squad decides
shipping_label_font             shipping        1    1      1  shipping squad decides
checkout_button_color           catalog         1    1      1  catalog squad decides

De 8 decisiones sobre la mesa, solo 4 son de nivel arquitecto.
Las otras 4 las decide su squad. Un arquitecto que quiere
tocar las 8 se vuelve el cuello de botella de todo Mercado.

Lee la tabla con calma, porque en ese reparto está la idea central del módulo.

Arriba están las cuatro decisiones de nivel arquitecto. Fíjate en qué tienen en común: todas puntúan alto en cross_team. Extraer el catálogo a un servicio (extract_catalog_to_service) obliga a que catalog, orders y todos los que leen el catálogo se pongan de acuerdo sobre un nuevo contrato. El contrato entre orders y shipping (orders_to_shipping_contract) es, literalmente, la frontera entre dos squads. Cambiar el token de autenticación compartido (shared_auth_token_change) toca a las cinco. Añadir un segundo proveedor de pagos (add_second_payments_provider) redefine cómo payments habla con el mundo. Ninguna de estas la puede decidir una squad sola porque ninguna cabe dentro de una sola squad: todas cruzan fronteras. Y esa es la definición operativa de una decisión de nivel arquitecto —no "la que suena importante", sino la que acopla equipos que de otro modo decidirían por separado—.

Abajo están las cuatro locales. El tamaño de página de la búsqueda del catálogo, el número de reintentos de orders, la tipografía de la etiqueta de envío, el color del botón del checkout: cada una vive por completo dentro de una squad, se revierte en un commit, y no afecta a nadie más. Un arquitecto que convoca una reunión para decidir el color de un botón no está siendo cuidadoso; está robándole a la squad de catalog una decisión que es suya, y de paso poniéndose a sí mismo en el camino de un cambio trivial. Multiplica eso por las decenas de decisiones locales que las cinco squads toman cada semana y tienes la receta exacta del cuello de botella que la lección 6 va a medir.

La lectura para llevarse: de ocho decisiones, el arquitecto toca cuatro —la mitad—, y aun eso es un caso de juguete con solo ocho. En un Mercado real, con decenas de decisiones semanales, la proporción que llega al arquitecto debería ser mucho menor. El primer acto del oficio no es decidir bien; es decidir en qué decisiones meterse, y tener la disciplina de soltar todas las demás. Un arquitecto que no suelta se convierte en el embudo de su propia organización.

Las cuatro imágenes falsas y las cuatro reales

Ese ejemplo tocó, sin desarrollarlas, las ideas del módulo. Cada lección toma una imagen falsa del rol y la reemplaza por la real. Vale la pena verlas juntas, porque son la columna vertebral de las siete lecciones que siguen.

1. La torre de marfil (lección 2). Falso: el arquitecto dibuja el diagrama perfecto y se va. Real: el diagrama del día uno es una hipótesis que la realidad corrige; el trabajo es estar presente para corregirla. La lección 2 mide cuánto del "diagrama perfecto" de Mercado sobrevivió al construir.

2. Despegado del código (lección 3). Falso: el arquitecto es demasiado senior para tocar código; vive en las reuniones y las slides. Real: el arquitecto sube al negocio y baja a la sala de máquinas —el elevador de Hohpe—; sin cercanía al código, sus decisiones se apoyan en un modelo mental viejo y sus estimaciones se equivocan. La lección 3 mide cómo crece el error con la distancia al código.

3. El dictador y el cuello de botella (lecciones 4, 5 y 6). Falso: el arquitecto decide todo y tiene siempre la razón; toda decisión pasa por él. Real: su producto es una decisión reversible (que equivocarse salga barato) más el porqué comunicado (lección 4); habilita al equipo como un jardinero que pone guardrails, no como un dictador (lección 5); y sabe que querer decidirlo todo lo convierte en el cuello de botella cuya cola crece sin fin (lección 6).

4. El Big Design Up Front (lección 7). Falso: un buen arquitecto diseña todo por adelantado, completo, antes de escribir una línea. Real: decide cada cosa al último momento responsable —cuando su información madura—, ni antes (BDUF, y pagas rework) ni después (parálisis, y pagas el default). La lección 7 mide el sobrecosto de decidir a ciegas.

Guarda este mapa; es la ruta del módulo:

Imagen falsa                     Lección   Lo que hace el arquitecto real
───────────────────────────────  ────────  ──────────────────────────────────
La torre de marfil               L2        estar presente; el plano es hipotesis
Despegado del codigo             L3        el elevador: baja a la sala de maquinas
Decide todo, tiene la razon      L4        vende decisiones reversibles, no certezas
El dictador                      L5        jardinero: guardrails y autonomia
El cuello de botella             L6        disena para NO ser el embudo
El Big Design Up Front           L7        decide al ultimo momento responsable
───────────────────────────────  ────────  ──────────────────────────────────
Diagnostica y redisena el rol    L8        el mini-proyecto, ejecutado

El mapa: dónde está este módulo en la guía y en el ecosistema

Este módulo es la puerta de entrada. Así se conecta con el resto de la guía:

flowchart TD
    M1["M1 · Que hace de verdad un arquitecto<br/>(desmontar los mitos del rol)"]
    M2["M2 · La ley de Conway"]
    M3["M3 · Comunicar la arquitectura (C4)"]
    M4["M4 · Liderazgo tecnico sin autoridad"]
    M5["M5 · Stakeholders y atributos de calidad"]
    M6["M6 · Disenar para el cambio"]
    M7["M7 · Documentacion que sobrevive"]
    M8["M8 · Proyecto: ser el arquitecto de<br/>Mercado ante un cambio"]
    M1 --> M2 --> M3 --> M4 --> M5 --> M6 --> M7 --> M8

Léelo así: aquí aprendes qué es el rol y desmontas sus mitos; en M2 ves cómo la estructura de los equipos moldea la del sistema (Conway); en M3 comunicas la arquitectura con el C4; en M4 lideras sin autoridad formal; en M5 traduces metas de negocio a atributos de calidad; en M6 planeas para el cambio; en M7 documentas para que sobreviva; y en M8 haces todo el recorrido como arquitecto de Mercado ante un cambio real.

Y la frontera con la guía hermana del ecosistema, que hay que respetar: architecture-decisions-and-tradeoffs enseña el método de decidir —comparar opciones con una matriz ponderada, la mecánica del ADR, escribir una fitness function, clasificar una decisión por su reversibilidad—. Esta guía enseña el oficio alrededor: cómo el humano que toma esas decisiones se relaciona con la organización, comunica y lidera para que se ejecuten. Son complementarias: la decisión contra el humano que la hace pasar. Cuando en la lección 4 hablemos de decisiones "reversibles", no vamos a re-enseñar la mecánica de la reversibilidad (eso es la otra guía); vamos a enseñar por qué hacer reversibles las decisiones caras es parte de lo que significa el rol.

Errores comunes

Estos tres errores son las tres patologías del rol que el módulo entero combate. Aparecen aquí en su forma de resumen; cada lección abre uno a fondo.

Creer que el diagrama es el entregable (la torre de marfil). Qué pasa: el arquitecto invierte semanas en el diagrama perfecto, lo presenta, y considera su trabajo hecho —"ahí está la arquitectura, ejecútenla"—. Por qué pasa: el diagrama es visible, prestigioso y se siente como "producir algo", mientras que el trabajo real —estar presente, ajustar, habilitar— es difuso y no se ve en una slide. Cómo detectarlo: si el arquitecto aparece al inicio de un proyecto y desaparece durante la construcción, o si el diagrama que entregó hace tres meses ya no se parece a lo que se está construyendo y a nadie le sorprende, estás ante una torre de marfil. Cómo corregirlo: tratar el diagrama como una hipótesis que la realidad va a corregir, y medir tu valor por tu presencia durante la construcción, no por la calidad del plano inicial. La lección 2 lo cuantifica: el 70% del diagrama perfecto de Mercado se rehízo al construir.

Despegarse del código y decidir sobre un modelo mental viejo. Qué pasa: el arquitecto lleva un año sin abrir el repositorio, decide sobre cómo cree que está el sistema, y sus decisiones y estimaciones fallan porque el sistema ya no es el que él recuerda. Por qué pasa: se confunde "senior" con "por encima del código", como si tocar código fuera de junior. Cómo detectarlo: si el arquitecto estima que un cambio toma tres días y a la squad le toma tres semanas, y esto pasa seguido, su modelo mental está desactualizado. Cómo corregirlo: bajar el elevador con regularidad —leer el código, revisar PRs, hacer un spike de vez en cuando— para mantener el modelo mental pegado a la realidad. La lección 3 mide cómo el error de estimación crece con la distancia al código.

Volverse el cuello de botella por querer decidirlo todo (el dictador). Qué pasa: cada decisión, grande o pequeña, tiene que pasar por el arquitecto para su aprobación, así que las squads esperan, se forma una cola, y el arquitecto trabaja de noche sin dar abasto. Por qué pasa: viene de un buen lugar mal calibrado —"quiero que quede bien"—, pero confunde "que las decisiones importantes queden bien" con "que yo tome todas las decisiones". Cómo detectarlo: si las squads dicen "estamos esperando que el arquitecto revise esto" con frecuencia, o si el arquitecto es el recurso más ocupado y más bloqueante del equipo, es un cuello de botella. Cómo corregirlo: separar las pocas decisiones de nivel arquitecto de las muchas locales (como el ejemplo de esta lección), y habilitar a las squads con guardrails para que decidan las suyas solas. Las lecciones 5 y 6 lo desarrollan y lo miden: el cuello de botella acumula 1430 decision-semanas de espera; el modelo distribuido, cero.

Ejercicios

Ejercicio 1 — ¿Arquitecto o squad? Para cada una de estas decisiones de Mercado, di si la tratarías como de nivel arquitecto (cruza squads, cara, amplia) o local (la decide su squad), y justifica con al menos uno de los tres ejes (cross_team, reverse_cost, blast_radius): (a) cambiar el texto del correo de confirmación de pedido; (b) definir el formato de los eventos que orders publica y que shipping, payments y analytics consumen; (c) elegir la librería de gráficas del dashboard interno de catalog; (d) migrar a todas las squads de sesiones en memoria a tokens firmados.

Ver solución
  • (a) Texto del correo → local. Vive dentro de la squad que manda las notificaciones, se revierte editando una plantilla, y no acopla a nadie. cross_team bajísimo. La decide su squad.
  • (b) Formato de los eventos de orders → nivel arquitecto, de los más claros. Es un contrato que consumen shipping, payments y analytics: cross_team máximo. Cambiarlo mal rompe a tres squads a la vez, y una vez que todos dependen del formato, revertirlo es caro. Es exactamente el tipo de decisión que solo el arquitecto puede sostener, porque es la única persona con la vista de las tres squads a la vez. (Cómo diseñar ese evento es tema de las guías técnicas; que es una decisión de nivel arquitecto es lo que importa aquí.)
  • (c) Librería de gráficas del dashboard interno de catalog → local. Solo la usa catalog, se cambia sin tocar a nadie más, blast_radius mínimo. La decide su squad. Un arquitecto que opina de esto está robándole una decisión a la squad.
  • (d) Sesiones en memoria → tokens firmados → nivel arquitecto. Toca cómo las cinco squads verifican identidad: cross_team y blast_radius altos, y revertirlo una vez emitidos los tokens es caro. Es del arquitecto —con las squads—, no de una sola.

Ejercicio 2 — El plano no es el trabajo. Un arquitecto nuevo en Mercado presenta, en su segunda semana, un diagrama completísimo de cómo "debería" quedar el sistema en dos años, con todos los servicios ya separados y todos los contratos definidos. Lo presenta y espera que las squads lo ejecuten. Nombra dos razones, usando la analogía del arquitecto de edificios, por las que ese diagrama —por bueno que sea— no es todavía "hacer arquitectura".

Ver solución

  1. El plano es una hipótesis, no una profecía. El arquitecto de edificios que dibuja la casa perfecta el día uno todavía no ha pisado el terreno: no sabe que el suelo es blando, que el material tarda, que el cliente va a querer la cocina abierta. Su diagrama de "cómo debería quedar en dos años" está, garantizadamente, parcialmente equivocado —porque se hizo antes de que la realidad lo corrigiera—. Presentarlo como un plan a ejecutar confunde la hipótesis con el trabajo. La lección 2 lo mide: el 70% de un diagrama perfecto se rehace al construir.

  2. El trabajo es la presencia, no la entrega. Aun si el diagrama fuera perfecto, entregarlo y esperar que "lo ejecuten" es justo la torre de marfil: el valor del arquitecto de edificios no está en enrollar los planos y marcharse, sino en visitar la obra, hablar con los albañiles (las squads) y ajustar durante meses. Un diagrama sin presencia no es arquitectura; es un dibujo. Y hay un problema extra: imponer un plan de dos años que las squads no ayudaron a construir es dictar, no habilitar (lección 5) —difícilmente lo van a ejecutar como suyo—.

Ejercicio 3 — El primer acto del oficio. Un arquitecto te dice: "para hacer bien mi trabajo necesito revisar y aprobar cada PR de las cinco squads, así me aseguro de que todo esté bien". Explica por qué esa postura, aunque suena responsable, es el error contrario al que debería cometer, y qué debería hacer en su lugar.

Ver solución

Suena responsable —"me aseguro de que todo esté bien"— pero confunde "que las decisiones importantes queden bien" con "que yo revise todo". Revisar cada PR de las cinco squads convierte al arquitecto en el cuello de botella de toda la organización: las squads esperan su revisión, la cola crece, y el arquitecto se ahoga revisando decisiones locales triviales (el color de un botón, un nombre de variable) que no son de su nivel. El costo de esa cola de espera es medible, y la lección 6 lo mide: cuando todo pasa por una persona, la espera acumulada explota.

Lo que debería hacer es el primer acto del oficio que enseñó el ejemplo de esta lección: separar las pocas decisiones de nivel arquitecto (las que cruzan squads, son caras, de radio amplio) de las muchas locales, meterse solo en las primeras —con la squad, no por encima—, y habilitar a las squads para que decidan las suyas solas, dándoles guardrails claros en vez de aprobación caso por caso (lección 5). Su trabajo no es revisar todo; es diseñar el sistema para que la mayoría de las decisiones no necesiten pasar por él. Un arquitecto que revisa cada PR no es más responsable; es más bloqueante.

Resumen y siguiente paso

En esta lección desmontaste la imagen que casi todo el mundo tiene del rol —el genio que dibuja el diagrama perfecto y se va— y la reemplazaste por la real: el arquitecto produce decisiones reversibles, un porqué comunicado y equipos habilitados, no diagramas. Viste, con el arquitecto de edificios, que el plano del día uno es una hipótesis y que el trabajo es la presencia que la corrige. Y lo mediste: clasificaste las decisiones abiertas de Mercado y viste que solo la mitad —las que cruzan squads— son de nivel arquitecto, mientras que las locales pertenecen a sus squads; un arquitecto que quiere tocarlas todas se vuelve el cuello de botella de su propia organización.

Antes de avanzar deberías poder: explicar por qué el diagrama es un subproducto y no el trabajo; nombrar las cuatro imágenes falsas del rol y las cuatro reales; distinguir una decisión de nivel arquitecto de una local con un ejemplo de Mercado; y argumentar por qué querer decidirlo todo es un error, no una virtud.

La lección 2 toma la primera imagen falsa y la desarma a fondo: la torre de marfil. Vas a ver por qué el diagrama perfecto no sobrevive al contacto con la realidad —no por mal dibujado, sino porque se dibujó antes de que la realidad hablara— y a ejecutar cuánto del diseño upfront de Mercado hubo que rehacer al construir. Con números, para que "el plano no es el trabajo" deje de ser un eslogan y sea una medición.

Recursos

  • Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. El ensayo fundacional de este módulo. Fowler distingue al "Architectus Reloadus" (el que decide todo y todos le consultan —el cuello de botella—) del "Architectus Oryzus" (el que mentorea, conversa y habilita al equipo). Es exactamente el contraste que trabaja todo el módulo. Corto y esencial. En inglés.
  • Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 1–2 "Introduction / Architectural Thinking" — la referencia central de la guía sobre qué es y qué no es el rol. Define las expectativas del arquitecto y por qué "pensar como arquitecto" no es dibujar mejor. En inglés.
  • Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020) — el libro que da la metáfora del elevador (subir al penthouse del negocio, bajar a la sala de máquinas del código) que la lección 3 desarrolla. La introducción ya deja clara la tesis: el arquitecto conecta pisos, no vive en uno. En inglés.
  • Matthew Skelton y Manuel Pais, Team Topologies (IT Revolution, 2019) — el marco de los tipos de equipo (stream-aligned, platform, enabling, complicated-subsystem) que sostiene la idea de "habilitar" y de guardrails, y que la lección 5 y el módulo 2 usan a fondo. En inglés.
Siguiente →El mito de la torre de marfil