¿Qué es la arquitectura de software? Parte 2
Conclusiones Clave
- Desarrolladores al mando: La arquitectura no debe ser un rol burocrático o un comité aislado, sino una habilidad compartida por el equipo de desarrollo.
- Decisiones vs. Estructura: La arquitectura consiste en capturar decisiones y sus justificaciones (“por qué”), no solo en diagramar la estructura física (“qué”).
- Proceso Empírico: Es una actividad exploratoria continua: proponer hipótesis sobre atributos de calidad (QAR), probarlas con código/experimentos y refinar iterativamente.
1. Decisiones y el “Por Qué”
El código muestra el qué hace el sistema. La arquitectura debe registrar el por qué se tomaron ciertas decisiones, sobre todo los compromisos (trade-offs).
El valor de lo rechazado: Saber qué alternativas se descartaron y por qué es tan valioso como saber cuál funcionó, ya que expone los límites bajo los que se operaba.
2. Habilidades Arquitectónicas Clave (No un Rol)
Cualquier desarrollador que impacte la viabilidad del sistema hace arquitectura. Las habilidades esenciales son:
- Foco en QARs (Quality Attribute Requirements): Priorizar escalabilidad, rendimiento, seguridad y mantenibilidad sobre la funcionalidad inmediata.
- Visión Holística: Abordar el sistema de manera global, mitigando los silos del diseño modular.
- Comprensión del Ciclo de Vida: Diseñar pensando en pruebas, despliegue, mantenimiento y modernización futura.
- Balance de Compromisos: Saber lidiar con atributos de calidad en conflicto y tomar decisiones con criterio de negocio.
- Empirismo: Diseñar experimentos controlados para validar o descartar estándares y herramientas.
- Liderazgo Técnico: Facilitar la discusión constructiva y el consenso técnico.
3. Exploración Continua y Registro
La arquitectura no se define por adelantado; evoluciona mediante hipótesis y validación en código. Al documentar una decisión arquitectónica, es indispensable registrar:
- Reversibilidad: El costo estimado de cambiar o revertir la decisión (ej. migrar de base de datos o reemplazar un framework).
- Restricciones y Supuestos: Límites asumidos en el diseño (ej. “máximo X peticiones concurrentes”).
- Cumplimiento de QARs: Qué se hizo para satisfacer el atributo de calidad y cómo se prueba empíricamente (con enlaces a tests automáticos).
- Opciones Consideradas: Alternativas analizadas y las razones específicas de su descarte.
- Deuda Técnica Asumida: Registrar conscientemente qué atajos o limitaciones se están introduciendo a corto plazo (evitando escenarios históricos como el efecto Y2K).
Figura 1: Relaciones entre QAR, decisión y deuda técnica
Conclusión
La arquitectura de software moderna es un bucle empírico continuo:
- Formar hipótesis para cumplir con atributos de calidad (QAR).
- Experimentar y medir el comportamiento real del sistema.
- Decidir y documentar la justificación (rationales) y la deuda técnica asumida.
- Iterar.