Por qué las transformaciones de "gran impacto" nunca funcionarán y qué hacer en su lugar
Es tentador pensar en el mainframe como una reliquia: un sistema obsoleto que no tiene lugar en una empresa moderna. Pero al igual que el microondas sigue siendo un elemento fijo en las cocinas de alta gama, el mainframe todavía tiene su lugar: transacciones de alto volumen y baja latencia. Donde la velocidad y la consistencia importan más que la flexibilidad o la toma de decisiones.
Piense, por ejemplo, en:
- Transacciones de cajeros automáticos
- Operaciones de trading de alto volumen
- Actualizaciones de registros por lotes
Pero existe un problema: no todas las cargas de trabajo en el mainframe entran en esas categorías. En su momento las empresas tuvieron que usar lo que estaba disponible para ejecutar aplicaciones de gran complejidad que requieren alta interacción. Los mainframes no eran lo ideal, pero estaban disponibles.
Ahora esas mismas organizaciones están trasladando procesos a la nube y buscando formas de integrar la automatización, acelerar con IA y sacar más partido de sus datos. Y ahora se encuentran atrapadas por el mainframe, con código heredado que impulsa procesos opacos, decisiones y políticas convertidas en cajas negras por la falta de documentación explícita y datos en un circuito cerrado.
Más del 75% de los proyectos de modernización fallan.1 ¿Por qué?
Las soluciones a la dependencia del mainframe han adoptado diferentes formas.
La técnica: Replataforma: Reconstruir todo el entorno del mainframe, minuciosamente, línea por línea, en la nube.
El problema: supone una cantidad increíble de trabajo, que depende de equipos de consultores sujetos al error humano. Y el resultado son solo las mismas versiones obsoletas replicadas en un lugar nuevo.
La técnica: Envolver y renovar: Se construye una capa de interfaz de usuario ágil y adaptable sobre las aplicaciones de mainframe para permitir cierta conexión con sistemas modernos y mejorar la usabilidad.
El problema: los viejos problemas permanecen bajo la superficie, y el mantenimiento, las actualizaciones y los cambios de proceso siguen suponiendo un esfuerzo enorme. No se está resolviendo el problema, se está ocultándolo.
La técnica: Elevar y trasladar: se trasladan las cargas de trabajo del mainframe en el entorno de la nube con una modificación mínima al código base existente.
El problema: hace poco para modernizar la propia aplicación. Las mismas estructuras monolíticas, reglas comerciales integradas y restricciones operativas acompañan al sistema a la nube.
Estos y otros métodos tradicionales no abordan la realidad de los mainframes: algunas partes son aptas para quedarse donde están, mientras que otras deben extraerse, reconstruirse para la nube y retirarse del mainframe. Pero la naturaleza de los mainframes heredados hace que eso sea increíblemente difícil de lograr. La lógica de negocio, el acceso a los datos y los flujos de trabajo están profundamente integrados en el código base; los límites no están claros; y los datos, la lógica y la interfaz de usuario están estrechamente acoplados.
La modularidad es la clave para la verdadera transformación de los sistemas heredados
Centrarse en aplicaciones empresariales compatibles con la nube (como el procesamiento de reclamos, las excepciones de pago, la gestión de cuentas, el manejo de fraudes, la gestión de cambios y mucho más), sin alterar los procesos transaccionales principales, es la receta del éxito. ¿Cómo es eso posible? A través de la IA.
El análisis de código impulsado por IA puede identificar y aislar la lógica de negocio oculta dentro de los programas COBOL. Pero aquí es donde las cosas se ponen interesantes: si bien algunas herramientas de análisis de código tienen como objetivo traducir COBOL a Java o HTML, el verdadero paso de modernización es transformar COBOL en documentación que pueda utilizarse para una aplicación nueva, replanteada y diseñada específicamente para la nube.
Una vez que se consigue acelerar el proceso de descubrimiento y el análisis de meses a días (o incluso hacer posible dicho descubrimiento en primer lugar), la modernización modular de aplicaciones pasa de ser otro proyecto indefinido y poco realista a ser un proceso de valor agregado, iterativo, repetible y escalable. Cada aplicación de mainframe modernizada puede entrar en funcionamiento en cuestión de semanas y comenzar a generar valor en un entorno de producto de inmediato, mientras el equipo identifica el siguiente objetivo.
Una fábrica para la modernización de mainframes
De esta manera, los proyectos de modernización y las partes interesadas de TI, proveedores, integradores de sistemas, usuarios de negocio y ejecutivos que los llevan a cabo se convierten en fábricas en miniatura, produciendo aplicaciones SaaS nativas de la nube una tras otra. Después de las primeras modernizaciones exitosas, el proceso se vuelve repetible. Los equipos crean un proceso de trabajo: analizar, replantear, implementar, repetir.
La modernización deja de ser una transformación que ocurre una vez por década para convertirse en un proceso industrializado.
Podrá analizar el código vinculado a una aplicación específica, replantearlo como un flujo de trabajo preparado para la nube, impulsado por IA y automatización, e implementarlo en una arquitectura preparada para el futuro, conectándose a o migrando sistemas de registro e integraciones según sea necesario, todo en el lapso de unos pocos meses. Y repetirlo una y otra vez.
A través de hiperescaladores como AWS, de prácticas de transformación consolidadas como Accenture o Infosys, y con la ayuda del entorno de trabajo de diseño de flujo de trabajo impulsado por IA,Pega Blueprint™, los CIO de las empresas pueden abordar los proyectos de modernización de mainframe que han pospuesto con un riesgo mínimo, un beneficio enorme y una iteración rápida.
1 Fuente: Survey: 79% of Application Modernization Projects Fail