Qué encuentra realmente una revisión de arquitectura

Se suele asumir 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á a punto de 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 silenciosamente 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 romperá 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 cerca de él 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, e identifica dónde se concentrará 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 silenciosamente hace tres trabajos que deberían haberse separado hace tiempo. Nombrar el primer punto de fallo es a menudo el resultado más valioso de todo el ejercicio.

Las decisiones que ya no encajan

La arquitectura temprana se construye para la empresa que eres en ese momento — pequeña, incierta, optimizando para la velocidad. Esa es la elección correcta al principio. El problema es que esas decisiones rara vez se revisan de forma deliberada. Se revisan solo cuando algo se rompe.

Una revisión saca a la luz las elecciones que tenían sentido a una escala y se han convertido silenciosamente en pasivos a la siguiente: el monolito que ahora debería tener una costura, el modelo de datos que asumía volúmenes que ya has superado, la integración que iba a ser temporal y se volvió 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 que difiere de la que realmente está corriendo. La documentación se desactualiza. Los parches se calcifican. Un servicio que se suponía sin estado silenciosamente empezó a guardar estado.

Una parte importante de una revisión es simplemente establecer qué es verdad realmente — mapear el sistema real, no el pretendido. La brecha entre ambos es de donde vienen los incidentes, y cerrarla suele ser esclarecedor para el propio equipo. Es común que una revisión de arquitectura le diga a un equipo cosas sobre su propio sistema que nadie había dicho 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 causan problemas hasta el día en que causan uno muy grande.

Una revisión los inventaría de forma deliberada, porque son invisibles durante la operación normal y catastróficos durante la operación anormal — y el día anormal siempre acaba llegando.

Lo que no es

Una revisión de arquitectura no va a reescribir tu sistema, y una buena no lo intentará. No producirá una lista de doscientos problemas triviales, y no recomendará reconstruir cosas que funcionan. 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 la longitud de 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 uno. Antes de un gran lanzamiento. Antes de una ronda de financiación que exigirá que el sistema escale. Antes de incorporar una oleada de nuevos usuarios. Antes de comprometer un año de roadmap sobre una base que nadie ha examinado.

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 — de enfrentar las preguntas en un día tranquilo, con opciones todavía abiertas, en lugar de en el peor día, sin ninguna.

Si tu sistema está a punto de cargar más de lo que nunca ha cargado, ese es exactamente el momento en que una mirada clara e independiente se paga sola.