DAVID GUIJARRO, CTO de WiZink.
ROBERTO ARIAS, responsable de Desarrollo Negocio Internacional y para la Oferta de Modernización en Servicios Financieros en Minsait.
CARLOS AZA, responsable de Modernización del Mainframe en Arquitecturas de Indra Group.

«En menos de un año hemos reducido el TCO entre un 30 y un 40%”

El mainframe tiene mala prensa. Se lo asocia con tecnología de otra época, con salas de servidores que huelen a los años ochenta y con lenguajes de programación que los programadores jóvenes prefieren no tocar. Sin embargo, sigue procesando la mayoría de las transacciones financieras a nivel global.

Según Roberto Árias, responsable de Desarrollo Negocio Internacional y para la Oferta de Modernización en Servicios Financieros en Minsait, en España más del 90% de los bancos mantienen sus procesos críticos sobre estas arquitecturas.

“Aunque entidades como WiZink han iniciado la migración de sus cargas a la nube, el mainframe se mantiene como un activo estratégico por la combinación que ofrece en cuanto a gestión de cargas masivas, alta disponibilidad y seguridad”.

El de la seguridad es un argumento de peso para estos entornos, que ofrecen una fiabilidad difícil de encontrar en otras tecnologías. “Ante el aumento actual de las brechas de seguridad, el mainframe sigue siendo relevante porque, aunque no es invulnerable, presenta una menor exposición que otros sistemas abiertos”.

Para muchas organizaciones, estos sistemas han sido la base de su estabilidad durante décadas y, gracias a las nuevas herramientas de desarrollo, ahora permiten incluso atraer talento joven que ayude a mantener estos procesos críticos en plataformas modernas. “No se trata solo de tecnología heredada, sino de una infraestructura robusta que sigue garantizando la continuidad operativa y la seguridad de las transacciones financieras más importantes a nivel global”.

¿Freno a la innovación?

No es nostalgia ni inercia: es el reconocimiento de que estas plataformas ofrecen una combinación de disponibilidad, seguridad y capacidad de proceso difícil de replicar. La gran cuestión en torno al mainframe no es que no funcione.

Tal y como subraya Carlos Aza, responsable de Modernización del Mainframe en Arquitecturas de Indra Group, el gran reto es lo que ocurre cuando empiezan a quedarse sin recambios, cuando los costes de mantenimiento suben y cuando la velocidad de evolución de los canales digitales supera con creces el ritmo al que puede evolucionar el backend.

Nuestra prioridad era eliminar las dependencias de una infraestructura que se estaba volviendo compleja y difícil de mantener

“Ambos mundos avanzan a velocidades distintas: mientras que el canal digital evoluciona con extrema rapidez, el desarrollo en el mainframe es más pausado debido a su tipología, a la forma en que se enfocan sus evolutivos y a las características de los equipos que están detrás”.

Para evitar que el mainframe actúe como un cuello de botella, el enfoque estratégico actual no consiste necesariamente en eliminarlo por completo, sino en extraer de él toda aquella funcionalidad que no sea estrictamente core, como por ejemplo la venta de nuevos productos. Al trasladar estas capas de negocio a entornos más flexibles, las entidades consiguen mejorar drásticamente su time to market y reducir los tiempos de respuesta, asegurando que los ciclos de innovación no se vean lastrados por la lentitud inherente a los sistemas tradicionales.

Esta “limpieza” de la arquitectura permite que el banco recupere la agilidad necesaria para competir en un entorno digital sin comprometer la robustez de sus procesos críticos.

Hay además una cuestión generacional que complica el panorama. Los equipos con experiencia real en Cobol, PL1 o Natural están llegando al final de sus carreras. Encontrar programadores jóvenes dispuestos a trabajar en esos lenguajes es cada vez más difícil, y formarlos desde cero requiere un esfuerzo que muchas organizaciones ya no están en condiciones de asumir.

El mainframe no va a desaparecer pronto, pero su ecosistema de talento sí se está reduciendo, y eso es una presión añadida sobre las organizaciones que todavía dependen de él.

Modernización del mainframe en WiZink

WiZink es un banco nativo digital que nació sin infraestructura hardware propia. Hace aproximadamente una década, cuando se constituyó como entidad independiente tras la integración de Barclaycard, optó por el mainframe para gestionar determinados procesos críticos. La decisión, según David Guijarro, CTO de WiZink, respondía a criterios que entonces eran difíciles de discutir: alta disponibilidad, seguridad contrastada y conocimiento interno de la tecnología.

“Sin embargo, tras una década de operación, fuimos conscientes de que el modelo debía evolucionar por tres motivos fundamentales: la obsolescencia de la infraestructura hardware, la necesidad de ganar flexibilidad para responder al negocio y los crecientes costes operativos que se incrementaban año tras año. Nuestra prioridad era eliminar las dependencias de una infraestructura que se estaba volviendo compleja y difícil de mantener en el tiempo”.

Ahora, al dar el salto a la nube, no solo han mantenido la misma fiabilidad que tenían en el mainframe, sino que pueden incorporar tecnologías modernas de forma más sencilla y atraer talento joven, para quien el entorno cloud es mucho más atractivo que el paradigma tradicional del Cobol.

Replataformización: coste y tiempos acotados

Ante un proceso de modernización de mainframe las organizaciones tienen varias alternativas. Pueden reescribir las aplicaciones desde cero en un lenguaje moderno, que ofrece una mayor renovación funcional, pero multiplica el riesgo y el tiempo de ejecución; pueden optar por una transformación del lenguaje, migrando el código Cobol a Java o Python mediante herramientas automatizadas; o pueden elegir la replataformización con las soluciones de Rocket Software: mover las aplicaciones existentes a una nueva infraestructura manteniendo intacta la lógica de negocio.

WiZink eligió esta tercera opción. Para Guijarro, fue la que mejor equilibraba modernización, riesgo y coste. “Nos ofrecía la posibilidad de ejecutar una migración en un periodo inferior a un año, reducir costes de hardware, licenciamiento y operación, a la vez de ganar flexibilidad al desplegar la nueva infraestructura sobre la nube pública de AWS”. Además, la lógica de negocio codificada en Cobol llevaba una década testada y era estable. El conocimiento interno de ese código era un activo que no tenía sentido sacrificar.

Roberto Arias añade una perspectiva que va más allá del caso concreto. Desde el punto de vista de la consultoría, este es un paso muy estratégico. Muchas entidades no son plenamente conscientes de todo lo que tienen en sus sistemas. De hecho, hay aplicaciones que llevan 30 años sin tocarse. La replataformización actúa como una herramienta de descubrimiento que permite “limpiar la casa” antes de completar la mudanza tecnológica definitiva.

El modelo de replataformización ha permitido a WiZink ejecutar una migración en un periodo inferior a un año

“Al mover el mainframe a sistemas abiertos en un tiempo acotado, aseguramos el éxito del proyecto y obtenemos beneficios rápidos, facilitando el camino para futuras modernizaciones o la integración de nuevas tecnologías que antes eran inaccesibles”.

En un entorno donde la tecnología avanza tan rápido, acotar el tiempo es vital; los proyectos excesivamente largos corren el riesgo de quedar obsoletos antes de finalizar sin haber entregado los beneficios esperados.

Las fases que deciden el resultado

La modernización no es un proyecto de software al uso. El código Cobol es una parte importante, pero pequeña, del sistema que hay que migrar. Dentro de un mainframe conviven sistemas de ficheros, bases de datos, sistemas de integración, mensajería, planificadores de procesos batch y sistemas de control. Pensar que tomar el código y ejecutarlo en otra plataforma es suficiente es un error habitual, y costoso.

Existen tres pilares fundamentales, según sostiene Carlos Aza, que determinan el éxito de estos proyectos. En primer lugar, una fase de análisis y descubrimiento exhaustiva, que incluye planificar qué se va a hacer con todos los componentes, no solo con el código. “Esa fase es también la que más sorpresas depara. Las organizaciones que llevan décadas sobre mainframe han acumulado componentes y dependencias que en muchos casos nadie recuerda con precisión”.

El segundo requisito es la implicación de las áreas de negocio. Es frecuente que los equipos de negocio adopten una postura de mínima intervención: quieren que todo funcione igual que antes y prefieren no conocer los detalles técnicos. Aza considera que ese enfoque es un riesgo.

“El negocio tiene que estar implicado desde el principio porque es posible que haya que aprovechar para limpiar procesos que se ejecutaban por restricciones técnicas del mainframe y que ya no son necesarios. Que prefiera no cambiar nada es legítimo, pero que sepa que se están haciendo cambios es imprescindible”.

No se trata de convertir el proyecto en una oportunidad de rediseño funcional sin límites. El margen de cambio tiene que ser acotado porque cada modificación dificulta la comparación entre el sistema original y el migrado. Lo que sí tiene sentido es aprovechar para eliminar restricciones técnicas: lanzar cadenas de procesos en paralelo que antes esperaban unas a otras o simplificar flujos que se habían construido condicionados por las limitaciones del entorno.

La tercera fase crítica es el testing y puede llegar a consumir la mitad del tiempo total. El objetivo es verificar que los procesos migrados se comportan exactamente igual que en el origen: mismos resultados, tiempos equivalentes o mejores, ningún problema nuevo introducido por el cambio de plataforma.

Según Aza, el modelo de despliegue también condiciona el resultado: “en proyectos de gran tamaño, intentar migrarlo todo de una vez —en un modelo big bang—es una garantía de fracaso. Hay que diseñar un faseado que permita que lo ya migrado conviva con lo que todavía permanece en el mainframe”.

El choque cultural

Más allá de la arquitectura técnica, la migración es también un proceso de gestión del cambio. Los equipos que trabajan en mainframe y los que lo hacen en entornos cloud tienen culturas de trabajo y velocidades de desarrollo distintas y, en la práctica, lenguajes distintos. Según Roberto Arias, encontrar quién puede actuar de intérprete entre ambos mundos es uno de los retos más subestimados de este tipo de proyectos.

Nuestra prioridad era eliminar las dependencias de una infraestructura que se estaba volviendo compleja y difícil de mantener

De hecho, David Guijarro defiende que el mayor reto de este proyecto no ha sido el tecnológico, sino el cultural. “Hablamos de equipos con mucha experiencia y un conocimiento profundo del negocio, pero que no se habían movido del entorno mainframe en 30 años. Al introducir conceptos como cloud, metodologías ágiles o despliegues basados en DevOps, el impacto inicial es fuerte. Trabajar ese aspecto, y hacer entender que podían aprender de los consultores que llegaban a ayudarles, fue uno de los puntos más críticos del proyecto”.

Frente a esto, era necesario transmitir que la curva de aprendizaje era inevitable: que, al principio, la velocidad de desarrollo sería inferior y que eso era lo esperado; pero que el resultado, una vez superada la curva inicial, sería positivo. “En un proyecto de esta naturaleza, el apoyo de la dirección es clave”, afirma Guijarro.

En cualquier caso, según Roberto Arias, la gestión del cambio y el reskilling de los empleados han sido piezas angulares. “El éxito de WiZink ha radicado en su capacidad para adaptar el talento interno, permitiendo que profesionales senior sigan aportando su valor en un entorno mucho más atractivo y moderno, lo cual también facilita la captación de perfiles jóvenes que veían el mundo del Cobol como algo obsoleto”.

El papel de la inteligencia artificial

El proyecto de WiZink comenzó antes de que la inteligencia artificial se convirtiera en una herramienta de trabajo habitual en los equipos de desarrollo. Cuando se planteó la propuesta técnica, la IA estaba disponible pero muy pocos la utilizaban de forma sistemática.

La IA, según apunta Roberto Arias, está actuando como un acelerador muy importante en fases que antes requerían de más tiempo, especialmente a la hora de entender funcionalmente las aplicaciones o en la definición y ejecución de las pruebas, permitiendo automatizar validaciones que de otro modo serían inabarcables.

Carlos Aza apunta que, aunque no estaba en la propuesta técnica inicial, han utilizado la IA para definir scripts de comparativa entre los ficheros generados en el entorno original y el migrado. Automatizar la generación de casos de prueba aceleró un trabajo que, si se hubiera realizado manualmente, habría llevado mucho más tiempo.

“No se puede plantear un proyecto de transformación de esta envergadura sin el uso de IA. La evolución del último año te ofrece ventajas que no puedes ignorar, sobre todo en validación de pruebas, análisis de dependencias y documentación”.

No se puede plantear un proyecto de transformación de esta envergadura sin el uso de IA

En cualquier caso, los portavoces coinciden en un mensaje clave: la IA no elimina la necesidad de contar con expertos, tanto a nivel de negocio como técnico, que validen la solución final. Todavía no está el estado del arte como para simplificar ese conocimiento experto hasta el punto de prescindir de él.

Los resultados

Una vez ejecutado el proyecto, el beneficio más visible y rápido fue la reducción del coste total de propiedad de entre un 30 y un 40%. Esto se ha logrado gracias a la eliminación de las costosas dependencias del hardware de mainframe y a la adopción de modelos de pago por uso en la nube, lo que se traduce en un ROI mucho más rápido que otros proyectos tecnológicos de esta envergadura. Además, Guijarro apunta que, “para la dirección, ver materializarse ese ahorro en un tiempo breve fue también una validación del enfoque elegido”.

El segundo beneficio fue la flexibilidad operativa. La infraestructura ya no depende de un único proveedor de hardware. WiZink está desplegado en AWS, pero podría migrar a otro cloud manteniendo la tecnología de desarrollo. Además, puede escalar su capacidad en función de picos de demanda predecibles, algo que antes implicaba comprar más hardware o contratar más licencias con compromisos a largo plazo.

El tercero fue la integración con los marcos de control corporativos. En el mainframe, la seguridad, la monitorización y el control de costes se gestionaban con herramientas separadas del resto de la compañía. En cloud, todo eso se unifica: el banco gestiona la infraestructura migrada con los mismos procesos y herramientas que usa para el resto de sus sistemas. La coherencia operativa que eso genera no es un detalle menor cuando se gestionan procesos bancarios críticos.

Para la dirección, ver materializarse ese ahorro en un tiempo breve fue también una validación del enfoque elegido

Otra de las ventajas llegará en los próximos meses: la capacidad de integrar inteligencia artificial y automatización de procesos que antes era compleja por las especificaciones del mainframe. Esa plataforma es ahora también la base sobre la que el banco puede integrar en su flujo de desarrollo el copilotaje con IA, analizar el código antes del despliegue y adoptarlo progresivamente para tareas concretas.

Pero, según apunta Guijarro, quizá el indicador más significativo del éxito del proyecto sea el más difícil de cuantificar: el negocio no se enteró de que habían cambiado de plataforma. “Los equipos de tecnología sí lo notaron, porque ahora pueden hacer cosas que antes no podían. Pero desde el lado del negocio, la migración fue invisible”.

Un mercado en movimiento

El de WiZink no es un caso aislado. En España, prácticamente todas las entidades financieras de tamaño medio o grande están estudiando o ejecutando alguna forma de modernización de sus sistemas mainframe. Según los directivos de Indra Group, la IA y la inteligencia generativa han acelerado esa tendencia de forma significativa: organizaciones que hace dos o tres años no se planteaban tocar sus sistemas porque funcionaban bien están ahora evaluando cómo y cuándo modernizarlos.

Según Carlos Aza, hay dos vertientes: por un lado, la adopción de modelos DevOps y copilotos de IA dentro del propio mainframe para facilitar el trabajo de desarrolladores que no dominan lenguajes como Cobol o PL1. Por otro, una tendencia creciente hacia arquitecturas homogéneas en Java, .NET o Python para solucionar la escasez de talento especializado. Un proceso que hasta hace poco parecía inalcanzable por tiempo y recursos, y que ahora, con el apoyo de herramientas de IA, puede plantearse en plazos razonables.

El gran objetivo de las entidades es “liberar el dato” para poder explotar toda su riqueza informativa

“Aunque la IA acelera enormemente la conversión de código y el entendimiento funcional, no es infalible; requiere una gobernanza y monitorización humana experta para asegurar que la funcionalidad crítica no se pierda en el proceso”.

A nivel estratégico, apunta Roberto Arias, el gran objetivo de las entidades es “liberar el dato” para poder explotar toda su riqueza informativa. Estamos viendo una actividad intensa no solo en España, sino también en mercados como Portugal o Latinoamérica, donde se están realizando migraciones de arquitecturas complejas a entornos modernos como Java sobre framework Quarkus.

Es cierto que la replataformización sigue siendo la opción más viable por costes y tiempos, pero la IA está abriendo la puerta a abordar tecnologías “olvidadas” que hasta ahora nadie se atrevía a tocar, como PowerBuilder, Visual FoxPro u Oracle Forms. El mix se define en función de los requerimientos concretos del cliente, su capacidad de absorber cambios y el estado de sus equipos internos.

“En definitiva, estamos en un momento de mercado apasionante, donde la tecnología por fin permite entender y evolucionar aplicaciones que llevaban décadas “bajo el escritorio” sin que nadie supiera exactamente qué hacían”.