Arquitecturas Ágiles
Los que nos dedicamos a la construcción de software a menudo nos topamos con el siguiente dilema:
¿Cómo conciliamos la necesidad de contar con una arquitectura sólida al arrancar un proyecto con el concepto de arquitectura emergente propuesto por las metodologías ágiles?
A simple vista parece una contradicción. En uno de los extremos están las metodologías pesadas que señalan que la arquitectura debe ser diseñada up front y descripta en pesadísimos documentos–que nadie lee. Esto en muchos casos degenera en parálisis del análisis. En el otro extremo se encuentran las metodologías ágiles que sugieren que la arquitectura se descubre durante el desarrollo, evolutivamente, y además señalan que no debe producirse documentación.
Veamos qué factores influyen en la elección de la arquitectura de un sistema (al margen del enfoque elegido):
- Consideraciones funcionales y no funcionales (performance, seguridad, escalabilidad)
- Restricciones sobre la tecnología (a veces viene impuesta), políticas internas, uso de licencias
- Herramientas, tecnologías, frameworks
- Principios, buenas prácticas
- Casos complejos y riesgosos que requieren pruebas de concepto y prototipos (exploración de nuevas tecnologías)
Está claro que los factores de la lista afectan y determinan la arquitectura. Son aspectos que no cambian ni pueden refactorizarse durante el desarrollo, pues impactan profundamente el diseño y la implementación de todo el sistema. Si el objetivo es implementar un sistema que funcione correctamente, todos los aspectos de la lista deberían estar definidos antes de comenzar a construir la solución.
Se desprenden entonces que la arquitectura no puede simplemente emerger durante el desarrollo. ¿Podríamos dejar pasar 4 sprints antes de considerar cómo gestionaremos la seguridad? ¿Aplazar hasta el final la medición del rendimiento?
Y sin embargo, debemos ser ágiles!
Simon Brown sugiere en su presentación The frustrated architect que es inviable sacar adelante el proyecto sin tener la arquitectura definida antes de comenzar a implementar y da una pista de cómo resolver el dilema: alcanza con definir aquello que es suficiente e imprescindible:
- Tener claro cómo los elementos más significativos encajan entre sí.
- Mitigar los riesgos haciendo pruebas de concepto y prototipos
- Proporcionar las bases y la visión para avanzar
- Producir solamente la documentación necesaria–pero no dejar de producirla!
La conclusión es que la definición de la arquitectura antecede a la fase de implementación del sistema. Pero no estamos hablando de hacer un gran diseño up front, sino simplemente de recolectar la información suficiente para evaluar las mejores opciones y establecer las bases para levantar el resto del proyecto–y esto no debería llevarnos más que un par de días.
