Bellacosa Mainframe quando o sonho da nuvem virada pesadelo

☕💸☁️ CLOUD BILL SHOCK — QUANDO A FATURA DA NUVEM CHEGA E O MAINFRAME COMEÇA A PARECER BARATO

Existe um momento muito curioso na vida de quase toda empresa que embarca na jornada da computação em nuvem.

No início tudo parece maravilhoso.

O desenvolvedor cria um servidor em poucos minutos.

O ambiente de testes nasce instantaneamente.

Os sistemas escalam sozinhos.

As equipes ganham agilidade.

Os executivos sorriem.

Os arquitetos comemoram.

Os fornecedores fazem apresentações cheias de gráficos coloridos.

E então chega a primeira fatura realmente grande.

Nesse momento nasce um fenômeno que ficou conhecido mundialmente como:

Cloud Bill Shock.

Ou, em português:

O Choque da Fatura da Nuvem.

Para muitos profissionais jovens, especialmente quem está começando carreira em COBOL e Mainframe, esse termo parece estranho.

Afinal, durante anos ouvimos que a nuvem era mais moderna, mais simples e mais barata.

Mas a realidade dos grandes ambientes corporativos mostrou uma verdade muito interessante.

Cloud pode ser fantástica.

Cloud pode ser revolucionária.

Cloud pode acelerar negócios.

Mas cloud nem sempre é barata.

E algumas empresas descobriram isso da forma mais dolorosa possível.

Ao abrir a fatura no final do mês.

---

O que uma Analista COBOL Júnior precisa entender

Vamos começar do início.

Imagine que você trabalha em um banco tradicional.

Existe um ambiente mainframe que processa:

• contas correntes;

• cartões;

• PIX;

• empréstimos;

• aplicações financeiras.

Tudo funciona há décadas.

O sistema está pago.

A infraestrutura está instalada.

Os profissionais conhecem a plataforma.

Os processos são estáveis.

Então surge a pergunta:

"Por que não colocar tudo na nuvem?"

Parece uma pergunta simples.

Mas a resposta é extremamente complexa.

Porque existe uma enorme diferença entre:

custo inicial
e
custo operacional contínuo.

---

O encanto da nuvem

Imagine uma startup recém-criada.

Ela possui:

• 5 desenvolvedores;

• 1 produto;

• 100 clientes.

Comprar um datacenter próprio seria loucura.

A nuvem resolve o problema.

Você cria:

• servidores;

• bancos de dados;

• armazenamento;

• monitoramento.

Tudo com poucos cliques.

O modelo parece perfeito.

E realmente é.

Nesse estágio.

---

O problema da escala

Agora imagine que essa startup cresceu.

Não possui mais:

• 100 clientes.

Possui:

• 1 milhão.

Depois:

• 10 milhões.

Depois:

• 50 milhões.

Depois:

• 100 milhões.

Agora o cenário muda completamente.

Cada operação gera consumo.

Cada acesso gera consumo.

Cada consulta gera consumo.

Cada byte armazenado gera consumo.

Cada transferência de dados gera consumo.

Cada serviço adicional gera consumo.

A conta começa a crescer.

E cresce rapidamente.

---

O aluguel invisível

Uma forma simples de explicar cloud para um iniciante é esta:

Mainframe tradicional muitas vezes funciona como casa própria.

Cloud funciona como aluguel.

Imagine um apartamento alugado.

No começo parece excelente.

Pouco investimento inicial.

Entrada reduzida.

Flexibilidade.

Mas depois de vinte anos pagando aluguel...

Você percebe que gastou uma fortuna.

Cloud possui comportamento parecido.

Você paga continuamente por:

• CPU;

• memória;

• armazenamento;

• rede;

• backup;

• tráfego;

• monitoramento;

• segurança.

A conta nunca para.

---

O dia em que o financeiro descobre a AWS

Existe uma história que se repete em inúmeras empresas.

A área técnica está feliz.

A inovação está acelerada.

Os desenvolvedores estão satisfeitos.

Então o departamento financeiro recebe a fatura.

Primeiro mês:

US$ 5 mil.

Segundo mês:

US$ 20 mil.

Terceiro mês:

US$ 80 mil.

Sexto mês:

US$ 500 mil.

Um ano depois:

milhões de dólares.

Nesse momento alguém pergunta:

"Por que estamos gastando tudo isso?"

E nasce uma investigação corporativa.

---

O caso do armazenamento

Uma analista COBOL talvez pense:

"Mas armazenamento é barato."

Sim.

Individualmente.

Mas vamos fazer uma conta simples.

Imagine um banco com:

• 100 milhões de clientes;

• documentos digitalizados;

• extratos;

• imagens;

• logs;

• backups;

• auditoria.

Estamos falando de petabytes.

Talvez dezenas de petabytes.

Quando o volume cresce, cada centavo por gigabyte se transforma em milhões.

---

O inimigo chamado Data Transfer

Existe uma cobrança que assusta muitos arquitetos.

Transferência de dados.

Os provedores de nuvem adoram falar sobre armazenamento.

Sobre CPU.

Sobre inteligência artificial.

Mas existe um detalhe.

Mover dados também custa dinheiro.

Muito dinheiro.

Imagine:

• aplicativos móveis;

• APIs;

• integrações;

• analytics;

• parceiros externos.

Bilhões de chamadas.

Bilhões de respostas.

Terabytes trafegando diariamente.

Cada pacote possui custo.

---

O pesadelo do ambiente esquecido

Todo analista experiente já viu isso.

Um desenvolvedor cria:

• servidor de teste;

• banco temporário;

• ambiente experimental.

O projeto termina.

O ambiente fica ligado.

Dias passam.

Meses passam.

Anos passam.

Ninguém percebe.

Mas a cobrança continua.

Existem empresas pagando milhares de dólares por recursos esquecidos.

---

O efeito multiplicador dos microsserviços

Os microsserviços trouxeram inúmeras vantagens.

Mas também criaram novos desafios.

No mundo tradicional talvez existisse:

• uma aplicação;

• um banco de dados.

No mundo moderno podemos ter:

• centenas;

• milhares;

• dezenas de milhares de serviços.

Cada um consumindo:

• CPU;

• memória;

• armazenamento;

• rede.

Separadamente parecem baratos.

Juntos tornam-se gigantescos.

---

Quando o Mainframe entra na conversa

É aqui que uma analista COBOL começa a entender o debate.

Um mainframe não é vendido como servidor barato.

Nunca foi.

Mas existe algo impressionante nele.

Consolidação.

Um único IBM Z moderno pode processar volumes absurdos de transações.

Em muitos casos substituindo centenas ou milhares de servidores distribuídos.

O resultado é que algumas cargas financeiras apresentam:

• menor consumo energético;

• menor ocupação física;

• menor administração;

• menor complexidade operacional.

Por isso o cálculo econômico não é tão simples quanto parece.

---

O choque das empresas famosas

Nos últimos anos surgiu um movimento chamado:

Cloud Repatriation

Traduzindo:

"Trazer sistemas de volta."

Empresas que migraram tudo para cloud começaram a revisar decisões.

Não porque a nuvem fosse ruim.

Mas porque certas cargas de trabalho ficaram caras demais.

Algumas descobriram economias milionárias ao mover parte dos ambientes para:

• infraestrutura própria;

• colocation;

• plataformas especializadas.

O mercado percebeu que não existe solução mágica.

---

O erro mais comum dos iniciantes

Muitos profissionais novos acreditam que arquitetura é apenas tecnologia.

Mas arquitetura também é economia.

Um arquiteto precisa entender:

• desempenho;

• segurança;

• disponibilidade;

• custos.

A melhor solução técnica do mundo pode fracassar se custar dez vezes mais que o necessário.

---

O que os bancos aprenderam

Os grandes bancos possuem uma experiência valiosa.

Eles processam bilhões de transações há décadas.

Por isso normalmente adotam arquitetura híbrida.

Não colocam tudo na cloud.

Também não deixam tudo no mainframe.

Cada ambiente recebe a carga mais adequada.

Por exemplo:

Aplicativo móvel?

Cloud.

Machine Learning?

Cloud.

Analytics?

Cloud.

Core bancário?

Talvez mainframe.

Liquidação financeira?

Talvez mainframe.

Processamento crítico?

Talvez mainframe.

---

O paradoxo que ninguém conta

Aqui está a parte mais interessante.

O objetivo da cloud nunca foi ser sempre mais barata.

O objetivo principal era:

agilidade.

Você consegue lançar produtos rapidamente.

Experimentar ideias.

Criar novos serviços.

Escalar em minutos.

Essa velocidade possui valor.

Muitas vezes o ganho de negócio compensa o aumento de custo.

Por isso empresas continuam investindo bilhões em nuvem.

---

O que uma Analista COBOL deve aprender com isso

Talvez a maior lição seja esta.

Não existe guerra entre Mainframe e Cloud.

Essa guerra só existe em apresentações simplificadas.

No mundo real os dois convivem.

E convivem muito bem.

O profissional moderno precisa compreender:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Integração;

• Arquitetura distribuída.

Porque o mercado não procura especialistas que conhecem apenas um lado.

Procura profissionais que entendem como tudo se conecta.

---

Conclusão: Quando a Fatura Vira Professor

Cloud Bill Shock é uma das lições mais importantes da tecnologia moderna.

Ele nos lembra que inovação possui custo.

Escalabilidade possui custo.

Conveniência possui custo.

Flexibilidade possui custo.

A nuvem transformou a indústria.

Permitiu o nascimento de empresas como Nubank, Mercado Pago e centenas de fintechs.

Mas também ensinou uma lição valiosa.

Quando os números chegam à casa dos milhões de clientes e bilhões de transações, a discussão deixa de ser tecnológica.

Passa a ser econômica.

E é justamente nesse momento que muitos executivos voltam a olhar para tecnologias que julgavam ultrapassadas.

Mainframe.

COBOL.

CICS.

DB2.

IBM Z.

Não porque sejam antigos.

Mas porque continuam resolvendo problemas extremamente difíceis com eficiência impressionante.

Por isso, da próxima vez que alguém disser que o futuro pertence apenas à nuvem, lembre-se de uma verdade que o mercado financeiro aprendeu ao longo das décadas:

A tecnologia mais moderna nem sempre é a mais barata.
A mais antiga nem sempre é a mais cara.
E a melhor arquitetura quase sempre é aquela que equilibra inovação, desempenho e custo.

É exatamente nesse ponto que nasce o verdadeiro arquiteto de sistemas.

E é exatamente aí que uma analista COBOL deixa de enxergar apenas código e começa a enxergar negócios.

 

Bellacosa Mainframe e uma visão do sistema bancario brasileiro

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

Existe uma frase que se tornou quase um mantra no mercado financeiro moderno:

"O futuro está na nuvem."

E é verdade.

Nubank, Inter, Mercado Pago, PicPay, PagBank e dezenas de fintechs brasileiras nasceram em arquiteturas modernas, utilizando APIs, microsserviços, containers, Kubernetes, inteligência artificial e infraestrutura cloud.

Mas existe uma realidade pouco comentada fora dos bastidores da tecnologia bancária.

Uma realidade que surpreende estudantes, jornalistas, executivos recém-chegados ao setor financeiro e até muitos profissionais de TI.

O dinheiro que movimenta bilhões de reais diariamente no Brasil continua passando por sistemas centrais executados em plataformas que nasceram décadas antes da internet comercial.

Sim.

Enquanto o cliente faz um PIX em um smartphone equipado com processadores capazes de executar bilhões de operações por segundo, uma parte significativa da infraestrutura que garante que aquele dinheiro chegue ao destino continua rodando em ambientes IBM Z, CICS, DB2, MQ e COBOL.

E isso não acontece por nostalgia.

Acontece porque funciona.

Muito bem.

---

O mito do "banco 100% digital"

Quando um banco digital aparece na televisão, geralmente a propaganda mostra:

• aplicativo moderno;

• cartão colorido;

• conta aberta em minutos;

• chatbot inteligente;

• investimentos com poucos cliques.

Tudo parece novo.

Tudo parece revolucionário.

Tudo parece distante do mundo dos grandes datacenters.

Mas existe uma diferença importante entre:

interface digital
e
infraestrutura financeira.

O cliente enxerga o aplicativo.

O sistema financeiro enxerga liquidação.

E são coisas completamente diferentes.

Um banco pode ter uma experiência totalmente digital e, ainda assim, depender de sistemas centrais extremamente robustos para realizar:

• liquidação financeira;

• compensação;

• controle contábil;

• reconciliação;

• registro de operações;

• cálculo de tarifas;

• processamento de empréstimos;

• integração com o Banco Central.

É nesse momento que entram os sistemas de missão crítica.

---

O que acontece quando você faz um PIX?

Vamos imaginar uma situação extremamente comum.

Você abre o aplicativo.

Transfere R$ 100 para um amigo.

A operação parece instantânea.

Na tela tudo ocorre em segundos.

Mas por trás dos bastidores existe uma verdadeira cadeia industrial de processamento.

O aplicativo envia a solicitação.

Uma API recebe o pedido.

Serviços de autenticação validam identidade.

Motores antifraude executam verificações.

Regras de compliance são avaliadas.

Sistemas de limites são consultados.

Dados cadastrais são verificados.

Mensagerias distribuem eventos.

Sistemas contábeis registram a operação.

Mecanismos de liquidação realizam o acerto financeiro.

Tudo isso antes que a mensagem "PIX realizado com sucesso" apareça na tela.

O usuário vê um clique.

O datacenter vê centenas de transações.

---

Onde entra o mainframe?

É aqui que muita gente se surpreende.

O mainframe raramente aparece na camada visual.

Ele normalmente opera na camada mais importante.

A camada onde não pode haver erro.

Imagine o seguinte cenário.

Se uma rede social ficar indisponível por 10 minutos, usuários reclamam.

Se um streaming cair durante uma série, pessoas ficam irritadas.

Mas se um banco perder o controle de saldos durante 10 minutos?

O problema pode atingir milhões de clientes.

Por isso os sistemas responsáveis pelos registros financeiros mais críticos precisam apresentar:

• disponibilidade extrema;

• consistência absoluta;

• segurança rigorosa;

• rastreabilidade completa;

• recuperação imediata.

São justamente essas características que fizeram os mainframes permanecerem relevantes.

---

O paradoxo da fintech

As fintechs surgiram prometendo romper com os bancos tradicionais.

Em muitos aspectos conseguiram.

Mudaram a experiência do cliente.

Reduziram burocracias.

Popularizaram contas digitais.

Criaram novos modelos de negócio.

Mas descobriram rapidamente uma verdade do mercado financeiro.

Movimentar dinheiro é muito mais difícil do que movimentar dados.

Enviar uma foto errada em uma rede social gera um transtorno.

Transferir R$ 10 milhões para a conta errada gera uma crise.

Por isso a arquitetura financeira moderna acabou evoluindo para um modelo híbrido.

Na superfície:

• cloud;

• APIs;

• microsserviços;

• inteligência artificial.

No núcleo:

• processamento transacional;

• bancos de dados críticos;

• mensageria corporativa;

• sistemas centrais de liquidação.

É uma combinação extremamente poderosa.

---

A nuvem descobriu que precisa do mainframe

Durante alguns anos surgiu uma narrativa bastante agressiva.

Muitos especialistas afirmavam que o mainframe desapareceria rapidamente.

A computação em nuvem seria suficiente para tudo.

A realidade mostrou algo diferente.

O que ocorreu foi integração.

Hoje observamos ambientes híbridos onde:

• Kubernetes conversa com CICS;

• APIs REST acessam programas COBOL;

• aplicações cloud consomem serviços do z/OS;

• eventos trafegam através do IBM MQ;

• microsserviços utilizam informações armazenadas em DB2.

Não houve substituição.

Houve convergência.

A nuvem não matou o mainframe.

A nuvem passou a conversar com ele.

---

O caso brasileiro

O Brasil possui um dos sistemas financeiros mais sofisticados do planeta.

Muitas vezes não percebemos isso.

PIX.

TED.

DOC.

Open Finance.

Cartões.

Boletos.

Débito automático.

Tudo isso precisa funcionar para centenas de milhões de contas.

Os números impressionam.

Bilhões de transações são processadas todos os meses.

Milhões de operações acontecem simultaneamente.

O sistema precisa funcionar:

• de madrugada;

• em feriados;

• durante promoções;

• na Black Friday;

• durante a Copa do Mundo;

• durante grandes eventos nacionais.

A infraestrutura necessária para suportar esse volume é gigantesca.

E boa parte dela continua baseada em tecnologias que nasceram décadas atrás, mas evoluíram continuamente.

---

O COBOL que ninguém vê

Poucas tecnologias sofreram tanto preconceito quanto o COBOL.

Para muitos profissionais jovens, COBOL parece uma relíquia.

Algo pertencente a museus de informática.

Mas existe um detalhe curioso.

Grande parte das pessoas que criticam COBOL utilizou sistemas processados por COBOL antes mesmo do café da manhã.

Salário.

PIX.

Cartão.

Financiamento.

Previdência.

Seguros.

Consórcios.

Tudo isso frequentemente passa por programas COBOL.

O motivo é simples.

Esses sistemas foram construídos ao longo de décadas.

Receberam investimentos bilionários.

Foram testados em condições extremas.

Acumularam conhecimento de negócio impossível de reproduzir rapidamente.

Muitas vezes o código representa mais valor do que a própria infraestrutura.

---

O banco invisível

Imagine um iceberg.

O cliente vê apenas a ponta.

Aplicativo.

Cartão.

Notificação.

Interface.

Mas abaixo da superfície existe uma massa gigantesca de tecnologia invisível.

Essa parte inclui:

• motores contábeis;

• sistemas regulatórios;

• integração com Banco Central;

• mecanismos de liquidação;

• auditoria;

• compliance;

• segurança.

É nesse universo invisível que o mainframe continua brilhando.

E justamente por ser invisível, raramente recebe o reconhecimento merecido.

---

Quando tudo funciona ninguém percebe

Existe uma ironia interessante no mundo da infraestrutura.

Quanto melhor um sistema funciona, menos as pessoas falam sobre ele.

Ninguém elogia um elevador por funcionar.

Ninguém agradece à rede elétrica por fornecer energia.

Ninguém faz uma postagem comemorando que o saldo bancário apareceu corretamente.

Mas quando ocorre uma falha?

Todo mundo percebe.

Por isso os sistemas centrais são projetados para uma missão simples:

não chamar atenção.

O sucesso é a invisibilidade.

---

O futuro não é cloud versus mainframe

Uma das maiores lições da última década foi perceber que a discussão estava errada.

A pergunta nunca deveria ter sido:

"Cloud ou Mainframe?"

A pergunta correta é:

"Como integrar os dois da melhor forma possível?"

Os líderes do mercado entenderam isso.

Hoje as arquiteturas mais modernas utilizam o melhor dos dois mundos.

Cloud para:

• inovação rápida;

• elasticidade;

• analytics;

• inteligência artificial.

Mainframe para:

• processamento massivo;

• transações críticas;

• consistência financeira;

• segurança corporativa.

O resultado é uma arquitetura híbrida extremamente eficiente.

---

A verdadeira transformação digital

Muitas empresas acreditam que transformação digital significa abandonar tudo que veio antes.

Mas a história mostra outra coisa.

Transformação digital bem-sucedida raramente consiste em destruir.

Consiste em evoluir.

Os sistemas que sustentam o mercado financeiro brasileiro representam décadas de conhecimento acumulado.

Substituí-los completamente seria como demolir uma usina hidrelétrica para construir um gerador portátil.

Não faz sentido.

O caminho inteligente é modernizar.

Expor APIs.

Integrar plataformas.

Automatizar processos.

Conectar o legado ao futuro.

---

O que os estudantes precisam entender

Quem está começando carreira em tecnologia frequentemente busca apenas as ferramentas mais recentes.

Isso é natural.

Mas existe uma lição valiosa.

As tecnologias que movimentam bilhões nem sempre são as mais populares nas redes sociais.

Muitas vezes são as mais confiáveis.

As mais estáveis.

As mais resilientes.

O profissional que entende:

• cloud;

• APIs;

• Kubernetes;

• segurança;

• mainframe;

• integração corporativa;

torna-se extremamente valioso para o mercado.

Porque consegue enxergar a arquitetura completa.

Não apenas a camada visível.

---

Conclusão: o coração continua batendo

Os maiores bancos digitais do Brasil nasceram na nuvem.

Foram criados por uma geração que cresceu falando de APIs, microsserviços e aplicações móveis.

Mudaram completamente a forma como os brasileiros se relacionam com o dinheiro.

Mas, ao crescerem, descobriram algo que os bancos tradicionais já sabiam há décadas.

No mercado financeiro, velocidade é importante.

Experiência do usuário é importante.

Inovação é importante.

Mas nada é mais importante do que confiança.

E confiança se constrói com sistemas capazes de operar dia após dia, ano após ano, movimentando bilhões de reais sem perder o controle de um único centavo.

Por isso, enquanto milhões de brasileiros fazem PIX, pagam boletos, investem, financiam imóveis e utilizam aplicativos modernos, existe uma infraestrutura silenciosa trabalhando nos bastidores.

Uma infraestrutura que raramente aparece nas propagandas.

Que quase nunca vira manchete.

Mas que continua sustentando o sistema financeiro nacional.

A nuvem trouxe inovação.

As fintechs trouxeram agilidade.

Os aplicativos trouxeram conveniência.

Mas, no coração de boa parte dessa engrenagem, o velho gigante continua trabalhando.

Discreto.

Confiável.

Resiliente.

Processando bilhões.

Como faz há décadas.

E, ao que tudo indica, continuará fazendo por muitos anos.

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 DITADURA DA BELEZA DIGITAL: QUANDO O MUNDO REAL DESAPARECEU DO FEEDB

 

Bellacosa Mainframe e a ditadura da beleza digital

☕🚀 A DITADURA DA BELEZA DIGITAL: QUANDO O MUNDO REAL DESAPARECEU DO FEED

"Espere um minuto... aqui só tem gente bonita."

Recentemente me peguei lembrando de uma cena curiosa do filme O Último Grande Herói (Last Action Hero, 1993).

Em determinado momento, o garoto que entra dentro de um filme de ação percebe algo estranho e diz ao personagem de Arnold Schwarzenegger:

— "Isso não é real. Aqui só tem gente bonita."

Quando assisti ao filme pela primeira vez, ainda nos anos 90, aquilo parecia apenas uma piada sobre Hollywood.

Hoje, olhando para Instagram, TikTok, Tinder e boa parte das redes sociais, percebo que aquela frase talvez tenha sido uma das previsões mais precisas sobre o futuro da internet.

Porque basta abrir o celular para entrar em um universo onde praticamente todos parecem mais bonitos, mais felizes, mais ricos, mais interessantes e mais bem-sucedidos do que a média da população.

E então surge uma pergunta desconfortável:

O que acontece com as pessoas comuns quando vivem cercadas por uma vitrine permanente de perfeição?

---

O Mundo Antes da Internet

Durante milhares de anos, os seres humanos viveram cercados por pessoas normais.

Sua referência de beleza era:

• sua escola;

• sua rua;

• seu bairro;

• seu local de trabalho;

• sua cidade.

Você comparava sua aparência com as pessoas que realmente encontrava todos os dias.

Havia gente bonita.

Havia gente feia.

Havia gente comum.

E tudo isso era perfeitamente natural.

Mas a internet alterou completamente essa dinâmica.

Pela primeira vez na história da humanidade, uma pessoa pode acordar e, em poucos minutos, ser exposta às pessoas mais bonitas do planeta inteiro.

Não da sua cidade.

Não do seu estado.

Não do seu país.

Do planeta.

Seu cérebro, porém, continua operando com hardware biológico desenvolvido há dezenas de milhares de anos.

Ele não entende que está vendo uma seleção.

Ele acredita que está vendo a realidade.

E aí começam os problemas.

---

O Algoritmo Não Ama a Verdade

O algoritmo não tem compromisso com a realidade.

Ele tem compromisso com atenção.

E atenção gera lucro.

Imagine duas fotos:

Foto 1:
Uma pessoa comum tomando café antes do trabalho.

Foto 2:
Uma modelo profissional em uma praia paradisíaca durante o pôr do sol.

Qual recebe mais curtidas?

Qual gera mais comentários?

Qual mantém o usuário mais tempo na plataforma?

O algoritmo aprende rapidamente.

E passa a entregar cada vez mais conteúdos semelhantes.

Pouco a pouco, a plataforma cria uma realidade paralela.

Uma realidade onde:

• todos são atraentes;

• todos viajam;

• todos treinam;

• todos empreendem;

• todos são felizes.

Mas essa realidade não existe.

Ela é uma seleção estatística.

Uma espécie de "Hollywood automatizada".

---

Tinder versus Badoo: Um Experimento Social Fascinante

Existe uma observação curiosa que muitos usuários já fizeram.

Ao navegar pelo Badoo, normalmente encontramos pessoas muito mais parecidas com aquelas que vemos no supermercado, no ônibus ou no shopping.

Pessoas comuns.

Fotos comuns.

Vidas comuns.

Já no Tinder, especialmente em grandes centros urbanos, muitas vezes parece que entramos em um catálogo de modelos.

Pessoas extremamente produzidas.

Fotos profissionais.

Corpos impecáveis.

Cenários perfeitos.

Isso não significa que só existam pessoas bonitas no Tinder.

Mas a dinâmica da plataforma favorece a exibição dos perfis mais atrativos visualmente.

O resultado é uma espécie de mercado altamente competitivo.

E, como em qualquer mercado, os participantes tentam otimizar sua apresentação.

Filtros.

Edição.

Poses.

Iluminação.

Produção.

A consequência é um ambiente cada vez mais distante da vida cotidiana.

---

O Desaparecimento da Pessoa Comum

Talvez o fenômeno mais interessante seja que as pessoas comuns não desapareceram da sociedade.

Elas desapareceram da visibilidade.

E isso faz toda a diferença.

Quando abrimos uma rede social, temos a impressão de que o mundo inteiro é formado por atletas, modelos, influenciadores e milionários.

Mas basta sair para caminhar na rua para perceber algo diferente.

A humanidade continua sendo composta majoritariamente por pessoas normais.

Pessoas que:

• trabalham;

• estudam;

• pagam boletos;

• criam filhos;

• enfrentam dificuldades;

• envelhecem.

A vida real continua acontecendo.

Mas ela recebe menos curtidas.

E por isso aparece menos.

---

A Ditadura da Visibilidade

Talvez o termo "ditadura da beleza" não seja suficiente para explicar o fenômeno.

Talvez estejamos vivendo algo maior:

A ditadura da visibilidade.

Não apenas os bonitos aparecem mais.

Também aparecem mais:

• os ricos;

• os polêmicos;

• os extravagantes;

• os extremos.

O algoritmo premia aquilo que captura atenção.

E atenção raramente está associada à normalidade.

Imagine uma rede social composta por:

• pessoas com empregos normais;

• casamentos normais;

• casas normais;

• corpos normais.

Provavelmente ela geraria menos engajamento.

E menos engajamento significa menos receita publicitária.

---

O Mainframe e a Vida Real

Aqui permitam-me uma analogia.

Enquanto o Instagram representa o glamour da superfície, o Mainframe representa algo completamente diferente.

Ninguém faz selfie ao lado de um processamento de folha de pagamento.

Ninguém vira influenciador porque executou um SORT eficiente.

Ninguém ganha milhões de seguidores por entender JES2, RACF ou DB2.

Mas milhões de pessoas recebem salário porque alguém executou corretamente aquele processamento invisível.

A sociedade moderna depende muito mais do que não aparece do que daquilo que aparece.

Isso vale para tecnologia.

E vale para seres humanos.

Os indivíduos mais importantes de nossas vidas frequentemente não são os mais bonitos nem os mais famosos.

São os mais presentes.

Os mais confiáveis.

Os mais consistentes.

---

O Problema da Comparação Global

Durante a maior parte da história, a comparação humana era local.

Hoje ela é global.

Um jovem de uma cidade do interior não se compara mais aos colegas da escola.

Ele se compara:

• a celebridades;

• a influenciadores;

• a atletas;

• a modelos internacionais.

A régua tornou-se absurda.

E quanto mais impossível a comparação, maior a chance de frustração.

Muitas pessoas passam a sentir que estão falhando.

Mas falhando em quê?

Na verdade, estão apenas competindo em um campeonato do qual nunca deveriam participar.

---

A Indústria da Insatisfação

Existe uma verdade econômica por trás de tudo isso.

Uma pessoa satisfeita é difícil de vender.

Uma pessoa insatisfeita compra.

Compra:

• cosméticos;

• roupas;

• procedimentos;

• cursos;

• suplementos;

• experiências.

A publicidade moderna aprendeu algo poderoso.

Antes de vender um produto, é preciso vender uma insegurança.

Primeiro cria-se o problema.

Depois vende-se a solução.

E as redes sociais tornaram-se máquinas extremamente eficientes para amplificar esse processo.

---

A Ironia da Beleza

Existe uma ironia fascinante.

Nós admiramos a perfeição.

Mas nos conectamos com a imperfeição.

Pense em seus melhores amigos.

Provavelmente eles possuem defeitos.

Pense nos familiares que você mais ama.

Também possuem defeitos.

Pense nos relacionamentos mais importantes da sua vida.

Nenhum deles foi construído porque alguém parecia uma fotografia publicitária.

As conexões humanas surgem justamente das vulnerabilidades compartilhadas.

Dos erros.

Das dificuldades.

Das imperfeições.

---

A Cidade das Pessoas Feias

Brincadeiras à parte, muitas cidades carregam a fama de possuir pessoas menos atraentes.

Mas existe um detalhe curioso.

Quando alguém afirma:

"Na minha cidade só tem gente feia."

Geralmente não está comparando a cidade com a média da população brasileira.

Está comparando com Instagram.

E contra o Instagram qualquer cidade perderá.

Qualquer uma.

Nova York.

Paris.

Tóquio.

Londres.

São Paulo.

Porque a comparação não é entre realidade e realidade.

É entre realidade e vitrine.

E vitrine sempre vence.

---

O Efeito Hollywood

O cinema já fazia isso há décadas.

Hollywood selecionava os atores mais bonitos.

As revistas selecionavam os modelos mais bonitos.

A publicidade selecionava os rostos mais bonitos.

A diferença é que aquilo ocupava algumas horas do dia.

Hoje carregamos Hollywood no bolso.

Vinte e quatro horas por dia.

Sete dias por semana.

Sem intervalo.

Sem desligar.

Sem perceber.

---

A Chegada da Inteligência Artificial

Agora estamos entrando em uma nova fase.

A era das pessoas que nem existem.

Modelos gerados por IA.

Influenciadores virtuais.

Avatares digitais.

Rostos sintéticos.

Corpos sintéticos.

Perfeição sintética.

O paradoxo torna-se ainda maior.

Pessoas reais passam a competir com indivíduos artificiais.

A comparação já era injusta.

Agora tornou-se impossível.

---

O Que Fazer Diante Disso?

Talvez a resposta não seja abandonar a tecnologia.

Nem demonizar as redes sociais.

Mas compreender seus mecanismos.

Entender que:

• o feed não é a realidade;

• a visibilidade não é representatividade;

• curtidas não medem valor humano;

• beleza não determina significado.

Da mesma forma que um operador de mainframe sabe interpretar um console sem acreditar em cada mensagem isoladamente, precisamos aprender a interpretar as redes sociais sem assumir que elas representam fielmente o mundo.

---

A Grande Lição

Quanto mais envelheço, mais percebo algo curioso.

As pessoas que realmente marcaram minha vida não foram necessariamente as mais bonitas.

Nem as mais ricas.

Nem as mais populares.

Foram aquelas que estavam presentes.

Aquelas que ensinaram algo.

Aquelas que ajudaram alguém.

Aquelas que construíram algo duradouro.

Aquelas que deixaram um legado.

Talvez seja exatamente como o Mainframe.

Enquanto todos olham para as interfaces brilhantes da superfície, existe uma infraestrutura silenciosa sustentando o mundo.

A beleza chama atenção.

Mas é a consistência que sustenta sistemas.

A aparência gera cliques.

Mas o caráter gera confiança.

O algoritmo valoriza o que é visto.

A vida valoriza o que permanece.

E talvez a maior ilusão da era digital seja acreditar que aquilo que aparece mais é aquilo que importa mais.

Porque, no final das contas, o mundo continua sendo movido por milhões de pessoas comuns.

Pessoas imperfeitas.

Pessoas invisíveis.

Pessoas reais.

E felizmente, fora das telas, a humanidade ainda se parece muito mais com a humanidade do que com o Instagram.

☕🚀 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. ☕🚀💻🏦