Aunque muchos lo dan por muerto, el mainframe sigue siendo el corazón que late detrás de buena parte de la tecnología que usamos cada día. La falta de relevo generacional amenaza con dejar sin mantenimiento los sistemas que mueven bancos, aseguradoras, Administraciones Públicas, Gobiernos o compañías de transporte, entre otros.
En el mundo de la informática subsisten mitos como la desaparición de los discos duros o la muerte del mainframe. Hace casi cuatro décadas que comencé mi carrera profesional desarrollando y manteniendo COBOL, y desde hace más de 20 años, imparto formación en sistemas informáticos críticos del entorno mainframe de IBM. Fue en los años noventa del pasado siglo cuando se pronosticó que el mainframe desaparecería y muchos de mis colegas huyeron hacia “la modernidad”. No lo creí entonces y el tiempo me ha dado la razón. Hoy, sin embargo, el verdadero riesgo no es la desaparición de este entorno, sino la falta de conocimiento y relevo generacional que sufre.
La ignorancia de la magnitud del mainframe es amplia, incluso en el sector tecnológico, y no solo pocos los que menosprecian a quien decide formarse en COBOL. Me comentan mis alumnos, que les dicen con ironía “¿pero eso sigue existiendo?”, “¡te quedarás sin trabajo pronto!”, “¿quién te ha engañado así?”. Son los mismos que pagan con tarjeta, consultan sus facturas, hacen su declaración de la renta o cobran la pensión sin saber que detrás de esas operaciones está COBOL.
Índice de temas
Sin relevo generacional
El primer día de curso suelo mostrar a mis alumnos artículos y noticias sobre la vigencia del mainframe. Es la mejor forma de devolverles la confianza porque demuestran que lo que están aprendiendo no es algo caduco y antediluviano, sino una infraestructura crítica. Aun así, cuesta atraer candidatos y suele haber abandonos en los primeros días.
Competir con los entornos modernos, con sus ventanas, opciones, ayudas visuales y autocompletados, no resulta sencillo. En un mainframe, COBOL apenas ofrece cuatro colores y un compilador que devuelve todos los errores al final y como un bofetón.
En un mainframe, COBOL apenas ofrece cuatro colores y un compilador que devuelve todos los errores al final y como un bofetón
Además, hace décadas que COBOL desapareció de los programas formativos de la universidad y también hace bastantes años que sucedió lo mismo en los ciclos formativos. Queda, es cierto, la formación privada, pero aun así, es notorio que faltan profesionales y los formadores somos una especie en riesgo de extinción.
Rendimiento y costes
Más allá de la falta de talento, hay otro problema encubierto en el entorno mainframe, que es la eficiencia y el rendimiento. En el entorno mainframe, cada instrucción mal optimizada se traduce en un coste medible. El consumo de CPU, el tiempo de ejecución y las operaciones de entrada/salida repercuten directamente en la factura mensual y en los acuerdos de nivel de servicio (SLA), y un programa poco eficiente puede multiplicar el gasto sin que nadie lo perciba a tiempo.
Por esos motivos, la optimización no es solo una cuestión técnica, sino también económica y reputacional. Los segundos que tarda una transacción pueden marcar la diferencia entre la confianza y la frustración del cliente, sobre todo, ahora que vivimos en la era de la inmediatez y a golpe de clic.
Fusiones y herencias tecnológicas
La optimización resulta especialmente relevante cuando se produce una fusión entre entidades, un proceso en el que confluyen distintos sistemas, arquitecturas, estilos de programación y migración de datos. La integración de aplicaciones COBOL de distintas generaciones exige un conocimiento profundo del rendimiento del mainframe y de sus interdependencias. Porque, además, las aplicaciones en el mainframe tienen una arquitectura de COBOL, pero también de PL/I, DB2, de JCL, incluso de JAVA y otros; es decir, el mainframe es COBOL y mucho más.
En este contexto, una mala gestión no solo puede provocar interrupciones, también sobrecostes millonarios. Por tanto, la optimización de código y de procesos no es un lujo, sino una condición indispensable para que la integración tecnológica sea viable.
Salir del mainframe, riesgo y estrategia
Tampoco hay que subestimar la complejidad de una salida del entorno mainframe. Migrar a otras plataformas sin una planificación rigurosa suele derivar en proyectos extremadamente costosos, tanto en dinero como en tiempo, y puede implicar riesgos de interrupción del servicio.
Son pocas las organizaciones que salen completamente del mainframe, de forma que la mayoría se queda con el mainframe y más sistemas, lo que eleva la complejidad. Además, muchas organizaciones se decantan por el modelo de nube híbrida, pero con un enfoque que implica desplegar aplicaciones desarrolladas en la nube en su CPU on premise. No es extraño, por tanto, que el intento de ‘modernizar’ termine generando, en muchos casos, una dependencia aún mayor de consultoras externas o de sistemas paralelos.
AWS, Azure, Google Cloud e incluso IBM Cloud ofrecen flexibilidad y ahorro, pero no son infalibles
Antes de abandonar un mainframe, conviene preguntarse si realmente se está ganando eficiencia o simplemente trasladando el problema a otro lugar. De poco sirve salir del monopolio de IBM por ahorrar costes y llevar los datos a la nube, o poner a prueba nuevas arquitecturas híbridas, si las aplicaciones no están optimizadas y el pago por uso va creciendo hasta volver al coste que inicialmente se pretendía reducir o incluso superarlo.
Así las cosas, me atrevo a vaticinar que muchas empresas revisarán con tiento sus proyectos de migración total del mainframe a la nube por los riesgos, costes, rendimiento y complejidad. Otras ni lo intentarán. Y algunas caerán de la nube como la lluvia y volverán a tierra.
Mala praxis
Es cierto también que los antiguos programas carecían de estándares, de estructura y, en muchos casos, de documentación. Efectivamente, entonces, el volumen de datos no tenía comparación con el actual. En la actualidad se exigen estándares, programación estructurada y amplia documentación y, sin embargo, la mala praxis sigue repitiéndose entre los jóvenes programadores, ya sea por desconocimiento, por urgencia o por simple dejadez.
Sabemos que lo más rápido y cómodo para el programador suele ser lo más costoso para el sistema. El programador suele desconocer que el resultado depende tanto de su código COBOL como del buen hacer del administrador de bases de datos (DBA), un tándem necesario; y, además, habitualmente los programadores desconocen las métricas, herramientas y técnicas de optimización ya que estas competencias tradicionalmente residen en el área de Infraestructuras y Operaciones (I&O), cuando en la práctica afectan, y mucho, a las aplicaciones.
COBOL en la era híbrida
Con los años, el monopolio histórico de IBM ha dado paso a un modelo híbrido: la nube, que cambia la infraestructura y el modo de acceder a los datos, pero no el lenguaje.
AWS, Azure, Google Cloud e incluso IBM Cloud ofrecen flexibilidad y ahorro, pero no son infalibles. De hecho, los recientes fallos en Amazon han hecho recapacitar al mundo. Por ese motivo son muchas las empresas que prefieren mantener el núcleo en COBOL (contabilidad, pagos, nóminas, transacciones) y desarrollan encima un middleware, esa parte intermedia que comunica el sistema con las aplicaciones modernas.
El valor del conocimiento
Afortunadamente, ante todos estos desafíos, existen empresas especializadas en optimizar software heredado como la tecnológica española Orizon, que desarrolla junto con la Universidad de Alicante (UA) un curso especializado en desarrollo mainframe que es un referente en este sector y que tengo el honor de impartir. Los profesionales de Orizon utilizan la plataforma BOA, de desarrollo propio, y su nuevo asistente BOA AI, para analizar el rendimiento, detectar cuellos de botella y recomendar cambios tácticos que pueden ahorrar millones de euros a sus clientes.
Sabemos que lo más rápido y cómodo para el programador suele ser lo más costoso para el sistema
Desarrollar estas funciones requiere un conocimiento especializado profundo y, si no formamos a tiempo a nuevos profesionales para que sean capaces de mantener y optimizar estos sistemas, los problemas técnicos y de rendimiento de hoy se convertirán en un lastre que asumirán las próximas generaciones.
Ante este imperativo de formación especializada y relevo generacional, me permito hacer cinco propuestas, empezando por reintroducir COBOL, al menos de forma optativa, en los grados de Ingeniería Informática y en los ciclos formativos.
En segundo lugar, es necesario fortalecer la colaboración entre universidades y empresas tecnológicas para ofrecer formación conjunta. Tercero, impartir formación en empresas TI a programadores COBOL en activo sobre rendimiento y optimización. Cuarto, valorar el talento maduro y aprovechar la experiencia acumulada. Y quinto, facilitar la contratación en remoto de profesionales especializados, tanto comunitarios como extracomunitarios.
Porque el mainframe y COBOL siguen ahí, discretamente, con ‘perfil bajo’, haciendo que todo funcione. Como el corazón que late y pasa desapercibido. Quizá ‘la modernidad’ debería empezar por reconocerlo.
