Cada día son muchas las empresas que se encuentran con el problema de que tienen que competir con fintech o empresas nacidas digitales que tienen unos sistemas ágiles y flexibles y que utilizan cloud y plataformas de bajo coste mientras que ellas tienen que mantener aplicaciones antiguas en las plataformas mainframes con costes mucho más elevados, tiempos mayores para entregar nuevas funcionalidades y dificultades cada vez mayores para encontrar personal formado con experiencia.
¿Tiene esto solución? Nuestra primera propuesta consiste en sustituir dichas las aplicaciones por otras nuevas con tecnologías modernas, una arquitectura flexible, centrada en el cliente, con unos interfaces atractivos y con la analítica y la seguridad integradas desde el diseño. Sin embargo, esto no es posible para la mayoría de las empresas. En las aplicaciones antiguas está embebido todo el conocimiento del negocio y la migración es tan grande y compleja que precisa proyectos de varios años y conlleva una enorme complejidad. Y durante el tiempo de la migración resulta difícil dar respuesta a las necesidades de la empresa.
Una alternativa es migrar las aplicaciones a plataformas modernas sin tener que modificarlas. Las empresas que eligen decisión lo hacen por razones de flexibilidad, por evitar los riesgos de mantenerse en una plataforma con cada vez menor personal con conocimiento experto, por razones de ahorros de coste o por una combinación de ellas.
En las aplicaciones antiguas está embebido todo el conocimiento del negocio y la migración es tan grande y compleja que precisa proyectos de varios años
Sin embargo, y aunque las ventajas son evidentes, cuando tomamos la decisión de migrar un mainframe nos embarcamos en una aventura complicada. Hay casos conocidos de importantes fracasos y de proyectos con una duración mucho mayor que la esperada.
El primer paso consiste en realizar un análisis de viabilidad. Es fundamental saber a qué nos enfrentamos y, aunque parezca lo contrario, no es algo obvio. Las aplicaciones puede que hayan sido desarrolladas hace 20 o 30 años por personas que ya no están en la empresa. El software está lleno de trampas: programas que no se han tocado en años y puede que ni seamos conscientes que existen, programas desarrollados en ensamblador con utilidades extrañas que ya nadie recuerda porqué se utilizaron y, en general, con una documentación escasa, en el mejor de los casos. Es muy importante conocer hasta el último programa de la instalación. No basta con decir es un 95% Cobol. Seguramente el 5% restante nos dé más problemas que todo el resto y es preciso conocerlo desde el principio. Hay que asegurar que sabremos migrar a la plataforma futura todos los programas existentes.
Las aplicaciones puede que hayan sido desarrolladas hace 20 o 30 años por personas que ya no están en la empresa
También hay que analizar las cargas y consumos. Es preciso conocer dónde están los picos de consumo, cuáles son las transacciones más consumidoras, los consumos de los procesos y las ventanas de tiempo comprometidas con negocio.
El segundo paso que hay que realizar es un estudio de coste-beneficio. Incluso aunque no se tome la decisión basada en ahorros de coste y preocupen la modernización de la instalación o eliminar los riesgos, es importante que los ahorros justifiquen el proyecto. Estamos pasando de una plataforma mainframe, con rendimientos excelentes y herramientas de gestión de gran calidad y conocidas por el fabricante y nuestro personal desde hace mucho tiempo, a un entorno mucho más flexible, estandarizado, pero que precisa de herramientas diferentes y formación de los equipos distinta. Es importante que los costes justifiquen la decisión y nos ayuden a defender el proyecto.
El análisis de coste debe contemplar los gastos operativos del entorno actual y futuro (Opex), tales como software del mainframe, resto del software, hardware, infraestructura y energía, personal, etc. y, lo equivalente en el entorno futuro. De forma adicional hay que considerar los costes del propio proyecto de migración (Capex) es decir, licencias adicionales y servicios de migración y formación necesarios.
Es importante reflexionar sobre la solución futura y sus costes. Considerando un periodo de tres o cuatro años, deberíamos tener unos ahorros considerables que nos justifiquen el proyecto. Si no fuera así habría que valorar si el coste de las nuevas licencias es demasiado elevado y buscar otras alternativas más baratas. También deberíamos evitar tener demasiadas dependencias y no deberíamos estar sujetos a un fabricante.
En el diseño de la solución futura hay que considerar la plataforma objetivo, pero también hay que pensar en el proyecto de migración y su mayor o menor complejidad. En una migración de este tipo hay tres factores bastante diferenciados: las transacciones, los procesos y los datos.
Habría que evitar tener que hacer una migración “big bang”, es decir en un paso único. El riesgo de la migración es muy elevado. El poder realizar migraciones incrementales reduce el riesgo, aunque seguramente precise de soluciones de convivencia adicionales.
Habría que evitar tener que hacer una migración “big bang”, es decir en un paso único. El riesgo de la migración es muy elevado
Muchas instalaciones tienen los picos de consumo en el teleproceso y muchas de las transacciones de mayor consumo son sólo de consultas. Si planificamos una migración incremental eligiendo las de consultas de mayor consumo podremos conseguir ahorros en las primeras fases de la migración y además tendremos la ventaja que poder volver muy rápido a la situación inicial si se produce algún incidente en las etapas iniciales de la nueva plataforma. Los datos precisan un estudio aparte, pero considerando que muchas de las operativas de mayor consumo son consultas, una estrategia posible es mantener los datos en el mainframe y utilizar una herramienta de replicación de datos. Los datos pueden migrarse en una segunda fase.
La problemática de los procesos es diferente. En este caso debemos tener especial atención a los tiempos de proceso y verificar que no serán mayores en la nueva plataforma. Las ventanas de procesos tienen dependencias comprometidas con negocio que no pueden alterarse. En estos casos, lo deseable es poder ejecutar simultáneamente trabajos en la plataforma antigua y nueva. Para ello será necesario un mecanismo que nos permita compartir ficheros entre los dos entornos.
También es necesario migrar las planificaciones. Las planificaciones de producción son una mecánica muy bien rodada y optimizada y tienen en cuenta muchos factores como la potencia de los procesadores, el equilibrio de las particiones, las cargas del teleproceso y procesos, las horas adecuadas para cada proceso, la temporalidad de los datos (ficheros más grandes a final de mes, más ligeros durante el resto del mes), etc. Cuando se traslada a un entorno open, muchos de estos factores cambian por duraciones diferentes en el nuevo entorno y hay que reescribir gran parte de la planificación. Además de que la mayoría de las veces no se puede convertir la planificación del mainframe a un planificador para sistemas open, incluso aunque sea del mismo fabricante.
La cantidad de datos que puede soportar un cloud de servidores open está más limitado que en mainframe
Otro factor que se debe considerar es la capacidad del nuevo entorno. Los entornos open, tradicionalmente no están preparados para funcionar con una saturación de los procesadores al 100% como el mainframe, sino que pueden tener problemas si se acercan a los máximos de consumo. Se ha mejorado mucho la resistencia de los sistemas open, pero no tienen todavía la robustez ante cargas importantes y prolongadas del mainframe.
También la cantidad de datos que puede soportar un cloud de servidores open está más limitado que en mainframe donde el DB2 está acostumbrado a manejar enormes cantidades de datos y seguir dando un buen servicio y un buen rendimiento. Incluso los mayores gestores de bases de datos es sus versiones más potentes no son capaces de soportar los grandes volúmenes que soportan los grandes bancos de nuestro país. Evidentemente existen soluciones, pero hay que tenerlas muy en cuenta en los análisis de coste y beneficios.
Podemos concluir que la migración de programas antiguos a plataformas de menor costes tiene muchas ventajas que justifican el esfuerzo, pero tenemos que estar seguros que los costes de la nueva plataforma son los adecuados y que tenemos todos los componentes necesarios antes de embarcarse en el proyecto.
