Por que os Mainframes Ainda São Importantes na Era Digital dos Bancos – Entrevista com Jennifer Nelson

Jennifer Nelson é CEO da izzi Software.

Descubra as principais notícias e eventos de fintech

Subscreva a newsletter do FinTech Weekly

Lida por executivos da JP Morgan, Coinbase, Blackrock, Klarna e mais

Numa indústria obcecada pela mais recente vaga de tecnologia, é fácil esquecer que alguns dos pilares mais fortes da infraestrutura financeira existem há décadas. Embora a inovação fintech seja frequentemente apresentada como uma corrida rumo ao futuro, a espinha dorsal da banca global continua silenciosamente ancorada em sistemas que muitos ignoram erradamente como relíquias: o mainframe.

Isto não é apenas uma questão de nostalgia ou inércia corporativa. Os mainframes ainda processam a maior parte das transações financeiras do mundo, com uma fiabilidade e escala que não são comparáveis por muitas plataformas mais recentes. A capacidade de lidar com volumes vastos de dados em tempo real, sem comprometer a segurança, tornou-os indispensáveis num sistema financeiro que depende tanto da rapidez como da confiança.

No entanto, apesar do seu papel crítico, os mainframes são frequentemente mal compreendidos. No clima atual, em que “cloud-first” é o mantra por defeito, pode parecer pouco intuitivo defender tecnologias mais antigas. Mas chamar o mainframe de sistema legado simplifica demais uma verdade muito mais complexa. Para perceber porquê, é preciso analisar o equilíbrio entre sistemas legados e a procura moderna por infraestruturas híbridas.

O Caso da Modernização com Cautela

As instituições financeiras estão sob uma pressão implacável para modernizar. Investidores, clientes e reguladores esperam serviços digitais sem falhas, segurança reforçada e desempenho cada vez mais rápido. Para muitos líderes, a tentação é perseguir a mudança de forma agressiva — abandonar sistemas antigos e migrar em massa para a cloud.

Mas a modernização não é apenas um projeto técnico. É um empreendimento estratégico que acarreta riscos quando é feito às pressas. Dados que estiveram guardados com segurança dentro de um ambiente de mainframe durante décadas ficam expostos assim que são transferidos para outro local. Aplicações otimizadas para o mainframe podem tropeçar quando são migradas, resultando em problemas dispendiosos de latência. Estes riscos vão além do hipotético — ameaçam operações diárias, conformidade regulamentar e até a confiança dos consumidores.

A lição é clara: a verdadeira modernização não é arrancar o antigo para dar lugar ao novo. É integrar forças, fazer atualizações faseadas com cuidado e garantir que o próximo passo em frente não destabiliza o que já funciona.

Uma Lacuna de Competências com Consequências Reais

A tecnologia evolui mais depressa do que a perícia necessária para a manter. Não há lugar onde isto seja mais evidente do que no universo do mainframe. Durante anos, bancos e instituições financeiras confiaram num conjunto de engenheiros com um conhecimento institucional profundo dos sistemas IBM Z e plataformas relacionadas. À medida que muitos desses especialistas se reformam, a geração seguinte ainda não substituiu totalmente esse conjunto de competências.

Isto cria um desafio sério. Um “banco” pouco profundo de especialização aumenta o risco de erros dispendiosos, mesmo quando existem proteções. A resiliência dos mainframes não consegue compensar totalmente o fator humano. Até que novos engenheiros sejam formados e orientados, os bancos enfrentarão vulnerabilidades não por causa da tecnologia em si, mas devido ao estreitamento do grupo de profissionais que sabem como utilizá-la em segurança.

A Segurança Continua a Ser Sobre Pessoas

Quando surgem conversas sobre cibersegurança, muita da atenção recai sobre ferramentas e defesas. Ainda assim, vez após vez, as fraquezas reais resultam do comportamento humano. No mundo do mainframe, isto acaba muitas vezes por se traduzir em como as permissões são concedidas, geridas e revogadas.

Engenheiros que não compreendem totalmente as implicações de permissões elevadas podem deixar portas abertas, não por malícia, mas por falta de formação completa ou por conveniência. Empresas que não atualizam o acesso quando os funcionários mudam de funções podem expor dados sensíveis desnecessariamente. Mesmo com tecnologia sofisticada, os princípios básicos de higiene de segurança continuam a ser essenciais — e demasiadas vezes são ignorados.

A Apresentação de Jennifer Nelson

Para contextualizar estes desafios e oportunidades, recorremos a Jennifer Nelson, CEO da Izzi Software. Nelson construiu a sua carreira em torno de sistemas de mainframe, passando 15 anos na Rocket Software e cinco anos na BMC antes de alargar a sua perspetiva através de funções de engenharia sénior fora do ecossistema IBM Z. Em 2024, fundou a Izzi Software, uma empresa dedicada à aquisição e ao crescimento de negócios construídos nas plataformas IBM Z e IBM Power.

O seu ponto de vista — abrangendo a engenharia tradicional de mainframes e a liderança moderna de software — faz dela uma voz rara no diálogo de hoje sobre estratégia tecnológica em serviços financeiros.

Aproveite a entrevista!

1. À medida que a fintech corre em direção a tudo “cloud-native”, defendeu que o mainframe continua a ser crítico para a estabilidade da banca global. O que acha que a maioria dos inovadores tem errado hoje no papel dos sistemas mais antigos?

A primeira coisa que fazem erradamente é chamar o mainframe de sistema legado; como foi lançado há mais de 60 anos, então, de algum modo, é automaticamente obsoleto. É como chamar ao sistema operativo Windows uma plataforma legada. Não é isso que corresponde à realidade. Os mainframes são hoje mais relevantes do que quando foram inventados.

Toda a gente quer dados à velocidade da luz. Querem que os dados lhes sejam devolvidos assim que carregam no botão, independentemente de onde esses dados estejam. E têm razão, porque o utilizador final não saberia — e nem deveria ter de saber — as complexidades do pedido, como, por exemplo, onde os dados estão. Mas apenas os mainframes conseguem dar-lhe o desempenho e a segurança num ambiente híbrido.

Os mainframes conseguem ingerir dados onde quer que estejam, analisá-los e devolvê-los com recomendações, melhor do que qualquer outra plataforma, e mais rapidamente. Mostre-me outro sistema que consiga ingerir dados de todo o lado a partir de uma rede global, analisá-los, detetar anomalias em tempo real e enviá-los imediatamente de volta ao chamador.

Aquele que conhece melhor os seus dados ganha, porque os dados são tão valiosos como o capital em dinheiro. Quando os inovadores dispensam os mainframes como sistemas legados, estão a dispensar a sua velocidade e poder, e a capacidade de processar quantidades massivas de dados à velocidade necessária para a deteção de risco em tempo real.

As pessoas acham que a cloud foi transformadora e moderna, e que os mainframes ficam obsoletos em comparação. O conceito de cloud computing através de uma rede é, de facto, moderno e transformador para muitos. Mas se você estiver familiarizado com a tecnologia de mainframe, os utilizadores vão reconhecer que tem muitas das mesmas características que a cloud. Por exemplo, quando se inicia sessão no mainframe, está a iniciar sessão no TSO, sigla para “time sharing option”. Tem a sua própria sessão TSO, ou uma ‘instância’ do Microsoft Teams.

Estão todos a usar os mesmos processadores no mainframe. Mas quando não estão a executar um programa ou um job em lote, a capacidade é atribuída a quem precisa dela. Também está a iniciar sessão num LPAR, ou partição lógica, completo com armazenamento dedicado, segurança e privacidade. Utilizadores num LPAR não conseguem aceder a dados noutro LPAR, a menos que estejam especificamente configurados para o fazer. É isso que a cloud é, na sua essência; partilhar recursos quando não os está a usar e proteger os dados dedicados à sua instância. Mas o mainframe tem usado estes conceitos há anos.

2. Infraestrutura híbrida — misturar mainframes com camadas de cloud mais recentes — está a tornar-se o padrão. Pelo seu ponto de vista, quais são os verdadeiros fatores de risco introduzidos quando as organizações tentam modernizar demasiado depressa ou de forma superficial?

De entre múltiplos fatores de risco, eu consigo reduzi-los a dois.

O primeiro risco é o consumo de dados. Os dados num mainframe são alguns dos dados mais seguros em qualquer lugar. Quando os retira do mainframe ou os torna visíveis para alguém que vai ingerir esses dados, há risco para a privacidade e para a regulamentação. Quem está a olhá-los? Para onde vão quando saem do mainframe?

O segundo risco está em otimizar aplicações para correr num ambiente híbrido. Aplicações otimizadas para o mainframe podem acabar por correr de forma pouco otimizada noutro servidor. Problemas de latência e de desempenho podem afetar a produtividade.

3. Já alertou para uma lacuna de competências em especialização de mainframe. Quão sério é o risco institucional quando há menos engenheiros que sabem operar e proteger os sistemas de que as instituições financeiras ainda dependem?

O risco é grave. Novos programadores — não apenas mais jovens, mas também aqueles que são novos na indústria — vão aprender e desenvolver a sua perícia. Mas até que a geração seguinte acompanhe, haverá exposição nas instituições financeiras durante algum tempo, quando o conhecimento institucional não estiver tão profundo quanto precisa.

Pessoas com uma experiência ou conhecimento pouco aprofundados podem fazer coisas inadvertidamente que gerem risco para os dados ou para um sistema operativo. Estes sistemas são resilientes e têm várias camadas de proteção contra erro humano, mas ainda existe um grau considerável de risco até as competências estarem onde precisam de estar. Os bancos já estão a lidar com esta lacuna de competências hoje.

4. As conversas sobre segurança muitas vezes focam-se em ferramentas, mas você apontou que as pessoas continuam a ser a linha da frente. Que lacunas operacionais tem visto surgir com mais frequência na gestão de ambientes de mainframe?

Gerir ambientes relevantes costuma centrar-se em permissões elevadas. Quando um engenheiro de software está a escrever código, às vezes precisa de uma permissão elevada para fazer algo específico no sistema operativo, onde pode permitir que o programa faça algo mais sensível. Se o engenheiro não compreender as melhores práticas do programador ao escrever software, não vai saber quando entrar e sair desse estado autorizado elevado. Esse estado traz mais risco, por isso os engenheiros não ficam nele tempo suficiente para compreenderem plenamente as melhores práticas ao desenvolver para esse sistema.

Há também algumas práticas fundamentais de melhores práticas de segurança a usar em qualquer rede de TI. Quando dá autorização especial a alguém numa determinada função, precisa de um processo claro para remover essa autorização quando a pessoa muda de função, para garantir que remove o acesso. Muitas vezes não é um problema, se a pessoa continua a ser funcionário da empresa ou se não é um mau ator. Mas existe sempre risco ao deixar demasiado dado sensível disponível para pessoas que já não precisam dele.

Além disso, os conjuntos de dados ao nível do sistema dos mainframes permitem que os utilizadores façam ações fundamentais num sistema. Só quer que certos utilizadores tenham acesso a essas funções. Por exemplo, certos controlos de segurança só podem ser ativados nos níveis mais profundos do sistema operativo. Vai ficar surpreendido com a frequência com que as empresas deixam princípios básicos de segurança por verificar. Há formas de os engenheiros fazerem o seu trabalho sem terem acesso a esses recursos de raiz, mas é mais fácil trabalhar com esse nível de acesso, por isso as empresas deixam a “porta dos fundos” aberta mais vezes do que deveriam.

A maioria dos empregados pode ser confiável, mas são estes princípios fundamentais que algumas instituições financeiras deixam abertos e esquecem.

5. Os ataques de ransomware estão a visar não apenas endpoints, mas também infraestruturas centrais. O que torna os sistemas legados simultaneamente de forma única vulneráveis — e, em alguns casos, mais resilientes — do que as plataformas mais recentes?

Os mainframes têm camadas de segurança embutidas que a maioria dos servidores simplesmente não tem. Apenas porque consegue iniciar sessão no mainframe não significa que agora tem acesso aos dados críticos para o negócio, que é o que o ransomware normalmente bloqueia. Depois tem de saber onde estão os dados e como aceder a esses dados. E, em seguida, os dados podem ser compartimentados, de modo que um invasor só tem acesso a um segmento dos dados e não a tudo o que precisa para um ataque de ransomware bem-sucedido. E se não tiver acesso ao dispositivo de armazenamento, não consegue ver os dados nesse dispositivo.

6. Pelo seu ponto de vista, como é que a modernização eficaz se parece, na prática, para instituições financeiras que não podem pagar “arrancar e substituir”, mas precisam de estar preparadas para o futuro?

Modernização significa coisas diferentes em empresas diferentes, dependendo do ponto em que estão com as aplicações que executam. Se são B2B ou B2C, as empresas estão a modernizar continuamente, atualizando servidores e portáteis.

O mesmo acontece com aplicações críticas para o negócio. Uma empresa pode atualizar periodicamente essas aplicações, mas como as aplicações tradicionais de mainframe foram desenvolvidas há várias gerações, o melhor que as empresas podem fazer é avaliar completamente o que cada aplicação faz fim-a-fim. Assim conseguem fazer a sua modernização em partes geríveis.

As empresas podem compartimentar uma aplicação, quebrando-a em partes para que diferentes funcionalidades e atividades sejam atualizadas e reescritas lentamente ao longo do tempo, conforme for financeiramente possível. Se olhar para a modernização como um processo contínuo, o impulso para melhorar e iterar torna-se constante.

Os líderes devem ter sempre uma mentalidade proativa. As perguntas devem ser: “O que podemos fazer agora? O que podemos conter este ano? O que podemos conter nos próximos dois anos?” Esta é uma abordagem melhor do que “como é que vamos reescrever isto tudo?”

Tem de iterar sobre os sistemas e construí-los ao longo do tempo. Comece por reescrever uma funcionalidade de uma aplicação crítica para o negócio e depois construa sobre isso, adicionando o resto das funcionalidades à medida que consegue. Faça as mudanças faseadamente, aos poucos.

Arrancar-e-substituir é uma opção. Parece cru e brutal, mas o que significa, na prática, é apenas parar de usar um sistema para passar a usar outro. Mas a liderança precisa de ter estômago para uma mudança grande de uma só vez e tem de aprovar o orçamento. A verdade é que, no fundo, é mais “substituir”, porque pode levar anos a concluir o procedimento.

7. Para líderes de tecnologia vindos de uma mentalidade cloud-first, o que diria que é a mudança mais importante no pensamento ao interagir com sistemas de mainframe críticos para a missão?

Aprenda o que o mainframe está efetivamente a fazer. A Declaração de Hipócrates diz para primeiro não causar dano, por isso aprenda pelo que o mainframe é responsável para evitar cometer erros prejudiciais. Depois, quando aqueles com uma mentalidade cloud-first compreenderem a totalidade das transações que entram no mainframe, a natureza dessas transações e o quanto a receita da sua empresa depende delas, vão compreender e saber como evitar danificar o desempenho e a rentabilidade da sua empresa.

Sobre Jennifer Nelson

Jennifer Nelson passou a maior parte da sua carreira no setor de mainframes, incluindo 15 anos na Rocket Software e cinco anos na BMC. Em 2019, transitou para funções de engenharia sénior em empresas globais de tecnologia fora do ecossistema IBM Z, alargando a sua perspetiva e conjunto de competências. No início de 2024, Nelson começou a assentar as bases do que viria a ser a Izzi Software, uma empresa focada em adquirir e fazer crescer negócios de software construídos nas plataformas IBM Z e IBM Power.