Dos organizaciones con carteras de software COBOL de tamaño similar toman decisiones de modernización diferentes. Una de ellas cambia de plataforma: traslada los programas COBOL a una infraestructura en la nube mediante AWS Mainframe Modernization o una capa de emulación de COBOL, conservando el código y eliminando el mainframe físico. En dieciocho meses, reducen los costes de infraestructura en un 40 % y el programa se considera un éxito. La otra organización intenta el mismo enfoque, pero tras doce meses se topa con dificultades y cambia de estrategia, reconstruyendo los programas más críticos como microservicios Java. Este cambio de estrategia duplica el presupuesto original y requiere tres años más.
Mismo punto de partida. Resultados radicalmente diferentes. La diferencia no radicaba en las herramientas, los proveedores ni los equipos. El problema radicaba en que la segunda organización optó por la migración de plataforma para sistemas con limitaciones arquitectónicas que la nueva plataforma no podía soportar: dependencias de transacciones CICS, estructuras de archivos VSAM y requisitos en tiempo real que el código migrado no podía satisfacer sin un rediseño fundamental. La decisión se tomó antes de que nadie comprendiera los sistemas lo suficientemente bien como para implementarla correctamente.
Encuentre los bloqueadores de la rearquitectura a tiempo
SMART TS XL Identifica automáticamente la profundidad de acoplamiento de CICS, la complejidad de VSAM y el código muerto en toda su cartera de productos COBOL.
MÁS INFORMACIÓNQué significa realmente cada ruta para COBOL
Las definiciones genéricas son bien conocidas. Lo que importa es lo que cada ruta significa específicamente para los programas COBOL, donde la arquitectura, el modelo de ejecución y las estructuras de datos difieren de las aplicaciones modernas de maneras que afectan directamente qué ruta es viable.
Replataforma COBOL
La migración de plataforma traslada los programas COBOL a un nuevo entorno operativo, normalmente una infraestructura en la nube, conservando el código prácticamente intacto. El código COBOL se compila y ejecuta en la nueva plataforma, ya sea de forma nativa (utilizando el compilador COBOL de IBM en Linux) o mediante una capa de emulación que intercepta las llamadas específicas del mainframe (CICS, VSAM, JES) y las traduce a sus equivalentes nativos de la nube.
Lo que se conserva al cambiar de plataforma:
- El código fuente de COBOL
- La lógica del programa, los cálculos y las reglas de negocio.
- El modelo de ejecución por lotes (bucles PERFORM, procesamiento secuencial de archivos)
- Las estructuras de datos (diseños de registros, definiciones de libros de copias)
- La estructura de trabajo JCL (reescrita para el nuevo planificador, pero lógicamente equivalente)
¿Qué cambios implica la migración de plataforma?
- La infraestructura física (z/OS → Linux en la nube)
- El subsistema de E/S (VSAM → almacenamiento de archivos gestionado o base de datos, según la herramienta)
- El planificador de tareas (JES2/JES3 → AWS Batch, Azure Logic Apps o equivalente)
- El modelo de costes (facturación basada en MIPS → facturación en la nube basada en el consumo)
Conclusión clave: La migración a una nueva plataforma es correcta cuando el problema reside en la plataforma, el coste de ejecución de z/OS, la dependencia de la infraestructura o el modelo de facturación MIPS. Es un camino erróneo cuando el problema reside en el código o la arquitectura.
Reestructuración de COBOL
La reestructuración modifica el diseño fundamental del sistema. La lógica de negocio se conserva o se deriva del código fuente COBOL, pero se implementa en un nuevo lenguaje, con un nuevo modelo de ejecución y sobre una nueva capa de datos. El resultado es un sistema que realiza las mismas funciones que COBOL, pero cuya estructura es completamente distinta.
¿Qué cambios implica la reestructuración?
- El lenguaje de programación (COBOL → Java, Python, Go, C#)
- El modelo de ejecución (por lotes → basado en eventos, en tiempo real o basado en API)
- La capa de datos (archivos VSAM → base de datos relacional, NoSQL, almacenamiento nativo en la nube)
- El modelo de transacción (CICS pseudoconversacional → servicios RESTful sin estado)
- El patrón de integración (conjuntos de datos compartidos → contratos de API, colas de mensajes)
Lo que debe preservarse al rediseñar la arquitectura:
- Cada regla de negocio que implementa COBOL, incluidos los casos límite no documentados.
- Cada cálculo, incluidas las características de precisión numérica de la aritmética decimal empaquetada
- Cada transformación de datos, incluidas las conversiones implícitas en las sentencias MOVE.
- Cada condición de error, incluidos los códigos de ESTADO DE ARCHIVO específicos y los comportamientos de terminación anormal de los que pueden depender los sistemas posteriores.
Atención: El fallo más común en la reestructuración del sistema se produce al descubrir que el código COBOL contenía reglas de negocio que no se documentaron en ningún otro lugar. El nuevo sistema se comporta de forma diferente al anterior en casos límite específicos, no por un error de implementación, sino porque la especificación estaba incompleta. La lógica de negocio debe extraerse y documentarse del código fuente COBOL antes de comenzar la reestructuración.
Los factores específicos de COBOL que modifican esta decisión
Los marcos de modernización genéricos consideran que la migración de plataforma y la reestructuración son decisiones que se basan principalmente en el costo, el plazo y el riesgo. En el caso de COBOL, varios factores técnicos específicos del lenguaje y su entorno de ejecución influyen considerablemente en la decisión, inclinándola hacia una u otra opción.
Dependencias de transacciones CICS
CICS (Customer Information Control System) es el middleware de procesamiento de transacciones que muchos programas COBOL utilizan para cargas de trabajo interactivas. Un programa COBOL que realiza llamadas EXEC CICS tiene una dependencia implícita del servidor de transacciones CICS para la gestión de pantallas, la comunicación con terminales, la asignación de tareas y el control del programa.
Implicaciones de la migración de plataforma: Herramientas como la emulación de Micro Focus CICS, OpenFrame y algunas funciones de modernización de mainframes de AWS emulan la semántica de CICS. Si el uso de CICS es estándar y se comporta correctamente, la emulación puede funcionar. Si el programa depende de la funcionalidad interna de CICS, la manipulación de áreas de comunicación, el control de puntos de sincronización o el almacenamiento a nivel de tarea, la fidelidad de la emulación se degrada.
Implicación de la reestructuración: Un programa CICS convertido a una API REST debe rediseñar su modelo de transacciones pseudoconversacionales para que funcione como interacciones sin estado. Esto es un cambio arquitectónico, no una traducción de código.
Señal que impulsa la reestructuración: Uso intensivo de CICS con manejo complejo de áreas de comunicación, encadenamiento de transacciones de back-end o lógica de puntos de sincronización.
Arquitectura de archivos VSAM
VSAM (Virtual Storage Access Method) es el sistema de archivos indexados que utilizan la mayoría de los programas de producción COBOL. Los archivos VSAM tienen patrones de acceso específicos (KSDS secuencial con clave, ESDS secuencial por entrada, RRDS registro relativo) que no tienen equivalentes directos en el almacenamiento nativo en la nube.
Implicaciones de la migración de plataforma: Las capas de emulación traducen las lecturas y escrituras de VSAM a operaciones de archivos o bases de datos subyacentes. Para accesos secuenciales o basados en claves simples, esto funciona. Sin embargo, para accesos complejos con claves alternativas, clústeres VSAM compartidos entre varios programas o patrones de acceso aleatorio que requieren un alto rendimiento, la emulación añade latencia y complejidad.
Implicaciones de la reestructuración: Reemplazar VSAM por una base de datos relacional requiere mapear la disposición de los registros a los esquemas de las tablas, gestionar las conversiones implícitas de tipos de datos y reescribir cada acceso a archivos para usar SQL o un ORM.
Señales que impulsan una reestructuración: archivos VSAM compartidos entre muchos programas, patrones de acceso a índices alternativos o requisitos de rendimiento en tiempo real que la emulación no puede satisfacer.
Requisitos de procesamiento por lotes frente a requisitos en tiempo real
Los programas por lotes de COBOL están diseñados para procesar grandes volúmenes de registros de forma secuencial en intervalos programados. Muchos sistemas bancarios, de seguros y gubernamentales aún ejecutan trabajos por lotes durante la noche que procesan millones de transacciones, generan informes y actualizan archivos maestros.
Implicaciones de la migración de plataforma: La semántica de procesamiento por lotes se adapta bien a la ejecución de lotes en la nube (AWS Batch, Azure Batch). El modelo de procesamiento secuencial se mantiene tras el cambio de plataforma. Si el requisito es simplemente ejecutar el mismo trabajo por lotes en una infraestructura más económica, la migración de plataforma lo soluciona directamente.
Implicaciones de la reestructuración: Si los requisitos del negocio han cambiado, pasando del procesamiento por lotes nocturno al procesamiento casi en tiempo real, del intercambio de archivos a la integración de API, o de la ejecución de procesos monolíticos por lotes a microservicios activados individualmente, la migración de la plataforma no puede satisfacer el nuevo requisito. La arquitectura debe cambiar.
Señales que impulsan una reestructuración: Requisitos de las partes interesadas para el procesamiento en tiempo real, la integración basada en API, la arquitectura orientada a eventos o los tiempos de respuesta inferiores a un segundo que la semántica por lotes no puede proporcionar.
Lógica de negocio integrada sin especificación externa
Este es el factor específico de COBOL más subestimado. Los principales riesgos incluyen la pérdida de reglas de negocio críticas integradas en código con décadas de antigüedad y la documentación insuficiente del comportamiento del sistema. Los programas COBOL suelen contener la única especificación que se conserva de una regla de negocio. La normativa que exigía un cálculo específico se redactó en 1983. El analista de negocio que la comprendió se jubiló en 2001. El código COBOL no es solo una implementación, sino también su documentación.
Implicación de la migración a una nueva plataforma: Las reglas de negocio se mantienen intactas porque el código se conserva. Este es uno de los argumentos más sólidos a favor de la migración a una nueva plataforma.
Implicación de la reestructuración: Las reglas de negocio deben extraerse del código fuente COBOL antes de su reimplementación. <cite index=”28-1″>El código no documentado y estrechamente acoplado multiplica el esfuerzo en cada fase.</cite> Si esta extracción es incompleta, el nuevo sistema tendrá una especificación diferente a la del anterior, y esas diferencias se harán evidentes en producción.
Marco de decisión: ocho preguntas
Antes de elegir un camino, estas ocho preguntas proporcionan la evidencia necesaria para tomar la decisión con confianza, en lugar de basarse en suposiciones.
1. ¿Cuál es el principal motor de esta modernización?
- Costo de infraestructura → la renovación de la plataforma es suficiente
- Dependencia de plataforma (z/OS) → la migración de plataforma es suficiente
- Requisitos en tiempo real → se requiere reconfiguración
- Requisitos de integración (API) → es probable que se requiera una reestructuración.
- Mantenibilidad / disponibilidad de talento → rediseñar o refactorizar
2. ¿Cuál es el nivel de acoplamiento de CICS? Enumere todas las llamadas EXEC de CICS. Cuente los programas con más de veinte comandos CICS distintos. Los programas con un alto acoplamiento de CICS no son buenos candidatos para la migración a una nueva plataforma si la fidelidad de la emulación es incierta.
3. ¿Cuáles son los patrones de acceso a VSAM? Identifique los programas que acceden a archivos VSAM con claves alternativas, clústeres compartidos o acceso aleatorio que afecta al rendimiento. Estos son indicadores de riesgo de migración a una nueva plataforma.
4. ¿Se ha documentado externamente la lógica de negocio? Si el código fuente COBOL es la única especificación autorizada, la reestructuración requiere la extracción de la lógica de negocio como paso previo, no como una carga de trabajo paralela.
5. ¿Cuál es la tolerancia de la ventana de lotes? Si la empresa requiere el mismo modelo de procesamiento por lotes a un menor costo, cambie de plataforma. Si la empresa requiere que el mismo procesamiento esté disponible en tiempo real, rediseñe la arquitectura.
6. ¿Cuál es la complejidad de las dependencias? Un programa con cincuenta dependencias descendentes, conjuntos de datos, denominados subprogramas y llamadas JCL, conlleva un mayor riesgo de reestructuración que una utilidad independiente. La estructura de dependencias determina la secuencia de migración y el alcance de las pruebas.
7. ¿Qué porcentaje del código está obsoleto? Excluir el código obsoleto del alcance antes de cualquier conversión reduce el esfuerzo en ambos casos. En el caso de programas de reestructuración, el código obsoleto no excluido se convierte a su costo total y luego se descarta.
8. ¿Cuál es la distribución de complejidad? Una complejidad ciclomática superior a 50 por programa, o más de veinte copybooks incluidos, indica programas que requieren una reestructuración costosa y conllevan riesgos al cambiar de plataforma. Estos requieren atención individual en lugar de una asignación de ruta masiva.
Aplicación del marco de trabajo: Cuatro perfiles de sistema COBOL
| Perfil de la empresa | Características | Ruta recomendada | Razón fundamental |
|---|---|---|---|
| Utilidad de lotes estable | E/S de archivos secuenciales, sin CICS, lógica bien documentada, baja complejidad. | Cambiar de plataforma | El problema es el costo de la plataforma; el código no es la limitación. |
| Transacción en línea con alto uso de CICS | Uso intensivo de EXEC CICS, dependencias de commarea, modelo pseudoconversacional | rediseñar | El riesgo de emulación de CICS es alto; es probable que se requieran tiempos reales. |
| Procesador de archivos maestros VSAM | Patrones de acceso VSAM complejos, compartidos entre muchos programas, alto volumen de lectura | Primero, evalúe la fidelidad de la emulación; cambie de plataforma si la emulación falla. | La emulación VSAM es la variable de decisión. |
| Tesorería de lógica empresarial | Reglas no documentadas, sin especificaciones externas, alta relevancia regulatoria. | Primero extrae la lógica y luego elige. | El riesgo de rediseñar la arquitectura es inaceptable sin una extracción previa de la lógica de negocio. |
Conclusión clave: <cite index=”30-1″>En la práctica, las grandes empresas combinan enfoques: modernizan las plataformas de las partes estables, refactorizan el código que es difícil de mantener, reescriben los pocos sistemas que necesitan nuevas capacidades y retiran lo que ya no se usa.</cite> La decisión no es a nivel de cartera, sino a nivel de carga de trabajo, aplicada individualmente a cada programa o grupo de programas en función de la evidencia.
El enfoque híbrido: primero, replantear la plataforma; luego, rediseñar la arquitectura donde sea necesario.
Una regla práctica: reubicar o cambiar de plataforma para detener rápidamente las pérdidas, y luego refactorizar o rediseñar los sistemas que realmente representan diferencias competitivas.
Para la mayoría de las organizaciones con grandes carteras de COBOL, la secuencia práctica es la siguiente:
Fase 1: Migrar la plataforma de los programas candidatos. Los programas sin CICS, con E/S secuenciales sencillas, lógica documentada y baja complejidad, pueden migrar a una nueva plataforma con un esfuerzo y riesgo predecibles. Esto permite reducir rápidamente los costos de infraestructura y genera confianza en la organización.
Fase 2: Evaluación de programas complejos. Los programas con acoplamiento CICS, patrones VSAM complejos o lógica de negocio no documentada requieren un análisis individual antes de elegir una solución. En esta fase, la extracción de la lógica de negocio y el análisis estructural determinan si es necesario rediseñar la arquitectura y cuál sería su alcance.
Fase 3: Reestructurar los programas con obstáculos arquitectónicos. Los programas que no pueden satisfacer los requisitos comerciales en la infraestructura remodelada, los requisitos en tiempo real, la integración de API y el procesamiento basado en eventos se reestructuran utilizando el patrón Strangler Fig: construir el nuevo servicio junto con el programa remodelado, enrutar el tráfico progresivamente a la nueva implementación a medida que se valida cada componente y desactivar el programa antiguo cuando se haya migrado todo el tráfico.
Fase 4: Eliminación de código obsoleto. Los programas identificados como obsoletos durante el análisis estructural se excluyen de ambas rutas y se desactivan, lo que reduce los costos de mantenimiento continuos sin necesidad de realizar ningún esfuerzo de conversión.
Qué debe arrojar el análisis antes de tomar cualquier decisión.
El marco de decisión descrito anteriormente ofrece mejores resultados cuando los datos de entrada son evidencias en lugar de estimaciones. El análisis estructural que proporciona dichos datos requiere analizar el código fuente COBOL directamente, en lugar de basarse en la documentación o el conocimiento del desarrollador.
Lo que el análisis debe establecer para cada programa:
Un inventario completo de programas que incluye programas que no están documentados. En grandes entornos COBOL, el número de programas no documentados suele superar el 20 % del total. Un gráfico de dependencias que muestra qué programas llaman a qué otros, qué conjuntos de datos se comparten, qué trabajos JCL invocan a qué programas. Inventario de comandos CICS para cada programa, el recuento, los tipos y la complejidad de las llamadas. Análisis de patrones de acceso VSAM, qué métodos de acceso, qué archivos se comparten entre programas, qué archivos tienen índices alternativos. Distribución de complejidad ciclomática, qué programas son estructuralmente simples y cuáles son candidatos de alto riesgo para cualquier conversión. Identificación de código muerto, qué programas y párrafos no tienen rutas de ejecución de entrada. Extracción de lógica de negocio, qué reglas implementa cada programa, en un formato que se puede utilizar para validar la salida de cualquiera de las rutas.
Sin este inventario, la decisión sobre la ruta se toma con información incompleta. Los programas se asignan a la migración de plataforma basándose en suposiciones que resultan ser erróneas cuando la emulación revela limitaciones arquitectónicas que no eran visibles durante la planificación.
Cómo SMART TS XL Genera la evidencia previa a la decisión.
SMART TS XL, modernización heredada El análisis automatiza el inventario estructural descrito anteriormente, analizando simultáneamente cada programa COBOL, copybook, trabajo JCL y referencia de archivo VSAM para construir el modelo de dependencia unificado que hace que la decisión de ruta se base en evidencia.
El mapeo de dependencias de la aplicación produce el gráfico de llamadas entre programas y el mapa de compartición de conjuntos de datos que determina la complejidad de la dependencia, el factor que afecta más directamente tanto al riesgo de emulación de la plataforma como al alcance y la secuencia de la reestructuración.
El análisis estático del código genera métricas de complejidad, inventarios de llamadas a CICS e identificación de código muerto para cada programa del portafolio. Los programas que superan el umbral de complejidad ciclomática y presentan un fuerte acoplamiento con CICS se identifican automáticamente como candidatos para rediseñar o evaluar, en lugar de asignarse masivamente a una nueva plataforma.
La expansión JCL resuelve los parámetros simbólicos y construye la cadena completa de dependencias de ejecución por lotes, que indica qué trabajos JCL invocan qué programas, en qué secuencia y con qué conjuntos de datos, proporcionando el contexto operativo que determina cómo debe comportarse la salida de cada ruta para cumplir con la programación del lote.
La capacidad de análisis de impacto concreta el alcance de cada ruta antes de que comience el programa: para cualquier programa seleccionado para su reestructuración, el análisis de impacto enumera todos los programas dependientes que deben actualizarse, volver a probarse o coordinarse con el componente reestructurado. Para los candidatos a la migración de plataforma, el mismo análisis identifica qué conjuntos de datos y subprogramas compartidos crean dependencias entre programas que deben gestionarse de forma coherente.
La búsqueda empresarial permite consultar el inventario completo en todo el programa: encuentre en segundos, a través de millones de líneas de COBOL, cada programa que utilice un comando CICS específico, cada programa que acceda a un clúster VSAM específico, cada copybook que defina una estructura de datos específica.
Las organizaciones que toman esta decisión correctamente son las que la toman a partir de evidencia estructural en lugar de suposiciones del plan del proyecto. La evidencia estructural es lo que SMART TS XL produce.
