Integrar sistemas legado: la capa que sostiene la transformación digital

En muchas iniciativas de Transformación Digital, el debate se concentra en la decisión de fondo: ¿reemplazamos el sistema legado o lo integramos? Esa pregunta es válida, pero suele consumir el análisis mientras la ejecución queda postergada. Cuando la decisión ya se inclinó hacia integrar, aparece un problema distinto: cómo construir la capa de integración para que sostenga la operación en lugar de fragmentarla aún más.

El dolor es concreto: procesos que cruzan dos o tres sistemas, tareas manuales para trasladar datos entre ellos y trazabilidad que se corta justo en el punto de unión. Una integración bien ejecutada ataca ese problema; mal ejecutada, lo replica con más capas.

Qué implica integrar sistemas legado en una transformación digital

Integrar legado no es conectar dos sistemas con un script y declarar el problema resuelto. Implica construir una capa que traduzca, ordene y exponga capacidades del sistema existente hacia los nuevos componentes digitales, sin exigir que el legado cambie su lógica interna.

La diferencia con reemplazar es operativa. Reemplazar supone migrar datos, reescribir reglas de negocio y asumir el riesgo de la transición. Integrar supone aceptar que el legado sigue siendo la fuente de verdad para ciertos dominios y construir alrededor de él una capa que permita a otros sistemas consumir esa verdad de forma controlada.

Esa capa cumple tres funciones:

• Traducción: adaptar formatos, protocolos y semánticas entre sistemas que no fueron diseñados para hablarse.
• Orquestación: coordinar el orden de los pasos de un proceso que cruza varios sistemas.
• Observabilidad: registrar qué pasó, cuándo y con qué resultado en cada punto de unión.

Cuando falta alguna de las tres, el síntoma es el mismo: el proceso funciona en el caso feliz y se rompe en los bordes. Ahí reaparecen las tareas manuales y la trazabilidad parcial.

Este artículo asume que la decisión de integrar ya está tomada y se enfoca en la ejecución de esa capa. El análisis sobre qué camino conviene tomar cuando la duda sigue abierta corresponde a otro conjunto de criterios, desarrollado en Sistemas legacy en la transformación digital: cuándo integrar y cuándo reemplazar.

Señales técnicas que indican cuándo la integración es viable

Antes de comprometer esfuerzo en una capa de integración, conviene leer el estado real del legado. Algunas señales anticipan problemas.

Estado de las interfaces existentes. ¿El sistema legado expone alguna interfaz documentada, o todo acceso pasa por base de datos o archivos planos? Una interfaz estable, aunque antigua, es un punto de partida. El acceso directo a tablas compartidas es una señal de fragilidad: cualquier cambio interno del legado puede romper la integración sin aviso.

Disponibilidad y consistencia de datos. ¿Los datos que se necesitan exponer están completos, son consistentes y tienen un dueño claro? Si el mismo dato vive en dos sistemas con valores distintos, la integración hereda esa ambigüedad. Resolverla antes de integrar es más barato que resolverla después.

Observabilidad en los puntos de unión. ¿Se puede saber, sin ambigüedad, si una transacción cruzó correctamente de un sistema a otro? Si la respuesta depende de revisar logs manualmente o de preguntar a alguien, la observabilidad es insuficiente.

Restricciones de latencia, volumen y criticidad. Un proceso batch nocturno tolera latencias que un proceso transaccional en línea no tolera. La criticidad operacional define cuánto margen hay para reintentos, colas y ventanas de mantenimiento.

Estas señales no son binarias: definen el nivel de esfuerzo y el tipo de arquitectura que la integración va a requerir.

Cómo se estructura una integración de legado que no colapsa

La estructura de una integración robusta se apoya en decisiones de desacoplamiento. El principio general: que el legado no sepa que está siendo integrado, y que los sistemas nuevos no dependan de sus detalles internos.

Desacoplamiento mediante contratos estables. La integración debe exponer una interfaz con contrato definido —qué recibe, qué devuelve, qué errores puede emitir— y esa interfaz debe ser el único punto de contacto. Si los sistemas nuevos consultan directamente tablas del legado, el desacoplamiento no existe.

Manejo explícito de errores y reintentos. Los puntos de unión fallan. La pregunta no es si van a fallar, sino qué pasa cuando fallan. Una integración sana distingue entre errores transitorios (reintentables) y errores de negocio (que requieren intervención). Sin esa distinción, los reintentos automáticos pueden duplicar operaciones o dejar procesos a medias.

Trazabilidad de punta a punta. Cada transacción que cruza la capa debería rastrearse desde su origen hasta su destino con un identificador común. Esto permite responder "¿qué pasó con esta operación?" sin reconstruir el camino a mano, y es la base sobre la que se construyen controles de auditoría y preparación frente a exigencias normativas como la Ley 21.719, sin que eso implique garantizar cumplimiento por sí solo.

Idempotencia donde el proceso lo permita. Si un mensaje se procesa dos veces, el resultado debería ser el mismo que procesarlo una vez. Esto reduce el daño de los reintentos y simplifica la recuperación ante fallos.

Separación entre integración y lógica de negocio. La capa de integración traduce y transporta; no debería contener reglas de negocio que pertenecen a los sistemas que conecta. Cuando esa separación se pierde, la capa se convierte en un punto único de falla difícil de mantener.

Estas decisiones se parecen a las del diseño de APIs empresariales, aunque el contexto sea distinto: en ambos casos, el costo de un contrato mal definido se paga durante toda la vida del sistema.

Criterio práctico para evaluar una integración en operación

Cuando la integración ya está en marcha, estas preguntas ayudan a evaluar si sostiene la operación o solo la disimula:

• ¿Cuántos procesos siguen requiriendo intervención manual en el punto de unión?
• ¿Se puede reconstruir el recorrido completo de una transacción sin acceso a los sistemas de origen?
• ¿Los errores se detectan por monitoreo o por reclamo del usuario?
• ¿Un cambio interno en el legado obliga a modificar la capa de integración?
• ¿Existe un dueño claro de la capa y de sus contratos?

Si varias respuestas apuntan a lo mismo, la integración funciona como parche y no como habilitante. Ese es el momento de revisar la arquitectura, no de agregar más conexiones encima.

Integrar sistemas legado dentro de una transformación digital es una decisión de arquitectura con consecuencias operativas concretas. Bien ejecutada, reduce tareas manuales, ordena procesos fragmentados y devuelve trazabilidad de punta a punta. Mal ejecutada, agrega una capa de complejidad sobre un problema que ya existía. La diferencia no está en la decisión de integrar, sino en cómo se ejecuta esa integración.