Qué encuentra realmente una revisión de arquitectura

Se suele dar por hecho que una revisión de arquitectura es una auditoría de código con un nombre más elegante. No lo es. Una auditoría de código mira cómo están escritas las cosas. Una revisión de arquitectura mira cómo están dispuestas, y si esa disposición puede cargar el peso que el negocio está por ponerle encima.

La distinción importa porque los problemas de software más caros casi nunca son por líneas de código malas. Son por decisiones tomadas temprano, bajo incertidumbre, que en silencio dejaron de encajar a medida que la empresa creció. Una revisión existe para encontrar esas decisiones mientras todavía son baratas de cambiar.

Dónde se rompe el sistema primero

Todo sistema tiene un punto más débil bajo carga. La mayoría de los equipos no ven el suyo con claridad, porque están demasiado cerca y porque nada lo ha forzado a fallar todavía.

Una revisión traza los caminos que cargan más tráfico y más riesgo, y descubre dónde se va a amontonar la presión a medida que crezca el volumen. Rara vez es la parte que preocupa al equipo. Suele ser una base de datos compartida, una llamada síncrona que debería ser asíncrona, o un servicio que en silencio hace tres trabajos que deberían haberse separado hace rato. Nombrar ese primer punto de fallo es muchas veces lo más valioso que produce todo el ejercicio.

Las decisiones que ya no encajan

La arquitectura temprana se construye para la empresa que eres en ese momento: chica, incierta, optimizando para la velocidad. Esa es la elección correcta al principio. El problema es que esas decisiones rara vez se revisan a propósito. Se revisan cuando algo se rompe.

Una revisión saca a la luz las elecciones que tenían sentido a una escala y se volvieron pasivos en la siguiente: el monolito que ahora debería tener una costura, el modelo de datos que asumía volúmenes que hace rato superaste, la integración que iba a ser temporal y ahora es estructural. Ninguna es un fracaso. Son la deuda natural del crecimiento, pero solo si las encuentras a propósito.

La brecha entre el diagrama y el sistema

Casi todo equipo tiene una arquitectura en la cabeza distinta de la que realmente está corriendo. La documentación se desactualiza. Los parches se calcifican. Un servicio que se suponía sin estado, en silencio, empezó a guardar estado.

Buena parte de una revisión es simplemente establecer qué es verdad de verdad: mapear el sistema real, no el que pensabas construir. La brecha entre los dos es de donde vienen los incidentes, y cerrarla suele ser esclarecedor para el propio equipo. Es común que una revisión le diga a un equipo cosas sobre su propio sistema que nadie había dicho nunca en voz alta.

Puntos únicos de fallo

Algunos riesgos son estructurales: un componente sin redundancia, un paso de despliegue manual que solo funciona porque una persona recuerda la secuencia, una dependencia de terceros sin alternativa. Rara vez dan problemas hasta el día en que dan uno muy grande.

Una revisión los inventaría a propósito, porque son invisibles durante la operación normal y catastróficos durante la anormal, y el día anormal siempre termina llegando.

Lo que no es

Una revisión de arquitectura no va a reescribir tu sistema, y una buena no lo va a intentar. No te va a entregar una lista de doscientos problemas triviales, y no va a recomendar reconstruir cosas que funcionan bien. Desconfía de cualquier revisión que lo haga. El volumen no es criterio.

El resultado de una revisión útil es corto y priorizado: esto es lo que te va a doler primero, esto es lo que cuesta resolverlo, esto es lo que puedes dejar tranquilo. El valor está en el criterio sobre lo que importa, no en lo larga que sea la lista.

Cuándo conviene hacerla

El mejor momento para una revisión de arquitectura es antes de un momento de presión, no durante. Antes de un gran lanzamiento. Antes de una ronda que va a exigir que el sistema escale. Antes de incorporar una oleada de usuarios nuevos. Antes de comprometer un año de roadmap sobre una base que nadie examinó.

El peor momento es en mitad de un incidente, cuando el costo de cada decisión sin examinar se cobra de golpe. Una revisión es, en el fondo, una forma de adelantar ese ajuste de cuentas: enfrentar las preguntas difíciles en un día tranquilo, con las opciones todavía abiertas, en lugar de en el peor día, sin ninguna.

Si tu sistema está por cargar más de lo que cargó nunca, ese es justo el momento en que una mirada clara e independiente se paga sola.