La arquitectura a lo largo del ciclo de vida: arquitectura inicial, emergente y continua

El viejo debate: ¿inicial o emergente?

Durante la mayor parte de la historia del software, la arquitectura era algo que se hacía al principio. En un proceso secuencial ("en cascada"), primero se recopilaban los requisitos, después se elaboraban y aprobaban una arquitectura y un diseño detallado, y luego se construía el sistema según ese diseño. Esto es el gran diseño inicial (big design up front) (BDUF). Su lógica es sólida en algunos contextos: cuando los requisitos son estables y se entienden bien, cuando los cambios después de la entrega son extremadamente costosos (software de vuelo, dispositivos médicos, sistemas ligados al hardware) o cuando muchos contratistas deben construir partes que encajen entre sí, un diseño minucioso antes de la construcción reduce el riesgo.

Sus debilidades son igual de conocidas. Los requisitos cambian, y un diseño elaborado hecho pronto incorpora supuestos que más tarde resultan erróneos. La retroalimentación del uso real solo llega al final, cuando el cambio es más costoso. Los equipos diseñan para necesidades imaginadas ("puede que necesitemos admitir cinco monedas") y pagan por una flexibilidad que nadie usa. Y los documentos que tardaron meses en aprobarse tienden a seguirse cuando ya han dejado de ser ciertos.

Los métodos ágiles reaccionaron contra esto. Extreme Programming, en particular, defendió el diseño emergente: construir lo más sencillo que funcione para las funcionalidades del momento, mantener el código limpio con refactorización continua y pruebas automatizadas, y dejar que el diseño crezca a la vez que el sistema. Las reglas del diseño simple de Kent Beck y el principio "you aren't gonna need it" (YAGNI, no lo vas a necesitar) expresan la misma idea. El diseño emergente funciona bien dentro de un módulo y en sistemas pequeños donde cada decisión es una puerta de doble sentido. Su debilidad aparece a escala: algunas decisiones (el modelo de datos de un sistema de registro, los límites entre equipos, el modelo de seguridad, la elección entre integración síncrona y asíncrona) son costosas de revertir y dan forma a todo lo que se construye encima. Dejar que surjan solas suele significar que las toma por accidente quien escriba el primer código.

Lo que dice y lo que no dice el Manifiesto Ágil

Uno de los doce principios del Manifiesto Ágil (2001) dice: Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. Se cita a menudo como si significara que los equipos ágiles no necesitan arquitectura ni arquitectos. No dice eso.

Leído con atención, el principio afirma algo sobre quién produce las mejores arquitecturas (las personas que construyen el sistema, organizadas por sí mismas en lugar de dirigidas desde fuera) y sobre cómo (surgen a través del trabajo, en lugar de entregarse terminadas desde arriba). No dice nada de que la arquitectura no sea importante, y el mismo documento contiene otro principio: la atención continua a la excelencia técnica y al buen diseño mejora la agilidad. Un equipo que ignora las decisiones estructurales no está siguiendo el manifiesto; está ignorando la mitad.

Lo que sí descarta el principio es una arquitectura impuesta desde una torre de marfil por personas que no vivirán con sus consecuencias, y una fase en la que la arquitectura se termina y se congela antes de que nadie escriba código. En la práctica, la conciliación más habitual es que la arquitectura se convierte en una actividad continua, compartida dentro del equipo, con un arquitecto (o ingenieros con mentalidad arquitectónica) que actúa como guía, facilitador y custodio de la visión de conjunto, en lugar de como guardián que da o niega el paso.

¿Cuánta arquitectura? El modelo dirigido por riesgos

Si ninguno de los extremos es correcto, ¿cuánto trabajo de arquitectura es suficiente? George Fairbanks dio una de las respuestas más claras en Just Enough Software Architecture: A Risk-Driven Approach (2010). Su modelo dirigido por riesgos dice que el esfuerzo que dedicas a la arquitectura debe ser proporcional al riesgo de fallo. Tiene tres pasos, que se repiten según sea necesario: identificar y priorizar los riesgos (idealmente como escenarios de fallo concretos, por ejemplo "la página de reservas agota el tiempo de espera cuando 5000 pacientes inician sesión a las 8 a. m."); seleccionar y aplicar técnicas que reduzcan esos riesgos (un modelo, un prototipo, una prueba de carga, un análisis, un patrón de diseño); y evaluar la reducción del riesgo, deteniéndose cuando el riesgo restante sea aceptable.

El modelo es eficaz porque ofrece una regla para detenerse. Una herramienta interna sencilla, construida con tecnología conocida y con pocos usuarios, se enfrenta a pocos riesgos arquitectónicos, y puede bastar con un boceto en una pizarra. Una plataforma de pagos que gestiona millones de transacciones, sujeta a regulación, se enfrenta a muchos, y merece un modelado, unos prototipos y una revisión cuidadosos. Un mismo equipo puede aplicar cantidades muy distintas de arquitectura a distintas partes de un mismo sistema. Fairbanks también subraya que el tiempo dedicado a diseñar es tiempo que no se dedica a construir ni a probar, así que diseñar de más es un costo real, no una opción segura por defecto.

La arquitectura intencional y la pista arquitectónica

Las grandes organizaciones se enfrentan a un problema de coordinación que un solo equipo no tiene: decenas de equipos deben construir partes que encajen entre sí. El Scaled Agile Framework (SAFe), un marco para escalar las prácticas ágiles ampliamente adoptado y también ampliamente debatido, describe la arquitectura como un equilibrio entre el diseño emergente dentro de los equipos y la arquitectura intencional: la planificación deliberada, entre equipos, de las estructuras y las pautas que los equipos comparten. Al resultado lo llama pista arquitectónica (architectural runway): el código, los componentes y la infraestructura técnica existentes necesarios para implementar las funcionalidades a corto plazo sin rediseños ni retrasos excesivos. El trabajo para ampliar la pista (por ejemplo, introducir una plataforma de mensajería antes de las funcionalidades que la necesitan) se planifica de forma explícita junto con el trabajo de funcionalidades, y las funcionalidades consumen la pista a medida que la usan.

Descrita de forma neutral, la metáfora de la pista recoge algo que es cierto para cualquier organización: si la infraestructura que necesita una funcionalidad aún no existe, esa funcionalidad será lenta, y construir la infraestructura requiere tiempo de antelación. Los críticos de SAFe sostienen que puede reintroducir una planificación pesada y jerárquica con vocabulario ágil; sus defensores sostienen que cierta coordinación central es inevitable a escala. No necesitas adoptar SAFe para usar la idea: "¿qué cimientos necesitarán las funcionalidades del próximo trimestre y los estamos construyendo a tiempo?" es una buena pregunta para cualquier arquitecto.

Arquitectura continua

Murat Erder y Pierre Pureur, en Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World (2015) y Continuous Architecture in Practice (2021, con Eoin Woods), describen la arquitectura como un flujo continuo de decisiones y no como una fase o un documento. Sus seis principios son: diseñar la arquitectura de productos, no solo soluciones para proyectos; centrarse en los atributos de calidad, no en los requisitos funcionales; retrasar las decisiones de diseño hasta que sean absolutamente necesarias; diseñar la arquitectura para el cambio aprovechando la fuerza de las partes pequeñas y débilmente acopladas; diseñar la arquitectura para construir, probar, desplegar y operar; y organizar los equipos a imagen del diseño del sistema en el que se trabaja.

Dos de esos principios recuerdan secciones anteriores de este capítulo: retrasar las decisiones es el último momento responsable, y organizar los equipos a imagen del sistema es un uso deliberado de la ley de Conway. El énfasis práctico está en que la unidad del trabajo arquitectónico sea la decisión, registrada en el momento en que se toma, y en los ciclos de retroalimentación (pruebas automatizadas, funciones de aptitud, monitorización en producción) que le dicen al equipo si la arquitectura sigue cumpliendo sus objetivos de calidad.

Esqueletos andantes y spikes

Dos técnicas sencillas unen la arquitectura y la entrega desde la primera semana. Un esqueleto andante (walking skeleton), término asociado a Alistair Cockburn, es una implementación diminuta del sistema que realiza una pequeña función de extremo a extremo a través de todos los componentes arquitectónicos principales. En un sistema de reservas de citas de un hospital, podría permitir que un usuario de prueba inicie sesión, vea las franjas horarias libres de una consulta fijada en el código, obtenidas del sistema de administración de pacientes, reserve una y reciba un mensaje de texto, todo desplegado en un entorno similar al de producción a través del pipeline de entrega real. No hace casi nada útil, pero demuestra que las piezas se conectan, que el pipeline funciona y que la arquitectura se puede construir. Cada funcionalidad posterior añade carne a un esqueleto que ya camina.

Un spike (investigación acotada) (otro término de Extreme Programming) es un experimento breve, con un tiempo limitado, para responder a una pregunta o reducir un riesgo: ¿puede la interfaz del PAS gestionar 50 solicitudes por segundo? ¿Cuánto tarda el proveedor de identidad en emitir un token? ¿Puede la biblioteca que hemos elegido generar archivos PDF accesibles? Los spikes suelen desecharse; su resultado es conocimiento, registrado en una decisión. Son la forma más barata de llevar una decisión de las conjeturas a las pruebas antes de su último momento responsable.

Las actividades de arquitectura en un ciclo iterativo

En un proceso iterativo, el trabajo de arquitectura no ocurre una sola vez; se repite en cada ciclo, con una profundidad que se ajusta a los riesgos que tiene delante el equipo. El plan de estudios de iSAQB describe las tareas centrales del arquitecto de una forma que encaja de manera natural en un ciclo así, y El papel del arquitecto las presentó. Aquí están en forma de bucle:

Aclarar los requisitos: encontrar a las partes interesadas y sus inquietudes, precisar los objetivos de calidad y las restricciones, e identificar los riesgos (consulta Partes interesadas e inquietudes). Diseñar las estructuras: tomar o revisar las decisiones significativas, eligiendo estilos y patrones y definiendo límites e interfaces. Comunicar y acordar: explicar las decisiones a las personas que construyen, operan y pagan el sistema, con vistas adecuadas a cada público, y registrarlas. Acompañar la implementación: trabajar con los equipos mientras construyen, responder preguntas, revisar código y ajustar el diseño cuando la realidad se resiste. Evaluar: comprobar que el sistema cumple sus objetivos de calidad, mediante revisiones, pruebas, mediciones en producción y funciones de aptitud automatizadas. Evolucionar: actuar según lo que encontró la evaluación, saldar deuda y adaptarse a los requisitos cambiados, lo que te lleva de nuevo a aclarar los requisitos.

La arquitectura en DevOps y en la entrega continua

La entrega continua, en la que cada cambio se compila, se prueba y se mantiene listo para lanzarse, y DevOps, que une la responsabilidad del desarrollo y de las operaciones, cambian tanto los objetivos de la arquitectura como sus ciclos de retroalimentación.

Cambian los objetivos porque la desplegabilidad, la capacidad de prueba y la operabilidad se convierten en atributos de calidad de primer orden. Un sistema no puede lanzarse muchas veces al día si los componentes deben desplegarse juntos en un orden fijo, si las pruebas necesitan una copia completa de producción o si nadie puede saber, por la monitorización, si un lanzamiento empeoró las cosas. La investigación resumida en Accelerate (Nicole Forsgren, Jez Humble y Gene Kim, 2018) concluyó que una arquitectura débilmente acoplada, que permita a los equipos probar y desplegar sus partes de forma independiente, estaba entre los indicadores más fuertes del rendimiento de la entrega continua. Por tanto, la buena práctica de entrega no solo ayuda a la arquitectura; la arquitectura es una de sus condiciones previas.

Cambian los ciclos de retroalimentación porque el sistema en ejecución se convierte en la revisión de arquitectura más honesta. Las métricas de producción, las trazas y las revisiones de incidentes muestran dónde es débil la arquitectura con mucha más fiabilidad que los diagramas. Las reglas de arquitectura pueden hacerse cumplir como funciones de aptitud automatizadas en el pipeline (Capítulo 11), la infraestructura se define como código y se revisa como el código (Capítulo 10), y técnicas como las feature flags y los lanzamientos canario hacen que muchas decisiones sean baratas de revertir. El papel del arquitecto cambia en consecuencia: menos aprobación de documentos y más modelado de la plataforma, del pipeline y de las barreras de protección que permiten a los equipos tomar buenas decisiones con rapidez.