{"id":6730,"date":"2022-03-30T16:38:18","date_gmt":"2022-03-30T15:38:18","guid":{"rendered":"https:\/\/telecomkh.info\/?p=6730"},"modified":"2022-03-30T16:38:18","modified_gmt":"2022-03-30T15:38:18","slug":"la-aventura-de-migrar-un-mainframe-el-analisis-de-viabilidad","status":"publish","type":"post","link":"https:\/\/telecomkh.info\/?p=6730","title":{"rendered":"La aventura de migrar un mainframe – El an\u00e1lisis de viabilidad"},"content":{"rendered":"

Cada d\u00eda 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 \u00e1giles 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\u00e1s elevados, tiempos mayores para entregar nuevas funcionalidades y dificultades cada vez mayores para encontrar personal formado con experiencia<\/strong><\/p>\n

 <\/p>\n

Por Herv\u00e9 Imbert, Director General IMC Group<\/em><\/span><\/p>\n

\u00bfTiene esto soluci\u00f3n? Nuestra primera propuesta consiste en sustituir dichas aplicaciones por otras nuevas con tecnolog\u00edas modernas, una arquitectura flexible, centrada en el cliente, con unos interfaces atractivos y con la anal\u00edtica y la seguridad integradas desde el dise\u00f1o. Sin embargo, esto no es posible para la mayor\u00eda de las empresas. En las aplicaciones antiguas est\u00e1 embebido todo el conocimiento del negocio y la migraci\u00f3n es tan grande y compleja que precisa proyectos de varios a\u00f1os y conlleva una enorme complejidad. Y durante el tiempo de la migraci\u00f3n resulta dif\u00edcil dar respuesta a las necesidades de la empresa.
\nUna alternativa es migrar las aplicaciones a plataformas modernas sin tener que modificarlas. Las empresas que eligen decisi\u00f3n 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\u00f3n de ellas.
\nSin embargo, y aunque las ventajas son evidentes, cuando tomamos la decisi\u00f3n de migrar un mainframe nos embarcamos en una aventura complicada. Hay casos conocidos de importantes fracasos y de proyectos con una duraci\u00f3n mucho mayor que la esperada.
\nEl primer paso consiste en realizar un an\u00e1lisis de viabilidad. Es fundamental saber a qu\u00e9 nos enfrentamos y, aunque parezca lo contrario, no es algo obvio. Las aplicaciones puede que hayan sido desarrolladas hace 20 o 30 a\u00f1os por personas que ya no est\u00e1n en la empresa. El software est\u00e1 lleno de trampas: programas que no se han tocado en a\u00f1os y puede que ni seamos conscientes que existen, programas desarrollados en ensamblador con utilidades extra\u00f1as que ya nadie recuerda porqu\u00e9 se utilizaron y, en general, con una documentaci\u00f3n escasa, en el mejor de los casos. Es muy importante conocer hasta el \u00faltimo programa de la instalaci\u00f3n. No basta con decir es un 95% Cobol. Seguramente el 5% restante nos d\u00e9 m\u00e1s 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.
\nTambi\u00e9n hay que analizar las cargas y consumos. Es preciso conocer d\u00f3nde est\u00e1n los picos de consumo, cu\u00e1les son las transacciones m\u00e1s consumidoras, los consumos de los procesos y las ventanas de tiempo comprometidas con negocio.
\nEl segundo paso que hay que realizar es un estudio de coste-beneficio. Incluso aunque no se tome la decisi\u00f3n basada en ahorros de coste y preocupen la modernizaci\u00f3n de la instalaci\u00f3n 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\u00f3n de gran calidad y conocidas por el fabricante y nuestro personal desde hace mucho tiempo, a un entorno mucho m\u00e1s flexible, estandarizado, pero que precisa de herramientas diferentes y formaci\u00f3n de los equipos distinta. Es importante que los costes justifiquen la decisi\u00f3n y nos ayuden a defender el proyecto.
\nEl an\u00e1lisis 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\u00eda, personal, etc. y, lo equivalente en el entorno futuro. De forma adicional hay que considerar los costes del propio Proyecto de migraci\u00f3n (Capex) es decir, licencias adicionales y servicios de migraci\u00f3n y formaci\u00f3n necesarios.
\nEs importante reflexionar sobre la soluci\u00f3n futura y sus costes. Considerando un periodo de tres o cuatro a\u00f1os, deber\u00edamos tener unos ahorros considerables que nos justifiquen el proyecto. Si no fuera as\u00ed habr\u00eda que valorar si el coste de las nuevas licencias es demasiado elevado y buscar otras alternativas m\u00e1s baratas. Tambi\u00e9n deber\u00edamos evitar tener demasiadas dependencias y no deber\u00edamos estar sujetos a un fabricante.
\nEn el dise\u00f1o de la soluci\u00f3n futura hay que considerar la plataforma objetivo, pero tambi\u00e9n hay que pensar en el proyecto de migraci\u00f3n y su mayor o menor complejidad. En una migraci\u00f3n de este tipo hay tres factores bastante diferenciados: las transacciones, los procesos y los datos.
\nHabr\u00eda que evitar tener que hacer una migraci\u00f3n \u201cbig bang\u201d, es decir en un paso \u00fanico. El riesgo de la migraci\u00f3n es muy elevado. El poder realizar migraciones incrementales reduce el riesgo, aunque seguramente precise de soluciones de convivencia adicionales.
\nMuchas instalaciones tienen los picos de consumo en el teleproceso y muchas de las transacciones de mayor consumo son s\u00f3lo de consultas. Si planificamos una migraci\u00f3n incremental eligiendo las de consultas de mayor consumo podremos conseguir ahorros en las primeras fases de la migraci\u00f3n y adem\u00e1s tendremos la ventaja que poder volver muy r\u00e1pido a la situaci\u00f3n inicial si se produce alg\u00fan 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\u00f3n de datos. Los datos pueden migrarse en una segunda fase.
\nLa problem\u00e1tica de los procesos es diferente. En este caso debemos tener especial atenci\u00f3n a que los tiempos de proceso y verificar que no ser\u00e1n 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\u00e1neamente trabajos en la plataforma antigua y nueva. para ello ser\u00e1 necesario un mecanismo que nos permita compartir ficheros entre los dos entornos.
\nTambi\u00e9n es necesario migrar las planificaciones. Las planificaciones de producci\u00f3n son una mec\u00e1nica 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\u00e1s grandes a final de mes, m\u00e1s ligeros durante el resto del mes), etc\u2026. Cuando se traslada a un entorno open, muchos de estos factores cambian por duraciones diferentes en el nuevo entorno y hay que volver a reescribir gran parte de la planificaci\u00f3n. Adem\u00e1s de que la mayor\u00eda de las veces no se puede convertir la planificaci\u00f3n del mainframe a un planificador para sistemas open, incluso aunque sea del mismo fabricante.
\nOtro factor que se debe considerar es la capacidad del nuevo entorno. Los entornos open, tradicionalmente no est\u00e1n preparados para funcionar con una saturaci\u00f3n de los procesadores al 100% como el mainframe sino que pueden tener problemas si se acercan a los m\u00e1ximos de consumo. Se ha mejorado mucho la resistencia de los sistemas open, pero no tienen todav\u00eda la robustez ante cargas importantes y prolongadas del mainframe.
\nTambi\u00e9n la cantidad de datos que puede soportar un cloud de servidores open est\u00e1 m\u00e1s limitado que en mainframe donde el DB2 est\u00e1 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\u00e1s potentes no son capaces de soportar los grandes vol\u00famenes que soportan los grandes bancos de nuestro pa\u00eds. Evidentemente existen soluciones, pero hay que tenerlas muy en cuenta en los an\u00e1lisis de coste y beneficios.
\nPodemos concluir que la migraci\u00f3n 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.<\/p>\n

Arriba, en la foto, Herv\u00e9 Imbert, Director General IMC Group \/ imagen cortes\u00eda de IMC Group<\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Cada d\u00eda 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 \u00e1giles 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\u00e1s … <\/p>\n

Continue reading \u00abLa aventura de migrar un mainframe – El an\u00e1lisis de viabilidad\u00bb<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":6731,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15],"tags":[],"_links":{"self":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/6730"}],"collection":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6730"}],"version-history":[{"count":1,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/6730\/revisions"}],"predecessor-version":[{"id":6732,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/posts\/6730\/revisions\/6732"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=\/wp\/v2\/media\/6731"}],"wp:attachment":[{"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/telecomkh.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}