Apostar por la transformación digital impulsada por el mainframe para los servicios financieros

Esta es la primera parte de una serie de cinco blogs sobre la modernización del mainframe.

Ya hemos explicado que la modernización de los mainframes no es solo para la industria financiera, así que ¿por qué no abordar el tema más importante? Los mayores retos de modernización del mundo se concentran en el sector bancario.

Antes de Internet y del cloud computing, y antes de los smartphones y las aplicaciones móviles, los bancos realizaban pagos a través de pasarelas de liquidación electrónica masivas y operaban mainframes como sistemas de registro.

Las empresas de servicios financieros se consideran instituciones porque gestionan y mueven los aspectos centrales de nuestro sistema económico global. Y el corazón palpitante de las instituciones financieras es el mainframe de IBM.

Los bancos son los que más tienen que ganar si tienen éxito (y más que perder si fracasan) a la hora de adaptar sus aplicaciones de mainframe y sus activos de datos a los estándares modernos de flexibilidad, agilidad e innovación similares a los de la nube para satisfacer la demanda de los clientes.

Hemos experimentado incertidumbres económicas mundiales en los últimos tiempos, desde la crisis de "demasiado grande para quebrar" de 2008 hasta nuestros altos tipos de interés actuales tras la pandemia, que han provocado la sobreexposición y la insolvencia de algunos grandes bancos depositantes.

Si bien las quiebras bancarias suelen ser el resultado de decisiones y políticas de mala gestión, hay buenas razones para atribuir parte de la culpa al retraso de las iniciativas y estrategias de modernización. ¿No podrían los ejecutivos haber realizado mejores análisis para detectar riesgos en los datos? ¿Por qué no lanzaron una nueva aplicación móvil? ¿Alguien los pirateó y bloqueó a los clientes?

Todo el mundo sabe que posponer la modernización de aplicaciones mainframe conlleva un coste de oportunidad, pero existe la creencia de que es arriesgado cambiar los sistemas que actualmente dan soporte a las operaciones.

Los bancos comunitarios y regionales pueden carecer de recursos técnicos, mientras que las instituciones más grandes tienen una cantidad abrumadora de deuda técnica, problemas de movimiento de datos de alta gravedad o tienen dificultades con el caso empresarial.

Es probable que los bancos grandes y pequeños hayan fracasado en una o más iniciativas de modernización o migración. A medida que se desechan los esfuerzos, los líderes de TI de estas organizaciones sintieron que mordían más de lo que podían masticar.

Transformar el esfuerzo de modernización no debería requerir una reescritura total del código del mainframe, ni un laborioso y costoso ejercicio de "lift-and-shift". En cambio, los equipos deberían modernizar lo que tenga sentido para las prioridades más importantes del negocio.

Aquí tiene algunos grandes casos de uso de bancos que fueron más allá de simplemente reiniciar iniciativas de modernización para mejorar significativamente el valor de sus mainframes en el contexto de arquitecturas de software altamente distribuidas y las altas expectativas actuales de experiencia del cliente.

Muchos bancos tienen miedo de abordar la deuda técnica dentro de su mainframe existente, que puede que se haya escrito en COBOL u otros lenguajes antes de la llegada de los sistemas distribuidos. A menudo, los ingenieros que diseñaron el sistema original ya no están presentes, y las interrupciones del negocio no son una buena opción, por lo que los responsables de la toma de decisiones de TI retrasan la transformación trasteando en el nivel intermedio.

Atruvia AG es uno de los principales proveedores de tecnología de servicios bancarios del mundo. Más de 800 bancos confían en sus servicios innovadores para casi 100 mil millones de transacciones anuales, respaldados por ocho sistemas IBM z15 que se ejecutan en cuatro centros de datos.

En lugar de eliminar y reemplazar, decidieron refactorizar in situ, escribiendo servicios RESTful en Java junto con el COBOL existente que se ejecuta en los mainframes. Al reemplazar gradualmente el 85 % de sus transacciones bancarias principales por Java moderno, pudieron crear nuevas funcionalidades para los clientes bancarios, mejorando al mismo tiempo el rendimiento de las cargas de trabajo en el mainframe en 3X.

La mayoría de los bancos tienen un plan de protección de datos que incluye algún tipo de redundancia para la recuperación ante desastres (DR), como una copia primaria del mainframe de producción en el centro de datos y quizás una copia de seguridad secundaria externa o una solución de cinta virtual que obtiene una nueva carga por lotes cada unos meses.

A medida que los volúmenes de datos aumentan inexorablemente en tamaño, con más transacciones y endpoints de aplicación, hacer copias de seguridad de ellos mediante tecnologías heredadas se vuelve cada vez más costoso y lleva mucho tiempo, y reconstituirlos también es lento, lo que puede dejar un hueco de recuperación en tiempo de inactividad. Existe una necesidad crítica de copias de seguridad y recuperación más oportunas para proteger el entorno informático del banco moderno, incluyendo ransomware.

ANZ, uno de los cinco principales bancos de Australia, buscaba aumentar su capacidad de realizar copias de seguridad de mainframe más rápidas y un rendimiento de DR más rápido para garantizar una alta disponibilidad para sus más de 8,5 millones de clientes.

Construyeron una capacidad de resiliencia entre sitios, ejecutando servidores IBM zSystems reflejados utilizando su función HyperSwap para permitir intercambios de almacenamiento multidestino sin necesidad de interrupciones, ya que cualquiera de los servidores idénticos puede ocuparse de las cargas de trabajo de producción si uno se somete a un proceso de copia de seguridad o recuperación.

Los líderes de TI de ANZ están tranquilos gracias a la mejor disponibilidad del sistema, pero más aún, ahora tienen una postura moderna de recuperación ante desastres que se puede certificar para ofrecer continuidad del negocio a sus clientes.

Los bancos dependen de análisis para casi todos los aspectos de las decisiones empresariales clave que afectan a la satisfacción del cliente, el rendimiento financiero, la inversión en infraestructuras y la gestión de riesgos.

Las consultas analíticas complejas sobre enormes conjuntos de datos en el mainframe pueden agotar los presupuestos informáticos y tardar horas o días en ejecutarse. Mover los datos a otro lugar, como un almacén de datos en la nube, puede conllevar retrasos de transporte aún mayores, lo que se traduce en datos obsoletos y decisiones de mala calidad.

Garanti BBVA, el segundo banco más grande de Turquía, implementó IBM Db2 Analytics Accelerator for z/OS, que acelera las cargas de trabajo mientras reduce el consumo de CPU en mainframe.

La separación de las cargas de trabajo de análisis del entorno de producción de mainframe permite a Garanti ejecutar más de 300 trabajos de análisis por lotes cada noche, y un informe de cumplimiento que solía tardar dos días en ejecutarse ahora solo tarda un minuto.

Los bancos compiten por su capacidad para ofrecer nuevas aplicaciones y ofertas de servicios innovadoras a los clientes, por lo que los equipos de desarrollo ágil contribuyen constantemente con características de software. Naturalmente, tendemos a generalizarlos como mejoras en el front-end de las aplicaciones para teléfonos inteligentes e integraciones basadas en API con servicios en la nube.

Pero espera, casi todas estas nuevas características acabarán tocando el mainframe. ¿Por qué no presentar al equipo de mainframe como participantes de primera clase en el movimiento DevOps para que puedan participar?

Danske Bank decidió incorporar a casi 1000 desarrolladores internos de mainframe a un movimiento de transformación DevOps en toda la empresa, utilizando IBM Application Delivery Foundation for z/OS (ADFz) como plataforma para el desarrollo de características, depuración, pruebas y gestión de versiones.

Incluso el código COBOL y PL/1 existente podría ingerirse en el pipeline de gestión de CI/CD y, a continuación, abrirse y editarse de forma intuitiva dentro de los IDE de los desarrolladores. Aquí se acabó el lío con las pantallas verdes. Ahora, Danske Bank puede lanzar ofertas al mercado en la mitad de tiempo que antes.

Lea el caso de éxito de Danske Bank https://www.ibm.com/es-es/case-studies/danske_bank_as

Incluso las empresas fintech más nuevas "nacidas en la nube" harían bien en considerar cómo sus propias innovaciones deben interactuar con un entorno informático híbrido en constante cambio de contrapartes.

Una transacción en una aplicación móvil acabará llegando a redes de pago globales, entidades reguladoras y otros bancos, cada uno con sus propios recursos de computación y almacenamiento en mainframe detrás de cada respuesta a la solicitud.

Aquí nunca habrá un camino único porque no hay dos bancos idénticos, y hay muchas posibles transformaciones que podrían producirse en el proceso de modernización de aplicaciones mainframe.

Los líderes de TI deben empezar por algún punto y seleccionar casos de uso que mejor se adapten a sus necesidades empresariales y a la arquitectura del entorno único de aplicaciones en el que se mantendrá el mainframe.

Para obtener más información, consulte los demás artículos de esta serie:

• Parte 1: "Modernización de aplicaciones mainframe más allá de la banca"
• Parte 2: “Utilizar la colaboración (no la migración) para modernizar sus aplicaciones de mainframe con la nube”
• Parte 4: “¿Mainframe y la nube? Es fácil con código abierto”