Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 11.1 de 11.8 · Avanzado · 28 min de lectura
Evaluación de la arquitectura y el ATAM
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
Toda arquitectura es una apuesta. Esta lección muestra cómo comprobar esa apuesta antes de comprometer el dinero, con el Architecture Tradeoff Analysis Method, o ATAM.
Antes de que una ciudad construya un puente nuevo, ingenieros independientes revisan el diseño. Preguntan qué pasa en una inundación, en una tormenta y con los camiones más pesados. Señalan dónde una decisión que ahorra dinero agrava otro peligro. No rediseñan el puente ni le ponen nota. Dicen a los propietarios dónde están los riesgos reales, mientras los cambios todavía son baratos. La evaluación de la arquitectura hace lo mismo con el software.
Una evaluación plantea una pregunta concreta y práctica: dado lo que este sistema debe lograr, ¿cuáles de sus decisiones arquitectónicas ponen en riesgo esos objetivos? Trabaja sobre decisiones, no sobre código, así que puede empezar con un diseño en una pizarra. Es más valiosa antes de un compromiso importante, como un contrato con un proveedor o una migración a la nube. Si se hace demasiado tarde, de sus hallazgos solo cabe lamentarse.
El ATAM lo describieron en 2000 Rick Kazman, Mark Klein y Paul Clements, del Software Engineering Institute, o SEI. Lo dirige un equipo de evaluación de tres a cinco personas ajenas al proyecto. La independencia importa: los evaluadores que diseñaron el sistema encuentran menos riesgos. Trabajan con los responsables de las decisiones, como el arquitecto y el patrocinador, y con un grupo más amplio de partes interesadas, desde los desarrolladores hasta operaciones, seguridad y soporte. El ATAM no da ninguna puntuación ni ninguna nota de aprobado. Encuentra dónde las decisiones ponen en riesgo los objetivos de negocio y dónde obligan a hacer compromisos entre cualidades.
El método se desarrolla en cuatro fases, con nueve pasos repartidos en dos reuniones de evaluación. En la fase cero, durante unas semanas, los líderes acuerdan el alcance, el costo y el equipo, y reúnen los documentos de arquitectura. La fase uno lleva aproximadamente un día con los responsables de las decisiones. Los pasos uno a seis presentan el método, los impulsores de negocio y la arquitectura, y luego construyen el árbol de utilidad y analizan. Tras una pausa de dos a tres semanas, la fase dos incorpora a las demás partes interesadas durante unos dos días. Generan y votan sus propios escenarios, que después se analizan. La fase tres es aproximadamente una semana de seguimiento: el informe final, con los temas de riesgo convertidos en elementos del backlog y registros de decisiones.
El núcleo del método es el análisis. Los evaluadores toman los escenarios priorizados y los enfoques arquitectónicos que responden a ellos. Piden al arquitecto que recorra cada escenario a través del diseño, y lo examinan a fondo. ¿Cuántas llamadas síncronas hay en esta ruta? ¿Qué ocurre cuando falla ese nodo? Cada respuesta se clasifica. Un riesgo es una decisión, o la falta de una decisión, que puede impedir que se cumpla un objetivo importante. Un no riesgo es una decisión sólida, registrada con sus supuestos. Un punto de sensibilidad es una propiedad de la que depende de forma crítica una cualidad. Un punto de compromiso es un punto de sensibilidad para más de una cualidad, de modo que mejorar una empeora otra. Los riesgos y los puntos de compromiso se agrupan en temas de riesgo, cada uno con una causa de fondo común. Y cada tema nombra los impulsores de negocio a los que amenaza, los mismos impulsores que definieron los escenarios.
Este es un ATAM resumido de la plataforma de reparto de comida, con cuatro mil restaurantes y nueve mil repartidores. El negocio quiere pasar de cincuenta a cien pedidos por segundo en el pico del viernes en un plazo de dieciocho meses. La latencia de los pedidos debe mantenerse por debajo de tres segundos en el percentil noventa y nueve, pero solo el proveedor de pagos ya tarda dos segundos y medio. Según la ley de Little, eso supone doscientas cincuenta solicitudes en curso para doscientos workers. Riesgo R1. Cuando el proveedor agota el tiempo de espera, el diseño actual hace fallar el pedido: riesgo R2. Autorizar más tarde, desde una cola, ayudaría, pero entonces algunos pedidos aceptados fallarían en el pago. Ese es el punto de compromiso T1. No todo es un riesgo. El outbox, Kafka con tres réplicas y los consumidores idempotentes garantizan que no se pierdan pedidos: no riesgo N1, con su supuesto registrado. En la fase dos, las partes interesadas votaron mucho un escenario que faltaba en el árbol: una tableta de restaurante sin conexión durante diez minutos en el pico debe recibir igualmente todos los pedidos. Riesgo R5, un punto ciego. Los riesgos se agrupan en dos temas: terceros en rutas críticas síncronas, y garantías de recuperación y de entrega que van por detrás de la disponibilidad prometida a las cadenas de restaurantes.
Un ATAM completo es caro: en la ilustración aproximada del curso, unos sesenta días de tiempo de las personas. Para un sistema cuyo fallo costaría millones, es un seguro barato. Para un equipo pequeño es desproporcionado, así que ajusta el método a lo que está en juego. Un ATAM reducido puede completarse en un día o menos. Los hallazgos que no se convierten en registros de decisiones, elementos del backlog y funciones de aptitud con responsables se olvidan en un trimestre.
La sección completa expone los nueve pasos y cómo el Cost Benefit Analysis Method pone el dinero sobre la mesa. A continuación, en la sección once punto dos, veremos las revisiones ligeras y el risk-storming. Nos vemos allí.
Lo que necesitas saber
- La evaluación de la arquitectura comprueba si las decisiones significativas de un sistema le permitirán cumplir sus objetivos de negocio y sus requisitos de calidad, y es más valiosa antes de compromisos importantes o irreversibles.
- El ATAM (Kazman, Klein y Clements, SEI, 2000) sigue nueve pasos repartidos entre la preparación, dos reuniones de evaluación y el seguimiento, con un equipo de evaluación independiente, los responsables de las decisiones del proyecto y un grupo más amplio de partes interesadas.
- Sus resultados son riesgos, no riesgos (con sus supuestos), puntos de sensibilidad, puntos de compromiso y temas de riesgo vinculados a los impulsores de negocio a los que amenazan; no otorga una nota de aprobado.
- El árbol de utilidad que construyen los responsables de las decisiones en el paso 5 se compara con los escenarios que las partes interesadas generan y votan en el paso 7, y las diferencias entre ambos revelan puntos ciegos.
- El CBAM se basa en el ATAM: pondera la utilidad que cada estrategia arquitectónica añade a los escenarios priorizados y la divide por su costo para comparar el valor obtenido por costo, aunque las restricciones pueden seguir imponiéndose a esa proporción.
- Un ATAM completo cuesta decenas de días-persona, así que el método debe ajustarse a lo que está en juego, y sus hallazgos deben convertirse en registros de decisiones, elementos del backlog y funciones de aptitud con responsables.
Por qué evaluar una arquitectura
Toda arquitectura es una apuesta. Cuando un equipo elige un intermediario de eventos, una base de datos por servicio o una sola región de nube, está prediciendo que esas decisiones darán el rendimiento, la disponibilidad, la seguridad y el costo que necesita el negocio. La Sección 1.3 mostró por qué importan esas apuestas: el costo de cambiar una decisión estructural crece con todo lo que se construye encima, y algunos de los fallos más caros del software fueron fallos de organización de las piezas más que de líneas de código concretas. La evaluación de la arquitectura es el acto deliberado de comprobar la apuesta antes de gastar el dinero, o mientras se gasta.
Una evaluación plantea una pregunta concreta y práctica: dado lo que este sistema debe lograr, ¿cuáles de sus decisiones arquitectónicas ponen en riesgo esos objetivos? No es una revisión de código, ni un concurso de belleza entre estilos, ni una auditoría de la calidad de la documentación. Trabaja sobre las decisiones y sus consecuencias para los atributos de calidad, así que puede hacerse mucho antes de que exista código, sobre un diseño en una pizarra o un conjunto de registros de decisiones, y puede repetirse en un sistema que lleva años funcionando.
La evaluación también tiene beneficios más allá de los hallazgos. Las partes interesadas que rara vez se reúnen (responsables de producto, operaciones, seguridad, finanzas, desarrolladores) tienen que ponerse de acuerdo sobre lo que más importa, lo que a menudo saca a la luz supuestos contradictorios. El arquitecto tiene que explicar el diseño con la claridad suficiente para que personas externas puedan examinarlo, lo que mejora la documentación. Y la organización obtiene un registro de los riesgos conocidos que ha decidido aceptar, algo muy distinto de los riesgos que nadie advirtió.
Cuándo evaluar
El mejor momento para evaluar es cuando ya se ha decidido lo suficiente para que la evaluación tenga algo que examinar, pero antes de que esas decisiones resulten caras de revertir. En la práctica hay varios momentos naturales, y las organizaciones maduras aplican a cada uno una evaluación de distinto peso.
Momentos para evaluar
| Desencadenante | Qué se comprueba | Peso habitual |
|---|---|---|
| Existe una arquitectura candidata, antes de construir a gran escala | Si los estilos y las tácticas principales pueden cumplir los escenarios de calidad priorizados | ATAM completo o reducido para sistemas grandes o de larga vida; si no, una revisión ligera |
| Antes de un compromiso importante | Un contrato con un proveedor, una migración a la nube, una compuerta de financiación o una decisión de cambio de plataforma que sería costoso deshacer | Formal, a menudo con evaluadores externos, porque la decisión es una puerta de un solo sentido |
| Cambio significativo en los impulsores de negocio | Nuevos mercados, una fusión, un objetivo de crecimiento por diez, nueva normativa | Rehacer el árbol de utilidad y analizar los escenarios que cambiaron |
| Cambios acumulados y deriva | Si el sistema tal como está construido sigue correspondiendo a la arquitectura prevista y a sus razones | Revisión ligera periódica más funciones de aptitud automatizadas |
| Adquisición o due diligence | Si un sistema existente puede sostener los planes del comprador | Evaluación con tiempo limitado de un sistema existente, a menudo combinada con análisis de código |
| Después de un incidente grave | Si el incidente reveló una debilidad arquitectónica y no un defecto aislado | Análisis centrado en los escenarios afectados |
Evaluar demasiado pronto desperdicia esfuerzo en decisiones que todavía no son reales; evaluar demasiado tarde convierte los hallazgos en lamentos. Aquí también sirve una regla útil del modelo dirigido por riesgos de Fairbanks (Sección 1.8): invierte en evaluación en proporción al riesgo. Una herramienta interna de dos equipos no necesita un taller de dos días; una plataforma nacional de pagos, sí.
El ATAM: orígenes, propósito y participantes
El Architecture Tradeoff Analysis Method (ATAM) es el método de evaluación más conocido. Rick Kazman, Mark Klein y Paul Clements, del Software Engineering Institute (SEI) de la Carnegie Mellon University, lo describieron en el informe técnico ATAM: Method for Architecture Evaluation (CMU/SEI-2000-TR-004, agosto de 2000). Surgió del anterior Software Architecture Analysis Method (SAAM), que Kazman y sus colegas publicaron en 1994 y que se centraba sobre todo en la modificabilidad. El ATAM también se describe en Software Architecture in Practice, de Bass, Clements y Kazman, que va ya por su cuarta edición (2021).
Su propósito se malinterpreta a menudo. El ATAM no da a una arquitectura una puntuación ni una nota de aprobado, y no demuestra que un sistema vaya a cumplir sus requisitos. Identifica dónde las decisiones arquitectónicas ponen en riesgo los objetivos de negocio y dónde obligan a hacer compromisos entre cualidades, para que las personas responsables puedan decidir qué hacer. El nombre del método destaca los compromisos porque la mayoría de los riesgos interesantes están donde una cualidad se consigue a costa de otra.
Participan tres grupos. El equipo de evaluación, normalmente de tres a cinco personas ajenas al proyecto, dirige el método: un jefe de equipo, un líder de evaluación que facilita, secretarios que recogen los escenarios y el desarrollo de las sesiones, y preguntadores expertos en cualidades concretas. Los responsables de las decisiones del proyecto son el arquitecto, el jefe de proyecto o de producto y el patrocinador o cliente que puede actuar sobre los hallazgos. Las partes interesadas en la arquitectura son todos los demás que tienen algo en juego: desarrolladores, testers, operaciones, seguridad, integradores, soporte y representantes de los usuarios. La independencia importa: los evaluadores que diseñaron el sistema, o que dependen del arquitecto, encuentran menos riesgos.
Las fases del ATAM
Los nueve pasos
- 1. Presentar el ATAMEl líder de evaluación explica el método, los roles de los participantes y los resultados, para que nadie confunda la sesión con una auditoría o con una revisión de diseño de su trabajo personal.
- 2. Presentar los impulsores de negocioUn representante sénior del negocio explica los objetivos del sistema, las restricciones, las partes interesadas y las cualidades que más importan, en términos de negocio. Estos impulsores de negocio (business drivers) son la vara de medir de todo lo que viene después.
- 3. Presentar la arquitecturaEl arquitecto describe la arquitectura con el nivel de detalle adecuado: contexto, estructuras principales, comportamiento en tiempo de ejecución, despliegue y cómo responde a los impulsores. Un límite de tiempo habitual de aproximadamente una hora obliga a centrarse.
- 4. Identificar los enfoques arquitectónicosEl arquitecto nombra los enfoques arquitectónicos en uso (estilos, patrones y tácticas como un broker, la replicación o la caché) y el equipo de evaluación los cataloga, sin analizarlos todavía.
- 5. Generar el árbol de utilidad de atributos de calidadLos responsables de las decisiones construyen o refinan un árbol de utilidad y valoran cada escenario hoja según su importancia para el negocio y su dificultad técnica.
- 6. Analizar los enfoques arquitectónicosPara los escenarios de mayor prioridad, los evaluadores preguntan qué enfoques responden a cada uno y los examinan con preguntas específicas de cada cualidad, registrando riesgos, no riesgos, puntos de sensibilidad y puntos de compromiso.
- 7. Generar y priorizar escenariosEn la fase 2, el grupo más amplio de partes interesadas propone sus propios escenarios y los vota. El resultado se compara con el árbol de utilidad; los escenarios importantes que faltan en el árbol son un hallazgo en sí mismos.
- 8. Volver a analizar los enfoques arquitectónicosLos escenarios nuevos mejor clasificados se analizan del mismo modo que en el paso 6, ahora con el conocimiento de las partes interesadas presentes en la sala.
- 9. Presentar los resultadosEl equipo de evaluación presenta los enfoques, los escenarios, el árbol de utilidad, los riesgos, los no riesgos, los puntos de sensibilidad, los puntos de compromiso y los temas de riesgo, y relaciona cada tema con los impulsores de negocio a los que amenaza.
El vocabulario del análisis
El núcleo del método son los pasos 6 y 8. Para cada escenario importante, los evaluadores piden al arquitecto que explique paso a paso cómo responde la arquitectura, y la examinan con preguntas extraídas de cada cualidad: ¿cuántas llamadas síncronas hay en esta ruta?, ¿qué ocurre con las solicitudes en curso cuando falla ese nodo?, ¿dónde se guarda esta credencial?, ¿qué limita la cola? Cada respuesta se clasifica con cinco conceptos que se han convertido en vocabulario habitual mucho más allá del propio ATAM.
Los resultados del análisis
| Resultado | Significado | Ejemplo de una plataforma de reparto de comida |
|---|---|---|
| Riesgo | Una decisión, o la falta de una decisión, que puede impedir que se cumpla un escenario importante o un objetivo de negocio | La autorización de la tarjeta está dentro de la ruta síncrona del pedido, así que un proveedor de pagos lento ralentiza todos los pedidos |
| No riesgo | Una decisión que se considera sólida para el escenario, registrada junto con los supuestos de los que depende | La bandeja de salida transaccional y los consumidores idempotentes cumplen el escenario de no perder pedidos, suponiendo que el broker replique cada partición tres veces |
| Punto de sensibilidad | Una propiedad de los componentes o las conexiones que es crítica para la respuesta de una cualidad | La latencia de los pedidos es sensible al número de saltos síncronos y al tiempo de respuesta p99 del proveedor |
| Punto de compromiso | Una propiedad que es un punto de sensibilidad para más de una cualidad, de modo que mejorar una empeora otra | El intervalo de actualización de la ubicación del repartidor: acortarlo mejora la actualidad del mapa, pero agota las baterías de los teléfonos y aumenta el costo de los datos móviles y de la ingesta |
| Tema de riesgo | Un grupo de riesgos con una causa de fondo común, vinculado a los impulsores de negocio a los que amenaza | Los servicios de terceros están en rutas críticas síncronas, lo que amenaza el objetivo de duplicar el volumen de pedidos sin perder conversiones |
Cómo produce el análisis sus resultados
Los no riesgos merecen más atención de la que suelen recibir. Registrar que una decisión es sólida gracias a un supuesto concreto (tres réplicas, un tiempo de respuesta contractual de un proveedor, un tráfico por debajo de cierto nivel) convierte una vaga tranquilidad en algo que se puede comprobar más adelante. Cuando el supuesto cambia, el no riesgo pasa a ser un riesgo candidato. Los puntos de sensibilidad y de compromiso son igual de valiosos después de la evaluación: indican a los futuros mantenedores qué parámetros deben cambiar con cuidado, y son lugares naturales para las comprobaciones automatizadas descritas en la Sección 11.3.
Otra mirada al árbol de utilidad
La Sección 2.8 presentó el árbol de utilidad como herramienta para priorizar los requisitos de calidad. Nació en el ATAM, y dentro del método desempeña dos papeles distintos. En el paso 5, los responsables de las decisiones construyen el árbol de arriba abajo: la utilidad, luego los atributos de calidad, luego los refinamientos y luego los escenarios concretos valorados (importancia para el negocio, dificultad técnica). Las hojas (H,H) se convierten en el orden del día del paso 6, porque son las que más importan y las más difíciles de lograr, así que es ahí donde es más probable que se escondan los riesgos.
En el paso 7, el grupo más amplio de partes interesadas genera escenarios de abajo arriba y los vota, de forma muy parecida a un Quality Attribute Workshop. Comparar las dos visiones es uno de los momentos más reveladores de una evaluación. Si los escenarios principales de las partes interesadas ya aparecen en el árbol, los responsables de las decisiones entienden el propósito de su sistema. Si falta un escenario que recibe muchos votos, por ejemplo un escenario de operaciones sobre tabletas de restaurantes que se quedan sin conexión, los responsables de las decisiones tienen un punto ciego, y puede que la arquitectura también. Esos escenarios se añaden al árbol y se analizan en el paso 8.
Ejemplo práctico
Ejemplo práctico: un ATAM resumido de la plataforma de reparto de comida
La plataforma de los Capítulos 2 y 4 conecta a los clientes, 4000 restaurantes y 9000 repartidores. Los impulsores de negocio son duplicar el volumen de pedidos en 18 meses (de 50 a 100 pedidos por segundo en el pico del viernes) sin perder conversiones, y captar cadenas nacionales de restaurantes que exigen una disponibilidad contractual. La arquitectura: microservicios por contexto delimitado (pedidos, restaurantes, despacho, notificaciones), cada uno con su propia base de datos PostgreSQL; un API gateway; REST síncrono para hacer pedidos, incluida la autorización de la tarjeta con un proveedor de pagos externo; un broker Kafka con una bandeja de salida transaccional para los eventos de pedidos; las posiciones de los repartidores se envían cada 4 segundos y se guardan en Redis; una sola región de nube con tres zonas de disponibilidad, con copias de seguridad nocturnas copiadas en una segunda región. El árbol de utilidad de la fase 1 reutilizó los seis escenarios de la Sección 2.8.
| Latencia de los pedidos (H,H) | p95 por debajo de 1.5 s y p99 por debajo de 3 s con 100 pedidos/s. Enfoques: gateway, cuatro saltos síncronos, autorización de la tarjeta dentro de la solicitud. Latencia medida del proveedor: p95 de 900 ms, p99 de 2.5 s |
|---|---|
| Análisis | El proveedor por sí solo consume la mayor parte del presupuesto de p99 y deja 500 ms para cuatro saltos y las escrituras en la base de datos. Según la ley de Little (Sección 2.4), 100 pedidos/s a 2.5 s suponen 250 solicitudes en curso; el pool de 200 workers del servicio de pedidos se satura cada vez que el proveedor se ralentiza. Riesgo R1; punto de sensibilidad S1: número de saltos síncronos y p99 del proveedor |
| Disponibilidad del pago (H,H) | El proveedor de pagos agota el tiempo de espera en el pico: pedidos aceptados y puestos en cola, ninguno perdido, cliente informado en 10 s. El diseño actual hace fallar el pedido cuando la autorización agota el tiempo de espera. Riesgo R2 |
| Opción planteada | Autorizar de forma asíncrona: aceptar el pedido como pendiente y autorizarlo desde una cola. Mejora la latencia y la disponibilidad, pero algunos pedidos aceptados fallan después en el pago y los restaurantes no deben cocinar pedidos sin pagar. Punto de compromiso T1: en qué punto del flujo del pedido se confirma el pago |
| No perder pedidos (parte de H,H) | Outbox en la misma transacción local que el pedido, Kafka con tres réplicas, consumidores idempotentes. No riesgo N1, suponiendo un factor de replicación de 3 y confirmaciones del productor de todas las réplicas sincronizadas |
| Fallo de región (H,M) | RTO de 15 min, RPO de 1 min. Las copias de seguridad nocturnas dan un RPO de hasta 24 horas y una restauración que se mide en horas. Riesgo R3 |
| Actualidad del seguimiento (M,M) | La posición en el mapa nunca tiene más de 5 s de antigüedad. 9000 repartidores cada 4 s son 2250 escrituras/s, algo cómodo para Redis. Punto de compromiso T2: el intervalo de actualización (actualidad frente a batería, datos y costo) |
| Robo de cuentas (H,M) | La limitación de tasa (rate limiting) por dirección IP en el gateway no detecta el relleno de credenciales (credential stuffing) repartido entre miles de direcciones. Riesgo R4 |
| Generación de escenarios de la fase 2 | Las partes interesadas de restaurantes y de operaciones votaron mucho un escenario que faltaba en el árbol: una tableta de restaurante sin conexión durante 10 minutos en el pico debe recibir todos los pedidos al reconectarse. Las notificaciones push se envían una sola vez y sin confirmación de recepción. Riesgo R5, y un punto ciego en el árbol |
| Temas de riesgo | Tema A (R1, R2, R4): las dependencias de terceros y del perímetro están en rutas críticas síncronas sin aislamiento; amenaza duplicar el volumen sin perder conversiones. Tema B (R3, R5): las garantías de recuperación y de entrega van por detrás de la disponibilidad que se promete a las cadenas de restaurantes; amenaza los contratos con las cadenas |
| Qué pasó después | Registros de decisiones para la autorización asíncrona con un estado pendiente (aceptando T1, y avisando a los restaurantes solo después de la autorización), una región de reserva en caliente (warm standby), la entrega de pedidos con confirmación de recepción a las tabletas y la detección del relleno de credenciales en el proveedor de identidad. Los supuestos de N1 se convirtieron en una comprobación automatizada de la configuración |
Los hallazgos tratan de decisiones, no de personas ni de calidad del código, y cada uno puede rastrearse hasta un escenario y un impulsor de negocio.
Dos de los cinco riesgos salieron de escenarios que el arquitecto no había priorizado o no había tenido en cuenta, y por eso existe el paso de las partes interesadas.
Los puntos de compromiso no son problemas que haya que eliminar: T1 se aceptó deliberadamente y quedó registrado, con sus consecuencias para los restaurantes y los clientes.
CBAM: poner el dinero sobre la mesa
El ATAM te dice dónde están los riesgos; no te dice qué correcciones merece la pena pagar. El Cost Benefit Analysis Method (CBAM), desarrollado en el SEI por Rick Kazman, Jai Asundi y Mark Klein (publicado por primera vez en 2001), se basa en los escenarios de un ATAM para construir esa justificación económica.
A grandes rasgos, las partes interesadas toman los escenarios priorizados y asignan una utilidad (en una escala de 0 a 100) a varios niveles de respuesta de cada uno: el peor caso, el actual, el deseado y el mejor caso. Los arquitectos proponen estrategias arquitectónicas y estiman la respuesta que lograría cada una. La utilidad que gana cada estrategia se lee en la curva de utilidad-respuesta del escenario y se pondera por la prioridad del escenario; sumada en todos los escenarios, es el beneficio de la estrategia. Al dividir el beneficio por el costo se obtiene una relación valor-costo (VFC), y las estrategias se eligen por orden de VFC dentro del presupuesto disponible y luego se contrastan con la intuición y las restricciones.
Un CBAM en miniatura para el riesgo de fallo de región
| Estrategia | Respuesta esperada | Ganancia de utilidad x peso | Costo anual | Valor por costo |
|---|---|---|---|---|
| Actual: copias de seguridad nocturnas | RTO de unas 6 h, RPO de hasta 24 h | utilidad 10 (referencia) | ya pagado | n/a |
| A: región de reserva en caliente, replicación asíncrona de la base de datos | RTO de 10 min, RPO por debajo de 1 min | (90 - 10) x 0.3 = 24 | £180k | 24 / 180 = 0.13 |
| B: pilot light (datos replicados, cómputo que se arranca bajo demanda) | RTO de 40 min, RPO por debajo de 1 min | (60 - 10) x 0.3 = 15 | £70k | 15 / 70 = 0.21 |
La estrategia B da más beneficio por libra, pero no cumple el tiempo de recuperación de 15 minutos que exigen los contratos con los restaurantes. Los números informan la decisión; no la toman. El verdadero valor del CBAM es que obliga a hacer estimaciones explícitas y comparables del beneficio y del costo, y deja ver cuándo debe decidir una restricción y no una proporción. Su debilidad es que las utilidades y los costos son juicios de valor; los equipos deberían variarlos y ver si cambia la clasificación, exactamente como recomienda la Sección 1.6 para las matrices de decisión ponderadas. La Sección 11.8 muestra cómo convertir esas estimaciones en una justificación económica.
Costos y aspectos prácticos
Un ATAM completo es caro en tiempo de las personas. A modo de ilustración aproximada: un equipo de evaluación de cuatro personas que dedica dos días cada una a la preparación (8 días-persona), una fase 1 de un día con tres responsables de las decisiones (7), una fase 2 de dos días a la que se suman diez partes interesadas (34) y una semana de seguimiento a cargo de dos personas (10) suman unos 60 días-persona, antes de que nadie corrija nada. Para un sistema cuyo fallo costaría millones, o que va a funcionar durante una década, es un seguro barato. Para un equipo de producto pequeño, es desproporcionado.
Varias prácticas hacen que las evaluaciones merezcan la pena. Ajusta el método: Bass, Clements y Kazman describen una evaluación ligera de la arquitectura, un ATAM reducido para equipos internos que puede completarse en un día o menos, y algunas organizaciones solo hacen los pasos 2 a 6 con un puñado de personas. Prepárate bien: la mayor parte del costo de una mala evaluación se va en descubrir, ya en la sala, que nadie sabe describir la arquitectura. Mantén a los evaluadores independientes pero informados. Acuerda de antemano quién es responsable de los hallazgos y cómo se les dará seguimiento, idealmente como registros de decisiones y elementos del backlog con responsables. Y repite: los hallazgos son una instantánea, y los riesgos cambian a medida que cambian el sistema y el negocio.
Los profesionales no se ponen de acuerdo sobre el lugar que ocupa hoy el método. Sus críticos lo ven como un artefacto pesado de los grandes proyectos con diseño previo, que encaja mal con equipos que despliegan muchas veces al día. Sus defensores responden que los conceptos (escenarios, puntos de sensibilidad y de compromiso, temas de riesgo) son justo lo que les falta a los equipos ágiles cuando se saltan la evaluación, y que el método se puede reducir. Ambos tienen parte de razón: la ceremonia completa conviene a sistemas de alto riesgo y larga vida y a compromisos importantes, mientras que el vocabulario y el hábito de preguntar a partir de escenarios son útiles en todas partes. La Sección 11.2 trata el extremo más ligero.
Preguntas frecuentes
¿Se puede aplicar el ATAM a un sistema que ya existe?
Sí. Los pasos son los mismos; la arquitectura se reconstruye a partir de la documentación, el código y las personas que operan el sistema, y las mediciones del sistema en producción sustituyen a las estimaciones. Evaluar un sistema existente es habitual antes de una ampliación importante, una migración o una adquisición.
¿Un ATAM sin hallazgos graves significa que el sistema cumplirá sus requisitos?
No. El ATAM examina una muestra de escenarios al nivel de las decisiones de diseño. Reduce la probabilidad de sorpresas desagradables, pero no puede sustituir a la medición, las pruebas y la experiencia operativa. Sus hallazgos deberían convertirse en pruebas y funciones de aptitud siempre que sea posible.
¿Quién debería presentar la arquitectura?
El arquitecto o el ingeniero principal que mejor la conoce. El trabajo del equipo de evaluación es hacer preguntas, no presentar, y el trabajo del arquitecto es explicar y explorar, no defenderse.
Comprueba lo que has entendido
¿Qué diferencia hay entre un punto de sensibilidad y un punto de compromiso?
Un punto de sensibilidad es una propiedad crítica para la respuesta de una cualidad. Un punto de compromiso es una propiedad que es un punto de sensibilidad para varias cualidades a la vez, de modo que cambiarla favorece a una y perjudica a otra.
¿Por qué registra el ATAM los no riesgos y qué debe registrarse junto con ellos?
Para mostrar qué decisiones se examinaron y se consideraron sólidas. También deben registrarse los supuestos de los que dependen, para poder volver a examinar el no riesgo si un supuesto cambia.
¿Qué significa que las partes interesadas voten mucho en la fase 2 un escenario que falta en el árbol de utilidad?
Que los responsables de las decisiones tienen un punto ciego sobre lo que importa, y puede que la arquitectura no responda a ese escenario. Se añade al árbol y se analiza en el paso 8.
En el CBAM, ¿cómo se calcula el valor por costo de una estrategia?
Su beneficio, la utilidad ponderada por prioridad que añade en los escenarios a los que afecta, se divide por su costo.
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 a punto de firmar un contrato de tres años con un proveedor de nube para nuestra plataforma de pagos. ¿Cómo haría un ATAM reducido en dos días para encontrar primero los mayores riesgos arquitectónicos?”