Apostas em transformação digital liderada por mainframe para serviços financeiros

Esta é a primeira de uma série de cinco partes do blog sobre modernização de mainframe.

Já abordamos como a modernização do mainframe não é apenas para o setor financeiro, então por que não lidar com o “elefante na sala”? Os maiores desafios de modernização do mundo estão concentrados no setor bancário.

Antes da internet e da computação em nuvem, e antes dos smartphones e aplicativos móveis, os bancos estavam enviando pagamentos por meio de enormes gateways de liquidação eletrônica e operando mainframes como sistemas de registro.

As empresas de serviços financeiros são consideradas instituições porque gerenciam e migrar os aspectos centrais do nosso sistema econômico global. E o coração das instituições financeiras é o mainframe da IBM.

Os bancos têm mais a ganhar se forem bem-sucedidos (e o que mais perderem se falharem) ao elevar suas aplicações e propriedades de dados de mainframe aos padrões modernos de flexibilidade, agilidade e inovação semelhantes à nuvem, para atender à demanda dos clientes.

Já experimentamos incertezas econômicas globais nos últimos tempos, desde a crise do modelo “grande demais para quebrar” de 2008 até nossas atuais taxas de juros altas pós-pandemia, que causaram exposição excessiva e insolvência de certos grandes bancos correntistas.

Embora as falhas bancárias sejam frequentemente resultado de políticas e decisões de gestão ruins, há bons motivos para atribuir parte da culpa a iniciativas e estratégias de modernização atrasadas. Os executivos não poderiam ter feito análises melhores para identificar riscos nos dados? Por que eles não lançaram um novo aplicativo móvel? Alguém hackeou e bloqueou os clientes?

Todos sabem que há um custo de oportunidade em adiar a modernização de aplicações mainframe, mas há uma crença de que é arriscado mudar os sistemas que atualmente estão apoiando as operaçōes.

Os bancos comunitários e regionais podem não ter os recursos técnicos, enquanto instituições maiores têm uma quantidade enorme de dívida técnica, problemas de movimentação de dados de alta gravidade ou dificuldades com o caso de negócio.

Bancos grandes e pequenos provavelmente falharam em uma ou mais iniciativas de modernização ou migração. À medida que os esforços são descartados, os líderes de TI dentro dessas organizações sentem que podem mastigar.

Transformar o esforço de modernização não deve exigir uma reescrita do código de mainframe, nem um exercício trabalhoso e caro de lift-and-shift. Em vez disso, as equipes devem modernizar o que faz sentido para as prioridades mais importantes do negócio.

Aqui estão alguns casos de uso de bancos que foram além de simplesmente reiniciar as iniciativas de modernização para melhorar significativamente o valor de seus mainframes no contexto de arquiteturas de software altamente distribuídas e as altas expectativas de experiência do cliente de hoje.

Muitos bancos têm medo de lidar com a dívida técnica em seu código de mainframe existente, que pode ter sido escrito em COBOL ou outras linguagens antes do advento dos sistemas distribuídos. Muitas vezes, os engenheiros que projetaram o sistema original não estão mais presentes, e as interrupções de negócios não são uma boa opção, então os tomadores de decisão de TI atrasam a transformação ajustando-se à camada intermediária.

A Atruvia AG é uma das principais fornecedoras de tecnologia de serviços bancários do mundo. Mais de 800 bancos dependem de seus serviços inovadores para quase 100 bilhões de transações anuais, com o apoio de oito sistemas IBM z15 executados em quatro data centers.

Em vez de remover e substituir, decidiram refatorar no local, escrevendo serviços RESTful em Java juntamente com o COBOL existente em execução nos mainframes. Ao substituir gradualmente 85% de suas principais transações bancárias por Java moderno, eles foram capazes de desenvolver novas funcionalidades para os clientes do banco, ao mesmo tempo em que melhoraram o desempenho das cargas de trabalho no mainframe em 3x.

A maioria dos bancos possui planos de proteção de dados que incluem alguma forma de redundância para recuperação de desastres (DR), como uma cópia primária do mainframe de produção no data center e talvez um backup secundário externo ou uma solução de fita virtual que obtém um novo upload em lote a cada alguns meses.

Conforme os volumes de dados aumentam inexoravelmente de tamanho, com mais transações e endpoints de aplicações, fazer cópias deles por meio de tecnologias de backup legadas se torna cada vez mais caro e demorado, e reconstituí-los também é lento, o que pode deixar uma lacuna de DR de downtime. Existe uma necessidade crítica para backups e recuperação mais rápidos para garantir falhas no ambiente computacional moderno do banco, incluindo ransomware.

O ANZ, um dos cinco principais bancos da Austrália, buscou aumentar sua capacidade de fazer backups de mainframe em tempo hábil e o desempenho de recuperação de desastres mais rápido para garantir alta disponibilidade para seus mais de 8,5 milhões de clientes.

Eles desenvolveram uma capacidade de resiliência entre locais, executando servidores sistemas IBM Z espelhados com sua função HyperSwap para permitir swaps de armazenamento de vários destinos sem a necessidade de interrupções, pois qualquer um dos servidores idênticos pode assumir cargas de trabalho de produção se um estiver passando por um processo de backup ou recuperação.

A liderança de TI da ANZ tem tranquilidade graças à melhor disponibilidade do sistema; Além disso, agora eles têm uma postura moderna de recuperação de desastres que pode ser certificada para proporcionar continuidade de negócios a seus clientes.

Os bancos dependem de funções de análise de dados avançadas para quase todos os aspectos das principais decisões de negócios que afetam a satisfação do cliente, o desempenho financeiro, o investimento em infraestrutura e a gerenciamento de riscos.

Consultas analíticas complexas sobre enormes conjuntos de dados no mainframe podem consumir orçamentos de computação e levar horas ou dias para serem executadas. Mover os dados para outro lugar — como um data warehouseem nuvem — pode trazer atrasos ainda maiores no transporte, resultando em dados obsoletos e decisões de baixa qualidade.

O Garanti BBVA, o segundo maior banco da Turquia, implementou o IBM Db2 Analytics Accelerator for z/OS, que acelera as cargas de trabalho de consulta enquanto reduz o consumo de CPU de mainframe.

A separação das cargas de trabalho de análise de dados das preocupações e custos do ambiente de produção de mainframe permite que o Garanti execute mais de 300 trabalhos em lote de análise todas as noites, e um relatório de conformidade que costumava levar dois dias para ser executado agora leva apenas um minuto.

Os bancos competem em sua capacidade de oferecer novas aplicações e ofertas de serviços inovadores aos clientes, de modo que as equipes de desenvolvimento ágeis estão constantemente contribuindo com funcionalidades de software. Naturalmente, tendemos a generalizar isso como melhorias de front-end para aplicativos para smartphones e integrações orientadas por APIscom serviços de nuvem.

Mas espere, quase todas essas novas funcionalidades acabarão por chegar ao mainframe. Por que não trazer a equipe de mainframe como participante de primeira classe no movimento DevOps para que eles possam se envolver?

O Danske Bank decidiu integrar quase 1.000 desenvolvedores internos de mainframe em um movimento de transformação DevOps em toda a empresa, utilizando o IBM Application Delivery Foundation for z/OS (ADFz) como plataforma para desenvolvimento de funcionalidades, depuração, testes e gerenciamento de versões.

Até mesmo o código COBOL e PL/1 existente poderia ser ingerido no pipeline de gerenciamento de CI/CD, depois aberto e editado intuitivamente nos IDEs dos desenvolvedores. Chega de usar telas verdes aqui. O Danske Bank agora pode lançar ofertas no mercado na metade do tempo que costumava levar.

Leia o estudo de caso do Danske Bank https://www.ibm.com/br-pt/case-studies/danske_bank_as

Mesmo as mais novas empresas de fintech “nascidas na nuvem” seriam sábias em considerar como suas próprias inovações precisam interagir com um ambiente de computação híbrida em constante mudança das contrapartes.

Uma transação em um aplicativo móvel ainda acabará por atingir redes globais de pagamento, entidades reguladoras e outros bancos, cada um com seus próprios recursos de computação e armazenamento de mainframe por trás de cada atendimento de solicitação.

Nunca haverá um caminho único a seguir, pois não há dois bancos idênticos e há muitas transformações possíveis que poderiam ser feitas na modernização de aplicações mainframe.

Os líderes de TI precisam começar em algum lugar e selecionar os casos de uso mais adequados às suas necessidades de negócios e à arquitetura do estado de aplicações exclusivo em que o mainframe viverá.

Para saber mais, veja os outros posts desta série:

• Parte 1: “Modernização de aplicações mainframe”
• Parte 2: “Uso da colaboração (não migração) para modernizar suas aplicações de mainframe com a nuvem”
• Parte 4: "Mainframe e a nuvem? É fácil com o código aberto"