Relación entre la PA y Spikes

La relación entre las pruebas de arquitectura y los spikes funciona en ambas direcciones:

Los spikes informan a la arquitectura: Los resultados de un spike pueden influir directamente en las decisiones arquitectónicas y, por lo tanto, en lo que se evaluará durante las pruebas de arquitectura.
- Por ejemplo, un spike para determinar qué base de datos NoSQL es más adecuada para ciertos patrones de acceso producirá resultados que deberían validarse como parte de las pruebas arquitectónicas.
Las pruebas de arquitectura pueden identificar la necesidad de spikes: Durante la evaluación arquitectónica, pueden surgir áreas de incertidumbre o riesgo que requieren más investigación, lo que lleva a la creación de nuevos spikes.

Los spikes son particularmente relevantes para las pruebas de arquitectura porque:

Ayudan a validar supuestos arquitectónicos antes de comprometerse completamente con una decisión.
Permiten explorar alternativas tecnológicas y sus implicaciones en la arquitectura.
Proporcionan datos empíricos para respaldar decisiones arquitectónicas.
Reducen el riesgo de fallos arquitectónicos en etapas posteriores del proyecto.

Una buena práctica es documentar formalmente los resultados de los spikes e incluirlos como parte de la documentación arquitectónica que será evaluada durante las pruebas de arquitectura.

Es una buena práctica resolver los items identificados como spikes junto con la prueba de arquitectura, especialmente en las etapas iniciales del proyecto. Esta aproximación ofrece varios beneficios importantes:

Reducción temprana de incertidumbre: Al resolver los spikes identificados durante o antes de las pruebas de arquitectura, se eliminan importantes áreas de riesgo cuando aún es relativamente económico hacer cambios.
Toma de decisiones basada en evidencia: Los spikes proporcionan datos empíricos que permiten tomar decisiones arquitectónicas más fundamentadas, en lugar de basarse en suposiciones o preferencias personales.
Validación de conceptos clave: Permiten validar que los componentes críticos de la arquitectura funcionarán como se espera antes de invertir en su implementación completa.
Mejor estimación: Al resolver las incertidumbres técnicas, los equipos pueden proporcionar estimaciones más precisas para el resto del proyecto.
Detección temprana de limitaciones: Pueden revelar limitaciones de tecnologías o enfoques que podrían haber causado problemas significativos más adelante.

Es importante tener un proceso para:

Priorizar qué spikes deben resolverse primero (generalmente aquellos con mayor impacto o riesgo)
Documentar formalmente los resultados y las decisiones tomadas
Incorporar lo aprendido en la arquitectura

Aunque nuevos spikes surgirán inevitablemente durante el proyecto, resolver los iniciales establece una base arquitectónica más sólida y reduce significativamente el nivel general de riesgo del proyecto. Esto proporciona al equipo mayor confianza para avanzar con la implementación.

Existen varias fuentes de documentación y referencias que apoyan la práctica de resolver spikes tempranamente junto con las pruebas de arquitectura para reducir la incertidumbre del proyecto:

"Software Architecture in Practice" (Bass, Clements, Kazman): Este libro de referencia del SEI (Software Engineering Institute) habla sobre la importancia de las pruebas de concepto (similar a los spikes) para validar decisiones arquitectónicas clave antes de comprometerse con una arquitectura completa.
Guías del SAFe (Scaled Agile Framework): En su documentación sobre "Architectural Runway" y "Enablers", SAFe recomienda explícitamente el uso de spikes arquitectónicos tempranos para reducir el riesgo técnico antes de que comience el trabajo de implementación principal.
"Agile Software Architecture" (Babar, Brown, Mistrik): Aborda la relación entre la arquitectura y la agilidad, enfatizando la importancia de la exploración temprana y la validación mediante actividades tipo spike.
"Risk-Driven Design" por George Fairbanks: Este enfoque promueve el uso de actividades exploratorias (similares a los spikes) para mitigar los riesgos arquitectónicos en etapas tempranas.
Documentación del Scrum Guide y prácticas XP (Extreme Programming): Ambas metodologías reconocen el valor de las actividades exploratorias tempranas para reducir la incertidumbre técnica.
"Just Enough Software Architecture" (George Fairbanks): Discute el uso de la experimentación temprana para validar decisiones de diseño arquitectónico.
TOGAF (The Open Group Architecture Framework): En su fase preliminar y de visión arquitectónica, enfatiza la necesidad de identificar y abordar riesgos e incertidumbres técnicas tempranas.
Publicaciones del SEI sobre ATAM (Architecture Tradeoff Analysis Method): Estas publicaciones recomiendan probar conceptos de alto riesgo temprano en el ciclo de vida del proyecto.

Estas fuentes coinciden en que la resolución temprana de incertidumbres técnicas mediante actividades exploratorias como los spikes es una práctica fundamental para establecer una arquitectura sólida y reducir el riesgo global del proyecto.