Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 1.6 de 1.8 · Intermedio · 20 min de lectura
Decisiones arquitectónicas y compromisos: reversibilidad y momento oportuno
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
Los arquitectos toman decisiones todo el tiempo, y ninguna sale gratis. Esta lección trata de cómo sopesar los compromisos, qué decisiones merecen cuidado, cuándo decidir y cómo mostrar tu razonamiento.
Elegir un vehículo es un compromiso. Un motor más grande gasta más combustible; un vehículo más pequeño es más fácil de estacionar, pero lleva menos. Nadie lo consigue todo. Algunas elecciones son fáciles de deshacer, como un color de pintura que puedes cambiar más adelante. Otras, como comprar la casa que está junto a una autopista, son muy difíciles de deshacer. Los buenos arquitectos toman rápido las elecciones fáciles, se toman su tiempo con las difíciles, deciden en el momento adecuado y anotan por qué.
La primera ley de Mark Richards y Neal Ford: todo en la arquitectura de software es un compromiso. La caché compra velocidad y lo paga con datos desactualizados. Si crees haber encontrado algo que no es un compromiso, probablemente todavía no lo has detectado. Su segunda ley: el porqué es más importante que el cómo. Cualquiera puede ver cómo está construido un sistema. Lo que el código no puede decirte es el porqué: qué alternativas se consideraron y qué riesgos se aceptaron. Y una tercera: la mayoría de las decisiones no son binarias. Rara vez eliges entre un monolito y microservicios; eliges cuántas unidades desplegables, divididas según qué líneas.
Una decisión bien formada tiene seis partes. A la izquierda hay tres entradas: el contexto, es decir, las fuerzas y las restricciones; al menos dos opciones reales; y los criterios, extraídos de las inquietudes de las partes interesadas. Alimentan la decisión en sí y su justificación: por qué la opción elegida superó a las demás. Después vienen las consecuencias, es decir, las ganancias, los costos, los riesgos y las opciones que quedan cerradas, y el estado, como propuesta, aceptada o reemplazada. Fíjate en la flecha discontinua. Las consecuencias se convierten en contexto para decisiones posteriores. Si eliges la mensajería asíncrona, a continuación debes decidir cómo tratar los mensajes duplicados.
La propiedad más útil de una decisión es con qué poco costo se puede deshacer. Jeff Bezos llamó a las decisiones reversibles puertas de doble sentido. Tómalas rápido, en grupos pequeños, porque puedes volver a cruzarlas. Una biblioteca de logging detrás de tu propia interfaz es una de ellas. Las puertas de un solo sentido son casi irreversibles, como el modelo de datos de un sistema de registro o una API pública que usan cientos de socios. Merecen una deliberación lenta y cuidadosa con las personas que cargan con las consecuencias. Y la reversibilidad cambia con el tiempo. Cuanto más código, más datos y más personas dependen de una elección, más difícil resulta deshacerla.
Entonces, ¿cuándo deberías decidir? A medida que avanza un proyecto, lo que sabes aumenta, mientras que las opciones que siguen abiertas disminuyen. Si decides demasiado pronto, estás adivinando. Fijar la base de datos en la primera semana, antes de entender la forma de los datos, es una conjetura. El último momento responsable es el punto en el que no decidir eliminaría una opción importante. Decidir entonces aprovecha el mayor conocimiento, sin dejar que la decisión se tome por ti. Si lo dejas demasiado tarde, la decisión se toma por omisión, por ejemplo cuando ya se ha escrito código en torno a un supuesto no expresado. Esto no es una licencia para procrastinar. Sabe qué decisiones están pendientes y cuándo debe tomarse cada una, y usa el tiempo hasta entonces para aprender.
Veamos un ejemplo práctico. Una empresa de reparto de comida necesita una base de datos para un nuevo servicio de pedidos. Los pagos nunca deben perderse ni cobrarse dos veces. El equipo de seis personas conoce bien PostgreSQL, pero no tiene administrador de bases de datos. Hay tres opciones: un servicio gestionado de PostgreSQL, la base de datos documental propia del proveedor de nube, o un PostgreSQL que gestione el propio equipo. Primero acuerdan seis criterios y sus pesos, como la integridad transaccional y el esfuerzo operativo, y luego puntúan cada opción. PostgreSQL gestionado obtiene setenta y nueve de noventa y cinco, por delante de setenta y tres y sesenta y siete. Después, una comprobación de sensibilidad: ¿y si el crecimiento fuera mucho mayor, o si otro gestionara las bases de datos? La opción A sigue primera o empatada en primer lugar. El resultado depende sobre todo de la falta de capacidad del equipo para operar bases de datos. Así que eligen PostgreSQL gestionado y registran las desventajas con honestidad: una factura mensual más alta y ventanas de mantenimiento fijadas por el proveedor. Los números no toman la decisión; hacen visible el razonamiento.
Como el porqué es lo que más importa, hay que ponerlo por escrito. El formato habitual es un registro de decisiones de arquitectura, o ADR: un archivo de texto breve con título, estado, contexto, decisión y consecuencias. Se guarda con el código y nunca se edita para cambiar la historia. Una decisión posterior lo reemplaza y enlaza con él, de modo que el registro cuenta la historia. Y evita los errores comunes: considerar solo una opción, ocultar las desventajas y no revisar nunca una decisión cuando cambian sus supuestos.
Eso es todo sobre decisiones y compromisos. La sección completa incluye una guía para decidir ahora o más adelante, las trampas cognitivas a las que debes estar atento y un ADR de ejemplo. A continuación, en la Sección uno punto siete, vemos la deuda técnica. Nos vemos allí.
Lo que necesitas saber
- Toda elección arquitectónica significativa es un compromiso: mejora algunas cualidades a costa de otras, y hay que encontrar y declarar sus desventajas.
- Una decisión bien formada registra su contexto, las opciones consideradas, los criterios, la decisión con su justificación, las consecuencias y su estado.
- La reversibilidad es la propiedad clave de una decisión: las puertas de doble sentido deben decidirse rápido y localmente; las de un solo sentido, de forma deliberada y con las personas que cargan con las consecuencias.
- El último momento responsable es el punto en el que un retraso eliminaría una opción importante; decidir entonces aprovecha el mayor conocimiento sin dejar que la decisión se tome por omisión.
- Las abstracciones en los límites, las feature flags, la migración incremental y los spikes hacen las decisiones más reversibles, con un costo que solo merece la pena pagar cuando tanto la incertidumbre como el costo de revertir son altos.
- Las matrices de decisión ponderadas y los registros de decisiones de arquitectura hacen visible el razonamiento y lo exponen a cuestionamiento; acuerda los criterios y los pesos antes de puntuar, y comprueba hasta qué punto el resultado depende de ellos.
Todo es un compromiso
Toda elección arquitectónica significativa compra algo renunciando a otra cosa. Dividir un sistema en servicios desplegables de forma independiente compra autonomía de los equipos y escalado independiente, y lo paga con latencia de red, complejidad operativa y una consistencia de datos más difícil. La caché compra velocidad y lo paga con datos desactualizados y lógica de invalidación. Una base de datos gestionada en la nube compra la liberación de parches y copias de seguridad, y lo paga con costo y dependencia de un único proveedor. Mark Richards y Neal Ford ponen esto al principio de Fundamentals of Software Architecture (2020; segunda edición 2025) como su primera ley: Todo en la arquitectura de software es un compromiso.
Un corolario que extraen es que, si crees haber encontrado algo que no es un compromiso, probablemente todavía no has identificado el compromiso.
Su segunda ley es que el porqué es más importante que el cómo. Cualquiera puede mirar un sistema en funcionamiento y ver cómo está construido: tres servicios, un intermediario de mensajes (message broker), una base de datos documental. Lo que no se puede recuperar del código es el porqué: qué alternativas se consideraron, qué inquietudes ganaron, qué riesgos se aceptaron. Sin el porqué, los ingenieros posteriores o bien conservan elecciones que ya no tienen sentido o bien deshacen elecciones cuyas razones siguen vigentes. La segunda edición añade una tercera ley: la mayoría de las decisiones arquitectónicas no son binarias, sino que se sitúan en un espectro entre extremos. Rara vez eliges entre "monolito" y "microservicios"; eliges cuántas unidades desplegables, divididas según qué líneas y compartiendo qué.
Pensar en compromisos es el hábito que más claramente separa el pensamiento arquitectónico del entusiasmo. Cuando alguien propone una tecnología, las preguntas útiles no son "¿es buena?", sino "¿qué cuesta, qué hace más difícil y son aceptables esos costos dadas nuestras inquietudes?". La sección anterior mostró de dónde vienen esas inquietudes.
La anatomía de una decisión
Una decisión arquitectónica es más que su resultado. Una decisión que se puede explicar, revisar y reconsiderar tiene seis partes, y nombrarlas es el primer paso para tomar bien las decisiones.
Contexto: las fuerzas en juego. El problema que se resuelve, los requisitos de atributos de calidad que influyen en él, las restricciones (presupuesto, plazos, normativa, sistemas existentes, habilidades del equipo) y los supuestos que se hacen. Opciones: al menos dos alternativas genuinas, a menudo incluidas "no hacer nada" o "aplazar". Una decisión en la que solo se ha considerado una opción es un anuncio, no una decisión. Criterios: cómo se juzgarán las opciones, derivados de las inquietudes de las partes interesadas y ponderados según su importancia. Decisión y justificación: la opción elegida y, sobre todo, por qué superó a las demás según los criterios. Consecuencias: qué se vuelve más fácil, qué se vuelve más difícil, qué riesgos nuevos aparecen y qué opciones futuras quedan cerradas. Estado: propuesta, aceptada, obsoleta o reemplazada, además de quién tomó la decisión y cuándo.
Las consecuencias merecen una atención especial porque es ahí donde se pone a prueba la honestidad. Toda opción tiene desventajas; ponerlas por escrito protege al equipo de las sorpresas y da a quien tome la siguiente decisión un relato justo. Las consecuencias de una decisión también pasan a formar parte del contexto de la siguiente: una vez que has elegido la mensajería asíncrona, debes decidir cómo tratar los mensajes duplicados y desordenados.
Anatomía de una decisión arquitectónica
Puertas de un solo sentido y puertas de doble sentido
La propiedad individual más útil de una decisión es su reversibilidad: con qué poco costo y con qué seguridad se puede deshacer. En su carta de 2015 a los accionistas de Amazon, Jeff Bezos distinguía las decisiones de Tipo 1, que tienen grandes consecuencias y son irreversibles o casi ("puertas de un solo sentido"), de las decisiones de Tipo 2, que se pueden cambiar y revertir ("puertas de doble sentido"). Las decisiones de Tipo 1 merecen una deliberación lenta y cuidadosa, y consultas. Las decisiones de Tipo 2 deben tomarlas rápido personas o grupos pequeños con buen criterio, porque si resultan equivocadas puedes volver a cruzar la puerta. Su advertencia era que las grandes organizaciones tienden a aplicar a todo el pesado proceso del Tipo 1, lo que las vuelve lentas y timoratas.
La idea se traslada directamente a la arquitectura. Una puerta de un solo sentido en el software es una decisión que, para deshacerse, exigiría reescribir grandes partes del sistema, migrar grandes cantidades de datos, renegociar contratos o volver a formar a muchas personas: el lenguaje de programación principal de una base de código grande, el modelo de datos de un sistema de registro (system of record), la API pública con la que se integran cientos de socios, un compromiso de nube de varios años. Entre las puertas de doble sentido están la elección de una biblioteca de logging detrás de tu propia interfaz, la estructura interna de un módulo, el ajuste de una caché, o cuál de dos formatos de mensaje equivalentes usar dentro de un servicio.
Dos advertencias. Primero, la reversibilidad es un espectro, no algo binario: la mayoría de las decisiones se sitúan en algún punto entre "trivial de deshacer" e "imposible de deshacer", y el costo de revertir suele crecer a medida que más código, más datos y más personas pasan a depender de la elección. Una decisión que es una puerta de doble sentido en el primer mes puede convertirse en una puerta de un solo sentido hacia el duodécimo. Segundo, a menudo puedes cambiar, mediante el diseño, el tipo de puerta ante el que estás, como muestra más abajo el apartado sobre la reversibilidad.
El momento: el último momento responsable
¿Cuándo debe tomarse una decisión? Mary y Tom Poppendieck, en Lean Software Development: An Agile Toolkit (2003), popularizaron la idea de decidir en el último momento responsable: el momento en el que no decidir eliminaría una alternativa importante. Antes de ese momento decides con menos información de la que podrías tener; después, la decisión se toma por ti por omisión, normalmente mal.
El principio funciona en los dos sentidos. Desaconseja decidir demasiado pronto: fijar la tecnología de base de datos en la primera semana, antes de entender la forma de los datos y los patrones de acceso, es adivinar. Igualmente desaconseja decidir demasiado tarde. Si el equipo ha empezado a escribir código de persistencia basado en un supuesto no expresado, la decisión ya se ha tomado, solo que no de forma consciente. Si compras necesita seis semanas para aprobar un proveedor de nube, el último momento responsable para esa elección es al menos seis semanas antes de que necesites el entorno.
Los profesionales no se ponen de acuerdo sobre hasta dónde llevar esto. Los críticos señalan que el "último momento responsable" se usa fácilmente mal como licencia para procrastinar, que algunas decisiones (la estructura de los equipos, el lenguaje de programación) dan forma a todo lo que sigue y por eso deben tomarse pronto, y que la indecisión tiene su propio costo: los equipos no pueden trabajar en paralelo sin interfaces acordadas. Los defensores responden que el principio nunca significó "lo más tarde posible", sino "lo más tarde que sea responsable", y que identificar el momento es en sí mismo un acto de planificación. Ambas posturas coinciden en el núcleo práctico: saber qué decisiones están pendientes, saber cuándo debe tomarse cada una y usar el tiempo hasta entonces para aprender.
Decidir demasiado pronto, demasiado tarde y en el momento adecuado
Diseñar para la reversibilidad
La forma más barata de tomar una decisión difícil suele ser convertirla en una más fácil. Varias técnicas reducen el costo de cambiar de opinión más adelante, a cambio de algo de esfuerzo ahora.
Abstracción en el límite. Pon una interfaz estrecha propia entre tu lógica central y una tecnología que podrías sustituir, como un proveedor de pagos, un intermediario de mensajes o la API de un modelo de lenguaje grande. Así, cambiar la tecnología más adelante afecta a un adaptador en lugar de a toda la base de código. La idea se remonta a la ocultación de información de David Parnas (1972) y reaparece en la arquitectura hexagonal (Capítulo 5). Feature flags. Entrega el nuevo comportamiento desactivado, actívalo para una pequeña parte de los usuarios y vuelve a desactivarlo en segundos si se comporta mal; esto convierte los lanzamientos en puertas de doble sentido. Migración incremental. Ejecuta lo antiguo y lo nuevo en paralelo y traslada el tráfico de forma gradual en lugar de cambiar en un solo paso. Spikes y pruebas de concepto. Dedica unos días a construir la parte más arriesgada con una tecnología candidata antes de comprometerte con ella. Salidas contractuales. Prefiere compromisos más cortos, formatos de datos estándar y la posibilidad de exportar tus datos.
Esto es el pensamiento en opciones, tomado de las finanzas: pagas ahora una pequeña prima (un adaptador, una flag, un spike) para comprar el derecho, pero no la obligación, de cambiar de rumbo más adelante. Como cualquier opción, solo merece la pena comprarla cuando la prima es pequeña en relación con el valor de la flexibilidad. Envolver cada biblioteca en una abstracción "por si la cambiamos" es una forma clásica de añadir costo e indirección a cambio de una flexibilidad que nadie usa. Compra opciones sobre las decisiones que son a la vez inciertas y costosas de revertir; para todo lo demás, decide y sigue adelante.
Guía de decisión
Guía de decisión: ¿decidir ahora o aplazar?
Usa esto para cualquier decisión que pueda ser arquitectónicamente significativa. Recorre las preguntas en orden.
- ¿Hay otro trabajo bloqueado, o desaparecerá pronto una opción importante si nadie decide (por ejemplo, un plazo de compras o un equipo que empieza a construir sobre un supuesto)?SíEstás en el último momento responsable. Decide ahora con la información que tienes, registra la decisión y sus supuestos, y fija una fecha para revisarla.NoPasa a la siguiente pregunta.
- ¿La decisión es barata y segura de revertir (una puerta de doble sentido)?SíDecide rápido, en el nivel sensato más bajo (a menudo, el equipo responsable del código), regístrala brevemente y sigue adelante. No pases una semana debatiéndola.NoEs una puerta de un solo sentido. Pasa a la siguiente pregunta.
- ¿Puedes hacerla más reversible con poco costo, por ejemplo con una interfaz alrededor de la tecnología, una feature flag o una vía de migración incremental?SíCompra primero esa opción y luego trata el resto de la decisión como una puerta de doble sentido.NoPasa a la siguiente pregunta.
- ¿Cambiaría la elección la información que puedes obtener de forma realista antes del plazo (un spike, una prueba de carga, una conversación con una parte interesada)?SíAplaza de forma deliberada: nombra la decisión, el responsable, la fecha en la que debe tomarse y el experimento que la informará.NoEsperar más no ayudará. Haz ahora una comparación estructurada (criterios, pesos, opciones), implica a las partes interesadas que cargan con las consecuencias y escribe un registro de decisiones de arquitectura.
Trampas cognitivas
Los arquitectos son humanos, y las decisiones arquitectónicas se toman bajo incertidumbre, presión de tiempo y presión social: condiciones ideales para los sesgos cognitivos. Conocer los más comunes por su nombre hace más fácil detectarlos en uno mismo y cuestionarlos con amabilidad en los demás.
Trampas que distorsionan las decisiones arquitectónicas
| Trampa | Cómo se manifiesta | Contramedida |
|---|---|---|
| Anclaje | La primera opción que se menciona, o la primera estimación que se da, se convierte en el punto de referencia con el que se juzgan todas las demás opciones. | Genera varias opciones de forma independiente antes de discutir ninguna; pide a las personas que anoten sus estimaciones antes de compartirlas. |
| Costo hundido | "Llevamos ocho meses con este framework, no podemos abandonarlo ahora", aunque lo ya gastado está perdido decidas lo que decidas. | Juzga las opciones solo por sus costos y beneficios futuros; pregúntate qué elegirías si empezaras hoy. |
| Pensamiento de grupo | Un equipo cohesionado converge rápido, discrepar parece desleal y nadie expresa la objeción obvia. | Asigna a alguien para que defienda la postura contraria; recoge las opiniones por escrito antes de la reunión; invita a un revisor externo. |
| Desarrollo guiado por el currículum | Se elige una tecnología porque es emocionante aprenderla o queda bien en un currículum, no porque se ajuste al problema. | Exige que cada elección se justifique frente a los criterios acordados; presupuesta por separado el tiempo de aprendizaje. |
| Moda y efecto arrastre | "Todo el mundo se está pasando a X" sustituye al análisis; las charlas de conferencias de empresas muy grandes se aplican a equipos pequeños. | Pregunta qué problema resolvió X a quienes lo adoptaron y si tú tienes ese problema a esa escala. |
| Sesgo de confirmación | Se buscan y se recuerdan las pruebas a favor de la opción preferida; las pruebas en contra se justifican. | Anota de antemano qué resultado te haría cambiar de opinión y después ejecuta el spike o la prueba. |
Ejemplo práctico
Ejemplo práctico: una matriz de decisión ponderada
Una empresa de reparto de comida está construyendo un nuevo servicio de pedidos. Los pedidos implican pagos y nunca deben perderse ni cobrarse dos veces. El equipo de seis personas conoce bien PostgreSQL y no tiene un administrador de bases de datos dedicado. Hay tres opciones sobre la mesa: (A) un servicio gestionado de PostgreSQL de su proveedor de nube, (B) la base de datos documental gestionada y propietaria del proveedor, y (C) PostgreSQL autoalojado en máquinas virtuales. El equipo construye una matriz de decisión ponderada: acuerda criterios y pesos a partir de las inquietudes de las partes interesadas (5 = lo más importante) y después puntúa cada opción de 1 (deficiente) a 5 (excelente).
| Integridad transaccional (peso 5) | A: 5, B: 3, C: 5. Las transacciones de varias filas son centrales para los pedidos y los pagos; el almacén documental las admite con más restricciones. |
|---|---|
| Esfuerzo operativo (peso 4) | A: 4, B: 5, C: 2. Autoalojar significa que los parches, las copias de seguridad y el failover quedan en manos de un equipo sin especialista en bases de datos. |
| Familiaridad del equipo (peso 3) | A: 5, B: 2, C: 4. |
| Costo con la carga prevista (peso 3) | A: 3, B: 4, C: 4. |
| Margen de escalado (peso 2) | A: 3, B: 5, C: 3. El crecimiento previsto es de unas tres veces en dos años, muy por debajo del límite de una sola instancia grande de PostgreSQL. |
| Reversibilidad y dependencia del proveedor (lock-in) (peso 2) | A: 4, B: 2, C: 5. PostgreSQL estándar puede trasladarse entre proveedores; la API propietaria no. |
| Totales ponderados (máximo 95) | A: 25 + 16 + 15 + 9 + 6 + 8 = 79. B: 15 + 20 + 6 + 12 + 10 + 4 = 67. C: 25 + 8 + 12 + 12 + 6 + 10 = 73. |
| Comprobación de sensibilidad | Sube el margen de escalado a peso 5 (como si se esperara un crecimiento de cincuenta veces): A 88, B 82, C 82. Baja el esfuerzo operativo a peso 1 (como si un equipo de plataforma les gestionara las bases de datos): A 67, B 52, C 67, un empate entre A y C. |
| Decisión | Opción A, PostgreSQL gestionado. Gana con los pesos acordados y se mantiene primera o empatada en primer lugar ante cambios plausibles. Consecuencias registradas: una factura mensual más alta que con el autoalojamiento; dependencia de las ventanas de mantenimiento del proveedor; un plan para mantener estándar el esquema y las consultas, de modo que la opción C siga siendo una alternativa. |
Los números no toman la decisión; hacen visible el razonamiento. Quien no esté de acuerdo puede señalar un peso o una puntuación concretos en lugar de discutir sobre el conjunto.
La comprobación de sensibilidad es el paso más informativo: muestra de qué supuestos depende el resultado. Aquí el resultado depende sobre todo de la falta de capacidad del equipo para operar bases de datos.
Las matrices se pueden manipular eligiendo los criterios y los pesos después de conocer la opción preferida. Acuerda los criterios y los pesos antes de puntuar, idealmente con las partes interesadas cuyas inquietudes representan.
Registrar las decisiones: un adelanto de los ADR
La segunda ley dice que el porqué importa más que el cómo, así que el porqué debe ponerse por escrito. El formato ligero más usado es el registro de decisiones de arquitectura (ADR), propuesto por Michael Nygard en una entrada de blog de 2011. Un ADR es un archivo de texto breve, guardado con el código en el control de versiones, que registra una decisión usando la anatomía descrita arriba: título, estado, contexto, decisión y consecuencias. Los ADR nunca se editan para cambiar la historia; una decisión posterior reemplaza a una anterior y enlaza con ella, de modo que el registro cuenta la historia de cómo evolucionó la arquitectura.
El Capítulo 4 trata las plantillas, las herramientas y los hábitos que mantienen útiles los ADR en Registros de decisiones de arquitectura (ADR). El ejemplo de abajo registra la decisión del ejemplo práctico.
ADR 7: Use managed PostgreSQL for the order service
Status: Accepted (2026-10-12)
Context
Orders and payments need multi-row transactions and must never be lost.
The team knows PostgreSQL well and has no database administrator.
Expected growth is about 3x in two years.
Decision
We will use the cloud provider's managed PostgreSQL service.
Consequences
+ Backups, patching and failover are handled by the provider.
+ Standard SQL keeps self-hosting or another provider open as a fallback.
- Monthly cost is about 30% higher than self-hosting at current load.
- Maintenance windows are set by the provider.
Revisit if write volume exceeds what one primary instance can handle.Comprueba lo que has entendido
¿Cuál es la diferencia entre la primera y la segunda ley de Richards y Ford?
La primera dice que toda elección arquitectónica es un compromiso. La segunda dice que el razonamiento detrás de una elección (el porqué) importa más que su implementación (el cómo), porque el porqué no se puede recuperar del código.
Da un ejemplo de puerta de doble sentido y otro de puerta de un solo sentido en una aplicación web típica.
De doble sentido: la biblioteca de logging usada detrás de tu propia interfaz, o el ajuste de caducidad de una caché. De un solo sentido: el modelo de datos de un sistema de registro, o una API pública de la que ya dependen muchos socios.
¿Por qué decidir demasiado pronto puede ser tan perjudicial como decidir demasiado tarde?
Demasiado pronto significa decidir con menos información de la que podrías haber tenido, a menudo adivinando. Demasiado tarde significa que la decisión se toma en la práctica por omisión, mediante supuestos ya incorporados al código o a los planes, o que una opción ha caducado.
¿Qué aporta una comprobación de sensibilidad a una matriz de decisión ponderada?
Muestra si la opción ganadora sigue ganando cuando los pesos o las puntuaciones cambian dentro de rangos plausibles, lo que revela de qué supuestos depende la decisión.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “Estamos discutiendo si adoptar un broker de eventos ahora o más adelante. ¿Cómo sé si es una puerta de un solo sentido y cuándo necesitamos decidir realmente?”