Banca en la transformación digital dirigida por mainframe para servicios financieros

Esta es la primera parte de un serie de blogs de cinco partes sobre la modernización de mainframe.

Ya cubrimos cómo la modernización del mainframe no es solo para la industria financiera, entonces, ¿por qué no abordar el tema de una vez? Los mayores desafíos de modernización del mundo se concentran en la industria bancaria.

Antes de Internet y la computación en la nube, y antes de los teléfonos inteligentes 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 tienen más que ganar si tienen éxito (y más que perder si fracasan) en llevar su aplicación de mainframe y patrimonios de datos a los estándares modernos de flexibilidad, agilidad e innovación similares a la nube para satisfacer la demanda de los clientes.

Hemos experimentado incertidumbres económicas globales en la memoria reciente, desde la crisis de "demasiado grande para quebrar" de 2008 hasta nuestras actuales altas tasas de interés posteriores a la pandemia que causaron sobreexposición e insolvencia de ciertos grandes bancos depositantes.

Si bien las quiebras bancarias suelen ser el resultado de malas decisiones y políticas de gestión, hay buenas razones para atribuir parte de la culpa a iniciativas y estrategias de modernización retrasadas. ¿No podrían haber realizado mejores análisis los ejecutivos para detectar riesgos dentro de 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 de mainframe tiene un costo de oportunidad, pero existe la creencia de que es arriesgado cambiar los sistemas que actualmente respaldan 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 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 abandonaban los esfuerzos, los responsables de TI de estas organizaciones sentían que habían asumido más de lo que podían abarcar.

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

Estos son algunos excelentes casos de uso de bancos que fueron más allá de simplemente reiniciar las 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 temen abordar la deuda técnica dentro de su mainframe existente, que puede ser 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 al realizar cambios en el nivel medio.

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 000 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, 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 centrales con Java moderno, pudieron crear nuevas funcionalidades para los clientes bancarios, al tiempo que triplicaron el rendimiento de las cargas de trabajo en el mainframe.

La mayoría de los bancos tienen un plan de protección de datos que incluye alguna forma de redundancia para la recuperación ante desastres (DR), como una copia principal 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 de tamaño, con más transacciones y endpoints de aplicación, hacer copias de ellos a través de tecnologías heredadas de copia de seguridad se vuelve cada vez más costoso y requiere más tiempo, y reconstituirlos también es lento, lo que puede dejar una brecha de DR en el 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, buscó aumentar su capacidad para realizar copias de seguridad de mainframe más oportunas y un rendimiento de DR más rápido para garantizar una alta disponibilidad para sus más de 8.5 millones de clientes.

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

El liderazgo de TI de ANZ obtiene tranquilidad gracias a una mejor disponibilidad del sistema; pero más aún, ahora tienen una postura moderna de recuperación ante desastres que puede certificarse para proporcionar continuidad de negocio a sus clientes.

Los bancos dependen de analytics avanzados para casi todos los aspectos de las decisiones comerciales clave que afectan la satisfacción del cliente, el rendimiento financiero, la inversión en infraestructura y la gestión de riesgos.

Las consultas analíticas complejas sobre grandes conjuntos de datos en el mainframe pueden consumir los presupuestos de computación 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 da como resultado datos obsoletos y decisiones de mala calidad.

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

La separación de las cargas de trabajo de analytics de las preocupaciones y los costos del entorno de producción del mainframe permite a Garanti ejecutar más de 300 trabajos por lotes de analytics 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 ágiles de desarrollo contribuyen constantemente con características de software. Naturalmente, tendemos a generalizarlas como mejoras frontend para aplicaciones de teléfonos inteligentes e integraciones basadas en API con servicios en la nube.

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

Danske Bank decidió incorporar a casi 1000 desarrolladores internos de mainframe en un movimiento de transformación de 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 luego abrirse y editarse intuitivamente dentro de los IDE de los desarrolladores. Aquí ya no hay que lidiar con pantallas verdes. Ahora, Danske Bank puede lanzar soluciones al mercado en la mitad del tiempo que antes.

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

Incluso las empresas de tecnología financiera más nuevas "nacidas en la nube" deberían 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.

Nunca habrá un camino único a seguir aquí porque no hay dos bancos idénticos, y hay muchas transformaciones posibles que podrían realizarse en el camino de modernización de aplicaciones de mainframe.

Los líderes de TI necesitan comenzar en algún lugar y seleccionar los casos de uso que mejor se adapten a sus necesidades de negocios y a la arquitectura del entorno de aplicaciones único en el que vivirá el mainframe.

Para aprender más, vea las otras publicaciones de esta serie:

• Parte 1: “Modernización de aplicaciones de mainframe más allá de la banca”
• Parte 2: “Usar 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 el código abierto”