Modernización
COBOL, mainframe e IBM i: modernizar sin apagar lo que funciona
Los sistemas centrales en COBOL o RPG suelen ser los más confiables de la empresa y, a la vez, los más difíciles de cambiar. No siempre conviene reescribirlos: primero medimos y luego decidimos qué se documenta, qué se abre por APIs y qué se migra.
El problema
El riesgo no es la tecnología, es el conocimiento
Las reglas de negocio llevan décadas acumulándose en programas batch, copybooks y archivos, y las personas que las conocen se están retirando. Cada cambio requiere a un especialista cada vez más difícil de encontrar, y el costo de operar el sistema no deja de crecer.
Cómo lo hacemos
Del núcleo heredado a decisiones con datos
Inventario de programas y datos
Programas, copybooks, procesos batch, archivos y tablas DB2 se inventarían y se relacionan entre sí.
Reglas extraídas a especificación
El comportamiento de cada proceso queda escrito como especificación verificable, con pruebas que la comprueban.
APIs alrededor del núcleo
Cuando reescribir todavía no conviene, el núcleo se abre por APIs para que los canales nuevos lo usen sin modificarlo.
Migración gradual
Lo que sí se migra sale por módulos, con conmutación reversible y comparación de resultados contra el sistema central.
Trabajamos con IBM como partner tecnológico.
Escenario ilustrativo
Una aseguradora con su núcleo de pólizas en COBOL
Imagina un sistema de pólizas en COBOL sobre mainframe, con procesos batch nocturnos y un portal web que necesita consultar datos en línea.
- El inventario identifica qué programas y archivos intervienen en la consulta y la emisión de pólizas.
- Las reglas de cálculo de esos programas se documentan como especificación con pruebas.
- Se publica una API de consulta sobre el núcleo actual, sin modificarlo, para que el portal la use.
- Con la especificación en mano se decide, módulo por módulo, cuál se queda en el mainframe y cuál se migra.
Escenario ilustrativo: Ejemplo hipotético para explicar el método: no describe a un cliente ni un resultado medido.
Qué te queda
Un núcleo documentado y un plan con datos
Inventario, especificación de reglas y un plan por olas que separa lo que conviene mantener de lo que conviene migrar.
Preguntas frecuentes
¿Hay que salir del mainframe?
No necesariamente. A menudo conviene mantener el núcleo y modernizar a su alrededor: documentación, APIs e interfaces nuevas. La decisión se toma con el inventario medido.
¿Aplica también a IBM i (AS/400) y RPG?
Sí, con el mismo método: inventario de programas, archivos y tablas, especificación de reglas y pruebas. La muestra medida lo comprueba sobre tu sistema.
¿Tienen un caso propio con COBOL?
No tenemos un caso propio publicado en COBOL; nuestro caso documentado es una migración desde GeneXus. Por eso proponemos empezar con una muestra medida sobre tu sistema.
Siguiente paso
Empieza por una muestra medida: de 5 a 10 pantallas de tu sistema convertidas en especificación verificable, con pruebas y un inventario de diferencias.