Bellacosa Mainframe e a tecnica de cloud repatriation

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:

"O futuro está na nuvem."

Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.

As apresentações dos fornecedores mostravam um cenário quase perfeito.

Tudo seria:

• mais rápido;

• mais moderno;

• mais simples;

• mais seguro;

• mais barato.

Executivos ficaram encantados.

Arquitetos embarcaram na jornada.

Consultorias venderam projetos bilionários.

E milhares de empresas iniciaram aquilo que ficou conhecido como:

Cloud Migration.

Mas alguns anos depois algo inesperado começou a acontecer.

Empresas gigantes passaram a fazer o caminho inverso.

Sim.

O movimento contrário.

Retirar sistemas da nuvem.

Trazer aplicações de volta para datacenters próprios.

Mover cargas para ambientes especializados.

Consolidar plataformas.

Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:

Cloud Repatriation.

Ou simplesmente:

Repatriação da Nuvem.

E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.

Porque ele está mudando a forma como as empresas enxergam tecnologia.

---

O sonho da nuvem

Vamos voltar alguns anos.

Imagine uma empresa tradicional.

Ela possui:

• servidores físicos;

• storage;

• rede;

• datacenter;

• equipe de infraestrutura.

Tudo precisa ser comprado.

Tudo precisa ser instalado.

Tudo precisa ser mantido.

Quando a nuvem chegou, a promessa parecia revolucionária.

Ao invés de comprar:

• você alugaria.

Ao invés de esperar semanas:

• criaria recursos em minutos.

Ao invés de investir milhões:

• pagaria apenas pelo uso.

Parecia perfeito.

E para muitas situações realmente era.

---

O nascimento do "Cloud First"

Entre 2015 e 2022 surgiu uma expressão muito popular.

Cloud First.

Ou seja:

"A nuvem primeiro."

Toda nova solução deveria nascer em cloud.

Muitas organizações foram além.

Não apenas criaram sistemas novos.

Também migraram sistemas antigos.

Tudo virou candidato à nuvem.

ERP.

CRM.

Banco de dados.

Analytics.

Arquivos.

Aplicações críticas.

Em muitos casos sem uma análise profunda de custo-benefício.

---

A pergunta que ninguém fazia

Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:

"Quanto isso custará daqui a cinco anos?"

A maioria analisava apenas:

• velocidade;

• facilidade;

• inovação.

Mas ignorava:

• crescimento;

• consumo;

• escalabilidade financeira.

A conta parecia pequena no início.

Mas crescia silenciosamente.

---

A armadilha do sucesso

Imagine uma fintech.

Primeiro ano:

100 mil clientes.

Segundo ano:

1 milhão.

Terceiro ano:

10 milhões.

Quarto ano:

50 milhões.

Tudo parece ótimo.

Mas existe um detalhe.

Cada cliente gera:

• armazenamento;

• processamento;

• logs;

• backups;

• monitoramento;

• tráfego de rede.

Quanto mais sucesso a empresa tem, maior fica a fatura.

O paradoxo é interessante.

O crescimento do negócio aumenta também o custo operacional da nuvem.

---

Quando chega a conta

É nesse momento que começa a repatriação.

Os diretores financeiros começam a fazer perguntas.

Por exemplo:

• Estamos usando tudo que pagamos?

• Precisamos realmente dessa configuração?

• Existe alternativa mais barata?

• O custo por transação está aumentando?

• O retorno continua justificando o investimento?

E muitas vezes a resposta é surpreendente.

Nem toda carga de trabalho se beneficia economicamente da nuvem.

---

A analogia da casa

Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.

No começo você mora de aluguel.

Faz sentido.

Você ainda está começando.

Precisa de flexibilidade.

Não quer investir muito.

Mas imagine que passaram vinte anos.

Você continua pagando aluguel.

Todo mês.

Sem parar.

Em algum momento surge a pergunta:

"Não seria melhor comprar?"

A repatriação nasce exatamente dessa reflexão.

---

O caso do Dropbox

Um dos exemplos mais famosos ocorreu com o Dropbox.

Durante anos a empresa utilizou cloud pública.

Mas conforme cresceu percebeu algo importante.

O volume de armazenamento era gigantesco.

A escala era enorme.

A previsibilidade era alta.

O resultado?

Passou a investir fortemente em infraestrutura própria.

A economia foi medida em centenas de milhões de dólares ao longo dos anos.

Isso chamou a atenção do mercado.

---

O caso da 37signals

Outro exemplo muito discutido foi a empresa por trás do Basecamp.

Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.

O argumento principal?

Economia.

Segundo eles, a redução de custos seria enorme.

A notícia gerou debates em toda a indústria.

---

O que isso ensina para uma Analista COBOL?

Ensina algo extremamente importante.

Tecnologia não é religião.

Não existe:

• Mainframe bom.

• Cloud ruim.

Nem o contrário.

Existe apenas:

o ambiente correto para a carga correta.

Essa é uma das maiores lições da arquitetura moderna.

---

Nem toda carga é igual

Imagine duas aplicações.

Primeira aplicação:

• Website promocional.

• Acessos variáveis.

• Crescimento imprevisível.

Cloud faz sentido.

Agora imagine:

• processamento de contas bancárias;

• liquidação financeira;

• batch noturno;

• milhões de transações previsíveis.

Talvez a análise econômica seja diferente.

Talvez uma plataforma especializada seja mais eficiente.

Talvez um mainframe seja mais competitivo.

Tudo depende do contexto.

---

O papel do Mainframe nessa história

É aqui que muitos jovens profissionais ficam surpresos.

Durante anos ouviram que o Mainframe estava desaparecendo.

Mas a realidade mostrou algo curioso.

Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.

Por quê?

Porque o Mainframe foi construído justamente para:

• alta escala;

• alta disponibilidade;

• processamento transacional;

• confiabilidade extrema.

Essas características continuam valiosas.

Muito valiosas.

---

O custo invisível da nuvem

Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.

Na cloud surgem custos menos óbvios.

Por exemplo:

• transferência de dados;

• snapshots;

• logs;

• replicação;

• monitoramento;

• APIs;

• tráfego entre regiões.

Cada item parece pequeno.

Somados podem se tornar gigantescos.

É por isso que tantas empresas passaram a adotar práticas de FinOps.

---

O nascimento do FinOps

FinOps significa:

Financial Operations.

Ou seja:

Operações financeiras aplicadas à tecnologia.

Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:

• Quem está consumindo recursos?

• Quanto custa cada aplicação?

• Qual é o custo por cliente?

• Qual é o custo por transação?

Isso praticamente não existia no início da corrida para a nuvem.

---

A verdade que ninguém gosta de ouvir

Existe uma verdade que incomoda muitos vendedores de tecnologia.

Nem toda inovação reduz custos.

Algumas aumentam custos.

Mas aumentam receita.

E isso pode ser perfeitamente aceitável.

Cloud frequentemente se encaixa nesse cenário.

A empresa paga mais.

Mas cresce mais rápido.

Lança produtos mais rapidamente.

Conquista clientes mais cedo.

Portanto o custo adicional pode valer a pena.

---

Então por que repatriar?

Porque chega um momento em que determinadas cargas se tornam:

• previsíveis;

• estáveis;

• maduras.

Nesse ponto a elasticidade da cloud perde parte do valor.

E a eficiência operacional começa a ganhar importância.

A pergunta muda.

Deixa de ser:

"Como crescer?"

E passa a ser:

"Como operar com eficiência?"

---

O futuro é híbrido

Talvez essa seja a maior conclusão.

O futuro não parece ser:

• tudo na cloud;

• tudo no mainframe;

• tudo on-premises.

O futuro parece híbrido.

Cada carga de trabalho executada no ambiente mais adequado.

É exatamente isso que vemos nos grandes bancos.

Itaú.

Bradesco.

Banco do Brasil.

Santander.

Caixa.

Todos operam ambientes mistos.

Cloud.

Linux.

Containers.

APIs.

Mainframe.

Tudo convivendo.

Tudo integrado.

---

O que você deve aprender como profissional

Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.

Pelo contrário.

O mercado está procurando profissionais que entendam integração.

Profissionais que consigam conversar sobre:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Kubernetes;

• IBM Z;

• Arquitetura distribuída.

Porque a verdadeira transformação digital não consiste em destruir o legado.

Consiste em conectá-lo ao futuro.

---

Conclusão: O Retorno da Maturidade Tecnológica

Cloud Repatriation não significa fracasso da nuvem.

Também não significa vitória do Mainframe.

Significa algo muito mais interessante.

Significa maturidade.

O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.

Nem por marketing.

Nem por tendências.

Ela deve ser escolhida por critérios objetivos:

• custo;

• desempenho;

• segurança;

• disponibilidade;

• escalabilidade.

A nuvem continuará crescendo.

Os datacenters continuarão existindo.

Os mainframes continuarão processando bilhões de transações.

E as arquiteturas híbridas se tornarão cada vez mais comuns.

Para uma Analista COBOL Júnior, essa é uma excelente notícia.

Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.

O profissional do futuro não será aquele que conhece apenas uma tecnologia.

Será aquele que entende quando usar cada uma delas.

E talvez essa seja a maior lição da Cloud Repatriation.

Às vezes a inovação não está em mover tudo para a nuvem.

Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.

 

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.

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

Bellacosa Mainframe e tecnicas e ferramentas de teste automatizado em ibm mainframe

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

A Arte Esquecida dos Testes no IBM Mainframe

Existe uma crença antiga nos corredores dos CPDs:

"Se compilou sem erro e rodou em produção, então está certo."

Foi exatamente esse tipo de pensamento que produziu alguns dos maiores incidentes da história da computação corporativa.

No mundo Mainframe, um erro não afeta apenas um usuário.

Pode afetar:

• milhões de contas bancárias

• faturamento de operadoras

• pagamento de aposentadorias

• processamento de cartões

• sistemas governamentais

Por isso, testar COBOL nunca foi opcional.

Sempre foi sobrevivência.

O curioso é que durante décadas o programador COBOL executava testes praticamente de forma artesanal:

1. Criava um arquivo de teste

2. Submetia um JOB

3. Esperava terminar

4. Analisava SYSOUT

5. Corrigia

6. Repetia

Hoje o cenário mudou radicalmente.

Temos frameworks modernos, automação, DevOps, CI/CD e até testes unitários para COBOL.

Sim.

Você leu corretamente.

Testes unitários para COBOL.

---

Como Pensar em Testes COBOL

Antes das ferramentas, precisamos entender os níveis de teste.

1. Teste Unitário

Valida apenas uma rotina.

Exemplo:

Programa calcula juros.

Entrada:

VALOR = 1000
TAXA  = 10

Saída esperada:

1100

Nada de arquivos.

Nada de DB2.

Nada de CICS.

Somente lógica.

---

2. Teste de Integração

Valida interação entre componentes.

Exemplo:

COBOL
 ↓
DB2
 ↓
MQ
 ↓
Outro Sistema

Aqui os problemas aparecem.

A lógica funciona.

A integração não.

---

3. Teste de Sistema

Avalia o fluxo completo.

Exemplo:

Tela CICS
 ↓
COBOL
 ↓
DB2
 ↓
IMS
 ↓
MQ

Tudo junto.

Como acontece na produção.

---

4. Teste de Regressão

O mais importante.

Você altera uma linha.

Precisa garantir que não destruiu outras 500 funcionalidades.

É aqui que a automação brilha.

---

Ferramenta 1 — IBM ZUnit

A joia da coroa da IBM.

ZUnit é o framework oficial de testes unitários para COBOL.

Foi criado para trazer ao Mainframe conceitos comuns em Java e .NET.

Zunit - https://eljefemidnightlunch.blogspot.com/2021/05/padawan-o-zunit-e-o-momento-em-que-o.html 

Vantagens

✔ Teste automatizado

✔ Integrado ao IDz

✔ Repetível

✔ Excelente para DevOps

✔ Integração com pipelines

---

Desvantagens

✘ Curva de aprendizado

✘ Dependência do ecossistema IBM

✘ Nem sempre simples para programas antigos

---

Exemplo Prático com ZUnit

Suponha o programa:

IDENTIFICATION DIVISION.
PROGRAM-ID. CALCJURO.

COMPUTE VALOR-FINAL =
        VALOR + (VALOR * TAXA / 100).

Passo 1

Abrir IDz.

---

Passo 2

Criar projeto ZUnit.

File
  New
    ZUnit Test Case

---

Passo 3

Selecionar programa COBOL.

CALCJURO

---

Passo 4

Definir entrada.

VALOR = 1000
TAXA  = 10

---

Passo 5

Definir saída esperada.

1100

---

Passo 6

Executar.

Run As
   ZUnit Test

Resultado:

PASS

ou

FAIL

---

Ferramenta 2 — IBM COBOL Check: Encontrando Defeitos Antes da Execução

Antes de executar qualquer teste, existe uma etapa ainda mais inteligente.

A análise estática.

É aqui que entra o IBM COBOL Check.

IBM Cobol Check - https://eljefemidnightlunch.blogspot.com/2026/06/ibm-cobol-check-ferramenta-que-trouxe.html

O Que É?

O COBOL Check examina o código-fonte procurando defeitos potenciais sem executar uma única instrução.

Ele atua como um inspetor de qualidade automatizado.

Enquanto o ZUnit pergunta:

"O programa funciona?"

O COBOL Check pergunta:

"Existe algo suspeito neste código?"

---

Problemas Detectados

Variáveis Não Inicializadas

01 WS-TOTAL PIC 9(05).

ADD 100 TO WS-TOTAL.

O campo recebeu valor antes?

Talvez não.

---

Índices Fora da Faixa

MOVE 150 TO WS-INDICE.

MOVE 'ABC' TO WS-DADO(WS-INDICE).

Tabela com apenas 100 ocorrências.

Possível S0C4.

---

Código Morto

STOP RUN.

DISPLAY 'NUNCA EXECUTA'

Trecho inalcançável.

---

Condições Impossíveis

IF VALOR > 100
AND VALOR < 50

Nunca será verdadeiro.

---

Possíveis S0C7

MOVE 'ABCDE' TO CAMPO-NUMERICO.

ADD 1 TO CAMPO-NUMERICO.

Compila.

Mas pode explodir em produção.

---

Vantagens do COBOL Check

✔ Não precisa executar o programa

✔ Automatizável

✔ Excelente para DevOps

✔ Descobre defeitos cedo

✔ Padronização corporativa

---

Desvantagens

✘ Não substitui testes

✘ Pode gerar falsos positivos

✘ Requer parametrização adequada

---

Ferramenta 3 — IBM Debug Tool

Muita gente acha que Debug Tool serve apenas para depuração.

Errado.

Ele também é excelente para validação de comportamento.

Vantagens

✔ Sem alterar código

✔ Breakpoints

✔ Análise em tempo real

✔ Visualização de variáveis

---

Desvantagens

✘ Não substitui testes automatizados

✘ Processo mais manual

---

Exemplo

Interceptar:

COMPUTE TOTAL = A + B

Durante execução:

AT LINE 125
DISPLAY TOTAL

Verificando se:

10 + 15 = 25

---

Ferramenta 4 — File-AID

Uma das ferramentas mais usadas para testes.

Principalmente em ambientes bancários.

O que faz?

Criação de massa de testes.

Manipulação de arquivos.

Comparação de resultados.

---

Exemplo

Criar arquivo VSAM contendo:

CLIENTE 001
CLIENTE 002
CLIENTE 003

Executar programa.

Comparar resultado.

---

Vantagens

✔ Rápido

✔ Simples

✔ Excelente para testes batch

---

Desvantagens

✘ Não executa lógica unitária

✘ Foco em dados

---

Ferramenta 5 — Xpediter

O lendário depurador da Compuware/BMC.

Praticamente um microscópio para COBOL.

Permite

• Breakpoints

• Alteração dinâmica

• Rastreamento

• Simulação

---

Vantagens

✔ Muito poderoso

✔ Excelente para programas complexos

✔ Integração com CICS

---

Desvantagens

✘ Licenciamento

✘ Excesso de recursos para iniciantes

---

Ferramenta 6 — Abend-AID

Não é exatamente uma ferramenta de testes.

Mas salva vidas.

Quando ocorre:

S0C7

ou

S0C4

Ela mostra:

• linha exata

• variável envolvida

• conteúdo dos campos

---

Vantagens

✔ Diagnóstico rápido

✔ Redução de MTTR

✔ Histórico de falhas

---

Desvantagens

✘ Atua após o erro

✘ Não evita defeitos

---

Técnica Clássica: Golden File

Uma das técnicas mais usadas em Mainframe.

Executa-se um programa conhecido.

Resultado esperado:

ARQ-OK

Depois da alteração:

ARQ-NOVO

Comparação:

SUPERC

ou

File-AID Compare

Se forem idênticos:

TESTE APROVADO

---

Técnica Moderna: Mocking

Muito usada com ZUnit.

Imagine:

SELECT CLIENTE
       ASSIGN TO VSAMCLI.

Em vez de acessar VSAM real:

VSAM MOCK

Resultado:

• teste rápido

• sem riscos

• repetível

---

Técnica de Cobertura

Pergunta simples:

Quanto do programa foi realmente executado?

Muitos acreditam:

Teste passou

Logo:

Programa está correto

Não necessariamente.

Você pode ter testado apenas 20% dos caminhos.

Ferramentas modernas ajudam a medir cobertura.

---

Curiosidades Históricas

COBOL já tinha testes antes da moda

Décadas antes de JUnit existir:

Programadores Mainframe já criavam:

ARQTEST1
ARQTEST2
ARQTEST3

Executando cenários controlados.

Na prática, eram testes unitários artesanais.

---

O custo do erro

Um defeito descoberto:

• Durante codificação → custo 1x

• Durante homologação → custo 10x

• Em produção → custo 100x

Essa regra continua válida.

---

Grandes bancos executam milhões de testes

Em ambientes modernos de DevOps Mainframe, pipelines podem disparar milhares de testes automáticos a cada alteração de código COBOL.

O objetivo é simples:

Quebrar no laboratório para não quebrar na produção.

---

Dicas do Bellacosa

☕ Dica 1

Nunca teste apenas o cenário feliz.

Teste:

• zeros

• negativos

• máximos

• mínimos

• espaços

• nulos

---

☕ Dica 2

Todo S0C7 que chega em produção é um teste que faltou.

---

☕ Dica 3

Crie bibliotecas permanentes de massa de testes.

Economiza centenas de horas.

---

☕ Dica 4

Automatize tudo o que puder.

O programador esquece.

O script não.

---

☕ Dica 5

Sempre mantenha testes de regressão após correções.

O defeito corrigido hoje costuma reaparecer daqui seis meses.

---

Exemplo de Pipeline DevOps Mainframe

Git
 ↓
Commit
 ↓
Build COBOL
 ↓
ZUnit
 ↓
Análise de Qualidade
 ↓
Deploy Homologação
 ↓
Testes Integração
 ↓
Produção

Cada etapa reduz riscos.

Cada teste reduz surpresas.

---

Resumo Executivo

Testar COBOL em ambiente IBM Mainframe deixou de ser uma atividade manual e passou a ser parte fundamental da engenharia moderna de software. Ferramentas como IBM ZUnit, Debug Tool, File-AID, Xpediter e Abend-AID permitem validar lógica, criar massas de teste, depurar falhas e automatizar regressões. O segredo não está apenas na ferramenta, mas na disciplina de criar cenários abrangentes, automatizar execuções e manter uma suíte de testes confiável. No fim das contas, o verdadeiro profissional Mainframe não é aquele que nunca gera defeitos. É aquele que constrói mecanismos para encontrá-los antes que o cliente encontre primeiro.

☕💣🚀 PADAWAN, O TESTE NÃO EXISTE PARA PROVAR QUE SEU COBOL ESTÁ CERTO. ELE EXISTE PARA PROVAR QUANTAS MANEIRAS ELE AINDA TEM DE DAR ERRADO ANTES DA PRODUÇÃO DESCOBRIR!

 

Bellacosa Mainframe e o meu projeto de assistant

☕💣Laboratorio Bellacosa Mainframe Assistant

"Porque nem todo problema precisa virar um ABEND."

🚀 Sobre o Projeto

O Bellacosa Mainframe Assistant é um assistente virtual especializado em tecnologias IBM Mainframe, criado para ajudar estudantes, operadores, desenvolvedores e administradores a navegar pelo universo do z/OS sem precisar abrir cinquenta manuais da IBM ao mesmo tempo.

A proposta é unir Inteligência Artificial com décadas de conhecimento acumulado sobre:

• COBOL
• JCL
• CICS
• DB2
• RACF
• TSO/ISPF
• JES2
• VSAM
• SORT
• IDCAMS
• z/OS
• Aspera
• Operação Mainframe

Tudo explicado de forma simples, prática e com exemplos reais de ambiente corporativo.

---

🎯 Objetivo

Reduzir a curva de aprendizado de profissionais que desejam:

• Entrar no mercado Mainframe
• Evoluir tecnicamente
• Resolver problemas operacionais
• Entender mensagens de sistema
• Aprender boas práticas
• Modernizar aplicações legadas

---

👨‍💻 Público-Alvo

Este agente foi desenvolvido para:

Iniciantes

Pessoas que nunca acessaram um ISPF e ainda acham que JCL é uma linguagem de programação.

Desenvolvedores

Profissionais que trabalham com:

• COBOL
• PL/I
• Natural
• Assembler

Operadores

Profissionais responsáveis por:

• JES2
• Spool
• SDSF
• Console
• Monitoramento

Administradores

Especialistas em:

• RACF
• CICS
• DB2
• z/OS

Empresas

Organizações que desejam preservar conhecimento técnico e acelerar treinamentos.

---

☕ Filosofia Bellacosa Mainframe

O agente segue alguns princípios simples:

1. Explicar sem complicar

A IBM já escreveu os manuais.

O objetivo aqui é traduzir o "IBMês" para português humano.

---

2. Ensinar com exemplos reais

Ao invés de apenas mostrar sintaxe:

//STEP01 EXEC PGM=IEFBR14

o agente explica:

"Esse é o famoso Hello World do operador Mainframe."

---

3. Contar a história por trás da tecnologia

Porque entender:

• por que o RACF existe
• por que o VSAM foi criado
• por que o JES2 funciona da forma atual

faz toda diferença no aprendizado.

---

4. Misturar técnica e curiosidade

Você pode aprender:

• Como funciona um checkpoint do JES2
• Como um ABEND acontece
• Como a NASA utilizou Mainframes
• Como bancos processam milhões de transações

Tudo na mesma conversa.

---

📚 Base de Conhecimento

Desenvolvimento

• COBOL
• Enterprise COBOL
• COBOL/400
• PL/I
• Natural
• Assembler

Processamento Batch

• JCL
• PROC
• Utilities
• SORT
• DFSORT
• Syncsort

Banco de Dados

• DB2
• VSAM
• IMS

Online

• CICS
• Web Services
• REST APIs
• z/OS Connect

Segurança

• RACF
• Perfis
• Classes
• Permissões

Operação

• JES2
• SDSF
• Console
• Spool
• WLM

Administração

• TSO
• ISPF
• SMP/E
• Catalogs

---

🧠 Como o Agente Responde

O Bellacosa Mainframe Assistant procura:

1. Entender o problema.
2. Explicar o conceito.
3. Mostrar um exemplo.
4. Apresentar boas práticas.
5. Alertar sobre armadilhas comuns.

---

💬 Exemplos de Perguntas

COBOL

"Como funciona um READ em VSAM?"

JCL

"Qual a diferença entre COND e IF/THEN?"

RACF

"Como conceder acesso a um dataset?"

JES2

"O que significa a mensagem $HASP250?"

CICS

"Como criar um Web Service em COBOL?"

---

📊 Métricas de Sucesso

O agente será avaliado por:

Métrica	Objetivo
Precisão	> 90%
Clareza	> 90%
Tempo de Resposta	< 5 segundos
Satisfação	> 4,5/5

---

🔧 Tecnologias Utilizadas

• Inteligência Artificial Generativa
• Processamento de Linguagem Natural
• Bases de Conhecimento Especializadas
• Documentação IBM
• Engenharia de Prompt

---

🔮 Evoluções Futuras

• Integração com manuais IBM
• Laboratórios interativos
• Simulador de JCL
• Simulador de RACF
• Simulador de Operação JES2
• Quiz automático
• Geração de exemplos COBOL
• Correção automática de JCL

---

☕💣 Mensagem Final

Mainframe não é tecnologia antiga.

É tecnologia que continua funcionando enquanto muitas outras já foram substituídas várias vezes.

O Bellacosa Mainframe Assistant nasceu para mostrar que aprender Mainframe pode ser tão interessante quanto assistir uma série, jogar um RPG ou explorar um novo universo tecnológico.

Porque no fim das contas...

Todo operador já derrubou um JOB.

Todo programador já causou um ABEND.

E todo profissional Mainframe tem pelo menos uma história impossível de acreditar durante o café.

Bem-vindo ao Bellacosa Mainframe Assistant.

https://github.com/VagnerBellacosa/395_ConstruaAssistenteVirtual_IAGenerativa

☕💣 Bellacosa Mainframe Assistant

Projeto desenvolvido para o desafio Construa seu Assistente Virtual com IA Generativa.
Um especialista virtual focado em COBOL, JCL, CICS, DB2, RACF, JES2, VSAM, TSO/ISPF e tecnologias IBM Mainframe.

🚀 Abrir Projeto no GitHub

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

• 28.000 linhas

• 134 COPYBOOKS

• 742 parágrafos

• Comentários da época do Plano Real

• Um PERFORM THRU que ninguém entende

• Um campo chamado WK-AREA1

• Outro chamado WK-AREA2

• Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica

---

O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

• principal

• juros

• correção

• multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.

---

EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

• 3.000 agências

• dezenas de fusões

• múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.

---

COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.

---

Frase 2

"É só uma correção rápida."

Nunca é.

---

Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.

---

Frase 4

"Não mexe porque funciona."

O terror dos bancos.

---

OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

• GOTO excessivo

• PERFORM THRU gigantes

• variáveis sem significado

• duplicação

---

2. Arquitetura

Problemas maiores.

Exemplos:

• sistemas monolíticos

• dependências excessivas

• integrações frágeis

---

3. Dados

Muito comum em bancos.

Exemplos:

• arquivos VSAM redundantes

• tabelas DB2 duplicadas

• dados inconsistentes

---

4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

• deploy manual

• testes manuais

• documentação inexistente

---

COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.

---

Sintoma 1

Mudanças simples levam semanas.

---

Sintoma 2

Toda alteração gera incidente.

---

Sintoma 3

Poucas pessoas entendem o sistema.

---

Sintoma 4

Ninguém quer mexer.

---

Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.

---

MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.

---

1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

• mais difícil testar

• mais difícil manter

• maior risco

Meta saudável:

• abaixo de 10 excelente

• até 20 aceitável

• acima de 30 perigoso

---

2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

• 500 linhas → simples

• 5.000 linhas → atenção

• 20.000 linhas → investigação

---

3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

• cadastro

• empréstimo

• cartão

• investimentos

Quando muda uma regra:

quatro programas precisam mudar.

---

4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.

---

5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.

---

6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?

---

FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.

---

IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

• dependências

• impacto

• análise de código

Mostra relacionamentos invisíveis.

---

IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

• DevOps

• testes

• integração

---

SONARQUBE

Uma das mais famosas.

Analisa:

• complexidade

• duplicação

• vulnerabilidades

Possui suporte para COBOL.

---

TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

• visualização

• debugging

• análise

---

ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.

---

GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.

---

COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.

---

PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

• onde está

• quanto existe

• qual impacto

---

PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.

---

PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.

---

PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.

---

PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.

---

PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.

---

PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.

---

O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

---

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.

---

CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.

---

A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

• melhorar nomes

• remover comentários obsoletos

• eliminar duplicações

Pequenas melhorias acumulam enormes resultados.

---

O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

• processar pagamentos

• movimentar bilhões

• atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.

---

O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"

---

☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

• Internet Banking

• Aplicativos móveis

• Chatbots

• APIs

• Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.

---

O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

---

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

• Portais Web

• Gateways API

• Aplicativos móveis

• Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.

---

O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

• Processos manuais escondidos

• Dependência excessiva de funcionários específicos

• Sistemas sem escalabilidade

• Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.

---

☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.

---

O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

• Comprar servidores

• Instalar servidores

• Configurar servidores

Meses de trabalho.

---

NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.

---

A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.

---

RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.

---

O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.

---

O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.

---

👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.

---

O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.

---

O DIA DO DESASTRE

Essa pessoa:

• aposenta

• muda de empresa

• entra em férias

Pronto.

Agora existe um risco operacional.

---

O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.

---

O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

• Git

• APIs

• DevOps

• Cloud

• Automação

• CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.

---

O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.

---

UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

• Git

• VS Code

• Zowe

• APIs REST

• Jenkins

• SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.

---

UM COBOL ANTIGO É REPELENTE

Agora imagine:

• documentação inexistente

• deploy manual

• FTP

• planilhas Excel

• mudanças sem controle

O problema não é COBOL.

É a cultura.

---

O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

• hardware

• software

• licenças

Mas esquecem:

• turnover

• treinamento

• conhecimento perdido

Esses custos podem superar os custos tecnológicos.

---

O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.

---

O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

---

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

• agilidade

• automação

• integração

• APIs

• escalabilidade

• experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

• pessoas

• conhecimento

• processos

• documentação

• cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.

---

CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

• documentação

• testes

• APIs

• observabilidade

• versionamento

• arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.