Lo que la arquitectura de software me lleva a versobre cómo funcionan las sociedades

Después de algunos años trabajando en arquitectura de software, empecé a notar que los principios que usamos para construir sistemas fiables se trasladan sorprendentemente bien a cómo funcionan y fallan las sociedades. Este no es un artículo político, es un artículo sobre sistemas. Probablemente no soy la primera persona en hacer esta comparación, pero cuanto más lo pensaba, más se sostenían los paralelismos, así que quise dejarlo por escrito.

Una sociedad es un sistema distribuido

Piensa en lo que realmente es una sociedad: un gran conjunto de servicios débilmente acoplados, cada uno con su propia responsabilidad. Educación, justicia, medios, mercados, sanidad. Cada uno expone interfaces a los demás y cada uno depende de que los otros funcionen razonablemente bien, incluso cuando nadie lo diseñó explícitamente de esa manera.

Eso es un sistema distribuido, y los sistemas distribuidos tienen modos de fallo bien conocidos. Cuando un servicio se degrada, el estrés se redistribuye hacia sus vecinos. Si la degradación no se detecta y se aísla, se propaga en cascada. Cualquiera que haya recibido una alerta a las 3 de la madrugada porque una única dependencia con mal comportamiento tumbó media plataforma sabe cómo se siente esto, y también sabe que el fallo casi nunca empezó donde saltó la alerta. Lo rastreas hacia atrás una y otra vez y el origen es alguna cosa pequeña que pasó desapercibida durante semanas.

Las sociedades fallan de la misma manera. La descomposición de una institución rara vez se mantiene contenida. Se propaga a través de cada interfaz que esa institución toca, y para cuando es visible en todas partes, encontrar el origen es la mitad del trabajo.

Malos operadores y deuda técnica

En software sabemos que la salud de un sistema no está determinada únicamente por su diseño. Está determinada por las personas que operan dentro de él. Un desarrollador introduce una dependencia frágil o recorta un atajo en la validación, nada se rompe de inmediato, y el daño se acumula silenciosamente hasta que, meses después, aflora como un fallo que nadie puede rastrear.

Hemos construido toda una disciplina en torno a esto: revisión de código, pruebas, documentación, estándares compartidos. Ninguno de estos mecanismos asume que los desarrolladores son perfectos. Asumen lo contrario. Asumen que los errores y las malas prácticas son inevitables y construyen la detección y la corrección dentro del propio proceso.

Creo que esta es la idea clave, y me llevó un tiempo apreciarla. La buena arquitectura no confía en la virtud individual. Diseña asumiendo su ausencia. Cuando aprendí por primera vez sobre toda la ceremonia en torno a las revisiones y las aprobaciones, me pareció burocracia por sí misma. No lo es. Es una admisión sobre la naturaleza humana, formalizada en un proceso.

Las barreras tienen un costo

Aun así, la compensación es real en ambos dominios. Cada salvaguarda añade fricción. Las revisiones obligatorias ralentizan los lanzamientos, la validación estricta añade latencia, las cadenas de aprobación bloquean parches urgentes. Sobredimensiona las barreras y tu sistema se vuelve tan rígido que no puede responder cuando la velocidad realmente importa. Infradimensiónalas y obtienes el fallo opuesto: componentes sin control acumulan influencia sobre todo, y al final tienes un servicio que evitó la revisión durante dos años y ahora es un monolito inmantenible del que depende media plataforma. Nadie lo planeó. Simplemente creció, porque nada lo detuvo.

Los sistemas que sobreviven a largo plazo no son los que tienen más barreras ni los que tienen menos. Son los que pueden ajustarse: apretar donde el riesgo se concentra, aflojar donde la fricción bloquea un cambio necesario. La adaptabilidad supera a cualquier diseño fijo, lo cual es una conclusión incómoda para quienes disfrutamos diseñando cosas.

La observabilidad lo es todo

No puedes arreglar lo que no puedes ver.

Estoy viviendo esto ahora mismo. Actualmente trabajo en un proyecto totalmente nuevo, la primera vez que construyo algo desde cero con las últimas herramientas de IA en el stack, y la parte de la que me he hecho cargo personalmente no es la parte vistosa. Es la observabilidad: métricas, alertas, avisos, dashboards, rutas de escalado. Y honestamente, hasta ahora es lo más importante de todo el proyecto. Con componentes de IA en el bucle, un fallo que pase desapercibido durante mucho tiempo no sería solo un bug, sería catastrófico. Costos, salidas incorrectas, sistemas aguas abajo consumiendo basura. Así que antes de que el producto haga algo impresionante, tiene que poder decirnos cuándo está enfermo. Instrumentamos todo no porque esperemos que el sistema esté sano, sino porque esperamos que no lo esté, y queremos saberlo pronto.

Las sociedades necesitan la misma capa, y su capa de observabilidad está hecha de personas capaces de evaluar información. Verificar una afirmación, rastrearla hasta su fuente, distinguir la señal del ruido. Cuando esa capacidad se erosiona, los fallos pasan desapercibidos y las falsas alarmas ahogan a las reales. Los malos actores aprenden que pueden empujar cambios rotos a producción porque nadie está leyendo los logs.

Por esto he llegado a pensar que las habilidades de razonamiento son infraestructura y no un lujo. Una población que puede evaluar evidencia es un sistema de monitoreo. Una población que no puede es un sistema funcionando a ciegas, y los sistemas ciegos no se degradan con elegancia.

Por qué el software es más fácil

Seré honesto sobre los límites de la analogía. El software es más fácil de razonar porque todo dentro de él es, en última instancia, lógico. Puedes perfilar un cuello de botella, reproducir un bug, revertir un despliegue defectuoso. Las sociedades tienen muchísimas más variables, bucles de retroalimentación que no puedes aislar, y ningún botón de rollback. Tampoco puedes hacer un test A/B de una política en la mitad de un país y comparar dashboards al cabo de un trimestre, aunque admito que una parte de mí desearía poder hacerlo.

Pero creo que esa diferencia apunta hacia la solución en lugar de invalidarla. Cuanto más actúen los participantes de un sistema sobre información verificada en vez de suposiciones sin examinar, más predeciblemente se comporta el sistema, y más fáciles de detectar y corregir se vuelven sus fallos. No necesitas que todos tengan la arquitectura completa en la cabeza. Nadie en mi equipo tiene tampoco nuestra arquitectura completa en la cabeza. Necesitas suficiente razonamiento compartido para que los fallos locales se detecten antes de que se propaguen en cascada.

La conclusión

Diseña para el fallo, no para la virtud. Mantén el acoplamiento débil para que un servicio que falla no arrastre al resto. Haz que las barreras sean ajustables, porque un sistema rígido muere lentamente y uno sin protección muere rápido. E invierte en observabilidad por encima de casi todo lo demás, porque ver un problema pronto vale más que cualquier cantidad de ingenio aplicada tarde.

No inventamos estos principios para el software. Los redescubrimos ahí, bajo condiciones donde la retroalimentación es rápida y el fallo es medible. Los sistemas que perduran son los que están construidos para notar cuándo se están rompiendo. Eso es cierto de la plataforma que estoy instrumentando ahora mismo, y sospecho que es cierto de todo lo demás.

Si trabajas en arquitectura y ves otros paralelismos, o crees que he estirado demasiado la analogía, me gustaría escucharlo.