Software Architecture
Explica cómo evaluar una arquitectura mediante escenarios, riesgos, evidencia y métodos como ATAM, evitando revisiones basadas solo en diagramas o preferencias.
Una revisión arquitectónica no busca declarar una solución “correcta”. Busca descubrir riesgos, supuestos y trade-offs antes de que el sistema convierta una decisión débil en una migración costosa o en un incidente.
Evaluar una arquitectura significa comprobar si sus decisiones responden a los drivers prioritarios con riesgos y costos aceptables.
drivers y restricciones
→ escenarios concretos
→ decisiones arquitectónicas
→ evidencia disponible
→ riesgos y trade-offs
→ acciones y seguimientoLa evaluación no se limita al diseño inicial. Debe repetirse cuando cambian el negocio, la escala, la organización, las dependencias o la evidencia operacional.
Los equipos pueden construir una arquitectura coherente internamente y aun así inadecuada para su contexto.
Ejemplos:
La revisión hace visibles supuestos que suelen quedar ocultos en diagramas o preferencias técnicas.
Una decisión arquitectónica puede expresarse como una hipótesis:
Dado este contexto,
si elegimos esta estructura,
entonces obtendremos esta capacidad,
a cambio de estos costos,
y lo comprobaremos mediante esta evidencia.Ejemplo:
Dado que inventario y ventas cambian coordinadamente,
si permanecen dentro de un monolito modular,
entonces podremos conservar transacciones simples
y despliegue único,
a cambio de menor independencia operacional,
y lo comprobaremos mediante límites de módulos y pruebas de concurrencia.La evaluación pregunta si el contexto sigue siendo cierto y si la evidencia confirma el resultado.
La evidencia real puede contradecir supuestos. Prototipos, benchmarks y primeras integraciones permiten ajustar antes de completar el sistema.
La arquitectura puede degradarse aunque no exista un gran proyecto. Incidentes, lead time, dependencias y costos operativos muestran señales.
No solo para corregir el bug inmediato. Un incidente puede revelar límites incorrectos, observabilidad insuficiente o un supuesto inválido.
Objetivos de negocio, atributos de calidad, restricciones y riesgos.
No basta con decir “escalabilidad”. Se necesita un escenario: volumen, crecimiento, operación y medida.
Cada grupo observa riesgos distintos. Excluir operación puede producir una solución imposible de mantener.
La revisión necesita suficiente representación para responder preguntas:
No se exige un conjunto ceremonial de diagramas. Se exige claridad sobre lo que se evalúa.
Cada decisión importante debería mostrar:
Sin alternativas, la revisión no puede saber si la solución fue elegida o simplemente asumida.
Un argumento no respaldado puede ser válido, pero debe reconocerse como supuesto o riesgo.
Una revisión efectiva recorre situaciones concretas.
Ejemplo de modificabilidad:
Cuando se añade un nuevo método de pago,
un equipo debe integrarlo sin modificar el dominio de pedidos,
en menos de una semana
y con despliegue independiente del proveedor anterior.Preguntas:
Ejemplo de resiliencia:
Durante hora pico,
si el proveedor de notificaciones no responde,
las ventas deben confirmarse,
las notificaciones quedar pendientes
y el sistema recuperarlas en menos de 15 minutos.Preguntas:
Los escenarios impiden discutir arquitectura en términos abstractos.
Adecuada para decisiones frecuentes.
Puede realizarse en una o dos sesiones con los responsables relevantes.
Architecture Tradeoff Analysis Method organiza:
Una decisión donde una pequeña variación afecta mucho una cualidad.
Ejemplo: el timeout del proveedor influye directamente en latencia y tasa de error.
Una decisión afecta varias cualidades en direcciones opuestas.
Ejemplo: replicación síncrona mejora durabilidad y puede empeorar latencia o disponibilidad.
No todos los equipos necesitan ejecutar ATAM formalmente. Sus conceptos ayudan a estructurar revisiones ligeras.
Los participantes recorren el sistema y marcan riesgo por componente, flujo o atributo.
Categorías:
Después agrupan y priorizan. La técnica es útil para descubrir conocimiento distribuido, pero necesita escenarios y seguimiento para no quedarse en post-its.
Un spike reduce incertidumbre, no produce automáticamente código de producción.
Debe responder una pregunta:
¿Puede el motor ejecutar esta consulta
con 100 millones de filas
y p95 menor a 300 ms
sin particionamiento distribuido?Define:
Un prototipo feliz con diez registros no reduce el riesgo de escala.
Propuesta: convertir Inventario en microservicio.
Permitir que otro equipo despliegue inventario de forma independiente y escale sus lecturas.
Mantener monolito modular, reforzar boundary y crear una proyección de lectura. Definir señales futuras para extracción: equipo independiente, volumen, despliegues conflictivos y capacidad operativa.
La revisión no “rechaza microservicios”; evita pagarlos antes de que sus beneficios sean necesarios.
Un registro útil contiene:
| Riesgo | Impacto | Probabilidad | Evidencia faltante | Acción | Owner |
|---|---|---|---|---|---|
| Sobreventa remota | Alto | Media | Prueba concurrente | Spike y escenario | Inventario |
| Latencia de proveedor | Media | Alta | Histograma real | Benchmark | Pagos |
No priorices solo por votación. Combina impacto, probabilidad, reversibilidad y costo de aprender.
Una revisión debe producir decisiones y trabajo concreto:
“Arquitectura aprobada” sin condiciones ni seguimiento ofrece poca utilidad.
Se revisa el sistema y sus riesgos, no la capacidad personal de quien diseñó.
Evita defender una única solución como identidad.
Desarrollo, plataforma, seguridad, soporte y producto aportan restricciones reales.
Profundiza en escenarios prioritarios, no en cada detalle.
No fuerces consenso artificial. Documenta decisión, riesgo y quién asume el costo.
Una persona con título de arquitecto no reemplaza evidencia ni ownership de los equipos.
Cuando todo está implementado, la revisión se convierte en aprobación o crítica sin capacidad real de cambio.
Un diagrama limpio puede ocultar fallos, datos y operación.
“Yo usaría otra tecnología” no es un hallazgo sin conexión con drivers.
La arquitectura trabaja con incertidumbre. El resultado puede ser una prueba o decisión reversible, no una respuesta absoluta.
Riesgos sin owner ni fecha reaparecen como incidentes.
Si toda decisión espera un comité, se reduce aprendizaje. Reserva revisión profunda para decisiones costosas y proporciona barandas para el resto.
La evaluación no termina al desplegar.
Señales de que una arquitectura necesita revisión:
Combina revisiones periódicas con evidencia de producción.
Deuda arquitectónica y refactoring explica cómo registrar, priorizar y reducir decisiones estructurales que ya no responden correctamente al contexto.