Reversible antes que correcto

Descripción

Las lecciones 2 y 3 quitaron dos cosas que el arquitecto no es: no es el que dibuja el plano perfecto y se va, ni el que decide desde el penthouse sin bajar al código. Esta lección responde la pregunta positiva: entonces, ¿cuál es su producto? ¿Qué entrega un arquitecto que hace bien su trabajo? La respuesta desafía la intuición. El producto del arquitecto no es "la decisión correcta". Es una decisión cuya equivocación sea barata —una decisión reversible— acompañada del porqué registrado para que pueda revisarse. En una palabra: el arquitecto no vende certezas; vende opciones que se pueden deshacer.

Esto suena casi a herejía en un rol al que se le pide "acertar". Pero es la consecuencia directa de las dos lecciones anteriores. Si el diagrama del día uno es una hipótesis que se rehace en un 70% (lección 2), y si toda estimación bajo incertidumbre puede fallar (lección 3), entonces apostar todo a acertar es apostar contra la realidad. El arquitecto maduro acepta que se va a equivocar parte del tiempo —es inevitable con información incompleta— y traslada su esfuerzo de "reducir la probabilidad de equivocarme" a "reducir el costo de equivocarme". Una decisión que puedes deshacer barato te deja equivocarte sin que duela; una que te amarra convierte cada error en una catástrofe. Esta lección lo mide: compara dos posturas —apostar a acertar contra apostar a poder deshacer— sobre decisiones inciertas de Mercado, y muestra por qué, cuando la incertidumbre es alta, abaratar el error gana por goleada.

Conexión con el módulo. Es la primera de las tres lecciones que definen al arquitecto real por lo que hace (esta: hace reversibles las decisiones caras y comunica el porqué; la 5: habilita; la 6: no se vuelve cuello de botella). Aquí instalamos su producto central. Cuidado con la frontera, porque es la más delicada del módulo: la mecánica de la reversibilidad —cómo clasificar una decisión como puerta de una o de dos vías, cómo calcular el último momento responsable, cómo estructurar una decisión para dejarla abierta— es la guía hermana architecture-decisions-and-tradeoffs (su módulo 7). Aquí no re-enseñamos esa mecánica; trabajamos la postura del rol: por qué el arquitecto entiende que su entregable es una decisión barata de deshacer más su porqué, y no un veredicto definitivo. La técnica es de la otra guía; la identidad profesional que la usa es de esta.

Una analogía: alquilar antes de comprar en una ciudad nueva

Te mudas a una ciudad que no conoces y tienes que decidir dónde vivir. Hay dos maneras de encarar esa decisión, y son dos filosofías del rol.

Apostar a acertar (comprar de una). Inviertes semanas investigando: mapas de criminalidad, tiempos de traslado, calidad de escuelas, tendencias de precios. Con toda esa información compras una casa el primer mes. Hiciste la tarea, elegiste con rigor. Pero la ciudad tiene cosas que ningún mapa te dice: que ese barrio "tranquilo" es insoportable los fines de semana por un bar, que el traslado que en el mapa es de 20 minutos son 50 en hora pico, que a tres cuadras hay una obra que durará dos años. Si te equivocaste —y con información incompleta es probable—, deshacer la compra es carísimo: vender, perder en comisiones, mudarte de nuevo. Apostaste todo a acertar, y cuando la realidad te contradice, pagas caro.

Apostar a poder deshacer (alquilar primero). Alquilas por seis meses en un barrio que parece bueno, sin la investigación exhaustiva. Vives la ciudad de verdad: sientes el bar del fin de semana, sufres el tráfico real, ves la obra. Si el barrio no era, te mudas al terminar el contrato —costo bajo, molestia acotada—. Y cuando por fin compras, compras con información que ningún mapa te habría dado, porque la viviste. No apostaste a acertar el primer mes; apostaste a que equivocarte fuera barato, y usaste ese margen para aprender.

Aquí está el punto: quien alquila primero se equivoca más veces, pero cada equivocación le cuesta poco; quien compra de una se equivoca menos veces, pero cada equivocación le cuesta una fortuna. Con una ciudad que no conoces —alta incertidumbre— la segunda estrategia gana casi siempre, porque el costo total no lo domina cuántas veces te equivocas, sino cuánto cuesta cada vez. El arquitecto real es el que alquila primero: ante orders→shipping, ante extraer el catálogo, ante el segundo proveedor de pagos —todas decisiones en una ciudad que no conoce del todo— prefiere la opción que puede deshacer barato sobre la que lo amarra, aunque la amarradora "suene" más definitiva. Esta lección pone número a esa intuición.

Ejemplo trabajado: apostar a acertar contra apostar a poder deshacer

Comparamos dos posturas del arquitecto sobre cuatro decisiones inciertas de Mercado. En cada decisión hay una probabilidad real de equivocarse (p_wrong), porque la información está incompleta —es la ciudad que no conoces—:

• aim_right — la postura de "voy a acertar": invierte mucho análisis por adelantado (que reduce la probabilidad de fallar a la mitad, pero no a cero) y se compromete de forma dura. Si aun así falla, revertir es carísimo porque quedó amarrado.
• aim_reversible — la postura del arquitecto real: decide rápido, sin gran análisis, pero conservando una salida barata. Si falla, revierte barato.

# El producto del arquitecto real no es "la decision correcta"; es una decision
# cuya EQUIVOCACION sea barata (reversible) + el porque registrado. Comparamos
# dos posturas ante 4 decisiones inciertas de Mercado:
#   aim_right      : invierte mucho analisis para acertar y se compromete duro;
#                    si aun asi falla, revertir es carisimo.
#   aim_reversible : decide rapido conservando una salida; si falla, revierte barato.
# p_wrong = probabilidad de equivocarse (la incertidumbre es real y alta).
DECISIONS = [
    # (id, p_wrong, revert_if_locked_in, revert_if_reversible, analysis_cost)
    ("async_orders_to_shipping", 0.40, 60000, 6000, 12000),
    ("extract_catalog_service",  0.35, 90000, 9000, 15000),
    ("second_payments_provider", 0.30, 40000, 4000,  8000),
    ("event_bus_vs_direct_call", 0.45, 50000, 5000, 10000),
]

print(f"{'decision':<28}{'aim_right':>12}{'aim_reversible':>16}")
print("-" * 56)
tot_right = tot_rev = 0
for did, p, lock_cost, rev_cost, analysis in DECISIONS:
    # aim_right: paga el analisis siempre; el analisis baja la prob de fallar a
    # la mitad, pero si aun asi falla, la reversion es carisima (quedo amarrado).
    cost_right = analysis + (p / 2) * lock_cost
    # aim_reversible: casi sin analisis; si falla, revierte barato.
    cost_rev = p * rev_cost
    tot_right += cost_right
    tot_rev += cost_rev
    print(f"{did:<28}{cost_right:>12,.0f}{cost_rev:>16,.0f}")

print("-" * 56)
print(f"{'TOTAL costo esperado (USD)':<28}{tot_right:>12,.0f}{tot_rev:>16,.0f}")
print()
print("aim_right paga analisis por adelantado Y sigue expuesto a una reversion")
print("carisima cuando falla. aim_reversible acepta que va a fallar a veces,")
print("pero hace que fallar sea barato. Con incertidumbre alta, abaratar el error")
print("gana. El arquitecto no vende certezas; vende opciones que se pueden deshacer.")

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

decision                       aim_right  aim_reversible
--------------------------------------------------------
async_orders_to_shipping          24,000           2,400
extract_catalog_service           30,750           3,150
second_payments_provider          14,000           1,200
event_bus_vs_direct_call          21,250           2,250
--------------------------------------------------------
TOTAL costo esperado (USD)        90,000           9,000

aim_right paga analisis por adelantado Y sigue expuesto a una reversion
carisima cuando falla. aim_reversible acepta que va a fallar a veces,
pero hace que fallar sea barato. Con incertidumbre alta, abaratar el error
gana. El arquitecto no vende certezas; vende opciones que se pueden deshacer.

Lee los dos totales, porque la diferencia es el argumento entero de la lección: 90000 dólares esperados apostando a acertar, contra 9000 apostando a poder deshacer. Un orden de magnitud. Diez veces más caro intentar acertar que hacer barato el error. Desglosemos por qué.

La postura aim_right paga dos veces. Primero paga el análisis por adelantado —12000, 15000, 8000, 10000 dólares de investigación para "acertar"— y lo paga siempre, aciertes o no. Segundo, aun después de todo ese análisis, sigue expuesta a la reversión carísima cuando falla, porque se comprometió de forma dura. En async_orders_to_shipping: 12000 de análisis + un 20% de probabilidad de fallar (el análisis bajó el 40% original a la mitad) por 60000 de revertir amarrado = 24000. El análisis redujo la probabilidad de error, pero no la eliminó, y cuando el error llega, el costo amarrado es brutal.

La postura aim_reversible casi no paga análisis —decide rápido— y cuando falla, revierte barato: en async_orders_to_shipping, un 40% de probabilidad de fallar por solo 6000 de revertir = 2400. Se equivoca más seguido que aim_right (40% contra 20%, porque no invirtió en reducir la probabilidad), pero cada equivocación le cuesta una décima parte. Y ahí está el corazón: el costo total no lo domina cuántas veces te equivocas, sino cuánto cuesta cada vez. aim_reversible acepta equivocarse el doble de seguido y aun así gana diez a uno, porque atacó la variable que importa —el costo del error— en vez de la que impresiona —la probabilidad del error—.

Fíjate en lo que esto le dice al arquitecto sobre su identidad. La cultura le pide "acertar", y él aprende a redefinir su trabajo: no como "tomar la decisión correcta" —una meta imposible con información incompleta— sino como "estructurar la decisión para que equivocarse salga barato". Eso cambia todo lo que hace: en vez de tres semanas de comité para elegir entre síncrono y eventos, monta la opción que puede cambiar después y avanza; en vez de amarrar Mercado a un proveedor de pagos "perfecto", elige uno que pueda intercambiar. Su producto no es un veredicto; es una puerta que sigue abierta más el registro de por qué la cruzó por aquí, para que quien venga después pueda cerrarla o abrir otra.

Como barras, la goleada es visible:

Costo esperado total (USD): acertar vs poder deshacer
 aim_right       |##################################  90,000
 aim_reversible  |###                                  9,000
                  ─────────────────────────────────
 10x mas caro apostar a acertar que a abaratar el error.

Profundización: por qué el porqué viaja con la decisión

El producto del arquitecto tiene dos partes, y hasta ahora nos concentramos en la primera —la decisión reversible—. La segunda es igual de importante: el porqué. Una decisión reversible sin su porqué es media entrega, y vale la pena entender por qué el arquitecto real nunca entrega una sin la otra.

Piensa en qué pasa seis meses después de tomar la decisión de orders→shipping. El arquitecto que la tomó quizá ya no está en esa reunión, quizá ya cambió de proyecto, quizá se fue de la empresa. Llega una squad nueva, ve la decisión —"orders llama a shipping de forma síncrona, con esta salida preparada por si hay que cambiar a eventos"— y tiene que decidir si la mantiene, la revierte o la evoluciona. Si lo único que heredó es qué se decidió, está a ciegas: no sabe qué alternativas se consideraron, qué se sabía y qué no, qué la haría revisable. Es probable que revierta una decisión que era buena, o mantenga una que ya no aplica, porque no tiene el contexto. El qué sin el porqué condena a los que vienen a repetir el análisis desde cero, o peor, a decidir a ciegas.

Por eso el arquitecto real hace que el porqué viaje con la decisión en el tiempo. Registra: qué se decidió, qué alternativas se pesaron, qué se sabía y qué no (la niebla honesta), y bajo qué condiciones habría que revisarlo. Ese registro es lo que permite que una decisión reversible se revierta con criterio meses después, en vez de por corazonada. La reversibilidad abre la puerta; el porqué le dice al que viene por qué está abierta y cuándo conviene cruzarla en otra dirección.

El vehículo formal de ese porqué es el ADR —Architecture Decision Record—, y aquí hay que ser preciso con la frontera del ecosistema. La mecánica del ADR (su estructura Context/Decision/Consequences/Status, cómo escribirlo, cómo versionarlo) la enseña la guía hermana architecture-decisions, y su uso comunicativo a fondo —el ADR como pieza que distintas audiencias entienden— es el módulo 3 de esta guía. Aquí solo instalamos el principio del rol: el arquitecto no entrega decisiones huérfanas de su porqué. Una decisión sin su razón registrada es una trampa para el futuro, por muy reversible que sea, porque nadie sabrá cuándo ni por qué revertirla. El producto completo del arquitecto es la puerta abierta y el mapa de por qué está donde está.

Una consecuencia liberadora del rol. Definir el producto como "reversible + porqué" en vez de "correcto" le quita al arquitecto un peso imposible. Nadie puede garantizar acertar bajo incertidumbre; todos pueden estructurar sus decisiones para que equivocarse salga barato y dejar registrado el porqué. El primer estándar produce arquitectos paralizados por el miedo a equivocarse (que caen en la parálisis y el BDUF); el segundo produce arquitectos que avanzan, aprenden y corrigen. La madurez del oficio no es equivocarse menos; es haber diseñado las cosas para que equivocarse no sea catastrófico. El arquitecto que interioriza esto deja de necesitar tener la razón —una necesidad que, como veremos en las lecciones 5 y 6, es la raíz del dictador y del cuello de botella— y empieza a construir sistemas y equipos que sobreviven a estar equivocados.

Errores comunes

Perseguir la decisión "correcta" y paralizarse. Qué pasa: el arquitecto trata cada decisión como si tuviera que acertarla, invierte semanas de análisis buscando la certeza, y mientras tanto las squads esperan y el sistema no avanza. Por qué pasa: la cultura le pide "acertar" y él lo interioriza como su estándar, sin notar que la certeza no existe con información incompleta —perseguirla es perseguir un horizonte—. Cómo detectarlo: si una decisión lleva semanas "en análisis" sin que baje su incertidumbre, o si el arquitecto no se compromete "hasta estar seguro", está apostando a acertar en una ciudad que no conoce. Cómo corregirlo: redefinir el producto —de "la decisión correcta" a "una decisión reversible más su porqué"— y preguntarse, ante cada decisión, no "¿cuál es la correcta?" sino "¿cuál puedo deshacer barato si me equivoco?". Eso desbloquea el avance sin apostar la casa. (El cálculo formal de cuánto analizar antes de decidir es la guía hermana; aquí basta la postura.)

Amarrar el sistema por buscar la opción "definitiva". Qué pasa: el arquitecto elige la solución que "suena" más completa y permanente —un proveedor de pagos único y perfecto, una integración síncrona "porque es más simple"— y en el proceso deja al sistema sin salida barata si esa opción resulta mala. Por qué pasa: las opciones definitivas se sienten más profesionales y decididas que las tentativas; "dejar una puerta abierta" puede parecer indecisión. Cómo detectarlo: si al preguntar "¿y si esto resulta mal, cuánto cuesta cambiarlo?" la respuesta es "carísimo, quedaríamos amarrados", el arquitecto optimizó por definitividad en vez de por reversibilidad. Cómo corregirlo: preferir, entre dos opciones de mérito parecido, la que conserva una salida barata, aunque sea un poco menos "elegante". El ejemplo lo cuantifica: la reversión amarrada (60000, 90000) es lo que hace a aim_right diez veces más cara. Una puerta abierta vale más que una decisión que se ve definitiva.

Entregar la decisión sin su porqué. Qué pasa: el arquitecto toma una decisión —incluso una reversible y buena— pero solo comunica el qué ("orders llama a shipping síncrono"), sin registrar las alternativas, lo que se sabía, ni cuándo revisarla; meses después nadie entiende por qué está así, y se revierte a ciegas o se conserva por inercia. Por qué pasa: el porqué vive en la cabeza del arquitecto en el momento de decidir, y se siente obvio, así que no se registra —hasta que el arquitecto se va o lo olvida—. Cómo detectarlo: si al preguntarle a la squad "¿por qué está así esto?" la respuesta es "no sé, ya estaba" o "así lo decidió el arquitecto anterior", el porqué no viajó con la decisión. Cómo corregirlo: tratar el registro del porqué como parte inseparable del producto —una decisión sin su razón no está terminada—. El ADR es el vehículo (su mecánica es la guía hermana; su uso comunicativo, el módulo 3), pero el principio del rol es este: no entregues puertas abiertas sin el mapa de por qué están abiertas.

Ejercicios

Ejercicio 1 — Reencuadra la decisión. El VP le pide al arquitecto "la decisión correcta" sobre si Mercado adopta un segundo proveedor de pagos. En vez de lanzarse a un análisis de tres semanas para "acertar", ¿cómo reencuadraría el arquitecto real esta decisión, y qué preguntaría para estructurarla como reversible?

Ver solución

El arquitecto real no busca "la correcta"; busca "la que puedo deshacer barato si me equivoco". Reencuadra la pregunta de "¿un proveedor o dos?" a "¿cómo estructuro los pagos para poder cambiar de idea sin que duela?".

Las preguntas que haría para volverla reversible: ¿podemos poner una capa de abstracción sobre el proveedor de pagos, de modo que agregar o quitar uno sea un cambio acotado y no una reescritura? ¿Podemos empezar con un proveedor pero diseñando la integración de forma que meter el segundo después cueste poco? ¿Qué información nos falta —cuánto de verdad se cae el proveedor único, qué volumen justifica el segundo— y podemos conseguirla barato antes de amarrarnos?

Con ese reencuadre, la entrega al VP no es "la respuesta definitiva tras tres semanas", sino algo como: "empezamos con un proveedor, pero con la integración estructurada para que sumar el segundo cueste poco si lo necesitamos; así avanzamos ya, y si la realidad nos dice que hace falta el segundo, lo metemos barato". El arquitecto le entregó una puerta abierta, no un veredicto —y le ahorró tres semanas de análisis para acertar algo que la reversibilidad vuelve innecesario acertar de primera—. (Cómo diseñar esa capa de abstracción es una guía técnica; que el arquitecto la busca por postura es esta lección.)

Ejercicio 2 — Cuando acertar sí importa: la puerta de una vía. El ejemplo muestra que apostar a poder deshacer gana diez a uno. ¿Significa eso que el arquitecto nunca debe invertir en análisis para acertar? Describe el tipo de decisión donde aim_right sí tendría sentido, y por qué.

Ver solución

No, no significa que el análisis nunca valga. La goleada de aim_reversible depende de un supuesto del ejemplo: que la decisión se puede hacer reversible barato (revertir cuesta 6000 en vez de 60000). Cuando eso es cierto, apostar a deshacer gana. Pero hay decisiones que son intrínsecamente irreversibles —las "puertas de una vía"— donde no existe una salida barata por más que la busques: partir la base de datos única de Mercado en una por servicio, por ejemplo, o una decisión que expone un contrato público a miles de clientes externos que luego dependerán de él.

En esas decisiones, aim_reversible no está disponible —no hay puerta que dejar abierta— así que el arquitecto sí debe invertir en acertar: análisis a fondo, spikes, comités si hace falta. El rigor debe ser proporcional a la irreversibilidad. Lo que la lección enseña no es "nunca analices", sino "primero pregunta si la puedes hacer reversible; si sí, hazla reversible y avanza barato; si es genuinamente de una vía, entonces sí invierte en acertar". El error es aplicar el rigor de una puerta de una vía a una decisión que era de dos —analizar tres semanas algo que pudiste dejar abierto y cambiar en un día—.

(La distinción formal entre puertas de una y de dos vías, y cómo clasificarlas, es exactamente el módulo 7 de la guía hermana architecture-decisions. Aquí basta con que el arquitecto sepa que su primera pregunta es "¿puedo hacer esto reversible?", y solo si la respuesta es no, apuesta a acertar.)

Ejercicio 3 — El porqué que no viajó. Una squad nueva de Mercado hereda esta decisión: "orders publica un evento OrderPlaced y shipping lo consume, en vez de una llamada directa". No hay ningún registro de por qué. La squad, que valora la simplicidad, está a punto de revertirla a una llamada síncrona directa "porque es más simple". Explica qué se perdió al no registrar el porqué, y qué debería haber contenido ese registro para evitar esta reversión a ciegas.

Ver solución

Lo que se perdió es el contexto que hacía buena a la decisión. La squad nueva ve el qué (eventos en vez de llamada directa) pero no el porqué, así que juzga la decisión solo por su criterio actual (simplicidad) sin saber qué problema resolvía. Es muy posible que esté a punto de revertir una decisión correcta: quizá se eligieron eventos justamente porque la llamada síncrona directa tiraba el checkout cuando shipping se caía (el problema que la lección 2 mencionó). Si revierte sin saberlo, va a reintroducir esa fragilidad y a redescubrir el problema por las malas, meses de trabajo después.

Ese registro debería haber contenido: qué se decidió (eventos), qué alternativas se pesaron (llamada síncrona directa, que es justo lo que la squad quiere ahora), por qué se descartó la alternativa (la síncrona acoplaba la disponibilidad del checkout a la de shipping; si shipping se caía, los pedidos se caían), qué se sabía y qué no en ese momento, y bajo qué condiciones tendría sentido revisarla (por ejemplo, "si shipping alcanza tal disponibilidad, reconsiderar"). Con ese registro, la squad nueva no revierte a ciegas: ve que la simplicidad que busca ya se consideró y se descartó por una buena razón, y decide con criterio —o encuentra que las condiciones cambiaron y la revierte sabiendo lo que hace—.

Ese es exactamente el sentido de "el porqué viaja con la decisión": una decisión reversible sin su registro no es una ventaja, es una trampa, porque cualquiera puede deshacerla sin entender qué sostenía. El producto del arquitecto no estaba completo con solo elegir eventos; le faltaba el mapa de por qué. (El formato de ese registro —el ADR— es la guía hermana y el módulo 3; el principio de no entregar decisiones huérfanas es esta lección.)

Resumen y siguiente paso

En esta lección definiste el producto del arquitecto real, y no es el que la cultura pide. No es "la decisión correcta" —una meta imposible bajo incertidumbre— sino una decisión cuya equivocación sea barata (reversible) más el porqué registrado para que pueda revisarse con criterio. Viste, con alquilar antes de comprar, que quien apuesta a poder deshacer se equivoca más seguido pero paga poco cada vez, y gana a quien apuesta a acertar. Y lo mediste: apostar a acertar cuesta 90000 dólares esperados contra 9000 de apostar a poder deshacer —diez a uno— porque el costo total lo domina cuánto cuesta cada error, no cuántos errores hay. El arquitecto no vende certezas; vende opciones que se pueden deshacer, con su porqué.

Antes de avanzar deberías poder: explicar por qué "reversible + porqué" es mejor estándar que "correcto" bajo incertidumbre; reencuadrar una decisión de "¿cuál es la correcta?" a "¿cuál puedo deshacer barato?"; reconocer cuándo una decisión es intrínsecamente irreversible (puerta de una vía) y sí merece el esfuerzo de acertar; y argumentar por qué una decisión reversible sin su porqué registrado es una trampa para el futuro.

La lección 5 sigue con el segundo verbo del arquitecto real. Ya sabes que hace reversibles las decisiones caras (esta lección); ahora vas a ver que habilita al equipo. El arquitecto real no es un dictador que decide por las squads; es un jardinero que pone guardrails —límites claros— y devuelve la decisión local a quien está más cerca del problema. Con números: cuántas decisiones de una semana típica de Mercado pueden resolver las squads solas cuando el arquitecto habilita en vez de dictar.

Recursos

• Jeff Bezos, Carta a los accionistas de Amazon (2015) — sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm. El origen de las "puertas de una vía y de dos vías": las decisiones irreversibles merecen deliberación; las reversibles, velocidad. La base de la postura de esta lección. Su mecánica se trabaja en la guía hermana architecture-decisions. En inglés.
• Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 19 "Architecture Decisions" — sobre por qué las decisiones significativas se miden por su costo de cambio, y por qué el arquitecto piensa en reversibilidad. En inglés.
• Martin Fowler, "Who Needs an Architect?" (IEEE Software, 2003) — martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. Contiene la idea de que el trabajo del arquitecto es, en buena parte, mantener las decisiones importantes fáciles de cambiar el mayor tiempo posible. En inglés.
• Michael Nygard, "Documenting Architecture Decisions" (2011) — cognitect.com/blog/2011/11/15/documenting-architecture-decisions. El post que originó el ADR, el vehículo del "porqué que viaja con la decisión". Su formato se trabaja en el módulo 3 y en la guía hermana. En inglés.