El mito de la torre de marfil

Descripción

La lección 1 nombró las cuatro imágenes falsas del rol. Esta desarma la primera y la más pegajosa: la torre de marfil. Es la imagen del arquitecto que se encierra, produce el diagrama perfecto del sistema, lo presenta como la arquitectura, y considera su trabajo terminado —"ahí está, ejecútenlo"—. El nombre viene de la idea de alguien que decide desde una altura aislada, sin bajar al terreno donde las cosas de verdad ocurren. Y el problema no es que el arquitecto dibuje —dibujar es útil—; el problema es creer que el dibujo era el trabajo, y que una vez entregado, la realidad tiene la obligación de parecerse a él.

Este mito es tan común porque tiene una lógica interna que suena impecable: "si diseño el sistema correctamente desde el principio, evitamos errores caros después". La promesa es la prevención. Pero descansa en un supuesto falso: que en el momento de dibujar tienes —o puedes conseguir— la información suficiente para acertar. En un sistema vivo con cinco squads, stakeholders que cambian de idea y un mercado que se mueve, esa información no existe todavía cuando se dibuja el plano. El diagrama del día uno no está mal por descuido; está incompleto por cronología —se hizo antes de que la realidad hablara—. Esta lección lo demuestra con números: mide cuánto del "diagrama perfecto" de Mercado sobrevivió al contacto con la construcción, y cuánto hubo que rehacer.

Conexión con el módulo. Es la primera lección de contenido, y ataca la imagen falsa más importante porque de ella salen casi todas las demás. Un arquitecto de torre de marfil casi siempre también está despegado del código (lección 3, porque no baja a la obra), tiende al BDUF (lección 7, porque cree en el diseño completo por adelantado) y a veces al dictado (lección 5, porque entrega un plan a ejecutar en vez de habilitar). Aquí instalamos la corrección de raíz: el diagrama es una hipótesis que la realidad corrige, y el trabajo del arquitecto es la presencia que la corrige, no el dibujo que la inicia. Cuidado con la frontera: cómo revisar una decisión cuando llega nueva información (la reversibilidad como técnica) es la guía hermana architecture-decisions; aquí trabajamos la postura —por qué el plano no es el trabajo—.

Una analogía: el plano que el terreno corrige

Vuelve al arquitecto de edificios de la lección 1, pero ahora mira una obra concreta.

El arquitecto entrega el plano de una casa: la cimentación aquí, la cocina allá, una ventana grande en la sala que da al jardín. Es un plano excelente —proporciones cuidadas, buena luz, todo en su sitio—. Entonces empieza la obra, y el terreno empieza a hablar.

Cavan la cimentación y el suelo es más blando de lo que decía el estudio de suelos: hay que reforzar los cimientos, lo que cambia las cargas, lo que obliga a mover un muro de carga que en el plano estaba en otro lado. El proveedor de las vigas de acero que el plano especificaba tiene tres meses de retraso, así que hay que rediseñar esa parte con material disponible. El dueño, al ver el hueco de la ventana grande de la sala, se da cuenta de que da directo a la pared de ladrillo del vecino —en el plano se veía precioso, en la realidad es feo— y pide reorientarla. Y a mitad de obra, el dueño consigue un mejor trabajo en otra ciudad y quiere una habitación extra como oficina para trabajar desde casa.

Un arquitecto de torre de marfil, ante todo esto, diría: "el plano ya está firmado, esos son problemas de ejecución". Y la casa saldría torcida —o no saldría—, porque el plano dejó de corresponder a la realidad en la primera semana. Un arquitecto real hace lo contrario: está en la obra. Ajusta la cimentación cuando el suelo habla, replantea la estructura cuando el material no llega, reorienta la ventana cuando la vista real lo pide, rediseña para meter la oficina cuando el dueño cambia de vida. El plano que entregó el día uno era una hipótesis razonable con la información de entonces. La casa que se construye es el resultado de decenas de correcciones que el plano original no anticipó y no podía anticipar.

El punto es este: el plano perfecto del día uno estuvo, garantizadamente, parcialmente equivocado —no por mal dibujado, sino por prematuro—. El valor del arquitecto no estuvo en el dibujo inicial; estuvo en las correcciones. En el software es idéntico. El diagrama de arranque de Mercado —"catalog y orders comparten base de datos, orders llama a shipping síncrono, un solo proveedor de pagos"— es el plano del día uno. La construcción es el terreno que habla. Y la torre de marfil es creer que, si el diagrama fue bueno, la realidad debía obedecerlo.

Ejemplo trabajado: cuánto del diagrama perfecto sobrevive a la realidad

No vamos a afirmar que el diagrama perfecto se rehace; lo vamos a medir. Tomamos las diez decisiones de diseño que un arquitecto de torre de marfil fijó en el diagrama de Mercado antes de construir, sin tocar código, y marcamos cuáles sobrevivieron al choque con la construcción y cuáles hubo que rehacer:

# El "diagrama perfecto" que un arquitecto de torre de marfil dibujo ANTES de
# construir Mercado: 10 decisiones de diseno fijadas en el papel, sin tocar
# codigo. Semanas despues, al construir, la realidad invalido varias.
# survived = True si la decision del papel sobrevivio al choque con la realidad.
UPFRONT_DESIGN = [
    # (design_decision, survived_contact_with_reality)
    ("catalog_and_orders_share_one_db",    False),
    ("sync_call_orders_to_shipping",       False),
    ("single_payments_provider_forever",   False),
    ("search_runs_on_the_main_db",         False),
    ("one_team_owns_everything",           False),
    ("rest_between_internal_services",     True),
    ("postgres_as_the_primary_store",      True),
    ("http_load_balancer_at_the_edge",     True),
    ("daily_batch_for_all_analytics",      False),
    ("sessions_kept_in_app_memory",        False),
]

survived = sum(1 for _, ok in UPFRONT_DESIGN if ok)
total = len(UPFRONT_DESIGN)
pct = round(100 * survived / total)

print(f"{'upfront design decision':<38}{'survived reality?':>18}")
print("-" * 56)
for decision, ok in UPFRONT_DESIGN:
    print(f"{decision:<38}{('yes' if ok else 'NO -> reworked'):>18}")

print()
print(f"Sobrevivieron {survived} de {total} decisiones del diagrama perfecto ({pct}%).")
print(f"El {100 - pct}% se rehizo al construir. El plano no fue el problema;")
print("creer que dibujarlo UNA vez y marcharse era el trabajo, si.")

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

upfront design decision                survived reality?
--------------------------------------------------------
catalog_and_orders_share_one_db           NO -> reworked
sync_call_orders_to_shipping              NO -> reworked
single_payments_provider_forever          NO -> reworked
search_runs_on_the_main_db                NO -> reworked
one_team_owns_everything                  NO -> reworked
rest_between_internal_services                       yes
postgres_as_the_primary_store                        yes
http_load_balancer_at_the_edge                       yes
daily_batch_for_all_analytics             NO -> reworked
sessions_kept_in_app_memory               NO -> reworked

Sobrevivieron 3 de 10 decisiones del diagrama perfecto (30%).
El 70% se rehizo al construir. El plano no fue el problema;
creer que dibujarlo UNA vez y marcharse era el trabajo, si.

Lee la tabla despacio, porque separa dos clases de decisión que el arquitecto de torre de marfil trató igual.

Las tres que sobrevivieron —rest_between_internal_services, postgres_as_the_primary_store, http_load_balancer_at_the_edge— tienen algo en común: son decisiones de tecnología base y convenciones amplias que no dependían de conocer el detalle de la carga o del negocio. Elegir REST para la comunicación interna, Postgres como almacén, un balanceador HTTP en el borde: son apuestas sólidas que casi cualquier información posterior habría confirmado. El diagrama del día uno sí puede acertar en esto, porque son decisiones cuya evidencia ya existía el día uno.

Las siete que se rehicieron son otra cosa. Que catalog y orders compartan una base de datos sonaba simple en el papel —una base, menos cosas que mantener—, pero al construir chocó con que las dos squads pisaban las mismas tablas y se bloqueaban. Que orders llamara a shipping de forma síncrona se veía directo en el diagrama, hasta que en producción una lentitud de shipping empezó a tirar el checkout. Un solo proveedor de pagos "para siempre" se rompió el primer día que ese proveedor tuvo una caída. La búsqueda sobre la base de datos principal aguantó hasta que el volumen la puso de rodillas. "Un equipo dueño de todo" se deshizo en cuanto hubo cinco squads. Ninguna de estas siete se rehizo porque el arquitecto fuera malo; se rehicieron porque su evidencia no existía el día uno —vivía en la construcción, en la carga real, en cómo las squads se organizaron de verdad—.

Y ahí está el número que da nombre a la lección: el 70% del diagrama perfecto se rehizo. Siete de cada diez trazos del plano inicial no sobrevivieron al terreno. Repito el matiz porque es el corazón de todo: eso no significa que planear sea inútil, ni que el arquitecto debió no dibujar nada. Significa que tratar el diagrama como un entregable terminado —dibujarlo, presentarlo, marcharse— era la postura equivocada. El diagrama es valioso como hipótesis de arranque; es dañino como profecía a ejecutar. La diferencia entre las dos es si el arquitecto se queda para corregirlo.

Visto como barras, el reparto salta a la vista:

Diagrama perfecto de Mercado: 10 decisiones fijadas antes de construir
 sobrevivieron (3)  |######                          30%
 se rehicieron  (7) |##############                  70%
                     ─────────────────────────────
 conclusion: el plano del dia uno era 70% hipotesis, no plan.

Profundización: por qué la torre de marfil es tan tentadora (y tan cara)

Si el diagrama perfecto se rehace tanto, ¿por qué la torre de marfil sigue siendo la imagen dominante del arquitecto? Porque tiene tres atractivos poderosos, y vale la pena nombrarlos para resistirlos.

Produce algo visible. El trabajo real del arquitecto —estar presente, ajustar, conversar con las squads, corregir el rumbo semana a semana— es difuso y no se ve. Un diagrama, en cambio, es un artefacto: se imprime, se pega en la pared, se presenta en una reunión con directivos que asienten. En una cultura que premia "entregables", el diagrama se siente como producir, y la presencia se siente como no hacer nada concreto. El arquitecto de torre de marfil no es perezoso; muchas veces es el más aplicado, solo que aplicado en lo que se ve en vez de en lo que sirve.

Confunde precisión con acierto. Un diagrama detallado —cada servicio, cada cola, cada base de datos— se ve más riguroso que un boceto con tres cajas y una nota que dice "esto lo decidimos cuando sepamos la carga". Pero la precisión del dibujo no tiene relación con su acierto: un plano detalladísimo hecho sin la información necesaria es precisamente detallado y equivocado. Peor: mientras más detallado el diagrama, más caro es admitir que hay que rehacerlo, porque más trabajo parece tirarse. La precisión prematura no es rigor; es compromiso con una hipótesis antes de tiempo (justo el mito del BDUF, lección 7).

Protege del contacto incómodo. Bajar a la obra es incómodo: significa descubrir que tu plano estaba mal, que la squad de orders no está de acuerdo, que el suelo era más blando. Quedarse en la torre —en las reuniones de alto nivel, en las slides— evita ese roce. Es más cómodo defender un diagrama abstracto que sentarse con la squad de payments a ver por qué el proveedor único los está reventando. La torre de marfil, además de prestigiosa, es cómoda: aísla del terreno donde el arquitecto de verdad se ensucia las manos.

Y hay una cadencia que distingue las dos posturas. El arquitecto de edificios no visita la obra una sola vez ni todos los días: la visita con un ritmo —al vaciar los cimientos, al levantar la estructura, al cerrar los muros—, en los momentos donde una corrección temprana ahorra un desastre tardío. El arquitecto de software es igual: no reaparece solo al final (torre de marfil) ni se instala a codear a tiempo completo (el error opuesto de la lección 3); establece una presencia rítmica en los hitos donde el terreno habla —cuando una squad implementa el contrato entre orders y shipping, cuando el catálogo se separa, cuando la carga real llega—. Esa cadencia es lo que convierte "estar presente" de una buena intención en una práctica: momentos agendados donde el plano se contrasta con lo construido y se corrige en pequeño. Sin cadencia, la presencia se diluye y el arquitecto termina, sin querer, de vuelta en la torre.

El costo de todo esto es doble, y compuesto. Primero, el rework directo: las siete decisiones que se rehicieron costaron tiempo y dinero que un arquitecto presente habría reducido corrigiendo antes, en pequeño, en vez de después, en grande. Segundo —y peor— el costo de credibilidad: cuando un arquitecto entrega un plano y desaparece, y la construcción lo contradice, las squads aprenden que el diagrama del arquitecto "no aplica en la práctica", y dejan de tomarlo en serio. El arquitecto de torre de marfil termina irrelevante no porque sus ideas fueran malas, sino porque su modo de trabajar lo desconectó de donde las ideas se vuelven sistema. La autoridad del arquitecto no viene del cargo ni del diagrama; viene de estar en el terreno lo suficiente para que su palabra corresponda a la realidad. Eso es lo que la torre de marfil destruye.

La corrección práctica: trata el diagrama como una hipótesis con fecha de revisión. No dejes de dibujar —el boceto de arranque orienta a todos y es valioso—. Cambia lo que crees que es: en vez de "este es el diseño, ejecútenlo", di "esta es nuestra mejor hipótesis con lo que sabemos hoy; estos tres trazos (la base compartida, la llamada síncrona, el proveedor único) son los que más dudo, y los vamos a revisar cuando la construcción nos dé datos". Marca en el propio diagrama qué es firme y qué es tentativo. Y agenda tu presencia: el arquitecto real bloquea tiempo para estar en la obra —revisar cómo va la construcción, sentarse con las squads— no como una interrupción de su "trabajo real", sino como su trabajo real. El diagrama abre la conversación; no la cierra.

Errores comunes

Presentar el diagrama y desaparecer. Qué pasa: el arquitecto invierte semanas en el diagrama, lo presenta en una gran reunión, y luego se va a diseñar otra cosa mientras las squads construyen; reaparece meses después, ve que lo construido no se parece a su plano, y se frustra —"no siguieron la arquitectura"—. Por qué pasa: cree que su trabajo era el diagrama, así que una vez entregado, se siente terminado. Cómo detectarlo: si el arquitecto solo aparece al inicio y al final de un proyecto, o si hay una brecha grande y sorpresiva entre el diagrama y lo construido, hubo una torre de marfil. Cómo corregirlo: entender que la entrega del diagrama es el inicio del trabajo, no el final; agendar presencia durante la construcción; y esperar —y planear— que el 70% del plano se ajuste, corrigiéndolo en pequeño y a tiempo en vez de descubrir la brecha entera al final.

Confundir un diagrama detallado con una buena arquitectura. Qué pasa: se juzga la calidad del arquitecto por lo completo y pulido que es su diagrama —"mira cuánto detalle, qué profesional"—, cuando ese detalle se produjo sin la información para acertarlo. Por qué pasa: la precisión visual se lee como rigor, y un dibujo lleno impresiona más que uno con huecos honestos. Cómo detectarlo: si el diagrama especifica con total certeza cosas que dependen de datos que aún no existen (la carga real, cómo se organizarán las squads, qué proveedor aguanta), es precisión prematura. Cómo corregirlo: preferir un diagrama que marca sus propias incertidumbres —"esto es firme, esto es tentativo hasta tener el dato X"— sobre uno que finge certeza en todo. Un boceto honesto sobre lo que no se sabe vale más que un plano detallado que se rehará en un 70%.

Defender el plano en vez de corregirlo. Qué pasa: cuando la construcción contradice el diagrama, el arquitecto insiste en que el problema es la ejecución —"el plano estaba bien, lo hicieron mal"— en vez de reconocer que el plano encontró información nueva. Por qué pasa: admitir que el diagrama estaba equivocado se siente como admitir incompetencia, cuando en realidad es lo esperado (el 70%). Cómo detectarlo: si el arquitecto reacciona a las sorpresas de la construcción con "así no era el diseño" en vez de "interesante, ajustemos", está defendiendo la torre. Cómo corregirlo: tratar cada contradicción entre plano y realidad como la obra hablando —justo lo que el arquitecto de edificios agradece, no lo que combate—. El terreno blando no es un error del albañil; es información que el plano no tenía. Corregir el plano ante ella es hacer el trabajo, no fallar en él.

Ejercicios

Ejercicio 1 — ¿Qué trazos del plano marcarías como tentativos? De las diez decisiones del diagrama de Mercado, tres sobrevivieron (rest_between_internal_services, postgres_as_the_primary_store, http_load_balancer_at_the_edge) y siete se rehicieron. Si tuvieras que dibujar ese diagrama de arranque bien —como hipótesis honesta, no como profecía—, ¿cuáles marcarías como "firme" y cuáles como "tentativo hasta tener más datos", y con qué criterio?

Ver solución

El criterio es: ¿la evidencia para acertar esta decisión existe ya el día uno, o vive en la construcción?

• Marcaría como firmes las tres que sobrevivieron, más cualquiera de su misma naturaleza: decisiones de tecnología base y convención amplia cuya evidencia ya existe (REST interno, Postgres, balanceador HTTP). No dependen de conocer la carga real ni cómo se organizarán las squads; son apuestas sólidas que la construcción difícilmente cambia.
• Marcaría como tentativas las siete que se rehicieron, porque cada una depende de un dato que el día uno no existe: que catalog y orders compartan base depende de si de verdad pisan las mismas tablas (se sabe construyendo); síncrono vs eventos entre orders y shipping depende del comportamiento bajo carga (se sabe en producción); un solo proveedor de pagos depende de su disponibilidad real; la búsqueda sobre la base principal depende del volumen; "un equipo dueño de todo" depende de cuántas squads terminen existiendo.

El diagrama honesto no tiene menos cajas; tiene etiquetas de confianza. Firme lo que la evidencia ya sostiene; tentativo lo que la construcción decidirá. Eso convierte el plano de una profecía en una hipótesis con puntos de revisión marcados —exactamente lo contrario de la torre de marfil—.

Ejercicio 2 — La reunión con el VP. El VP de producto ve el diagrama de arranque de Mercado, le encanta, y dice: "perfecto, entonces esta es la arquitectura, congelémosla y que los equipos la ejecuten tal cual durante el año". Como arquitecto, ¿qué le respondes, sin sonar a que "no tienes un plan"?

Ver solución

La respuesta tiene que hacer dos cosas a la vez: no destruir la confianza del VP en que hay un rumbo, y no aceptar congelar una hipótesis como si fuera un plan.

Algo como: "Me alegra que el diagrama comunique bien el rumbo —para eso lo dibujé—. Y sí tenemos un plan, pero el plan incluye cómo vamos a ajustarlo. Este diagrama es nuestra mejor hipótesis con lo que sabemos hoy; hay tres o cuatro trazos —cómo orders habla con shipping, si el catálogo se queda junto a orders— que dependen de datos que solo la construcción nos va a dar. Congelarlos ahora nos obligaría a ejecutar decisiones tomadas a ciegas, y las pagaríamos en rework. Lo que te propongo es firme en el rumbo y flexible en esos puntos: avanzamos, y cuando la construcción nos dé el dato, revisamos esos trazos concretos. Así no vamos sin plan; vamos con un plan que aprende."

La clave es reencuadrar "ajustar" no como "no tener plan" sino como parte del plan. Un VP entiende bien la idea de una hipótesis de mercado que se corrige con datos; la arquitectura es igual. Congelar el diagrama sería la torre de marfil pactada con el negocio, y la pagarían las squads. (Cómo comunicarle esto con el diagrama adecuado para su nivel es el módulo 3; cómo decidir esos trazos cuando el dato llega es la guía hermana.)

Ejercicio 3 — Torre de marfil vs presencia, en una decisión real. La squad de orders te avisa, a mitad de construcción, que la base de datos compartida con catalog (que tu diagrama fijó) los está bloqueando: las dos squads chocan en las mismas tablas. Describe cómo reaccionaría un arquitecto de torre de marfil y cómo reaccionaría un arquitecto presente, y por qué la segunda reacción es la que hace el rol.

Ver solución

Torre de marfil: "El diseño dice base compartida por una razón —menos infraestructura que mantener—. El problema es de coordinación entre las squads; pónganse de acuerdo en no pisarse. El plano está bien." Defiende el diagrama y devuelve el problema como un fallo de ejecución. Resultado probable: las squads siguen bloqueándose, aprenden que el arquitecto no baja al terreno, y resuelven por su cuenta —quizá peor de lo que el arquitecto habría resuelto si hubiera estado presente—.

Arquitecto presente: baja a la obra. Se sienta con las dos squads, mira las tablas concretas donde chocan, y reconoce que la base compartida —una hipótesis razonable en el papel— encontró información nueva: catalog y orders tienen ritmos y datos lo bastante distintos como para que compartir base genere fricción real. A partir de ahí, ayuda a decidir el ajuste (separar los datos, o definir límites claros de qué tabla es de quién) con las squads, no por encima de ellas. Corrige el plano con el terreno que habló.

La segunda es la que hace el rol por dos razones. Primera: la base compartida era una hipótesis (uno de los siete trazos que se rehacen), y la fricción que reporta orders es exactamente la construcción dando el dato que el día uno no existía —corregir ante ese dato es el trabajo, no el fracaso—. Segunda: la autoridad del arquitecto se sostiene solo si su palabra corresponde a la realidad; defender el plano contra la evidencia lo vuelve irrelevante, mientras que bajar a resolver con las squads construye la credibilidad de la que depende todo lo demás que el arquitecto quiera influir. (Cómo comparar las opciones de separación es la guía hermana; que hay que estar ahí para hacerlo es esta lección.)

Resumen y siguiente paso

En esta lección desarmaste la imagen falsa más pegajosa del rol: la torre de marfil, el arquitecto que dibuja el diagrama perfecto y se va. Viste, con el plano que el terreno corrige, que el diagrama del día uno es una hipótesis hecha antes de que la realidad hablara, y por eso está garantizadamente incompleto —no por descuido, sino por cronología—. Y lo mediste: de las diez decisiones del diagrama de arranque de Mercado, solo el 30% sobrevivió al construir; el 70% se rehizo. El plano no fue el error; creer que dibujarlo una vez y marcharse era el trabajo, sí. El arquitecto real trata el diagrama como una hipótesis con fecha de revisión y hace su trabajo en la presencia que la corrige.

Antes de avanzar deberías poder: explicar por qué el diagrama perfecto se rehace tanto sin que eso signifique que planear sea inútil; distinguir las decisiones que el día uno sí se pueden acertar (base tecnológica) de las que dependen de la construcción; y reconocer los tres atractivos de la torre de marfil (produce algo visible, confunde precisión con acierto, protege del contacto incómodo) para resistirlos.

La lección 3 sigue el hilo natural: si el arquitecto debe estar en la obra para corregir el plano, tiene que poder bajar a la obra —al código—. Vamos a ver el elevador del arquitecto de Gregor Hohpe: subir al penthouse del negocio y bajar a la sala de máquinas del código, y por qué un arquitecto que se queda arriba estima mal y decide sobre un sistema que ya no existe. Con números: cómo el error de estimación crece cuando el arquitecto se despega del código.

Recursos

• Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. La fuente del contraste central del módulo. El "Architectus Reloadus" que decide desde arriba y espera que se ejecute es la torre de marfil de esta lección. En inglés.
• Gregor Hohpe, The Software Architect Elevator (O'Reilly, 2020) — el libro entero es un argumento contra la torre de marfil: el arquitecto que se queda en el penthouse pierde contacto con la sala de máquinas y sus decisiones se vuelven irreales. La lección 3 desarrolla su metáfora. En inglés.
• Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 2 "Architectural Thinking" — sobre por qué el arquitecto debe mantener contacto técnico y por qué la arquitectura es un flujo de decisiones, no un artefacto congelado. En inglés.
• Martin Fowler, "Is Design Dead?" — martinfowler.com/articles/designDead.html. Sobre por qué el diseño evolutivo supera al diseño planeado completo por adelantado, y cómo un plan es una hipótesis que se ajusta. Complementa la tesis de esta lección y anticipa el módulo 7 (BDUF). En inglés.