O Caso TSB Bank : Como uma migração de mainframe destruiu a reputação de um banco

Bellacosa Mainframe edição especial O Caso TSB Bank

Um café no Bellacosa Mainframe Edição Especial

O Caso TSB Bank

Como uma migração de mainframe destruiu a reputação de um banco

Resumo

Em abril de 2018, o banco britânico TSB Bank realizou uma migração do seu core bancário.

O objetivo era:

• abandonar a plataforma herdada da Lloyds

• desligar o ambiente mainframe legado

• migrar milhões de contas para a plataforma espanhola Proteo4UK, desenvolvida pelo grupo Sabadell.

O resultado foi um desastre.

Durante semanas:

• clientes ficaram sem acessar contas

• pagamentos falharam

• salários não foram creditados

• pessoas visualizaram contas de terceiros

• fraudes aumentaram

• o banco praticamente parou.

Até hoje o episódio é usado em universidades e cursos de gerenciamento de projetos.

---

Antes da crise

2008

Crise financeira mundial.

O governo britânico salva o Lloyds Banking Group.

Como condição da União Europeia:

Lloyds deveria vender parte de seus ativos.

---

2013

Nasce o novo TSB.

Entretanto...

O banco não possuía infraestrutura própria.

Continuou utilizando o enorme ambiente tecnológico da Lloyds.

Era praticamente um "inquilino" da infraestrutura do antigo dono.

---

O problema

Todos os anos o TSB pagava milhões para utilizar:

• mainframe

• processamento

• storage

• sistemas

• infraestrutura

Era caro.

Muito caro.

---

2015

O banco espanhol

Banco Sabadell

compra o TSB por cerca de £1,7 bilhão.

O plano era simples.

"Vamos desligar toda a tecnologia da Lloyds e colocar tudo na plataforma Sabadell."

Nascia o projeto Proteo4UK. (Tsb)

---

O erro número 1

Uma consultoria estratégica contratada antes da aquisição recomendou justamente o contrário:

permanecer o máximo possível na plataforma Lloyds e, depois, utilizar uma cópia independente ("clone") da plataforma existente, reduzindo riscos de migração. (Tsb)

Mas, após a compra pelo Sabadell, prevaleceu o objetivo de capturar rapidamente as sinergias financeiras da aquisição, acelerando a migração para a plataforma própria. (Tsb)

• Para saber mais

https://eljefemidnightlunch.blogspot.com/2020/04/o-caso-tsb-bank-como-uma-migracao-de.html

• House MD investiga quando os dados mentem

https://eljefemidnightlunch.blogspot.com/2021/04/o-paciente-tsb-house-cobol-e-migracao.html

---

O cronograma

2015

Projeto iniciado

---

2016

Construção da nova plataforma

---

2017

Testes

Dress rehearsals

Ensaios

Migrações parciais

Segundo o banco:

• nove ensaios completos

• milhares de testes

• piloto com cerca de 1.600 funcionários

Tudo aparentemente aprovado. (Tsb)

---

Abril de 2018

Chega o grande fim de semana.

Toda migração foi planejada para ocorrer entre

20 e 22 de abril.

---

Sexta-feira

20/04/2018

Os sistemas entram em manutenção.

Clientes avisados.

---

Domingo

22/04

Às 18h

Os serviços deveriam voltar.

Não voltaram normalmente.

Começaram os primeiros relatos:

• erro de login

• saldo incorreto

• aplicativos travando

E o mais assustador...

Algumas pessoas conseguiam visualizar dados bancários de outros clientes. (The Guardian)

---

Segunda-feira

23 abril

O banco dizia:

"Há apenas problemas de acesso."

Nas redes sociais a situação parecia muito pior.

Milhares de reclamações.

Curiosamente, a própria Sabadell chegou a publicar uma nota comemorando o "sucesso" da migração antes de retirar o comunicado. (The Guardian)

---

Terça-feira

24 abril

O caos.

Até 1,9 milhão de clientes de internet banking e aplicativo foram afetados. (The Guardian)

---

O que aconteceu tecnicamente?

Durante muito tempo imaginou-se que:

"os dados foram perdidos."

Na realidade...

Não.

Os dados principais foram migrados corretamente.

Todas as contas chegaram.

O problema estava na infraestrutura.

Segundo as análises posteriores:

• inconsistências entre os dois data centers

• diferenças de configuração entre ambientes que deveriam ser idênticos

• problemas de capacidade

• defeitos de software

• gargalos inesperados

• canais digitais instáveis

• explosão de acessos dos clientes tentando verificar suas contas, sobrecarregando ainda mais call centers e agências. (Tsb)

Ou seja...

Os registros bancários foram preservados.

A plataforma ao redor deles não conseguiu operar de forma estável.

---

IBM entra em cena

Dias depois, o CEO Paul Pester anunciou que especialistas da IBM haviam sido chamados para ajudar na estabilização da plataforma. O objetivo era recuperar o ambiente, e não conduzir a migração original. (The Guardian)

É importante destacar:

A IBM não foi responsável pelo projeto de migração.

Ela entrou posteriormente para auxiliar na recuperação.

---

As consequências

Durante semanas ocorreram:

• salários atrasados

• hipotecas afetadas

• cartões recusados

• pagamentos perdidos

• transferências bloqueadas

• empresas incapazes de pagar funcionários

Houve também aumento nas tentativas de fraude contra clientes durante o período de instabilidade. (Grupo Banc Sabadell)

---

O Parlamento britânico

O CEO Paul Pester foi convocado diversas vezes para prestar esclarecimentos ao Comitê do Tesouro da Câmara dos Comuns.

As audiências foram bastante críticas e questionaram planejamento, governança, comunicação e avaliação de riscos. (The Guardian)

---

O relatório independente

Em 2019, o conselho do TSB publicou uma revisão independente conduzida pelo escritório de advocacia Slaughter and May.

Entre as conclusões estavam:

• cronograma excessivamente agressivo

• supervisão insuficiente de fornecedores

• falhas na governança

• testes que não reproduziram adequadamente o ambiente real

• excesso de confiança nos indicadores de prontidão antes do "go live". (Tsb)

---

Quanto custou?

As estimativas variam conforme o critério contábil, mas o impacto financeiro foi enorme.

Os custos incluíram:

• compensações a clientes

• recuperação operacional

• perda de clientes

• reforço da infraestrutura

• consultorias

• suporte emergencial

• investigações regulatórias

O Grupo Sabadell informou centenas de milhões de libras em impactos relacionados ao incidente ao longo do tempo, considerando custos diretos e indiretos. (Grupo Banc Sabadell)

---

Houve multa?

Sim.

Em dezembro de 2022, os reguladores britânicos (Financial Conduct Authority – FCA e Prudential Regulation Authority – PRA) anunciaram um acordo com o TSB.

As multas somadas chegaram a aproximadamente £48,65 milhões, relacionadas às deficiências na gestão dos riscos operacionais e da migração tecnológica. (Tsb)

---

O CEO caiu?

Sim.

Paul Pester renunciou em setembro de 2018.

A pressão política e pública tornou sua permanência praticamente inviável. (The Guardian)

---

O TSB quebrou?

Curiosamente...

Não.

O banco continuou existindo.

Hoje opera normalmente utilizando a nova plataforma.

Após anos de estabilização, o próprio TSB afirma que os incidentes de TI voltaram a níveis comparáveis aos de outros bancos do mercado e que internalizou parte relevante da gestão de TI. (Tsb)

---

As principais lições para quem trabalha com mainframe

Este caso costuma ser resumido em algumas lições clássicas:

1. O problema não era o mainframe. A motivação principal era reduzir dependências e custos do ambiente legado, não substituir uma plataforma que estivesse falhando.

2. Migrações de core bancário são projetos de transformação organizacional, não apenas de tecnologia.

3. Testes de laboratório não garantem comportamento em produção. Carga real, usuários simultâneos e cenários extremos podem revelar problemas invisíveis.

4. Cronogramas definidos por metas de negócio podem aumentar o risco técnico. O relatório independente critica explicitamente o calendário considerado otimista demais. (Tsb)

5. Planos de rollback e contingência precisam ser extremamente robustos. Em sistemas financeiros, recuperar a operação rapidamente é tão importante quanto migrar.

---

Links para as principais fontes históricas

• Timeline da crise (The Guardian)

• Relatório independente Slaughter and May (PDF)

• Comunicado oficial do TSB sobre a revisão da migração

• Relatório Anual do TSB 2018 (PDF)

• Relatório do Grupo Sabadell 2018 (PDF)

• Evidências ao Parlamento britânico sobre falhas de TI no setor financeiro

Na minha opinião técnica, o caso TSB é um dos melhores estudos para profissionais de mainframe porque desmonta um mito recorrente: a falha não ocorreu porque o banco usava mainframe, mas porque uma transformação extremamente complexa foi conduzida sob um cronograma agressivo e encontrou problemas de arquitetura, implantação, governança e operação. A própria migração preservou os dados dos clientes; o colapso aconteceu na infraestrutura e nos serviços que deveriam disponibilizar esses dados de forma confiável. É por isso que o episódio continua sendo citado em discussões sobre modernização de sistemas críticos, muito mais como uma lição de engenharia e gestão do que como uma crítica à tecnologia de origem.

20 Anos Depois da Bolha da Internet : O Que Todo Programador COBOL Padawan Precisa Aprender com o Maior Crash Tecnológico da Era Digital

 

Bellacosa Mainframe e o impacto da bolha da internet 25 anos apos os eventos

☕ Um Café no Bellacosa Mainframe

25 Anos Depois da Bolha da Internet

O Que Todo Programador COBOL Padawan Precisa Aprender com o Maior Crash Tecnológico da Era Digital

"Nem toda inovação sobrevive. Mas toda inovação deixa código, cicatrizes e conhecimento."

---

Introdução — A História se Repete... Apenas Troca de Interface

Imagine um jovem programador COBOL entrando pela primeira vez no CPD em 1999.

Enquanto ele aprendia JCL, CICS e Db2, do outro lado do mundo acontecia algo considerado "o futuro absoluto".

Internet.

Sites.

Portais.

E-commerce.

Empresas que nunca haviam vendido absolutamente nada estavam sendo avaliadas em bilhões de dólares.

Bastava colocar ".com" no nome da empresa.

O dinheiro aparecia.

Investidores compravam ações sem perguntar uma única coisa:

"Como essa empresa ganha dinheiro?"

Foi provavelmente o maior delírio coletivo já visto na história da tecnologia moderna.

E, como quase toda bolha financeira...

Ela estourou.

Milhões perderam dinheiro.

Empresas desapareceram.

Profissionais ficaram desempregados.

Projetos gigantescos foram abandonados.

Mas...

Curiosamente...

Foi justamente daquele caos que nasceram praticamente todas as gigantes digitais que usamos hoje.

Google.

Amazon.

Netflix.

PayPal.

Salesforce.

Wikipedia.

LinkedIn.

A bolha destruiu milhares de empresas.

Mas fortaleceu as poucas que realmente tinham fundamentos.

Hoje, mais de vinte anos depois, vale perguntar:

Estamos vivendo algo parecido novamente?

Prepare seu café.

Vamos voltar para 1995.

---

Capítulo 1 — O Mundo Antes da Internet Comercial

Para quem nasceu depois dos anos 2000 é difícil imaginar.

Não existia:

• Google

• YouTube

• WhatsApp

• Streaming

• Redes sociais

• Smartphones

A internet era praticamente um ambiente acadêmico.

Empresas utilizavam:

• Mainframes

• AS/400

• UNIX

• Novell

• Lotus Notes

Os sistemas corporativos eram fechados.

A Web ainda parecia um experimento.

Até surgir algo revolucionário.

O navegador gráfico.

Primeiro Mosaic.

Depois Netscape.

Pela primeira vez qualquer pessoa podia navegar clicando em imagens.

Parecia magia.

---

Capítulo 2 — A Febre das Dot-Com

Entre 1995 e 2000 aconteceu uma explosão.

Todo empreendedor dizia possuir uma startup.

Na época nem existia esse nome.

Chamavam simplesmente de empresas ".com".

Qualquer ideia parecia revolucionária.

Vendia-se:

• comida

• livros

• flores

• brinquedos

• viagens

• carros

Tudo online.

Investidores passaram a acreditar que a internet substituiria completamente o comércio tradicional em poucos anos.

Começou uma corrida maluca.

---

A lógica da época era assustadoramente simples

Não importava:

• lucro

Nem:

• faturamento

Nem:

• clientes

Nem:

• produtos

Importava apenas:

"Crescimento."

Era comum ouvir frases como:

"Primeiro conquistamos usuários.
Depois descobrimos como ganhar dinheiro."

Soa familiar?

---

Capítulo 3 — A Economia do "Queime Caixa"

Hoje chamamos isso de:

Burn Rate.

Na época:

Era praticamente um esporte.

Empresas queimavam milhões de dólares por mês.

Publicidade.

Marketing.

Escritórios luxuosos.

Contratações gigantescas.

Sem receita.

Sem lucro.

Sem modelo sustentável.

O dinheiro vinha dos investidores.

Enquanto houvesse investidores...

Tudo parecia funcionar.

---

Capítulo 4 — O Mercado Entrou em Histeria

O índice NASDAQ praticamente explodiu.

As ações subiam diariamente.

Jornais diziam:

"A Nova Economia chegou."

Especialistas afirmavam:

"O lucro não importa mais."

Foi um dos maiores erros intelectuais da história econômica.

Durante alguns anos...

Parecia verdade.

---

Capítulo 5 — O Estouro da Bolha (2000)

Então veio a pergunta que ninguém queria responder.

"Essas empresas realmente valem isso?"

A resposta apareceu rapidamente.

Não.

O capital desapareceu.

Os investidores correram.

As ações despencaram.

Empresas quebraram em semanas.

O NASDAQ perdeu aproximadamente 78% de seu valor entre março de 2000 e outubro de 2002, marcando um dos maiores colapsos da história dos mercados financeiros.

Bilhões evaporaram.

---

Capítulo 6 — O Efeito Dominó

Quando uma startup quebrava...

Ela deixava de pagar:

• fornecedores

• publicidade

• hospedagem

• infraestrutura

• salários

Outra empresa também quebrava.

Depois outra.

Depois outra.

O caos espalhou-se rapidamente.

Era um problema sistêmico.

---

Capítulo 7 — Milhares de Programadores Ficaram Sem Emprego

Esse ponto costuma ser esquecido.

A bolha não afetou apenas investidores.

Ela afetou profissionais.

Desenvolvedores.

Analistas.

Administradores.

DBAs.

Engenheiros.

Muitos mudaram completamente de carreira.

Outros voltaram para empresas tradicionais.

Inclusive para...

Mainframes.

Enquanto muitas startups desapareciam...

Bancos continuavam funcionando.

Seguradoras continuavam processando milhões de transações.

Governos continuavam pagando aposentadorias.

Os grandes sistemas corporativos permaneceram de pé.

---

Capítulo 8 — Amazon Quase Morreu

Pouca gente sabe.

A Amazon perdeu cerca de 95% de seu valor de mercado durante o colapso.

Muitos analistas afirmavam:

"A empresa nunca dará lucro."

Jeff Bezos tomou uma decisão histórica.

Reduzir custos.

Melhorar eficiência.

Pensar no longo prazo.

Não abandonar a visão.

Essa disciplina permitiu que a empresa sobrevivesse quando milhares desapareceram.

---

Capítulo 9 — Google Nasceu no Meio da Crise

Outro fato curioso.

Google surgiu praticamente durante o caos.

Enquanto empresas quebravam...

Google construía tecnologia.

Não publicidade exagerada.

Não marketing.

Infraestrutura.

Algoritmos.

Qualidade.

Foi exatamente isso que fez diferença.

---

Capítulo 10 — A Grande Lição

Tecnologia não substitui fundamentos.

Ela apenas acelera.

Uma empresa ruim...

fica ruim mais rápido.

Uma empresa boa...

escala mais rapidamente.

---

Capítulo 11 — O Que Isso Tem a Ver com COBOL?

Muito mais do que parece.

Durante toda a bolha, muitos diziam:

"O mainframe morreu."

"O COBOL acabou."

"O futuro pertence apenas às startups."

Vinte anos depois...

Quem continua processando:

• cartões

• folha salarial

• bolsas de valores

• pagamentos

• impostos

• previdência

São justamente sistemas construídos com décadas de engenharia sólida.

O hype passou.

Os sistemas críticos permaneceram.

---

Capítulo 12 — As Lições para o Padawan COBOL

Imagine um sistema bancário.

Você pode criar uma interface moderna.

Pode colocar IA.

Pode usar Kubernetes.

Pode rodar APIs REST.

Mas...

Se a transação financeira falhar...

Nada disso importa.

A base continua sendo:

• confiabilidade;

• consistência;

• disponibilidade;

• recuperação;

• auditoria.

São princípios que existiam antes da Web e continuam indispensáveis.

---

Capítulo 13 — Comparando com Outras Bolhas

A história econômica mostra um padrão recorrente. A tecnologia muda, mas o comportamento humano permanece semelhante.

A bolha ferroviária (século XIX)

As ferrovias revolucionaram o transporte, e investidores aplicaram recursos em qualquer empresa ligada aos trilhos. Muitas fracassaram, mas a infraestrutura construída transformou a economia mundial.

A bolha das empresas de energia e telecomunicações

No fim dos anos 1990, além das empresas de internet, houve excesso de investimentos em redes de fibra óptica e telecomunicações. Muitas companhias faliram, mas os cabos permaneceram e sustentaram a internet de alta velocidade dos anos seguintes.

A crise financeira de 2008

O problema não era uma nova tecnologia, mas a crença de que o mercado imobiliário subiria para sempre. Quando essa premissa caiu, todo o sistema financeiro sofreu.

As criptomoedas

Entre 2017 e 2022 surgiram milhares de projetos sem utilidade real. Muitos desapareceram, mas a tecnologia de blockchain continuou evoluindo para aplicações específicas.

O Metaverso

Após 2021, diversas empresas anunciaram que o metaverso substituiria a internet tradicional. O entusiasmo foi muito maior do que a adoção real. Ainda assim, tecnologias como realidade virtual, aumentada e computação espacial continuam evoluindo.

A Inteligência Artificial Generativa

Vivemos hoje um momento que lembra, em alguns aspectos, a era das dot-com. Há investimentos bilionários, criação acelerada de startups e expectativas elevadas. A diferença é que a IA já demonstra aplicações concretas em produtividade, programação, pesquisa, atendimento e automação. Ainda assim, permanece a mesma pergunta fundamental:

Qual problema real está sendo resolvido?

---

Capítulo 14 — Os Efeitos na Sociedade

A bolha deixou marcas profundas.

Mudou a forma como investidores analisam empresas.

Fortaleceu a cultura das startups.

Popularizou o capital de risco (venture capital).

Acelerou a transformação digital.

Criou milhões de empregos na economia digital nos anos seguintes.

Também ensinou que inovação precisa caminhar ao lado de governança, gestão financeira e planejamento.

---

Capítulo 15 — Os Efeitos no Trabalho

Depois do colapso, o mercado passou a valorizar muito mais profissionais capazes de construir sistemas robustos do que apenas criar demonstrações impressionantes.

Ganharam espaço competências como:

• arquitetura de sistemas;

• segurança da informação;

• banco de dados;

• integração entre plataformas;

• engenharia de software;

• testes automatizados;

• observabilidade;

• continuidade de negócios.

É exatamente esse perfil que encontramos em muitos profissionais de mainframe.

---

Capítulo 16 — Os Riscos dos Novos Hypes

Hoje ouvimos frases parecidas com as do ano 2000:

• "A IA substituirá todos os programadores."

• "Não será mais necessário aprender arquitetura."

• "Modelos resolvem tudo."

• "Quem não usar IA ficará para trás."

Essas afirmações podem conter parte da verdade, mas também escondem exageros.

Um modelo de IA depende de:

• dados de qualidade;

• infraestrutura;

• governança;

• segurança;

• integração;

• pessoas.

Assim como uma página HTML não fazia uma empresa lucrativa em 1999, um chatbot não transforma automaticamente um negócio em sucesso.

---

Capítulo 17 — O Mainframe e a Sabedoria dos Sistemas Duradouros

Uma das maiores lições da bolha da internet é que tecnologia de verdade não é aquela que aparece nas manchetes, mas a que continua funcionando décadas depois.

Mainframes atravessaram:

• a popularização do PC;

• a internet;

• o comércio eletrônico;

• os smartphones;

• a computação em nuvem;

• os microsserviços;

• a IA generativa.

Não porque resistiram à mudança, mas porque evoluíram continuamente.

Hoje, plataformas IBM Z executam Linux, Kubernetes, APIs REST, OpenShift, criptografia avançada e aceleradores para IA, sem abrir mão da confiabilidade que sempre os caracterizou.

---

Easter Egg Bellacosa Mainframe 🍵

Na Frota Estelar existe uma regra não escrita:

Nunca escolha um capitão apenas porque a nave é bonita. Escolha porque ela consegue voltar para casa.

Foi exatamente isso que aconteceu com as dot-com.

Muitas tinham interfaces espetaculares.

Poucas tinham motores confiáveis.

As que sobreviveram aprenderam que design atrai, marketing encanta, inovação impressiona — mas são arquitetura, disciplina, execução e sustentabilidade que mantêm uma empresa viva por décadas.

---

Conclusão — A História Não se Repete, Mas Costuma Rimar

Vinte anos após o estouro da bolha da internet, percebemos que ela não foi o fim da revolução digital. Pelo contrário, foi seu processo de amadurecimento.

O entusiasmo excessivo financiou infraestrutura, talentos e ideias que pareciam exageradas para a época. Muitas fracassaram, mas deixaram sementes que floresceram em empresas capazes de transformar a economia global.

Para um Padawan COBOL, essa história traz uma mensagem poderosa. Não se deixe levar apenas pelo brilho das novidades nem rejeite toda inovação por apego ao passado. O profissional valioso é aquele que consegue distinguir modismo de transformação estrutural.

Hoje, enquanto Inteligência Artificial, agentes autônomos, computação quântica e novas arquiteturas ocupam as manchetes, a pergunta continua a mesma de 1999:

Existe um problema real sendo resolvido?

Se a resposta for "sim", estamos diante de uma tecnologia com potencial para mudar o mundo.

Se a resposta depender apenas de apresentações bonitas, promessas vagas e crescimento sem fundamentos, talvez estejamos apenas assistindo ao próximo capítulo de uma história que já vimos antes.

Como todo bom oficial da Frota Estelar sabe, a missão não é perseguir cada estrela que aparece no radar, mas construir naves capazes de atravessar gerações. O mesmo vale para empresas, carreiras e sistemas: as tecnologias mudam, os princípios permanecem. E é justamente essa combinação entre inovação e fundamentos que separa um fenômeno passageiro de um verdadeiro legado tecnológico.

O Grande Equívoco: A Modernização Não é Sair do Mainframe

 

Bellacosa Mainframe e a modernizacao na Stack mainframe

---

☕ Um Café no Bellacosa Mainframe

O Grande Equívoco: A Modernização Não é Sair do Mainframe

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

COBOL
↓
CICS
↓
z/OS Connect
↓
REST
↓
Mobile

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.

---

2. Refatorar

Melhora código COBOL.

COBOL 74

↓

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.

---

3. Reescrever

Maior risco.

COBOL

→

Java

COBOL

→

Go

COBOL

→

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.

---

4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age

---

Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico

---

Bellacosa Mainframe e o mainframe no Brasil

Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.

---

Descobrir significa:

inventário

mapear

catalogar

entender

---

Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.

---

Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta

---

Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

Há empresas cujo negócio inteiro está aqui.

---

A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.

---

Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

↓

Programa B

↓

VSAM

↓

MQ

↓

DB2

↓

Batch

↓

Scheduler

↓

API

---

Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.

---

Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes

---

Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.

---

Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.

---

Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks

---

IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid

---

Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.

---

Go

Ótimo.

Microserviços.

Baixo consumo.

---

Node

Excelente APIs.

Menor adequação para batchs enormes.

---

.NET

Muito usado em seguradoras.

---

E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.

---

Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.

---

Docker resolve.

Empacotamento.

Não arquitetura.

---

Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança

---

Para muitas empresas.

OpenShift.

É mais comum.

---

Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.

---

Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.

---

Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.

---

Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic

---

Imagine.

SMF 110

↓

OpenTelemetry

↓

Grafana

Isso já acontece.

---

O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.

---

Ela lê.

20 milhões linhas COBOL.

Em minutos.

---

Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.

---

Minha visão sobre a frase central

A maior oportunidade tecnológica da próxima década não será abandonar o Mainframe, mas integrá-lo ao ecossistema moderno de APIs, IA, DevOps, observabilidade e computação híbrida.

O IBM Z não está desaparecendo. Está se tornando um nó de alto valor dentro de arquiteturas distribuídas, orientadas a eventos e assistidas por IA.

Acredito que estamos diante de uma das maiores ondas de transformação desde a popularização da internet comercial e da computação em nuvem, mas provavelmente ela não será uma história de "COBOL versus Java". Será uma história de preservar décadas de capital intelectual enquanto se adicionam capacidades modernas, reduzindo risco, aumentando a velocidade de entrega e mantendo a confiabilidade que fez o Mainframe sobreviver por mais de meio século. Afinal, substituir tecnologia é relativamente simples; substituir quarenta anos de conhecimento de negócio embutido em milhões de linhas de código é muito mais difícil.

Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe

A história do software pode ser entendida como uma sucessão de grandes ondas tecnológicas. Nos anos 1960 surgiu a Crise do Software, quando projetos se tornavam caros, atrasados e difíceis de manter, motivando o nascimento da Engenharia de Software. A Crise do Petróleo dos anos 1970 aumentou a pressão por eficiência, impulsionando a automação bancária, industrial e governamental.

Nos anos 1980 ocorreu o movimento de downsizing, migrando parte do processamento de grandes sistemas centralizados para servidores menores e estações de trabalho. Na década de 1990 surgiu o rightsizing, buscando equilibrar custos, desempenho e confiabilidade, reconhecendo que nem tudo deveria sair do mainframe.

A popularização da Internet revolucionou os negócios, exigindo aplicações conectadas, comércio eletrônico e integração global. No final dos anos 1990, o Y2K mobilizou milhares de profissionais para corrigir sistemas legados, preservando um enorme patrimônio tecnológico e renovando plataformas críticas.

A partir dos anos 2000, a Cloud Computing trouxe elasticidade, pagamento sob demanda e novas arquiteturas distribuídas, embora também revelasse desafios de custo, governança e dependência de fornecedores. Atualmente, a onda da Inteligência Artificial acelera desenvolvimento, documentação, testes e modernização de sistemas legados. Diferentemente das revoluções anteriores, a IA não elimina o conhecimento humano: amplia a capacidade dos especialistas de compreender, preservar e evoluir décadas de regras de negócio.

 

Bellacosa Mainframe apresenta o IBM Garage

☕🚀 IBM Garage para Padawans do COBOL

Como a IBM descobriu que colocar arquitetos, desenvolvedores e usuários numa sala com Post-it era mais barato do que deixar um Comitê decidir durante 18 meses

Por Vagner Bellacosa – Bellacosa Mainframe

---

Introdução

Existe uma cena que provavelmente aconteceu em algum lugar do planeta Terra.

Uma grande empresa possui:

• 40 milhões de linhas COBOL;

• 8 regiões CICS;

• 12 subsistemas DB2;

• IMS desde a época em que Darth Vader ainda era funcionário da Estrela da Morte;

• dezenas de integrações misteriosas que ninguém sabe exatamente quem fez.

Então alguém da diretoria aparece numa reunião e pergunta:

"Por que nosso aplicativo não é igual ao Nubank?"

Silêncio.

O programador COBOL olha para o sysprog.

O sysprog olha para o DBA.

O DBA olha para o arquiteto.

O arquiteto olha para o teto.

O teto continua sendo o profissional mais experiente da sala.

E foi justamente para lidar com este tipo de situação que surgiu uma metodologia chamada:

IBM Garage

E não...

Não é uma oficina mecânica da IBM.

Você não troca óleo do z16.

Não calibra pneus do CICS.

Não faz alinhamento de DB2.

Apesar de alguns ambientes precisarem desesperadamente de uma revisão completa.

---

A origem do IBM Garage

A IBM percebeu uma coisa importante.

Muitas empresas estavam gastando fortunas em projetos de transformação digital.

E a sequência era sempre parecida.

Fase 1

Consultoria.

Fase 2

PowerPoint.

Fase 3

Mais PowerPoint.

Fase 4

Comitê.

Fase 5

Outro comitê.

Fase 6

Projeto cancelado.

Fase 7

Novo projeto para descobrir porque o primeiro falhou.

Não parecia eficiente.

A IBM decidiu buscar inspiração em outro lugar.

Nas startups.

No Vale do Silício.

No Design Thinking.

No Agile.

No Lean Startup.

E criou algo chamado:

IBM Garage.

O objetivo era simples.

Parar de discutir ideias infinitamente.

E começar a construir.

Rapidamente.

---

O que significa Garage?

A inspiração vem literalmente das garagens onde várias empresas começaram.

Apple.

HP.

Google.

Amazon.

Muitas delas nasceram em espaços pequenos.

Com poucas pessoas.

Testando ideias.

Errando.

Aprendendo.

E evoluindo rapidamente.

A IBM tentou trazer esta mentalidade para empresas gigantes.

Inclusive bancos.

Seguradoras.

Governos.

Telecom.

Empresas aéreas.

Hospitais.

---

O problema das empresas tradicionais

Imagine um banco.

Ele possui.

COBOL

CICS

IMS

DB2

VSAM

MQ

Batch

JCL

Tudo funcionando.

Há décadas.

Milhões de transações.

99,999% disponibilidade.

Mas surge uma nova necessidade.

Aplicativo mobile.

Pix.

Open Finance.

IA.

Chatbots.

APIs.

Machine Learning.

Analytics.

A pergunta aparece.

Como modernizar?

Reescrever tudo?

Jamais.

Isso seria equivalente a desmontar um Boeing 787 em pleno voo.

E pedir para os passageiros aguardarem tranquilamente.

---

O IBM Garage resolve isso

A ideia é:

Não jogar fora.

Não substituir.

Não destruir.

Mas aproveitar.

Modernizar.

Expor.

Integrar.

Evoluir.

---

Os pilares do IBM Garage

Design Thinking

Descobrir o problema.

Não assumir soluções.

Perguntas.

Quem usa?

Como usa?

Por que usa?

O que incomoda?

---

Agile

Pequenas entregas.

Feedback rápido.

Melhoria contínua.

Não esperar dois anos.

Não esperar aprovação do Conselho Jedi.

---

DevOps

Automação.

Pipeline.

Testes.

Deploy.

Integração contínua.

---

Hybrid Cloud

Executar aplicações onde faz sentido.

Cloud.

OpenShift.

IBM Z.

Linux.

Containers.

---

Inteligência Artificial

Watsonx.

LLMs.

Assistentes.

Análise de dados.

---

O IBM Garage para quem trabalha com Mainframe

Aqui fica interessante.

Porque o COBOL deixa de ser visto como problema.

E passa a ser ativo estratégico.

Imagine.

Programa COBOL

↓

CICS

↓

z/OS Connect

↓

API REST

↓

Aplicativo Android

Fim.

Sem reescrever.

Sem migrar.

Sem trauma psicológico.

---

Exemplo real

Sistema bancário.

Programa COBOL:

CONSCLIE

Recebe:

CPF

Retorna:

Nome

Saldo

Conta

Antes.

Somente terminal 3270.

Agora.

API.

JSON.

Cliente consulta pelo celular.

COBOL continua executando.

Feliz.

Seguro.

Confortável.

Como um senhor aposentado tomando café observando jovens discutirem Kubernetes.

---

As quatro fases do IBM Garage

1 Descobrir

Workshop.

Usuários.

TI.

Negócio.

Arquitetos.

Desenvolvedores.

Perguntas.

O que dói?

O que demora?

O que pode melhorar?

---

2 Definir

Escolher MVP.

Escopo.

Backlog.

Priorização.

---

3 Construir

Sprint.

Desenvolvimento.

Testes.

Protótipos.

---

4 Escalar

Produção.

DevSecOps.

Observabilidade.

Governança.

---

Exemplo para um desenvolvedor COBOL Júnior

Vamos imaginar.

Seu gerente diz.

Precisamos criar uma API.

Consultar cliente.

Passo 1

Identificar programa COBOL.

CONSCLIE

Passo 2

Verificar COMMAREA.

01 DFHCOMMAREA.

   05 CPF         PIC X(11).

   05 NOME        PIC X(40).

   05 SALDO       PIC S9(9)V99.

Passo 3

Criar serviço z/OS Connect.

Mapear campos.

Passo 4

Gerar Swagger.

Passo 5

Publicar.

Passo 6

Testar.

curl http://api.banco.com/clientes/12345678901

Resposta.

{
"name":"JOAO SILVA",
"saldo":1500.50
}

Pronto.

Você participou de uma iniciativa IBM Garage.

Sem perceber.

---

Ferramentas utilizadas

OpenShift

Git

Jenkins

UrbanCode

Ansible

Instana

Turbonomic

watsonx

Zowe

z/OS Connect

API Connect

---

O papel do desenvolvedor COBOL

Muita gente acredita.

Garage é somente para arquitetos.

Errado.

COBOL Developers são fundamentais.

Porque conhecem.

Regras de negócio.

Batch.

CICS.

DB2.

Processos críticos.

Sem eles.

Modernização vira arqueologia.

---

Dicas para um Programador COBOL Júnior

Estude APIs

REST.

JSON.

Swagger.

OpenAPI.

---

Aprenda Git

Git é obrigatório.

---

Conheça Docker

Mesmo sem usar.

Entenda conceitos.

---

Aprenda OpenShift

É o Kubernetes corporativo da IBM.

---

Estude z/OS Connect

Talvez seja a ferramenta mais importante atualmente para integração Mainframe.

---

Aprenda Agile

Scrum.

Kanban.

Sprint.

---

Não tenha medo de IA

A IA provavelmente escreverá códigos.

Mas dificilmente entenderá cinquenta anos de regras bancárias escondidas em programas COBOL com 80 mil linhas.

Você entenderá.

E isso possui enorme valor.

---

Minha opinião sobre IBM Garage

Eu gosto da proposta.

Porque ela reconhece algo importante.

Mainframe não é problema.

Mainframe é patrimônio.

COBOL não está morrendo.

Está sendo conectado.

API por API.

Container por container.

Sprint por sprint.

Workshop por workshop.

Até que um sistema criado em 1989 converse naturalmente com uma aplicação React, um chatbot baseado em LLM, um aplicativo Android e um painel analítico em nuvem.

E talvez esta seja a maior lição do IBM Garage.

Transformação digital não significa jogar fora décadas de conhecimento.

Significa pegar tudo aquilo que funciona incrivelmente bem.

Colocar uma interface moderna.

Adicionar automação.

Criar APIs.

Aplicar inteligência artificial.

E permitir que a próxima geração de desenvolvedores COBOL continue escrevendo história.

Porque, no fim das contas, o COBOL continua sendo aquele veterano experiente do escritório.

Ele não usa tênis colorido.

Não fala em Web3.

Não posta frases motivacionais no LinkedIn.

Mas é ele que paga os boletos do banco.

Processa salários.

Liquida cartões.

Movimenta bolsas de valores.

Autoriza pagamentos.

E mantém o mundo funcionando enquanto a internet discute qual será o próximo framework JavaScript da semana.

E talvez seja exatamente por isso que o IBM Garage exista.

Para mostrar que inovação não é destruir o passado.

É construir uma ponte elegante entre 1960 e 2030.

E fazer isso tomando um bom café, de preferência acompanhado de um desenvolvedor COBOL, um arquiteto IBM Z, um especialista em APIs e algumas dezenas de Post-its espalhadas pela mesa.

Apenas tome cuidado.

Se alguém aparecer dizendo que vai reescrever 40 milhões de linhas COBOL em um final de semana usando Inteligência Artificial, esconda o café.

E chame imediatamente um sysprog.

Bellacosa Mainframe e uma visão da integração mainframe + nuvem

☕🚀 Azure + IBM MQ + CICS + COBOL: Quando a Nuvem Descobre Que Ainda Precisa do Mainframe

A arquitetura híbrida que responde em milissegundos e movimenta bilhões sem que ninguém perceba

Existe uma frase que escuto há mais de trinta e cinco anos:

"O Mainframe está morrendo."

A primeira vez que ouvi isso foi quando ainda existiam fitas magnéticas por todos os lados, terminais 3270 ocupavam salas inteiras e a internet comercial engatinhava.

Depois ouvi novamente quando surgiram os ERPs.

Depois quando surgiram os Data Centers distribuídos.

Depois quando vieram os smartphones.

Depois quando chegaram os containers.

Depois quando Kubernetes virou moda.

Depois quando a nuvem se tornou o assunto do momento.

E agora escuto novamente com a Inteligência Artificial.

Curiosamente, enquanto todos anunciavam o funeral do Mainframe, ele continuava processando cartões de crédito, transações bancárias, reservas aéreas, operações de seguradoras, sistemas governamentais e bilhões de dólares diariamente.

Talvez o erro nunca tenha sido tecnológico.

Talvez o erro tenha sido imaginar que inovação significa substituir tudo o que existe.

Na prática, a verdadeira inovação costuma acontecer quando conseguimos conectar mundos aparentemente incompatíveis.

E poucas arquiteturas representam isso melhor do que a integração entre Microsoft Azure e IBM Mainframe utilizando IBM MQ, CICS e COBOL.

Estamos falando de uma arquitetura capaz de unir o melhor dos dois universos:

• Agilidade da nuvem

• Robustez do Mainframe

• Escalabilidade dos microsserviços

• Consistência transacional do CICS

• Segurança do IBM MQ

• Décadas de regras de negócio escritas em COBOL

Tudo funcionando como uma única plataforma.

---

O Grande Equívoco Sobre Modernização

Quando alguém fala em modernização, muitas pessoas imaginam algo parecido com isto:

Sistema Antigo
      ↓
Apagar Tudo
      ↓
Reescrever Tudo
      ↓
Sistema Novo

Na teoria parece simples.

Na prática costuma ser um desastre.

Imagine um banco que possui:

• 40 milhões de clientes

• 30 anos de regras de negócio

• milhares de programas COBOL

• dezenas de sistemas satélites

• integrações desconhecidas

Reescrever tudo pode levar anos.

Custar centenas de milhões.

E ainda introduzir novos erros.

Por isso os grandes bancos do mundo adotaram outro caminho.

Em vez de substituir o Mainframe, passaram a conectá-lo ao ecossistema digital.

É exatamente isso que esta arquitetura faz.

---

O Cliente Nem Imagina o Que Está Acontecendo

Imagine um cliente consultando saldo pelo aplicativo.

Ele toca um botão.

Em menos de um segundo recebe a resposta.

Para ele parece algo simples.

Mas nos bastidores ocorre uma verdadeira orquestra tecnológica.

O aplicativo chama uma API hospedada no Azure.

A API gera uma mensagem JSON.

Essa mensagem atravessa a rede.

Chega ao IBM MQ.

O MQ desperta uma transação CICS.

O CICS chama um programa COBOL.

O COBOL consulta DB2.

A resposta retorna pelo mesmo caminho.

Tudo isso em poucos milissegundos.

O usuário jamais perceberá.

E essa é justamente a beleza da arquitetura.

---

IBM MQ: O Carteiro Mais Confiável do Mundo Corporativo

Muitos profissionais mais jovens cresceram utilizando APIs REST.

Naturalmente surge a pergunta:

Por que usar MQ?

Porque sistemas críticos exigem garantias que HTTP sozinho não consegue fornecer.

Quando uma mensagem entra em uma fila MQ, ela não desaparece.

Ela permanece armazenada até ser processada.

Mesmo que:

• um servidor caia

• a rede falhe

• uma aplicação seja reiniciada

a mensagem continua lá.

Imagine uma transferência financeira de cem mil reais.

Você gostaria que ela dependesse exclusivamente de uma conexão HTTP momentânea?

Provavelmente não.

É por isso que bancos continuam apaixonados pelo MQ.

Ele foi criado para ambientes onde perder uma única mensagem pode significar prejuízo milionário.

---

Request-Reply: O Casamento Entre Dois Mundos

Existe um detalhe fascinante nessa arquitetura.

O mundo web é síncrono.

O mundo MQ é assíncrono.

São filosofias diferentes.

Quando um navegador faz uma requisição HTTP, ele espera uma resposta.

Quando uma aplicação grava uma mensagem em uma fila MQ, ela normalmente segue seu caminho.

Mas o usuário quer uma resposta imediata.

Surge então o padrão Request-Reply.

Funciona assim:

A aplicação envia uma mensagem para a fila REQUEST.

O Mainframe processa.

Depois envia uma resposta para uma fila REPLY.

A aplicação recupera a resposta e devolve ao usuário.

Parece simples.

Mas essa simplicidade esconde décadas de evolução arquitetural.

---

O Poder dos Identificadores

Aqui encontramos um dos elementos mais importantes de toda a solução.

O MsgId.

Cada mensagem recebe um identificador único.

Por exemplo:

A1B2C3D4E5

Quando a resposta é gerada, esse valor reaparece como CorrelId.

Dessa forma:

Request
MsgId = A1B2C3D4E5

Reply
CorrelId = A1B2C3D4E5

A aplicação consegue saber exatamente qual resposta pertence a qual requisição.

Sem isso seria impossível processar milhares de mensagens simultaneamente.

É como o número de protocolo de uma ligação para suporte.

Sem ele tudo viraria uma enorme confusão.

---

MQ Trigger: O Despertador do Mainframe

Uma das partes mais elegantes dessa arquitetura é o Trigger.

Imagine um operador sentado observando uma fila.

Sempre que chegasse uma mensagem ele iniciaria um programa.

Seria absurdo.

O MQ faz isso automaticamente.

Quando uma mensagem chega:

QUEUE DEPTH = 1

o Trigger entra em ação.

Instantaneamente ele inicia uma transação CICS.

Sem polling.

Sem scripts.

Sem agendadores.

Sem desperdício de CPU.

É uma solução extremamente elegante criada décadas antes do conceito moderno de eventos ganhar popularidade.

Na verdade, muitos sistemas chamados hoje de Event-Driven Architecture fazem algo conceitualmente muito parecido com o que MQ e CICS realizam há anos.

---

O Router Program: O Maestro da Orquestra

Após a ativação do Trigger entra em cena o Router Program.

Se eu tivesse que apontar o cérebro da arquitetura, seria ele.

Sua função é simples:

Receber.

Analisar.

Decidir.

Encaminhar.

Ele lê o payload.

Consulta tabelas de roteamento.

Avalia parâmetros.

E escolhe qual backend deverá executar o processamento.

Por exemplo:

CONSULTA_CLIENTE → CUST0001
PIX → PIX0001
CARTAO → CARD0001

Isso oferece enorme flexibilidade.

Novos serviços podem ser adicionados sem alterar toda a arquitetura.

Basta cadastrar uma nova regra.

É o equivalente corporativo de um controlador de tráfego aéreo.

---

Quando COBOL Encontra JSON

Muitos profissionais ainda acreditam que COBOL vive preso a arquivos sequenciais e layouts de 80 colunas.

A realidade atual é muito diferente.

O CICS moderno possui recursos nativos para trabalhar com JSON.

Isso significa que uma estrutura como:

{
  "cliente":"VAGNER",
  "saldo":1500
}

pode ser transformada diretamente em estruturas COBOL.

Sem parsers complexos.

Sem centenas de linhas de manipulação de texto.

Sem gambiarras.

Durante décadas, integrar COBOL com formatos modernos exigia muito esforço.

Hoje o próprio CICS faz grande parte desse trabalho.

Essa é uma das transformações menos conhecidas fora do universo Mainframe.

---

O Segredo da Performance

Quando alguém vê Azure, JSON e microsserviços, normalmente imagina dezenas de chamadas distribuídas.

Mas o processamento principal acontece dentro do CICS.

E isso muda tudo.

Após chegar ao Mainframe, a execução ocorre dentro de um ambiente extremamente otimizado.

Não existe:

• startup de container

• inicialização de JVM

• criação de novos processos

• overhead desnecessário

O programa já está carregado.

O ambiente já está pronto.

A transação apenas executa.

É por isso que muitas operações conseguem responder em poucos milissegundos.

Uma característica frequentemente subestimada por quem nunca trabalhou em ambientes de missão crítica.

---

DB2: O Guardião da Consistência

Toda essa velocidade seria inútil sem consistência.

É aqui que entra o DB2.

Quando o COBOL consulta ou atualiza dados, o DB2 garante:

• integridade

• atomicidade

• isolamento

• durabilidade

Os famosos princípios ACID.

Em outras palavras:

ou tudo acontece corretamente

ou nada acontece.

Em sistemas financeiros isso não é luxo.

É obrigação.

Ninguém quer descobrir que o débito ocorreu mas o crédito não.

---

O Valor das Transações

Um aspecto frequentemente ignorado é o gerenciamento transacional.

Quando MQ, CICS e DB2 trabalham juntos, formam um ecossistema extremamente robusto.

Imagine:

• mensagem recebida

• atualização realizada

• resposta enviada

Tudo dentro de uma única unidade lógica de trabalho.

Se qualquer etapa falhar:

rollback.

Como se nada tivesse acontecido.

Esse é um dos motivos pelos quais Mainframes continuam dominando ambientes financeiros.

Confiabilidade não é um recurso opcional.

É parte fundamental do negócio.

---

Dead Letter Queue: A Sala de Quarentena

Nem toda mensagem nasce perfeita.

Erros acontecem.

Layouts incorretos.

Dados inválidos.

Problemas de roteamento.

Mensagens corrompidas.

Se elas bloqueassem a fila principal, toda a operação sofreria.

A solução é a Dead Letter Queue.

A famosa DLQ.

Ela funciona como uma área de isolamento.

Mensagens problemáticas são removidas do fluxo principal e armazenadas separadamente.

O processamento continua.

Os usuários continuam trabalhando.

A equipe técnica pode investigar posteriormente.

É um conceito simples.

Mas extremamente poderoso.

---

O Que os Jovens Arquitetos Podem Aprender Com Isso

Existe uma tendência atual de acreditar que tudo começou com APIs, Kubernetes e microsserviços.

Arquiteturas como esta mostram que muitos conceitos modernos possuem raízes muito mais antigas.

Observe:

Eventos.

Mensageria.

Roteamento dinâmico.

Processamento assíncrono.

Alta disponibilidade.

Escalabilidade.

Observabilidade.

Resiliência.

Tudo isso já existia em ambientes Mainframe décadas atrás.

A diferença é que hoje utilizamos novos nomes para ideias antigas.

---

O Futuro Não É Cloud ou Mainframe

A pergunta correta não é:

Cloud ou Mainframe?

A pergunta correta é:

Como combinar Cloud e Mainframe?

A resposta está justamente nesta arquitetura.

O Azure fornece velocidade para inovação.

O Mainframe fornece estabilidade para execução.

O MQ conecta os dois mundos.

O CICS orquestra as transações.

O COBOL preserva o conhecimento acumulado.

O DB2 protege os dados.

Juntos, eles formam uma plataforma capaz de atender milhões de usuários simultaneamente.

---

Considerações Finais

Ao observar esta arquitetura, não vejo apenas filas MQ, programas COBOL ou serviços Azure.

Vejo algo muito mais interessante.

Vejo a prova de que tecnologia não é uma disputa entre velho e novo.

É uma construção contínua.

Os sistemas que realmente movem o mundo raramente são os mais barulhentos.

São os mais confiáveis.

Enquanto muitos discutem tendências, frameworks e modismos passageiros, arquiteturas híbridas como esta continuam processando pagamentos, movimentando recursos financeiros, autorizando cartões, executando operações críticas e sustentando economias inteiras.

Talvez essa seja a maior lição de todas.

O futuro não pertence exclusivamente à nuvem.

O futuro pertence às arquiteturas capazes de unir inovação e legado sem sacrificar desempenho, segurança ou confiabilidade.

E poucas combinações fazem isso tão bem quanto Azure, IBM MQ, CICS, COBOL e DB2 trabalhando em perfeita harmonia.

Porque, no final das contas, modernizar não significa destruir o passado.

Significa construir pontes entre o que já funciona e aquilo que ainda está por vir.

E essa arquitetura é uma dessas pontes.

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Bellacosa Mainframe e o incidente informatico do Nubank

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Introdução

Em junho de 2026, um episódio incomum chamou a atenção do mercado financeiro brasileiro, dos profissionais de tecnologia e dos especialistas em gestão de riscos. Clientes do Nubank receberam comunicações oficiais informando que a instituição teria entrado em processo de liquidação. A mensagem, enviada por canais legítimos da empresa, parecia autêntica, utilizava terminologia regulatória correta e mencionava procedimentos relacionados ao Fundo Garantidor de Créditos (FGC).

O problema era simples e ao mesmo tempo alarmante: a informação era falsa.

Em poucas horas, a notícia se espalhou pelas redes sociais, grupos de investidores, fóruns especializados e veículos de imprensa. O Banco Central precisou esclarecer que não existia qualquer procedimento de liquidação em andamento. O Nubank confirmou que se tratava de um erro operacional decorrente de uma falha em processos internos.

À primeira vista, o incidente parece apenas um erro de comunicação. Entretanto, uma análise mais profunda revela um caso clássico de falha sistêmica envolvendo automação, governança, gestão de mudanças, segregação de ambientes e controles de produção.

Mais importante ainda: o episódio oferece uma oportunidade rara para discutir um tema frequentemente negligenciado em empresas digitais modernas — a diferença entre construir sistemas rápidos e construir sistemas confiáveis.

---

O que aconteceu

Segundo informações divulgadas publicamente, um fluxo responsável por notificações relacionadas a processos de liquidação institucional teria sido acionado indevidamente.

A comunicação foi distribuída para clientes reais utilizando canais oficiais.

Do ponto de vista do usuário final, todos os elementos indicavam legitimidade:

• origem oficial;

• identidade visual correta;

• linguagem regulatória compatível;

• referência ao FGC;

• comunicação direta da instituição.

Em segurança da informação existe um princípio fundamental:

O usuário não possui mecanismos para diferenciar uma mensagem legítima de uma mensagem enviada legitimamente por engano.

Essa frase resume a gravidade do incidente.

Quando uma comunicação falsa vem de um atacante externo, o cliente pode desconfiar.

Quando a mesma comunicação vem do próprio banco, a confiança desaparece como mecanismo de defesa.

---

O erro informático por trás do incidente

Embora os detalhes técnicos completos não tenham sido divulgados, a descrição pública permite inferir algumas hipóteses plausíveis.

O problema parece ter ocorrido em uma combinação de:

• automação de mensagens;

• parametrização inadequada;

• ausência de validações obrigatórias;

• insuficiência de mecanismos de aprovação.

Em engenharia de software, isso é conhecido como um erro de "guard rails", ou seja, ausência de barreiras que impeçam uma ação perigosa.

Imagine um sistema com a seguinte lógica:

Evento:
Liquidação Institucional

Instituição:
[NOME_DO_BANCO]

Ação:
Enviar comunicação aos clientes

Se o campo da instituição estiver vazio, o sistema deveria interromper imediatamente o processo.

No entanto, em muitos sistemas corporativos existem valores padrão.

Exemplo:

if banco == null:
    banco = "Nubank"

Ou ainda:

if banco == "":
    utilizar_instituicao_padrao()

Pequenos atalhos criados durante desenvolvimento, testes ou homologação podem se transformar em bombas-relógio quando chegam à produção.

---

Quando ambientes de teste contaminam a produção

Uma das hipóteses mais discutidas é a existência de um fluxo originalmente criado para testes.

Esse cenário é extremamente comum.

Empresas desenvolvem sistemas utilizando ambientes distintos:

Desenvolvimento

Local onde programadores criam funcionalidades.

Homologação

Ambiente utilizado para validações.

Produção

Sistema real utilizado por clientes.

Na teoria, esses ambientes são completamente isolados.

Na prática, muitas organizações acabam criando atalhos.

Exemplos comuns:

• cópia de bases produtivas;

• reutilização de configurações;

• compartilhamento de APIs;

• uso de dados reais em homologação.

Quando isso acontece, uma fronteira crítica desaparece.

O resultado é que ações originalmente pensadas para teste passam a ter impacto real.

---

A armadilha da automação

O setor financeiro moderno depende de automação em larga escala.

Bancos digitais enviam diariamente:

• notificações;

• alertas;

• extratos;

• avisos regulatórios;

• comunicações de segurança.

Uma única plataforma pode disparar milhões de mensagens por hora.

O benefício é evidente:

• redução de custos;

• velocidade operacional;

• escalabilidade.

O problema é que a automação amplifica erros.

Um funcionário que envia uma mensagem errada manualmente afeta algumas pessoas.

Um sistema automatizado pode afetar milhões.

Existe uma máxima conhecida em operações de TI:

A automação não elimina erros humanos. Ela multiplica seus efeitos.

O incidente ilustra perfeitamente esse princípio.

---

O papel dos controles de mudança

Toda alteração em sistemas críticos deveria seguir um processo formal.

Esse processo normalmente inclui:

Revisão técnica

Validação por outros desenvolvedores.

Aprovação operacional

Análise dos impactos.

Aprovação de negócio

Validação da área responsável.

Testes

Verificação funcional.

Plano de rollback

Capacidade de reversão rápida.

Quando qualquer uma dessas etapas falha, o risco aumenta exponencialmente.

A questão não é impedir erros.

Erros são inevitáveis.

A questão é impedir que erros individuais alcancem clientes.

---

O conceito de “blast radius”

Engenheiros de confiabilidade utilizam o conceito de blast radius.

Traduzindo livremente:

"raio de explosão".

A pergunta é simples:

Se algo der errado, quantas pessoas serão afetadas?

Sistemas modernos devem ser projetados para minimizar esse impacto.

Exemplo:

Em vez de enviar uma comunicação para toda a base de clientes, o sistema deveria:

1. enviar para um grupo piloto;

2. validar resultados;

3. liberar gradualmente;

4. expandir para toda a população.

Essa técnica é utilizada por empresas como:

• Google;

• Amazon;

• Microsoft;

• Netflix.

Caso o disparo incorreto tivesse sido submetido a um rollout progressivo, o incidente provavelmente teria sido detectado nos primeiros minutos.

---

O problema dos dados reais em testes

Outro aprendizado importante envolve o uso de dados produtivos.

Muitas empresas utilizam bases reais para reproduzir cenários complexos.

Isso facilita testes.

Também aumenta riscos.

Dados reais possuem características imprevisíveis:

• relacionamentos existentes;

• integrações ativas;

• gatilhos automáticos;

• usuários legítimos.

Uma rotina criada para laboratório pode encontrar condições inesperadas quando executada em produção.

É por isso que organizações maduras investem em:

• anonimização;

• mascaramento de dados;

• ambientes sintéticos.

O objetivo é reproduzir a realidade sem colocar clientes reais em risco.

---

O fator psicológico do incidente

Existe um aspecto pouco discutido.

O dano não foi apenas tecnológico.

Foi psicológico.

O sistema financeiro funciona baseado em confiança.

Quando um banco afirma que está sendo liquidado, o cliente não realiza uma análise técnica.

Ele reage emocionalmente.

As perguntas surgem imediatamente:

• Meu dinheiro está seguro?

• Preciso sacar recursos?

• Minha conta continuará funcionando?

• Meu cartão será cancelado?

• Vou perder investimentos?

Em poucos minutos pode surgir um fenômeno conhecido como corrida informacional.

Não necessariamente uma corrida bancária tradicional.

Mas uma corrida por esclarecimentos.

Milhares de pessoas acessam simultaneamente:

• aplicativo;

• central de atendimento;

• redes sociais;

• imprensa.

O volume gerado pode se tornar um problema operacional por si só.

---

O impacto no mercado

Embora o incidente tenha sido rapidamente esclarecido, ele produziu repercussões relevantes.

Mercados financeiros são altamente sensíveis à informação.

Especialmente quando envolve:

• liquidez;

• solvência;

• regulação.

Investidores institucionais monitoram continuamente sinais de risco.

Uma notícia sobre liquidação, ainda que falsa, pode provocar:

• volatilidade;

• aumento de dúvidas;

• especulação;

• pressão reputacional.

Mesmo após o esclarecimento, permanece uma questão:

Como um mecanismo tão crítico conseguiu ser acionado incorretamente?

Essa pergunta interessa mais ao mercado do que o próprio erro.

Porque ela trata da maturidade operacional da organização.

---

O custo invisível da reputação

Empresas costumam medir:

• receita;

• lucro;

• crescimento;

• número de clientes.

Poucas conseguem medir confiança.

Entretanto, confiança é um dos ativos mais valiosos do setor financeiro.

Uma instituição pode gastar bilhões em marketing.

Mas basta um único incidente de credibilidade para comprometer anos de construção de marca.

A reputação é semelhante a um sistema distribuído:

Leva muito tempo para convergir.

Pode ser afetada em segundos.

---

O que empresas podem aprender

O incidente produz diversas lições para organizações digitais.

1. Sistemas críticos precisam de múltiplas aprovações

Nenhuma comunicação regulatória deveria depender de uma única ação.

Princípio dos quatro olhos:

duas pessoas precisam validar.

2. Produção deve ser protegida contra operadores

O objetivo não é desconfiar das pessoas.

É reconhecer que erros acontecem.

Sistemas precisam impedir ações perigosas.

3. Rollouts graduais reduzem impacto

Nenhum disparo massivo deveria ocorrer instantaneamente.

4. Testes precisam ser isolados

Ambientes de homologação devem permanecer separados da produção.

5. Alertas precisam monitorar comportamentos anormais

Se uma mensagem de liquidação for enviada, alarmes automáticos deveriam disparar imediatamente.

---

O paradoxo dos bancos digitais

O caso revela um paradoxo interessante.

Os bancos digitais são extraordinariamente eficientes.

Conseguem:

• abrir contas em minutos;

• aprovar cartões rapidamente;

• processar milhões de transações.

Mas velocidade e confiabilidade nem sempre evoluem no mesmo ritmo.

À medida que organizações crescem, seus sistemas tornam-se mais complexos.

Mais integrações.

Mais automações.

Mais dependências.

Mais pontos de falha.

O desafio deixa de ser construir funcionalidades.

Passa a ser controlar complexidade.

---

A maturidade dos sistemas modernos

Os maiores incidentes tecnológicos raramente acontecem por falhas sofisticadas.

Na maioria das vezes eles surgem de:

• configurações incorretas;

• permissões inadequadas;

• processos incompletos;

• validações ausentes.

A história da tecnologia está repleta de exemplos semelhantes.

Falhas milionárias já foram causadas por:

• campos vazios;

• scripts de manutenção;

• comandos executados no ambiente errado;

• parâmetros incorretos.

O problema não é a tecnologia.

O problema é a interação entre tecnologia, pessoas e processos.

---

Conclusão

O episódio envolvendo a falsa comunicação de liquidação do Nubank não deve ser interpretado apenas como um erro operacional isolado.

Ele representa um estudo de caso sobre os desafios da engenharia moderna em sistemas de missão crítica.

O incidente demonstrou como um único evento pode atravessar múltiplas camadas organizacionais:

• tecnologia;

• governança;

• comunicação;

• segurança;

• reputação;

• mercado financeiro.

Mais importante, revelou uma verdade frequentemente esquecida em ambientes digitais:

A confiabilidade não nasce da ausência de erros.

Ela nasce da capacidade de impedir que erros inevitáveis se transformem em crises.

Em um mundo onde bancos são plataformas de software, cada linha de código, cada configuração e cada processo operacional participa diretamente da construção da confiança do cliente.

E confiança, diferentemente do software, não pode ser restaurada simplesmente com um novo deploy.

Ela precisa ser reconquistada.

Para ir mais longe

Bellacosa Mainframe e o incidente do nubank

nubank-diz-que-mensagem-sobre-liquidacao-extrajudicial-enviada-a-clientes-foi-erro-tecnico-pontual

https://www.cnnbrasil.com.br/economia/macroeconomia/cofundadora-do-nubank-diz-que-mensagem-sobre-liquidacao-foi-erro-bizarro/

https://www.tecmundo.com.br/mercado/413858-erro-de-desenvolvedor-disparou-mensagens-de-liquidacao-extrajudicial-do-nubank.htm

https://comunidade.nubank.com.br/discussoes/post/email-de-liquidacao-judicial-Ii0ygNNm8mD5Qxr

☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Bellacosa Mainframe e a internet cada vez mais restrista e insonsa

 ☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Durante uma conversa recente me peguei lembrando de uma ferramenta que muitos profissionais mais jovens provavelmente nunca ouviram falar.

O nome era Copernic.

Para quem viveu a internet dos anos 1990 e início dos anos 2000, o Copernic era quase mágico.

Você digitava uma pesquisa.

Ele consultava diversos motores de busca simultaneamente.

AltaVista.

Lycos.

Excite.

HotBot.

Infoseek.

Yahoo.

Depois consolidava os resultados e apresentava aquilo que considerava mais relevante.

Na época parecia algo revolucionário.

Hoje parece uma relíquia arqueológica.

Mas aquela lembrança me levou a uma reflexão muito maior.

A internet ficou maior ou menor?

A resposta parece óbvia.

Maior.

Muito maior.

Milhões de vezes maior.

Mas talvez essa resposta esteja errada.

☕ A INTERNET QUE PROMETIA CONHECIMENTO INFINITO

Quem começou a navegar na internet durante os anos 1990 provavelmente lembra da sensação.

Cada clique parecia abrir uma porta para um universo desconhecido.

Você começava pesquisando COBOL.

Terminava lendo sobre arqueologia romana.

Depois encontrava um PDF perdido de um professor australiano.

Mais tarde descobria uma apostila digitalizada em 1987.

Era uma experiência de exploração.

A internet era um continente selvagem.

Cheio de trilhas.

Cheio de mapas incompletos.

Cheio de descobertas inesperadas.

O objetivo principal dos mecanismos de busca era simples:

Encontrar informação.

Não importava se ela estava em uma universidade.

Num servidor pessoal.

Num fórum obscuro.

Ou numa página criada por um entusiasta usando HTML rudimentar.

O importante era que ela existia.

☕ O GOOGLE QUE MUDOU O MUNDO

Quando o Google surgiu, ele parecia resolver um problema impossível.

Enquanto outros buscadores dependiam principalmente de palavras-chave, o Google utilizava uma ideia brilhante.

O PageRank.

Em vez de perguntar apenas:

"Quantas vezes esta palavra aparece?"

O sistema perguntava:

"Quantas páginas apontam para esta página?"

A lógica era elegante.

Links funcionavam como votos.

Quanto mais votos de qualidade uma página recebesse, mais relevante ela provavelmente seria.

Os resultados eram impressionantes.

Muitas vezes os primeiros resultados eram exatamente aquilo que procurávamos.

Não porque o Google nos conhecia.

Mas porque compreendia melhor a estrutura da web.

☕ QUANDO O USUÁRIO VIROU O PRODUTO

Com o passar dos anos, algo começou a mudar.

O Google deixou de ser apenas um mecanismo de busca.

Transformou-se em uma plataforma de publicidade.

Isso não é necessariamente uma crítica.

Foi o modelo econômico que financiou boa parte da internet moderna.

Mas a mudança trouxe consequências.

O objetivo deixou de ser apenas encontrar informação.

Agora era necessário:

• Maximizar receita publicitária.

• Combater spam.

• Combater manipulação de SEO.

• Reduzir desinformação.

• Personalizar resultados.

• Aumentar retenção.

A busca deixou de ser um problema puramente técnico.

Passou a ser um problema econômico.

☕ O FIM DA WEB ARTESANAL

Talvez a maior vítima dessa transformação tenha sido a web artesanal.

Quem trabalhou com tecnologia nas décadas passadas certamente conhece esse tipo de conteúdo.

Um especialista mantinha um site simples.

Visual horrível.

HTML básico.

Fundo cinza.

Talvez alguns GIFs piscando.

Mas o conteúdo era extraordinário.

Anos de experiência condensados em dezenas de páginas.

Hoje esse material frequentemente desaparece dos resultados.

Não porque perdeu qualidade.

Mas porque perdeu relevância algorítmica.

O algoritmo prefere:

• Grandes portais.

• Sites otimizados.

• Plataformas com autoridade.

• Conteúdo constantemente atualizado.

O conhecimento continua existindo.

Mas tornou-se invisível.

☕ A DEEP WEB QUE NÃO É CRIMINOSA

Quando ouvimos o termo Deep Web, muitas pessoas pensam imediatamente em mercados ilegais, hackers ou atividades criminosas.

Mas essa é apenas uma pequena parte da história.

Originalmente, Deep Web significa simplesmente conteúdo não indexado.

E essa categoria inclui:

• Bancos de dados acadêmicos.

• Arquivos históricos.

• Fóruns antigos.

• Grupos privados.

• Repositórios técnicos.

• Coleções digitais.

Existe uma quantidade gigantesca de conhecimento que simplesmente não aparece nas buscas tradicionais.

Ele não foi destruído.

Ele não foi censurado.

Ele apenas deixou de ser encontrado.

E do ponto de vista prático, existe pouca diferença entre algo destruído e algo impossível de localizar.

☕ O PARADOXO DA ABUNDÂNCIA

Aqui encontramos um fenômeno fascinante.

A internet produz mais conteúdo do que nunca.

Mas os usuários acessam uma parcela cada vez menor desse conteúdo.

Pense no seu comportamento diário.

Quantos sites diferentes você visita regularmente?

Provavelmente:

• Google

• YouTube

• Wikipedia

• Reddit

• LinkedIn

• Algumas redes sociais

A web aberta continua existindo.

Mas boa parte dela está escondida atrás de plataformas gigantes.

É como morar numa cidade com milhões de ruas e caminhar sempre pelas mesmas dez.

☕ A MORTE DA SERENDIPIDADE

Existe uma palavra pouco conhecida chamada serendipidade.

Ela descreve descobertas valiosas feitas por acaso.

A internet antiga era uma máquina de serendipidade.

Você procurava uma coisa.

Encontrava dez outras.

Hoje os algoritmos tentam ser eficientes.

Eles querem prever seus interesses.

Querem antecipar suas necessidades.

Querem entregar exatamente aquilo que você procura.

Parece maravilhoso.

Mas existe um efeito colateral.

Você encontra menos surpresas.

Menos desvios.

Menos acidentes intelectuais.

Menos descobertas inesperadas.

A eficiência mata a exploração.

☕ O EFEITO BOLHA

Outro fenômeno importante é a personalização.

Os algoritmos aprendem quem somos.

Aprendem nossas preferências.

Nossos hábitos.

Nossos interesses.

Isso melhora a experiência?

Muitas vezes sim.

Mas também cria bolhas.

Quanto mais o sistema aprende sobre você, mais ele entrega versões de você mesmo.

Você gosta de determinado tema.

Recebe mais daquele tema.

Você gosta de determinada opinião.

Recebe mais daquela opinião.

Você gosta de determinado conteúdo.

Recebe mais daquele conteúdo.

A internet que prometia expandir horizontes frequentemente acaba reforçando horizontes já existentes.

☕ A PUBLICIDADE QUE NOS PERSEGUE

Existe algo quase cômico no modelo atual.

Você pesquisa uma cadeira.

Durante semanas recebe anúncios de cadeiras.

Compra a cadeira.

Continua recebendo anúncios de cadeiras.

O sistema supostamente inteligente não percebe que o problema já foi resolvido.

Isso acontece porque o objetivo não é compreender perfeitamente o usuário.

O objetivo é maximizar a probabilidade de uma compra.

Somos constantemente observados.

Segmentados.

Classificados.

Modelados.

Transformados em perfis estatísticos.

A economia digital moderna depende disso.

☕ O CONHECIMENTO INVISÍVEL

Talvez a consequência mais preocupante seja outra.

Estamos produzindo uma quantidade absurda de conhecimento.

Mas encontrar esse conhecimento tornou-se cada vez mais difícil.

Não porque ele não exista.

Mas porque está enterrado.

Sob camadas de algoritmos.

Publicidade.

SEO.

Priorizações automáticas.

Curadorias invisíveis.

A informação não desapareceu.

Ela foi soterrada.

☕ O ARQUEÓLOGO DIGITAL DE 2526

Imagine um historiador vivendo daqui a 500 anos.

Ele descobre que a humanidade possuía acesso ao maior repositório de conhecimento já criado.

Bilhões de páginas.

Bilhões de documentos.

Bilhões de pessoas conectadas.

Então ele faz uma pergunta simples:

"Se havia tanto conhecimento disponível, por que as pessoas consultavam sempre os mesmos poucos sites?"

Talvez essa seja uma das grandes ironias do século XXI.

Nunca produzimos tanto conhecimento.

Nunca tivemos tanta capacidade de compartilhá-lo.

E, ao mesmo tempo, nunca dependemos tanto de um pequeno conjunto de algoritmos para decidir o que merece ser visto.

☕ CONCLUSÃO

Quando lembro do Copernic, do AltaVista ou dos primeiros anos do Google, não sinto apenas nostalgia tecnológica.

Sinto nostalgia de uma filosofia diferente.

A filosofia da descoberta.

A sensação de que a internet era um território a ser explorado.

Não um ambiente cuidadosamente organizado para maximizar engajamento.

Talvez a internet não tenha ficado menor.

Talvez ela tenha ficado tão grande que precisou de guias.

O problema é que esses guias passaram a decidir quais caminhos merecem ser percorridos.

E quando isso acontece, surge uma pergunta inquietante.

O que está sendo escondido?

Não por censura.

Não por conspiração.

Mas simplesmente porque ninguém mais consegue encontrá-lo.

Porque às vezes a forma mais eficiente de tornar algo invisível não é destruí-lo.

É apenas enterrá-lo sob uma montanha de informações mais lucrativas.

E essa talvez seja uma das histórias mais importantes da era digital.

 

Bellacosa Mainframe e a crise silenciosa do COBOL

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

"O problema não é que os sistemas COBOL vão parar amanhã. O problema é que, quando precisarmos deles depois de amanhã, talvez não haja gente suficiente para entendê-los."

---

Introdução: O paradoxo que desafia a lógica

Existe uma frase repetida há décadas no mundo da tecnologia:

"COBOL está morrendo."

Curiosamente, essa frase é tão antiga que já deveria ter morrido antes do próprio COBOL.

Nos anos 1980 diziam isso.

Nos anos 1990 também.

Nos anos 2000 então, parecia inevitável.

Veio Java.

Veio .NET.

Veio Python.

Veio Cloud.

Vieram Microservices.

Vieram Containers.

Vieram APIs.

Veio Inteligência Artificial.

E o COBOL continua processando bilhões de transações diariamente.

Mas há algo diferente acontecendo agora.

Pela primeira vez na história, o risco não é tecnológico.

O risco é humano.

Não estamos falando da morte da linguagem.

Estamos falando da aposentadoria das pessoas que sabem usá-la.

E isso muda completamente a discussão.

---

O grande erro dos anos 90

Durante os anos 1990 aconteceu um fenômeno curioso.

Universidades do mundo inteiro decidiram que COBOL não fazia mais sentido.

Os currículos migraram para:

• C++

• Java

• Redes

• Sistemas Distribuídos

• Orientação a Objetos

Naquele momento parecia uma decisão racional.

A internet estava explodindo.

O mundo falava sobre websites.

Empresas de tecnologia surgiam diariamente.

Tudo indicava que os sistemas legados seriam substituídos rapidamente.

Mas havia um detalhe que ninguém percebeu.

Substituir um sistema crítico não é como trocar um aplicativo de celular.

---

O mito da reescrita fácil

Imagine um sistema bancário criado em 1975.

Durante cinquenta anos ele recebeu:

• correções

• adaptações

• mudanças regulatórias

• novos produtos

• fusões bancárias

• ajustes tributários

• exceções operacionais

Hoje esse sistema possui milhões de linhas de código.

Mas o código é apenas a ponta do iceberg.

O verdadeiro patrimônio é o conhecimento de negócio embutido nele.

Muitas regras não estão documentadas.

Elas vivem no código.

E pior.

Muitas vezes nem o próprio negócio sabe que elas existem.

---

Exemplo real

Uma seguradora decidiu migrar um sistema COBOL para Java.

Projeto estimado:

• 2 anos

• US$ 20 milhões

Resultado:

• 7 anos

• mais de US$ 100 milhões

E ainda assim precisaram manter parte do sistema original funcionando.

Por quê?

Porque descobriram regras escondidas no código que ninguém conhecia.

Uma delas calculava benefícios de clientes antigos utilizando uma legislação que já nem existia mais.

Mas aqueles contratos continuavam válidos.

Remover a regra geraria processos judiciais.

---

O COBOL virou infraestrutura invisível

Hoje ninguém acorda pensando em COBOL.

Da mesma forma que ninguém acorda pensando em:

• rede elétrica

• abastecimento de água

• sistema de esgoto

Mas todos percebem quando param de funcionar.

O COBOL tornou-se uma camada invisível da sociedade moderna.

---

Quando você faz um PIX

Existe grande chance de algum processamento acabar passando por sistemas mainframe.

Quando usa cartão de crédito

Mainframe.

Quando recebe aposentadoria

Mainframe.

Quando paga imposto

Mainframe.

Quando consulta benefícios governamentais

Mainframe.

Quando uma companhia aérea processa reservas

Mainframe.

---

Muitas pessoas acreditam que esses sistemas foram substituídos.

Na realidade, na maioria dos casos, eles foram encapsulados.

Colocou-se uma API na frente.

Um aplicativo bonito.

Uma interface moderna.

Mas atrás continua existindo um programa COBOL executando a lógica crítica.

---

O IRS e o sistema de 60 anos

Um dos exemplos mais famosos é o Internal Revenue Service (IRS) dos Estados Unidos.

Quando falamos do IRS estamos falando do órgão responsável pela arrecadação federal americana.

Grande parte da infraestrutura principal foi construída durante os anos 1960.

Pense nisso.

Quando parte desses sistemas nasceu:

• o homem ainda não havia chegado à Lua;

• a internet não existia;

• computadores ocupavam salas inteiras;

• discos rígidos tinham capacidade ridícula para os padrões atuais.

Mesmo assim esses sistemas continuam funcionando.

Isso não é apenas impressionante.

É quase inacreditável.

---

O custo da modernização

Existe outra ilusão comum.

A ideia de que basta investir dinheiro para resolver o problema.

Se fosse verdade, ele já estaria resolvido.

Governos e bancos gastaram bilhões tentando modernizar sistemas legados.

Alguns tiveram sucesso.

Muitos não.

---

O motivo

A dificuldade não está em programar.

A dificuldade está em entender.

Imagine receber um programa COBOL escrito em 1978.

O programador original já morreu.

O analista de negócios aposentou-se.

A documentação desapareceu.

Os requisitos originais não existem.

Agora descubra exatamente o que ele faz.

Sem errar.

Porque um erro pode impactar:

• milhões de aposentados;

• bilhões de dólares;

• benefícios sociais;

• arrecadação tributária.

---

A aposentadoria em massa

Aqui está o ponto mais preocupante.

O profissional COBOL médio não tem 25 anos.

Nem 35.

Nem 45.

Em muitos lugares ele já ultrapassou os 55 anos.

Isso significa que estamos diante de uma transição geracional gigantesca.

Imagine uma empresa com:

• 100 especialistas COBOL

Se 10% se aposentam por ano:

Ano 1:
100 → 90

Ano 5:
90 → 59

Ano 10:
59 → 35

Ano 15:
35 → 20

Ano 20:
20 → 12

O conhecimento evapora rapidamente.

---

O conhecimento que não está nos livros

Aqui existe algo ainda mais perigoso.

Muitas pessoas confundem saber COBOL com saber sistemas COBOL.

São coisas completamente diferentes.

Aprender COBOL pode levar semanas.

Dominar um ambiente corporativo pode levar décadas.

---

Exemplo

Um desenvolvedor pode aprender:

ADD A TO B GIVING C.

em poucos minutos.

Mas compreender:

• JES2

• CICS

• DB2

• IMS

• RACF

• VSAM

• MQ

• JCL

• SMF

• DFSORT

e a integração entre todos eles...

isso pode exigir anos.

---

O verdadeiro gargalo não é COBOL

Essa é uma observação que faço frequentemente.

As manchetes falam:

"Faltam programadores COBOL."

Mas essa frase é simplista.

O que realmente falta são profissionais capazes de entender ecossistemas corporativos complexos.

---

Porque um especialista de verdade entende:

• negócio

• arquitetura

• operação

• performance

• segurança

• recuperação de desastres

Ele não é apenas programador.

Ele é guardião do conhecimento institucional.

---

A inteligência artificial vai resolver?

Pergunta inevitável em 2026.

A resposta é:

Sim.

E não.

---

Onde a IA ajuda

Hoje a IA consegue:

• explicar código COBOL;

• converter COBOL para Java;

• gerar documentação;

• identificar dependências;

• acelerar manutenção.

Isso é extraordinário.

---

Onde a IA não resolve

A IA não sabe:

• por que determinada regra existe;

• qual acordo político gerou aquela exceção;

• qual legislação de 1987 originou um cálculo;

• qual cliente depende daquela lógica.

Esse conhecimento continua humano.

---

O caso brasileiro

Como brasileiro e profissional de mainframe, vejo um cenário interessante.

O Brasil está em posição melhor do que muitos países.

Por quê?

Porque nunca abandonou completamente a formação em tecnologias corporativas.

Temos profissionais atuando em:

• bancos;

• seguradoras;

• governo;

• telecomunicações.

Instituições como:

• Banco do Brasil

• Caixa

• Bradesco

• Itaú

• Santander

• Serpro

• Dataprev

continuam mantendo grandes ambientes mainframe.

Isso criou uma continuidade geracional que muitos países perderam.

---

O erro estratégico das empresas

Durante anos muitas organizações enxergaram o mainframe apenas como custo.

E isso gerou decisões perigosas.

Redução de equipes.

Pouco treinamento.

Ausência de sucessão.

Falta de documentação.

Perda de conhecimento.

---

O resultado?

Quando um especialista se aposenta, descobre-se que ele era o único que compreendia determinado processo crítico.

Já vi situações em que uma única pessoa entendia completamente um sistema responsável por movimentar bilhões.

Quando ela saiu, a empresa entrou em pânico.

---

O mito do profissional velho

Existe também um preconceito silencioso.

Muita gente associa COBOL a tecnologia ultrapassada.

Logo associa seus profissionais a algo ultrapassado.

Isso é um erro monumental.

Os melhores especialistas que conheci dominavam:

• COBOL

• Java

• APIs

• Linux

• Cloud

• Containers

• DevOps

Eles simplesmente entendiam também a camada que sustenta o mundo.

---

O que deveria estar acontecendo

As organizações mais inteligentes já perceberam o problema.

Elas estão investindo em:

Mentoria reversa

Veteranos treinando jovens.

Pair Programming

Transferência contínua de conhecimento.

Documentação moderna

Captura do conhecimento tácito.

IA aplicada ao legado

Aceleração da curva de aprendizado.

Programas universitários

Retorno do ensino de COBOL.

---

Uma comparação com a engenharia civil

Imagine uma ponte construída há 60 anos.

Ela continua suportando milhões de veículos.

Ninguém diria:

"Vamos demolir porque é antiga."

Primeiro analisamos:

• estabilidade;

• manutenção;

• custo;

• risco.

Sistemas COBOL deveriam ser vistos da mesma forma.

A idade não é o problema.

A capacidade de manutenção é.

---

O verdadeiro risco para o futuro

A pergunta não é:

"Quando o COBOL vai acabar?"

A pergunta correta é:

"Quem vai entender os sistemas quando os especialistas atuais não estiverem mais aqui?"

Essa é uma questão muito mais séria.

Porque linguagens podem ser aprendidas.

Conhecimento institucional não pode ser recriado facilmente.

---

A visão Bellacosa Mainframe

Depois de décadas observando o mundo corporativo, cheguei a uma conclusão simples.

O futuro não será COBOL versus IA.

Nem Mainframe versus Cloud.

Nem Legado versus Modernização.

O futuro pertence à integração.

Os vencedores serão aqueles capazes de unir:

• conhecimento histórico;

• arquitetura moderna;

• inteligência artificial;

• plataformas corporativas.

O profissional mais valioso da próxima década não será aquele que conhece apenas a tecnologia nova.

Nem aquele que conhece apenas a tecnologia antiga.

Será aquele que consegue traduzir um mundo para o outro.

---

Conclusão: a crise silenciosa é real

A grande ironia da história é que o COBOL nunca foi tão invisível e tão importante ao mesmo tempo.

Ele está escondido atrás de aplicativos modernos, APIs elegantes e interfaces digitais sofisticadas.

Mas continua sustentando partes fundamentais da economia global.

O verdadeiro desafio não é técnico.

É humano.

A cada aposentadoria, perde-se mais do que um programador.

Perde-se contexto.

Perde-se história.

Perde-se conhecimento acumulado ao longo de décadas.

E conhecimento não pode ser recompilado.

A crise silenciosa do COBOL não é sobre uma linguagem criada em 1959.

É sobre a transferência de conhecimento de uma geração para outra.

Se governos, bancos e grandes corporações não tratarem isso como prioridade estratégica, poderão descobrir tarde demais que substituir hardware é fácil, substituir software é difícil, mas substituir experiência é quase impossível.

E talvez essa seja a maior lição que o mundo da tecnologia ainda não compreendeu.

O problema nunca foi o COBOL envelhecer. O problema é que seus especialistas envelheceram primeiro. ☕🚀💻🏦