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

BDUF contra el último momento responsable

Siguiente →

Descripción

Esta es la última de las cuatro imágenes falsas del rol, y cierra el módulo antes del proyecto. El Big Design Up Front —BDUF, "gran diseño por adelantado"— es la creencia de que un buen arquitecto diseña todo el sistema completo antes de escribir una línea de código: cada servicio, cada contrato, cada decisión, resuelta de antemano en un documento exhaustivo. Es la prima hermana de la torre de marfil (lección 2), pero con un matiz distinto: la torre de marfil es sobre dónde trabaja el arquitecto (aislado, sin bajar a la obra); el BDUF es sobre cuándo decide (todo al principio, antes de tener la información).

Contra el BDUF, esta lección instala la postura del arquitecto real: decidir cada cosa al último momento responsable (LRM, last responsible moment). La idea es precisa y hay que entenderla bien porque es fácil de deformar en las dos direcciones. El último momento responsable no es "decidir lo más tarde posible" (eso sería parálisis, que también se paga); no es "decidir lo antes posible" (eso es el BDUF, y pagas rework). Es decidir en el momento en que ya tienes la información para decidir bien, pero todavía no es tan tarde que la demora te cueste. Cada decisión tiene su propio último momento responsable, que llega cuando su información madura. El arquitecto real no decide todo el día uno ni pospone todo indefinidamente: decide cada cosa a su tiempo. Esta lección mide el sobrecosto de no hacerlo —de decidir todo por adelantado, a ciegas, y pagar el rework—.

Conexión con el módulo. Cierra las imágenes falsas y conecta con la 4: si el producto del arquitecto es una decisión reversible (lección 4), el BDUF es su enemigo, porque comprometer todo por adelantado es lo más irreversible que se puede hacer. También es la contracara temporal de la lección 6: el dictador centraliza en el espacio (todo pasa por él), el BDUF centraliza en el tiempo (todo se decide al principio). Cuidado con la frontera, que aquí es especialmente importante: la reversibilidad y el último momento responsable como técnica —cómo calcular ese momento, cómo estructurar una decisión para diferirla, el costo de no decidir a fondo— es la guía hermana architecture-decisions (su módulo 7). Aquí trabajamos la postura mental del oficio: por qué el arquitecto rechaza el BDUF y adopta el LRM como forma de pensar, no la mecánica de calcularlo.

Una analogía: empacar para un viaje de tres meses

Te vas de viaje tres meses por varios países, con climas distintos, y tienes que preparar la maleta. Hay tres formas de encarar el equipaje, y solo una es sensata.

El BDUF: empacar todo el primer día, para los tres meses. Decides, antes de salir, absolutamente todo lo que vas a usar en noventa días: la ropa de cada clima, el regalo para el amigo que verás en el mes dos, los medicamentos para un resfriado que quizá te dé en el mes tres. Empacas una maleta gigantesca, pesadísima, con decisiones tomadas hoy sobre situaciones que aún no conoces. ¿Qué pasa en la realidad? El "clima frío" del mes dos resultó ser una ola de calor, así que la ropa de invierno fue peso muerto que cargaste dos meses. Al amigo del mes dos ya no lo verás porque cambió de planes, y el regalo va y viene inútil. El resfrío nunca llegó. Empacaste con información del día uno para un viaje que aún no existía, y pagaste el precio: cargar peso muerto y, cuando la realidad cambió, tener que comprar cosas de todos modos (rework) porque lo que empacaste no servía.

La parálisis: no empacar nada, decidir todo sobre la marcha. El otro extremo: sales sin maleta, "ya compraré lo que necesite en cada lugar". Suena flexible, pero llegas a la primera ciudad de noche, sin ropa limpia, sin cargador, sin lo básico, y pierdes el primer día resolviendo lo que pudiste haber traído. Diferir todo también cuesta.

El último momento responsable: empacar lo que ya sabes, diferir lo que aún no. Empacas hoy lo que la información de hoy ya permite decidir bien: la ropa de los primeros días (sabes el clima), lo básico e imprescindible (cargador, documentos, medicinas que sí usas). Y difieres explícitamente lo que depende de información que aún no tienes: la ropa del mes dos la comprarás allá cuando sepas el clima real; el regalo lo eliges cuando confirmes que verás al amigo. No cargas peso muerto (no es BDUF) ni sales desnudo (no es parálisis): decides cada cosa cuando su información madura. Tu maleta es ligera y tus decisiones, acertadas, porque cada una se tomó con el dato disponible en su momento.

El punto: el BDUF empaca los tres meses el día uno y carga peso muerto más rework; el último momento responsable empaca cada cosa cuando sabe. El arquitecto real es el viajero sensato. No diseña todo Mercado por adelantado —qué proveedor de pagos, cómo se separa el catálogo, qué protocolo entre orders y shipping— porque muchas de esas decisiones dependen de información que solo la construcción y la operación darán. Decide hoy lo que hoy ya sabe (la base tecnológica, como vimos en la lección 2 que sobrevive), y difiere el resto a su último momento responsable. Esta lección mide el peso muerto y el rework del que empaca todo el día uno.

Ejemplo trabajado: el sobrecosto de decidir a ciegas

Modelamos seis decisiones de diseño de Mercado. Cada una tiene una semana en la que su información madura (info_ready_week): el momento en que por fin hay datos para decidirla bien —la carga real, cómo se organizaron las squads, cómo se comportó un proveedor—. Comparamos dos posturas:

  • BDUF decide las seis en la semana 0, antes de esa información. Las que decide antes de tiempo salen mal y hay que rehacerlas (rework).
  • LRM (último momento responsable) decide cada una en su semana de información madura. Sin rework, porque cada decisión se tomó con el dato disponible.
# BDUF (Big Design Up Front) vs decidir al ULTIMO MOMENTO RESPONSABLE (LRM).
# Cada decision de Mercado tiene una semana en la que por fin hay informacion
# para decidirla bien (info_ready_week). BDUF decide TODO en la semana 0, antes
# de esa info: las que decide antes de tiempo salen mal y hay que rehacerlas
# (rework). LRM decide cada una en su semana de info: sin rework.
DECISIONS = [
    # (id, info_ready_week, rework_cost_if_decided_blind)
    ("payments_provider_count",  6, 20000),
    ("catalog_service_boundary", 9, 35000),
    ("orders_shipping_protocol", 4, 18000),
    ("search_index_strategy",    8, 15000),
    ("cache_layer_shape",        5, 12000),
    ("edge_load_balancer",       0,     0),   # esta SI se sabe desde el dia 0
]

DECIDE_COST = 3000    # decidir una (analisis + registro), igual en ambas posturas

bduf_cost = 0
lrm_cost = 0
for did, ready, rework in DECISIONS:
    # BDUF: decide todo el dia 0. Si la info no estaba lista (ready>0), decide a
    # ciegas y luego rehace -> paga decidir + rework.
    bduf_cost += DECIDE_COST + (rework if ready > 0 else 0)
    # LRM: decide cada una cuando su info madura -> paga solo decidir, sin rework.
    lrm_cost += DECIDE_COST

print(f"{'decision':<26}{'info_ready':>12}{'BDUF outcome':>16}")
print("-" * 54)
for did, ready, rework in DECISIONS:
    outcome = "blind -> rework" if ready > 0 else "ok (day 0)"
    print(f"{did:<26}{('week ' + str(ready)):>12}{outcome:>16}")

print()
print(f"Costo total BDUF (decidir todo el dia 0): {bduf_cost:>7,.0f} USD")
print(f"Costo total LRM  (decidir al madurar):    {lrm_cost:>7,.0f} USD")
print(f"Sobrecosto del BDUF por decidir a ciegas: {bduf_cost - lrm_cost:>7,.0f} USD")
print()
print("BDUF no falla por planear; falla por decidir TODO antes de tener la info y")
print("pagar el rework. El arquitecto real decide al ultimo momento responsable:")
print("ni antes (BDUF) ni despues (la paralisis de la guia hermana).")

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

decision                    info_ready    BDUF outcome
------------------------------------------------------
payments_provider_count         week 6 blind -> rework
catalog_service_boundary        week 9 blind -> rework
orders_shipping_protocol        week 4 blind -> rework
search_index_strategy           week 8 blind -> rework
cache_layer_shape               week 5 blind -> rework
edge_load_balancer              week 0      ok (day 0)

Costo total BDUF (decidir todo el dia 0): 118,000 USD
Costo total LRM  (decidir al madurar):     18,000 USD
Sobrecosto del BDUF por decidir a ciegas: 100,000 USD

BDUF no falla por planear; falla por decidir TODO antes de tener la info y
pagar el rework. El arquitecto real decide al ultimo momento responsable:
ni antes (BDUF) ni despues (la paralisis de la guia hermana).

Lee la columna de la derecha, porque separa la única decisión que el BDUF acertó de las cinco que reventó.

Fíjate en edge_load_balancer: su info_ready_week es 0, y su resultado es ok (day 0). Es la única que el BDUF decide bien, y no por suerte: es una decisión cuya información ya existía el día uno —poner un balanceador HTTP en el borde es una apuesta sólida que no depende de conocer la carga futura ni cómo se organizarán las squads—. Es exactamente la clase de decisión que en la lección 2 sobrevivió al contacto con la realidad. Para estas, decidir el día uno está bien, porque su último momento responsable es el día uno.

Las otras cinco son la historia del BDUF. payments_provider_count no se puede decidir bien hasta la semana 6, cuando hay datos del comportamiento real de los proveedores; el BDUF la decidió en la semana 0, a ciegas, y cuando la información llegó, la decisión resultó equivocada y hubo que rehacerla —20000 dólares de rework—. catalog_service_boundary madura en la semana 9 (necesitas ver cómo las squads y los datos se organizan de verdad antes de trazar la frontera del servicio); decidirla el día uno costó 35000 de rework. Y así las cinco: cada una decidida antes de que su información existiera, cada una rehecha después.

El número final es el argumento: el BDUF cuesta 118000 dólares; el LRM, 18000; el sobrecosto por decidir a ciegas es 100000. Fíjate de dónde sale exactamente ese sobrecosto: no del análisis ni del registro —esos cuestan lo mismo en las dos posturas (3000 por decisión, 18000 en total)—. Sale enteramente del rework: las cinco decisiones que el BDUF tomó antes de tiempo y tuvo que rehacer. El BDUF no es más caro por planear más; es más caro por decidir antes de tener con qué decidir, y pagar la corrección después. Repito el matiz porque es el corazón de la lección y el más fácil de deformar: el problema del BDUF no es pensar por adelantado —pensar, explorar, bosquejar es bueno—; el problema es comprometerse por adelantado, congelar decisiones cuya información aún no maduró.

Y aquí está la simetría que completa la postura. Decidir antes del último momento responsable es el BDUF: pagas rework (los 100000 de esta lección). Decidir después del último momento responsable es la parálisis: pagas el costo del default y de la demora (que la guía hermana mide a fondo). El arquitecto real navega entre los dos: ni antes, ni después; cada decisión a su tiempo, cuando su información madura pero antes de que la demora cueste. El último momento responsable es ese punto de equilibrio, uno distinto para cada decisión.

Como barras, el sobrecosto salta:

Costo total: BDUF vs ultimo momento responsable (USD)
 BDUF (todo el dia 0)  |###############################  118,000
 LRM  (cada cosa a su tiempo) |####                        18,000
                        ────────────────────────────────
 sobrecosto del BDUF = 100,000, TODO rework por decidir a ciegas.

Profundización: por qué el BDUF es tan tentador (y cómo se reconoce el último momento responsable)

El BDUF, como la torre de marfil, tiene un atractivo que hay que entender para resistirlo, y el último momento responsable tiene una dificultad práctica que hay que resolver.

Por qué el BDUF tienta. Primero, da una sensación de control: tener todo decidido de antemano se siente como tener el proyecto dominado, mientras que dejar decisiones abiertas se siente como ir a ciegas. La ironía es que es al revés —decidir a ciegas el día uno es lo que va a ciegas; diferir hasta tener el dato es lo informado—. Segundo, responde a una presión organizacional real: los stakeholders piden "el plan completo" antes de aprobar presupuesto, y un documento que dice "esto lo decidiremos en la semana 6 cuando tengamos el dato" se siente menos sólido que uno que lo decide todo ahora. Tercero, hay una confusión de fondo entre planear y decidir: son cosas distintas, y el BDUF las funde. Se puede —y se debe— planear por adelantado (bosquejar el rumbo, identificar las decisiones que vendrán, anticipar los riesgos) sin comprometer por adelantado cada decisión. El plan puede decir "aquí habrá que elegir el protocolo entre orders y shipping, y lo decidiremos cuando veamos la carga"; eso es planear sin caer en BDUF.

Cómo se reconoce el último momento responsable de una decisión. La postura del LRM es fácil de enunciar y difícil de aplicar sin una guía práctica. La pregunta que la operacionaliza es doble:

  1. ¿Qué información me falta para decidir esto bien, y cuándo la voy a tener? Si a la decisión le falta un dato concreto que llegará en un momento identificable (la carga del próximo pico, cómo se comporta el proveedor tras un mes, cómo se organizaron las squads), su último momento responsable no es hoy: es cuando ese dato madure. Decidir antes es BDUF.

  2. ¿Cuándo empieza a costarme no haber decidido? El último momento responsable no es "para siempre después": llega cuando la demora empieza a costar —cuando otras decisiones se bloquean esperando esta, cuando el default se entrenca, cuando el equipo no puede avanzar sin saber—. Diferir más allá de ese punto es parálisis.

El último momento responsable es la ventana entre esos dos: después de que la información madura, antes de que la demora cueste. Si esa ventana existe, difieres hasta entrar en ella. Si el dato ya está (como edge_load_balancer), decides ya. Si la demora ya cuesta y el dato no llega, decides con lo que tienes y haces la decisión reversible (lección 4) para corregir cuando el dato aparezca. Nota lo bien que encajan las piezas del módulo: la reversibilidad (lección 4) es lo que hace seguro diferir, porque si te ves forzado a decidir antes del último momento responsable, una decisión reversible se corrige barato cuando la información llega.

Una advertencia sobre el otro extremo. Así como este módulo no dice "no planees", tampoco dice "difiere todo". Un arquitecto que usa "último momento responsable" como excusa para no decidir nunca cayó en la parálisis, que es tan cara como el BDUF por el otro lado. La disciplina del LRM tiene las dos mitades: diferir lo que aún no maduró y comprometerse en cuanto madura o en cuanto la demora empieza a costar. El arquitecto maduro no es el que decide más temprano (BDUF) ni el que decide más tarde (parálisis); es el que decide cada cosa a su tiempo, y sabe reconocer cuándo es ese tiempo para cada decisión. (El cálculo formal de ese punto —el valor de la información, el costo de diferir semana a semana— es la guía hermana; aquí basta la postura de buscarlo.)

Errores comunes

Confundir planear con decidir (y comprometer todo por adelantado). Qué pasa: el arquitecto produce un documento de diseño exhaustivo que no solo bosqueja el rumbo sino que congela cada decisión —protocolo, proveedores, fronteras de servicio— antes de escribir código, y luego el equipo ejecuta decisiones tomadas a ciegas que la realidad va invalidando. Por qué pasa: se funde "tener un plan" con "haber decidido todo", cuando planear (bosquejar, anticipar) y decidir (comprometerse) son cosas distintas. Cómo detectarlo: si el documento de arranque decide con certeza cosas que dependen de información que aún no existe (la carga real, cómo se organizarán las squads), es BDUF disfrazado de plan. Cómo corregirlo: separar las dos capas —el plan identifica qué habrá que decidir y cuándo madurará su información; las decisiones se toman cada una a su tiempo—. Un buen plan puede decir "aquí va una decisión pendiente, con este disparador"; eso es planear sin comprometer. El sobrecosto de comprometer a ciegas fue de 100000 en el ejemplo, todo rework.

Usar "último momento responsable" como excusa para no decidir nunca (parálisis). Qué pasa: el arquitecto difiere decisiones indefinidamente "porque aún no es el último momento responsable", cuando en realidad la información ya maduró o la demora ya está costando. Por qué pasa: diferir se siente seguro (no te equivocas si no decides), y "LRM" da una justificación de sonido profesional para no comprometerse. Cómo detectarlo: si al preguntar "¿qué información específica esperas y cuándo llegará?" no hay respuesta concreta, no estás en el último momento responsable; estás en parálisis. Cómo corregirlo: aplicar las dos mitades de la disciplina —diferir solo mientras falte un dato identificable con fecha, y comprometerse en cuanto ese dato llega o la demora empieza a costar—. El último momento responsable es un punto de decisión, no un aplazamiento perpetuo. (El costo de no decidir, medido semana a semana, es la guía hermana.)

Aplicar el mismo momento a todas las decisiones. Qué pasa: el arquitecto trata todas las decisiones con la misma cronología —o todas el día uno (BDUF), o todas "más adelante"— sin notar que cada una tiene su propio último momento responsable. Por qué pasa: es más simple tener una sola política ("decidamos todo ahora" o "decidamos todo después") que evaluar decisión por decisión cuándo madura su información. Cómo detectarlo: si el arquitecto decidió edge_load_balancer (que se sabe el día uno) y catalog_service_boundary (que madura en la semana 9) en el mismo momento, ignoró que tienen relojes distintos. Cómo corregirlo: reconocer que el último momento responsable es por decisión: las de base tecnológica cuya evidencia ya existe se deciden temprano; las que dependen de la carga, la operación o la organización se difieren hasta que ese dato madure. La misma lección 2 lo anticipó: tres decisiones del diagrama sobrevivían (su info existía el día uno) y siete se rehacían (su info vivía en la construcción). Cada decisión, su reloj.

Ejercicios

Ejercicio 1 — ¿Decidir ya o diferir? Para cada una de estas decisiones de Mercado, di si su último momento responsable es probablemente "el día uno" o "más adelante", y qué información habría que esperar en el segundo caso: (a) elegir el lenguaje y framework base de los servicios; (b) decidir si el buscador tendrá su propio índice o consultará la base del catálogo; (c) elegir el formato de logs para la observabilidad transversal; (d) decidir el número de proveedores de pago.

Ver solución
  • (a) Lenguaje y framework base → día uno. Su información ya existe: el equipo conoce sus habilidades, el mercado de contratación, el ecosistema. No depende de la carga futura ni de cómo evolucione Mercado. Es una decisión de base, como edge_load_balancer: decidirla temprano está bien, y diferirla solo bloquearía todo lo demás. Además es cara de revertir, así que conviene decidirla con cuidado pero pronto.
  • (b) Índice propio del buscador vs base del catálogo → más adelante. Depende del volumen real de búsquedas y del tamaño del catálogo, datos que no existen el día uno. Su último momento responsable llega cuando haya tráfico real que muestre si la base del catálogo aguanta o no. Decidirla el día uno es adivinar (BDUF); esperar el dato de carga es LRM.
  • (c) Formato de logs → día uno (con matiz). El formato (JSON estructurado con ciertos campos) se puede y conviene fijar temprano como guardrail, porque la observabilidad transversal lo necesita desde el principio y su info no depende del futuro. Es una decisión de convención amplia, como las que sobrevivían en la lección 2.
  • (d) Número de proveedores de pago → más adelante. Depende de la disponibilidad real del proveedor único (¿se cae?), del volumen (¿justifica la redundancia?) y del costo. Esa información madura con la operación, no el día uno. Es exactamente el payments_provider_count del ejemplo, con último momento responsable en la semana 6.

El patrón: las decisiones de base y convención cuya evidencia ya existe se deciden temprano; las que dependen de carga, operación u organización se difieren hasta que su dato madure. Cada decisión, su reloj.

Ejercicio 2 — El plan que el VP pide. El VP exige "el diseño completo de Mercado antes de aprobar el presupuesto: quiero todas las decisiones tomadas". Sabiendo que decidirlas todas ahora costaría 100000 en rework, ¿cómo le das un plan que lo satisfaga sin caer en el BDUF?

Ver solución

La clave es separar lo que el VP realmente necesita (confianza en que hay un rumbo y un manejo del riesgo) de lo que pide literalmente (todas las decisiones congeladas). Le das un plan que planea sin comprometer a ciegas:

  • El rumbo y la arquitectura de alto nivel, firmes. Las decisiones cuya información ya existe —lenguaje, base tecnológica, los guardrails, el balanceador— sí las decides y las presentas como firmes. Eso le da al VP la solidez que busca.
  • Las decisiones pendientes, explícitas y con disparador. En vez de ocultar que hay decisiones abiertas, las haces visibles como parte del plan: "estas cinco decisiones —proveedores de pago, frontera del catálogo, protocolo orders/shipping, índice del buscador, forma del cache— dependen de información que tendremos en las semanas 4 a 9; las decidiremos ahí, con el dato, en vez de adivinar hoy". Cada una con su disparador (qué dato la desbloquea).
  • El argumento de negocio. Le explicas que decidir esas cinco ahora no da más control, da más rework: 100000 dólares de decisiones que rehacer cuando la realidad las contradiga. Diferirlas al último momento responsable no es "no tener plan"; es el plan que evita ese costo. Un VP entiende bien la idea de no comprometer capital antes de tiempo —es su propio oficio—.

Así el VP recibe un plan que es firme donde puede serlo y honesto donde no, con un manejo del riesgo explícito. Eso es más sólido, no menos, que un BDUF que congela decisiones a ciegas. (Cómo presentárselo con el nivel de diagrama adecuado para él es el módulo 3; el argumento del costo de diferir vs decidir es la guía hermana.)

Ejercicio 3 — BDUF y parálisis, los dos errores. Un compañero dice: "entonces la lección es clara: nunca decidas por adelantado, difiere todo lo posible". Corrige su conclusión mostrando cómo cae en el error opuesto, y enuncia la postura correcta con precisión.

Ver solución

Su conclusión invierte el BDUF pero cae en el otro extremo: la parálisis. "Nunca decidas por adelantado, difiere todo lo posible" trata el diferir como un bien en sí mismo, cuando diferir también cuesta —el costo del default, de las decisiones bloqueadas esperando, de la demora—. Si difieres una decisión cuya información ya maduró (como edge_load_balancer, que se sabe el día uno), no estás siendo prudente; estás retrasando sin razón y bloqueando lo que depende de ella. Y si difieres una decisión más allá del punto donde su demora empieza a costar, pagas la parálisis que la guía hermana mide.

La postura correcta no es "decide temprano" (BDUF) ni "difiere todo" (parálisis), sino el último momento responsable, por decisión: decide cada cosa cuando su información madura pero antes de que la demora cueste. Con precisión, son tres casos:

  • Si la información ya existe (base tecnológica, convenciones): decide ya; diferir solo bloquea.
  • Si la información madurará en un momento identificable: difiere hasta ahí, y decide cuando llegue.
  • Si la demora ya está costando y la información no llega: decide con lo que tienes y hazla reversible (lección 4) para corregir cuando el dato aparezca.

La disciplina tiene las dos mitades: diferir lo que aún no maduró y comprometerse en cuanto madura o la demora cuesta. El arquitecto maduro decide cada cosa a su tiempo, ni antes ni después —y reconoce que ese "tiempo" es distinto para cada decisión—.

Resumen y siguiente paso

En esta lección desarmaste la última imagen falsa del rol: el Big Design Up Front, diseñar y comprometer todo por adelantado antes de tener la información. Viste, con la maleta del viaje de tres meses, que empacar los tres meses el día uno carga peso muerto y obliga a rework, mientras que empacar cada cosa cuando sabes mantiene la maleta ligera y las decisiones acertadas. Y lo mediste: el BDUF cuesta 118000 dólares contra 18000 del último momento responsable, un sobrecosto de 100000 que es todo rework —no por planear, sino por decidir a ciegas antes de que la información madurara—. La postura del arquitecto real es el último momento responsable: cada decisión a su tiempo, ni antes (BDUF, pagas rework) ni después (parálisis, pagas el default), con la reversibilidad como red para las que la demora fuerza a decidir pronto.

Antes de avanzar deberías poder: distinguir planear (bueno, anticipar el rumbo) de comprometer por adelantado (BDUF); enunciar el último momento responsable con sus dos mitades (después de que la info madura, antes de que la demora cueste); reconocer que cada decisión tiene su propio reloj; y ver cómo la reversibilidad de la lección 4 hace seguro diferir.

La lección 8 es el proyecto que integra todo el módulo. Vas a tomar el rol del arquitecto actual de Mercado, diagnosticar cuáles de las cuatro imágenes falsas padece —torre de marfil, despegado del código, dictador/cuello de botella, BDUF—, medir el costo de coordinación de su forma de trabajar, y producir un role charter que reparte lo que el arquitecto posee, lo que delega y cómo habilita. Ejecutado, con el costo de espera antes y después. Es el módulo entero puesto a trabajar sobre un caso.

Recursos

  • Mary y Tom Poppendieck, Lean Software Development (Addison-Wesley, 2003) — la fuente del concepto "last responsible moment": diferir el compromiso hasta el último momento en que se puede tomar la decisión con información suficiente, sin que la demora cueste. La postura central de esta lección. En inglés.
  • Martin Fowler, "Is Design Dead?" — martinfowler.com/articles/designDead.html. Sobre por qué el diseño evolutivo supera al diseño completo por adelantado, y cómo el diseño es una actividad continua, no un documento inicial. En inglés.
  • Barry Boehm, "Get Ready for Agile Methods, with Care" (IEEE Computer, 2002) — el análisis clásico del balance entre planear por adelantado y decidir tarde, y por qué el punto óptimo depende del costo del cambio. En inglés.
  • Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), sobre arquitectura evolutiva y por qué el arquitecto diseña para el cambio, no para la permanencia. La reversibilidad y el LRM como técnica a fondo son la guía hermana architecture-decisions (módulo 7); la postura mental es esta lección. En inglés.
← AnteriorLa trampa del cuello de botellaSiguiente →Mini-proyecto: diagnostica y rediseña el rol del arquitecto en Mercado