Cómo modernizar APIs de sistemas legacy sin reescribir

Cómo modernizar un ERP AS/400 sin reescribirlo: el patrón API que sí funciona

Reescribir un ERP AS/400 con más de 20 años de reglas de negocio rara vez es una opción viable. El riesgo, el coste y el tiempo necesarios suelen hacer inviable un proyecto de este tipo.

La alternativa que mejor funciona en entornos empresariales consiste en envolver el sistema legacy con una capa de APIs limpias, seguras y observables, lo que permite evolucionar la arquitectura sin interrumpir la operación. Este es el patrón que aplicamos en nuestros proyectos.

---

Diagnóstico previo (Semana 1)

Antes de escribir una sola línea de código, es imprescindible entender qué hace realmente el sistema.

Durante la fase inicial analizamos:

• ¿Qué procesos de negocio residen en el ERP?
• ¿Qué integraciones existen con otros sistemas?
• ¿Qué SLA deben cumplirse?
• ¿Qué volumen de peticiones (throughput) soporta realmente el entorno?
• ¿Qué dependencias técnicas y funcionales existen?

Sin este diagnóstico, cualquier API terminará exponiendo las limitaciones del sistema legacy en lugar de abstraerlas.

---

El patrón Strangler Fig

La estrategia consiste en introducir una capa de API delante del ERP y hacer que toda la comunicación pase por ella.

En una primera fase, la API simplemente delega las operaciones en el sistema legado. A medida que evolucionan los nuevos servicios, determinados endpoints dejan de depender del AS/400 y comienzan a resolverse en una arquitectura moderna.

El consumidor nunca percibe ese cambio.

La API se convierte en el contrato estable, mientras que la implementación evoluciona de forma transparente.

Fase 1: Fachada sobre el legacy

Se construye una API REST o GraphQL que actúa como adaptador.

En esta etapa:

• No se añade lógica de negocio.
• No se modifican procesos existentes.
• La API únicamente traduce las llamadas al ERP.

Fase 2: Caché y read models

Una vez estabilizada la fachada, se introducen mecanismos para reducir la carga sobre el sistema principal:

• Cachés para consultas frecuentes.
• Read models optimizados.
• Consultas desacopladas del modelo transaccional.

El objetivo es descargar trabajo del mainframe sin alterar su funcionamiento.

Fase 3: Migración por dominios

La modernización comienza a realizarse por capacidades funcionales, por ejemplo:

• Facturación.
• Inventario.
• Gestión de clientes.
• Pedidos.

Cada dominio migrado deja de depender progresivamente del ERP original.

Fase 4: Retirada o convivencia

Llegado este punto, existen dos escenarios posibles:

• El legacy se retira completamente.
• Permanece únicamente para funciones residuales, mientras que los nuevos servicios asumen el resto de las responsabilidades.

---

Cómo integrar un AS/400 o un mainframe

Los mecanismos de integración más habituales son:

• DB2 para consultas de solo lectura.
• IBM MQ para mensajería y procesamiento asíncrono.
• Invocación de programas RPG o COBOL mediante middleware.
• Intercambio de ficheros para procesos batch.

Una regla que nunca rompemos

DB2 nunca debe exponerse directamente al exterior.

Toda interacción debe pasar por la capa API, donde se aplican:

• Validaciones.
• Autorización.
• Rate limiting.
• Auditoría.
• Observabilidad.

---

Seguridad y observabilidad

Una API moderna debe incorporar mecanismos de seguridad desde el primer día.

Nuestra arquitectura suele incluir:

• OAuth 2.0 para autorización.
• mTLS para autenticación entre servicios.
• WAF como primera línea de protección.
• Trazabilidad distribuida mediante OpenTelemetry.

Cada llamada al ERP queda correlacionada con la petición original.

Esta correlación es fundamental para:

• Diagnosticar incidencias.
• Localizar cuellos de botella.
• Reducir los tiempos de resolución en producción.
• Evitar escalar cada incidencia al equipo responsable del mainframe.

---

Errores comunes que conviene evitar

El error más habitual consiste en trasladar directamente la estructura del ERP a una API REST.

Es decir, crear endpoints que correspondan a las tablas, los campos y las relaciones internas del sistema legacy.

El resultado suele ser una API tan rígida y frágil como el propio ERP.

La regla de oro

Una API debe representar el dominio de negocio, no la estructura interna del sistema que hay detrás.

Cuando el contrato está diseñado en torno al negocio, la implementación puede evolucionar sin afectar a los consumidores de la API.