Gobierno de la capa intermedia: qué lógica debe vivir en el middleware

En la mayoría de las operaciones TI chilenas, el middleware no se diseña: se acumula. Cada integración nueva deja algo ahí —una transformación, una regla condicional, un enriquecimiento de datos, un mapeo de campos— y nadie decide explícitamente que ese sea su lugar. Años después, la capa intermedia contiene lógica de negocio que no está versionada como código, no se prueba como software y no tiene dueño claro. Cuando algo falla, el diagnóstico empieza por la aplicación o por la base de datos, porque en el middleware "solo pasa el tráfico".

Ese supuesto es el problema. La capa intermedia no falla por ser middleware: falla porque nadie definió qué debería vivir en ella y qué no. Este artículo no repite qué es el middleware ni cómo fluye un request entre aplicaciones, APIs y bases de datos. Asume que esa capa ya opera en tu arquitectura y aborda una pregunta distinta: cómo gobernar qué lógica reside en el middleware, cómo versionarla y probarla, y quién decide sus límites.

El problema del middleware sin gobierno

Cuando no existe una definición explícita de responsabilidades, la capa intermedia se convierte en el lugar donde se resuelve todo lo que no cabe en otro lado. Un sistema destino no expone el campo que se necesita: se transforma en el middleware. Una regla de negocio cambia con frecuencia y tocar la aplicación implica un release completo: se mueve al middleware. Un formato propietario debe convivir con uno estándar: se traduce en el middleware.

Cada decisión individual es razonable. El resultado agregado no lo es: la capa intermedia acumula lógica que debería estar versionada, probada y con dueño, pero que en la práctica vive como configuración opaca. Las consecuencias operacionales son concretas y ya conocidas por quien opera estos sistemas: latencia que no se puede atribuir a ningún componente, errores de integración que aparecen tras un cambio aparentemente no relacionado, y una dificultad creciente para responder qué hace exactamente la capa intermedia con un mensaje dado.

El síntoma visible suele ser la inestabilidad. La causa, casi siempre, es la ausencia de gobierno sobre qué vive en esa capa.

Qué debería vivir en el middleware y qué no

No existe una regla universal, pero sí un criterio útil: el middleware debe mediar entre contratos, no implementar reglas de negocio. La mediación es infraestructura; la regla de negocio es dominio. Confundirlas es lo que produce el acoplamiento que después nadie puede deshacer.

Vive razonablemente en la capa intermedia:

• Traducción de protocolos y formatos. SOAP a REST, colas a HTTP, formatos propietarios a JSON. Es mediación pura, sin conocimiento del dominio.
• Enrutamiento y resolución de destino. Decidir a qué sistema va un mensaje según criterios técnicos o de configuración estable.
• Políticas transversales. Autenticación, autorización, límites de tasa, trazabilidad, cifrado en tránsito. Aplican a todos los flujos por igual y no pertenecen a ningún sistema en particular.
• Control de flujo. Timeouts, reintentos con backoff, circuit breakers, límites de concurrencia. Son decisiones operacionales, no de negocio.

No debería vivir ahí, aunque sea técnicamente posible:

• Reglas de negocio con vigencia y dueño funcional. Si cambia por decisión de un área de negocio, su lugar es el sistema que la posee, no la capa de integración.
• Transformaciones que dependen de estado o de datos históricos. Convierten al middleware en un sistema con estado, con todo lo que eso implica en disponibilidad y consistencia.
• Cálculos, validaciones de dominio o enriquecimiento con lógica condicional compleja. Son código de aplicación disfrazado de configuración.
• Orquestación de procesos de negocio extensos. Requieren visibilidad, reintentos con compensación y trazabilidad que la capa intermedia rara vez ofrece de forma nativa.

La frontera no siempre es nítida, y ahí está el valor del gobierno: alguien debe decidir caso a caso, con criterio explícito, en lugar de dejar que la acumulación decida por defecto.

Versionado y pruebas: tratar la lógica del middleware como código

Si una transformación, una regla de enrutamiento o una política condicional vive en el middleware, debe cumplir los mismos estándares que cualquier otro artefacto de software. Esto implica cuatro prácticas mínimas:

Control de versiones. Cada cambio en la lógica de la capa intermedia debe quedar registrado con autor, fecha y motivo. La configuración que solo existe en la consola de administración no es auditable ni reversible con confianza.

Ambientes separados. La lógica que se prueba en desarrollo no debería promoverse a producción sin pasar por un ambiente intermedio que reproduzca las condiciones reales de integración. Promover configuración directamente entre ambientes es una fuente recurrente de incidentes.

Pruebas de contrato. Cada interfaz que el middleware media debería tener pruebas que verifiquen que el contrato se respeta en ambos extremos. Cuando un sistema cambia su esquema, la prueba de contrato falla antes que el incidente en producción.

Revisión y aprobación. Los cambios en la capa intermedia afectan a múltiples sistemas a la vez. Deberían pasar por un proceso de revisión equivalente al de un cambio en un sistema crítico, no por una modificación directa en caliente.

La ausencia de estas prácticas no se nota hasta que un cambio en un extremo rompe un flujo que nadie sabía que dependía de una transformación específica. En ese momento, la falta de versionado convierte un incidente acotado en una investigación larga.

Quién decide: roles y responsabilidades sobre la capa intermedia

El gobierno de la capa intermedia falla cuando no hay un responsable claro. En muchas organizaciones, el middleware queda en una zona gris entre infraestructura, desarrollo e integración, y esa ambigüedad es la que permite que la lógica se acumule sin control.

Una asignación de responsabilidades que funciona en la práctica distingue tres roles:

• Dueño de la plataforma. Responsable de la disponibilidad, el dimensionamiento y la operación de la capa intermedia. No decide qué lógica vive en ella, pero sí cómo se despliega y se monitorea.
• Dueño de cada integración. Responsable del contrato entre dos sistemas específicos. Decide, con criterio de arquitectura, si una transformación vive en el middleware o en un extremo.
• Arquitectura. Define los criterios de frontera, revisa las excepciones y mantiene la coherencia del conjunto. Sin este rol, cada integración decide por su cuenta y la capa intermedia se fragmenta.

El punto crítico no es la estructura organizacional, sino que exista una decisión explícita sobre cada pieza de lógica que vive en la capa intermedia. Cuando esa decisión no existe, la capa crece por inercia y su comportamiento se vuelve difícil de explicar incluso para quien la opera.

Señales de que el gobierno de la capa intermedia se perdió

Hay indicios que, en conjunto, muestran que la capa intermedia dejó de estar gobernada:

• Nadie puede enumerar qué transformaciones aplica el middleware sin revisar la configuración directamente en producción.
• Un cambio en un sistema obliga a modificar el middleware de forma no planificada, porque había lógica oculta que dependía del contrato anterior.
• Los incidentes de integración se resuelven por prueba y error, sin poder atribuir el fallo a una transformación o regla específica.
• La configuración de producción difiere de la documentada, y no hay forma de saber cuándo ni por qué cambió.
• El equipo de operaciones no puede explicar el comportamiento de la capa bajo carga sin escalar al proveedor o al área que la configuró originalmente.

Cualquiera de estas señales, por separado, es manejable. Varias en conjunto indican que la capa intermedia opera sin gobierno efectivo, y que cualquier inversión en capacidad o en herramientas va a rendir menos de lo esperado mientras esa condición se mantenga.

Cómo ordenar el gobierno de la capa intermedia

Recuperar el gobierno no requiere reemplazar la plataforma. Requiere cuatro decisiones concretas:

1. Inventariar la lógica existente. Enumerar qué transformaciones, reglas y políticas viven hoy en el middleware, con su dueño funcional y su motivo. Es el paso que más resistencia genera y el más necesario.

2. Definir la frontera. Establecer, con criterio explícito, qué tipo de lógica puede vivir en la capa intermedia y qué tipo debe residir en los extremos. Documentar la regla y aplicarla a las excepciones existentes.

3. Versionar y probar. Incorporar la lógica del middleware al mismo ciclo de control de versiones, ambientes y pruebas que el resto del software crítico.

4. Asignar responsabilidades. Nombrar quién decide qué vive en la capa intermedia, quién opera la plataforma y quién revisa las excepciones. Sin esta asignación, las tres decisiones anteriores se diluyen.

Este tipo de ordenamiento se apoya en capacidades especializadas de Middleware cuando la operación exige sostener la capa con niveles de servicio medibles y trazabilidad sobre lo que ocurre en ella.

Cuándo conviene revisar el gobierno y no solo el síntoma

El patrón se repite: la organización resuelve el incidente —más memoria, más conexiones, más nodos— y vuelve al mismo punto meses después con un síntoma equivalente. La causa es que se optimizó un componente sin revisar quién decide qué vive en él.

Tres disparadores justifican una revisión de gobierno y no solo una intervención operacional:

• El mismo tipo de incidente reaparece con distinta aplicación de origen. Señal de que el problema está en la capa común, no en cada sistema.
• Los cambios en un extremo obligan a cambios no planificados en el middleware. Señal de que hay lógica oculta sin dueño claro.
• El equipo no puede explicar el comportamiento de la capa bajo carga sin abrir un ticket al proveedor. Señal de que la configuración no está bajo control propio.

En esos casos, la conversación útil no es "qué componente reemplazamos", sino "quién decide qué vive en esta capa y cómo se versiona y se prueba". Esa conversación permite priorizar inversión con criterio, y es el tipo de evaluación que conviene hacer antes de que la inestabilidad la imponga por la vía del incidente.