Cada excepción se convierte en arquitectura

La excepción iba a durar un trimestre. Dos años después sigue en marcha, otros tres sistemas dependen de ella y el único ingeniero que entendía por qué se concedió ya no está en la empresa.

Suele empezar así. Un equipo tiene que conectar a un nuevo socio logístico antes de una fecha de lanzamiento. El estándar dice que los datos de los socios entran por la plataforma de integración, que los valida, deja constancia de cada entrega y avisa a alguien cuando una falla. La plataforma todavía no lee el formato de archivo de este socio, e incorporarlo llevará tres meses que el lanzamiento no tiene. Así que el equipo pide una excepción: un pequeño script en un único servidor que recoge cada noche el archivo del socio y lo escribe directamente en la base de datos de pedidos, con una contraseña exenta de la rotación habitual, porque cambiarla rompería el script. Todos están de acuerdo en que es razonable. Todos coinciden en que es temporal.

El lanzamiento sale bien y la presión se va a otra parte. Seis meses después, la plataforma ya lee el nuevo formato, pero nadie migra el script: funciona, y quienes lo pidieron están ocupados. Finanzas empieza a conciliar facturas contra la tabla que el script alimenta. Un segundo socio se conecta «igual que el primero», porque esa ruta ya existe. El sistema operativo del servidor se acerca al fin de su soporte. El ingeniero que escribió el script cambia de trabajo. Nadie decidió nunca que el script formara parte de la arquitectura; sencillamente, nunca dejó de estar ahí.

La historia es hipotética, pero cualquiera que haya operado sistemas en producción tiene su propia versión. Y deja ver algo que las organizaciones rara vez dicen en voz alta: la arquitectura que de verdad operas no es solo lo que decidiste diseñar. Es ese diseño más cada excepción que aprobaste y nunca volviste a revisar.

Qué es, en realidad, una excepción

Un estándar es una decisión que se toma una vez para no tener que tomarla cada vez. «Todos los datos de socios pasan por la plataforma de integración» resuelve de antemano cómo se validan los datos, a quién se avisa cuando algo falla y cómo se recupera una entrega defectuosa. El pipeline de despliegue, las reglas de monitoreo, las tecnologías aprobadas: cada uno es una pregunta respondida una sola vez, para que cualquier equipo pueda apoyarse en la respuesta sin reabrirla.

Una excepción es el permiso para saltarse una de esas respuestas, en un caso y por un motivo. Puede tratarse de saltarse el pipeline para una corrección urgente, de operar una base de datos que el equipo de plataforma no soporta o de abrir una ruta de red que el modelo de seguridad normalmente prohíbe. La solicitud casi siempre llega como un asunto local y pasajero, y así se aprueba.

Piensa en una casa antigua con una viga del sótano que empezó a ceder. Alguien coloca debajo un poste de acero «por ahora», hasta que haya dinero para cambiar la viga. Pasan los años. Arriba se remodela la cocina, y una isla de granito, pesadísima, queda justo encima de ese poste. Cuando un nuevo dueño quiere despejar el sótano, el contratista no pregunta por qué está ahí el poste, sino qué pasará al quitarlo. Nadie diseñó la cocina para apoyarse en él, pero ahora se apoya. Eso significa que algo es estructural: si lo retiras, lo que está encima se mueve.

Las excepciones se vuelven estructurales de la misma manera, no por decisión de nadie, sino porque otras cosas se construyen encima mientras nadie mira.

La aprobación dura un momento; la obligación, no

Aprobar una excepción parece un hecho puntual: alguien revisa la solicitud, sopesa el riesgo inmediato, dice que sí y el ticket se cierra. Pero en ese momento empiezan cuatro cosas que no se cierran con él.

La primera es una ruta que debe seguir funcionando. El script necesita ahora un servidor, parches de seguridad, una credencial y alguien que note cuando falla, y las herramientas estándar que habrían cubierto todo eso no llegan hasta él. La segunda es una dependencia. Todo lo que puede observarse termina usándose: en cuanto el script llena una tabla, alguien la consulta, y la excepción gana usuarios que quien la aprobó nunca conoció. En ingeniería de software el patrón general tiene nombre, la ley de Hyrum: con suficientes usuarios, cada comportamiento observable de un sistema terminará siendo una dependencia para alguien, prometa lo que prometa su documentación. La tercera es un precedente, que el próximo equipo con una fecha límite va a invocar. La cuarta es un conocimiento que vive en una o dos cabezas, porque la documentación describe la ruta estándar y la excepción, por definición, queda fuera de ella.

La solicitud rara vez deja ver nada de esto. Pide una sola cosa, por poco tiempo. Los compromisos aparecen después y no vencen cuando vence la justificación original. La plataforma aprendió a leer el formato del socio y el motivo de la excepción desapareció; la excepción siguió ahí.

Por eso las excepciones describen un sistema con tanta precisión. Un diagrama muestra la arquitectura prevista; la lista de excepciones aprobadas, la que está en marcha: el despliegue manual, el servicio sin monitoreo, la conexión directa a la base de datos. A partir de cierto punto, esa lista es el mejor documento de arquitectura.

La factura llega después, y la paga otro

Las excepciones parecen baratas al aprobarlas porque el beneficio es inmediato, mientras que el costo queda diferido y repartido a lo largo de años, en fragmentos tan pequeños que nadie los suma.

Cada excepción necesita sus propias pruebas, porque ya no sigue la ruta que cubren las pruebas estándar. El monitoreo tiene que extenderse hasta ella o se convierte en un punto ciego: el script nocturno que falla en silencio se descubre cuando finanzas encuentra una semana de facturas faltantes. Las preguntas de soporte se concentran en las pocas personas que entienden la desviación, y el conocimiento local se vuelve un punto único de falla. La recuperación se complica, porque el procedimiento describe la ruta normal y no la especial. Y cada revisión de seguridad señala la contraseña que nunca cambia, hasta que alguien renueva otra vez la dispensa.

Hay, además, una asimetría entre quien decide y quien paga. Quien aprueba una excepción suele llevarse la recompensa visible: el lanzamiento salió, el bloqueo se resolvió. Quienes la cargan son los operadores, los ingenieros de guardia de madrugada, el próximo equipo que toque el sistema y los auditores, a menudo años después y en otra parte de la organización. La factura rara vez lleva el nombre de quien aprobó. Un proceso de aprobación que nunca pregunta por el costo futuro no es neutral: está construido para inclinarse hacia el sí.

El costo más alto es el precedente, y también el más fácil de pasar por alto. «Si a ellos se lo permitieron, ¿por qué a nosotros no?» es una pregunta difícil de responder después de la primera aprobación. El segundo socio entra por el script nocturno porque la ruta ya existe y negarse parecería arbitrario. El estándar se erosiona mediante comparaciones que, una por una, suenan justas. Nadie lo abandona de manera formal. La organización concede la misma desviación tantas veces que la desviación pasa a ser lo normal, y el estándar, aquello que hay que defender.

Por qué nadie la retira

Si las excepciones cuestan tanto, ¿por qué sobreviven? Porque conservar una no cuesta nada visible este trimestre, y retirarla cuesta un proyecto.

Para retirar el script, alguien tiene que encontrar todo lo que depende de él, y esas dependencias nunca se registraron, porque se suponía que la excepción no tendría ninguna. Alguien tiene que llevar los datos a la ruta estándar, probar el cambio contra la conciliación de finanzas y programarlo. Ese trabajo compite con las nuevas funcionalidades, y su éxito es invisible por diseño: si sale bien, nada cambia para nadie. Su fracaso, en cambio, se notaría muchísimo. Para quien decide esta semana, dejarlo en paz siempre parece lo más seguro.

El tiempo lo empeora. Cuando se van quienes la concedieron, el motivo se desdibuja, y da miedo tocar un componente que nadie sabe explicar. Cuanto más tiempo lleva en marcha una excepción, más la protege la misma ignorancia que la volvía riesgosa. «Temporal» termina describiendo la intención, no la duración.

No toda desviación es un error

Sería equivocado, y poco práctico, tratar toda desviación como una falla. Una arquitectura seria tiene que responder a condiciones que el estándar no anticipó. Una regulación propia de un mercado, una restricción de rendimiento que alguien midió de verdad o un sistema heredado en una adquisición pueden justificar otra ruta. Negar toda excepción no produce una arquitectura pura, sino equipos que la rodean sin pedir permiso y las mismas desviaciones sin registro alguno.

El problema no es que existan desviaciones, sino que la mayoría nunca recibe un estado. Se conceden como una cosa y luego derivan, sin que nadie las examine, hacia otra. Una desviación puede estar, con honestidad, en uno de tres estados, y hay un cuarto al que llega por omisión.

Marco práctico

Los cuatro estados de una desviación

Toda desviación de un estándar está en uno de estos estados, lo haya dicho alguien o no:

1. Excepción temporal. Una desviación acotada, con un responsable identificado, una fecha de vencimiento y condiciones explícitas para volver al estándar. La organización sabe de qué se apartó y cuándo debe regresar.
2. Deuda técnica. Un compromiso conocido que dificulta cambios u operaciones futuras, reconocido como tal y con una decisión explícita sobre si pagarlo y cuándo. Nadie espera que desaparezca por sí solo, ni finge que lo hará.
3. Capacidad deliberada. Una desviación que atiende una necesidad duradera y se incorporó al estándar: se diseña, financia, monitorea, documenta y soporta como todo lo demás. A esas alturas ya no es una excepción; el estándar creció para incluirla.
4. Arquitectura no reconocida. Una desviación cuyo vencimiento pasó sin que nadie decidiera nada. Continúa en marcha, acumula dependencias y en todas partes se la sigue llamando temporal. Nadie eligió este estado: es adonde va a parar toda excepción cuando nadie elige por ella.

Los tres primeros son legítimos. El cuarto es el tema de este artículo, y solo se sale de él con una decisión.

El momento decisivo es la fecha de revisión. Cuando una excepción llega a ella, hay cuatro salidas honestas: retirarla, renovarla con evidencia nueva de que el motivo sigue vigente, reclasificarla como deuda con un plan financiado o convertirla en una capacidad con soporte formal. Dejar que continúe sin ninguna de ellas es una quinta salida, y no es neutral: lleva la excepción al cuarto estado.

Aplícalo al script nocturno. Cuando la plataforma aprendió a leer el formato del socio, el motivo desapareció y la salida honesta era retirarlo. Si el equipo de plataforma hubiera decidido no soportar nunca ese formato, el script debía haberse promovido, con monitoreo adecuado, una contraseña que cambie según lo previsto, un responsable con nombre y un lugar en el diagrama de arquitectura. Cualquiera de las dos habría sido defendible; lo que ocurrió en realidad, nada, era la única que no.

Difíciles de olvidar, no difíciles de obtener

Si las excepciones van a convertirse en arquitectura de todos modos, la única elección real es si lo harán de manera deliberada. En la práctica, cada aprobación debería dejar constancia de unas pocas cosas, en un lugar donde la próxima persona de verdad vaya a buscar: quién responde por ella, es decir, la persona o el equipo que la operará y algún día la retirará, que no siempre es quien la pidió; qué cubre, qué deja fuera a propósito y por qué el estándar no encaja; cuánto costará mantenerla en pruebas, monitoreo, soporte y recuperación, para que la decisión se tome con el precio a la vista; cuándo se revisará; y qué le permitiría volver al estándar.

Tres prácticas evitan que todo esto termine en formularios que nadie lee: la primera es registrar las excepciones donde ya viven las decisiones de arquitectura. Una excepción es una decisión con consecuencias, como cualquier otra que el equipo registra, y su lugar está junto al estándar del que se aparta, no en un ticket cerrado. La segunda es darle dientes a la fecha de revisión. Si pasa sin una decisión, lo normal debería ser devolver el caso a quien la aprobó, no renovarla en silencio; un vencimiento que nadie hace cumplir es apenas una fecha optimista. La tercera es tratar las excepciones abiertas como un presupuesto, con un tope aproximado y una revisión periódica. Al llegar al tope, una excepción nueva debería obligar a retirar una vieja, en lugar de engrosar una lista que solo crece.

Nada de esto dificulta obtener una excepción, ni debería. Un equipo con una fecha límite real y un motivo real tiene que seguir recibiendo un sí rápido. La meta es que ninguna excepción pueda olvidarse, porque la arquitectura de una organización no es solo lo que dibuja. También es lo que permite una y otra vez, hasta que la concesión se vuelve estructura.

Así que empieza por una. Busca la excepción más antigua que siga en marcha, esa que todos llaman temporal. Pregunta quién responde hoy por ella, cuánto cuesta mantenerla, qué depende de ella y cuándo decidió alguien conservarla por última vez. Si nadie sabe responder, ya no es una excepción: es parte de tu arquitectura, y alguien debería decidirlo a propósito.

Notas de fuentes

Estas fuentes respaldan el tratamiento de las decisiones de arquitectura, la deuda técnica y las dependencias no previstas. La integración con el socio logístico y el poste del sótano son ejemplos hipotéticos. El modelo de los cuatro estados y la asimetría de costos entre quien aprueba y quien opera son una síntesis de este artículo y no se atribuyen a ninguna fuente.

• Registrar una decisión junto con sus consecuencias. Nygard propone el registro de decisiones de arquitectura como un relato breve y duradero del contexto, la decisión y sus consecuencias. Respalda registrar las excepciones junto a los estándares de los que se apartan. Fuente: Michael Nygard, «Documenting Architecture Decisions», 2011.
• La deuda técnica como decisión gestionada. El Software Engineering Institute trata la deuda técnica como un conjunto gestionado de decisiones de diseño o implementación que afectan la entrega futura, no como sinónimo de toda decisión fuera del estándar. Fuente: Software Engineering Institute, «Managing Technical Debt».
• Todo comportamiento observable atrae dependencias. Hyrum Wright observa que, con suficientes usuarios de una interfaz, cada comportamiento observable de un sistema terminará siendo una dependencia para alguien, más allá de lo que prometa su contrato. Fuente: Hyrum’s Law.