El código del mainframe se moderniza

Se evidencia una carencia de programadores de Cobol y la necesidad de un software "ágil"

12 MAY 2006

Partiendo de la premisa de que el mainframe no ha muerto, la clave está en redefinir las aplicaciones volcadas en el hardware. El software desarrollado hace años no es el mismo que se necesita en la actualidad, porque los requerimientos y las necesidades de las empresas tampoco son iguales. Se impone la necesidad de reescribir los códigos del mainframe. Según algunas estimaciones, el valor total de las aplicaciones que residen hoy en día en los mainframes excede la cifra de 1.000 millones de dólares. La mayoría de ese código se ha ido escribiendo a lo largo de los últimos 40 años en Cobol, mezclado con ensamblador, PL/1 y 4GL. El problema surge porque estos programas no encajan todo lo bien que debieran con los sistemas distribuidos de hoy en día, con lo que su reescritura se convierte en una tarea inabarcable. Con el retroceso en el número de programadores en Cobol previsto para la próxima década y la necesidad de un software más ágil y con menos gastos de operatividad, las organizaciones de TI han empezado a marcar planes de transición para aplicaciones mainframe. El truco reside en determinar no sólo qué aplicaciones hay que modernizar, sino también cómo hacerlo y dónde deben residir. Las aplicaciones van encajando en uno de los siguientes tres grupos, según su tamaño, asegura Dale Vecchio, analista de Gartner. Las de menos de 500 MIPS migran a sistemas distribuidos. Así, al empezar a deshacerse de las aplicaciones pequeñas, las empresas pueden moverse a una aplicación conjunta; exportar la aplicación a Unix, Linux o Windows; o, en algunos casos, reescribir las aplicaciones para ejecutarlas en un entorno .Net o Java. En el campo que va de los 1.000 MIPS en adelante, el mainframe sigue siendo la plataforma preferida. Mientras, las aplicaciones entre 500 y 1.000 MIPS quedan en un área gris donde no está claro cuál es la mejor alternativa. Una estrategia que se va imponiendo para estas aplicaciones es dejar Cobol tal y como está y usar arquitecturas orientadas a servicios (SOA) para exponer interfaces determinantes que permitan a los desarrolladores de sistemas aislar el código. Lo cierto es que Cobol no se está extinguiendo, pero tampoco está avanzando. Aunque se espera que la base de código Cobol en mainframes se incremente de un 3 a un 5% al año, eso se interpreta más bien como un efecto secundario del mantenimiento, constatan fuentes de Ovum. Y es que Cobol no es una “asignatura de estudio”, sino que se considera como “latín”, con lo que los fabricantes han abandonado la idea de evolucionar el lenguaje Cobol para aplicarlo al desarrollo de los sistemas distribuidos. Transfiriendo recursos y activos La posibilidad de reprogramar millones de líneas de código se antoja, como poco, difícil. Se trata de una inversión muy importante y de un nivel de trabajo considerable. Lo ideal sería una transición gradual a aplicaciones agrupadas, “una tendencia que podría ayudar a las empresas”, según apuntan fuentes de Ovum. Y es que alrededor del 80% de los procesos financieros centrales es el mismo en los distintos bancos, por lo tanto, en un período de 10 años, quizás no tenga demasiado sentido disponer de un programa de ahorro propio y exclusivo. Otra opción pasa por migrar algunas aplicaciones de menor criticidad, con el propósito de liberar la capacidad de los mainframes. La razón principal reside en los costes, ya que los gastos de operación totales de ejecutar aplicaciones y modificarlas en un equipo mainframe pueden ser muy elevados. Si bien algunos proveedores ya han empezado a ofrecer estrategias bajo demanda, cuyo coste se basa en el uso requerido, lo cierto es que han sido menos los proveedores de software para mainframes que han optado por seguir el mismo camino. Fuentes de la firma Ovum han destacado que “aquellos fabricantes que no se unan a la tendencia de ofrecer flexibilidad en los precios, estarán acelerando el declive de su negocio”. Actualizaciones in situ Algunas compañías ya han iniciado la carrera para la actualización de las aplicaciones de sus mainframes. Sin embargo, no es tarea fácil, ya que reprogramar las aplicaciones no siempre es algo práctico, es decir, implica extraer y recolocar, lo que supone que las modificaciones pueden no encajar tan bien como cuando se desarrolló inicialmente. La transición también requiere más potencia y, además, otra cuestión reside en si la estrategia incluirá a las aplicaciones de mayor tamaño. En la gama alta, las empresas TI comienzan a moverse a SOA porque no hay otras opciones, aseguran fuentes de Ovum, y “la esperanza para los usuarios de mainframe es que WebSphere y Java puedan funcionar con la misma calidad de servicio que uno ha acabado esperando de CICS, IMS y Cobol”. Inhibidores del uso del mainframe ------------------------------------------------ Diversos responsables de centros de datos citaron los costes del software como el principal motivo de inhibición a la hora de aumentar el uso de sus mainframes. • Costes de hardware: 1% • Costes de software de IBM: 15% • Costes de software de terceras empresas: 47% Base de la muestra: 100 asistentes a conferencias de centros de datos La sequía de talentos de Cobol -------------------------------------------- Las universidades ya no ofrecen más programadores de Cobol y el manejo de ese lenguaje es una de las tres mayores preocupaciones de los fabricantes de mainframes, afirma Dale Vecchio, analista senior de Gartner. Algunas empresas afirman que ya están teniendo problemas para contratar programadores de Cobol, con lo que comienza a ser un hecho la dificultad de encontrar gente como soporte. De hecho, esta es una de las razones por las que algunas empresas están optando por migrar a una nueva arquitectura de aplicaciones construida alrededor de Java o de WebSphere. Mientras tanto, el número de programadores con experiencia también se está reduciendo. Y es que muchos desarrolladores de Cobol están entrando en la edad lógica de jubilación, lo que abre el reto de la selección de personal. Sin embargo, hay voces que restan importancia a este asunto, aludiendo a la estabilidad de las aplicaciones Cobol. Gary Barnett, analista en Ovum, insiste en que el mundo de las TI no tiene por qué caer en el pánico. “No hay una crisis de talentos”, defiende. Aunque hay menos programadores con alta formación en mainframe, muchas de las aplicaciones Cobol existentes son muy estables y no necesitan demasiado mantenimiento. Además, las herramientas están evolucionando de manera que con un solo desarrollador se pueda mantener más código del que era posible sólo hace unos años. Ovum predice que la cantidad de código Cobol en uso crecerá del 3 al 5% de manera anual hasta 2010, pero eso afectará