Translate

Mostrar mensagens com a etiqueta resiliencia. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta resiliencia. Mostrar todas as mensagens

terça-feira, 14 de julho de 2026

Capítulo 14 — O Julgamento da História

Bellacosa Mainframe e o Julgamento da Historia

☕ Um Café no Bellacosa Mainframe

Capítulo 14 — O Julgamento da História

Quarenta Anos Depois, Quem Estava Certo?

O capítulo final reúne as principais lições das previsões sobre a morte do mainframe e mostra como a evolução do IBM Z oferece ensinamentos para o futuro da computação corporativa.

Por

A evolução do IBM Mainframe julgada pela história após quarenta anos
As manchetes envelhecem. A engenharia permanece. Quatro décadas depois, a história oferece seu veredito sobre o futuro do mainframe.

"A História não julga pelas manchetes. Ela julga pelos sistemas que continuam funcionando."

— Bellacosa Mainframe

O veredito da História

Após quarenta anos de previsões sobre o desaparecimento do mainframe, bancos, seguradoras, governos, companhias aéreas e grandes empresas continuam executando bilhões de transações diárias sobre plataformas IBM Z, agora integradas com APIs, Linux, containers, OpenShift, Inteligência Artificial e cloud híbrida.

O julgamento histórico mostra que a evolução tecnológica não ocorreu por substituições absolutas, mas por integração contínua e preservação do conhecimento acumulado.

O legado para as próximas gerações

O trabalho de Wolfgang Spruth permitiu preservar um importante registro histórico das previsões sobre a morte do mainframe, oferecendo às novas gerações uma oportunidade rara de comparar expectativas, realidade e evolução tecnológica ao longo das décadas.

A última xícara de café

O verdadeiro legado do IBM Mainframe não é provar que estava certo. É lembrar que engenharia sólida, conhecimento de negócio e inovação contínua costumam sobreviver a modismos passageiros. O futuro pertence às tecnologias capazes de evoluir sem esquecer as lições do passado.


Bellacosa Mainframe e a hora da verdade

Finalmente chegamos ao tribunal

Imagine um enorme tribunal.

Não um tribunal comum.

Um tribunal onde o juiz é o tempo.

As testemunhas são quarenta anos de história da computação.

As provas são milhões de transações executadas todos os dias.

E os jurados...

Somos nós.

Arquitetos.

Programadores.

DBAs.

Operadores.

Sysprogs.

Analistas de negócios.

Estudantes.

Todos aqueles que vivem a computação real.

No banco dos réus existe uma placa.

IBM Mainframe

A acusação?

Ter sobrevivido quando deveria ter desaparecido.


A promotoria apresenta seu caso

O promotor começa.

— Meritíssimo...

Temos aqui dezenas de reportagens.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas afirmavam que esta plataforma estava ultrapassada.

Que seria substituída.

Que desapareceria.

Que sua arquitetura não possuía futuro.

Apresentamos como prova os artigos preservados pelo Professor Wolfgang Spruth em seu histórico trabalho The Death of the Mainframe.

O juiz olha os documentos.

Todos verdadeiros.

Todos publicados.

Todos assinados por profissionais respeitados.


A defesa não chama advogados

Curiosamente...

A defesa do Mainframe não apresenta um único advogado.

Não chama executivos.

Não chama jornalistas.

Não chama analistas.

Ela chama apenas testemunhas.

Primeira testemunha.

Um banco internacional.

— Quantas transações você processou hoje?

— Bilhões.

Segunda testemunha.

Uma companhia aérea.

— Quantas reservas?

— Milhões.

Terceira.

Uma operadora de cartões.

— Quantas autorizações?

— Milhões por minuto.

Quarta.

Uma seguradora.

— Quantos contratos?

— Dezenas de milhões.

Quinta.

Um governo.

— Quantos cidadãos dependem dos seus sistemas?

— Praticamente todos.

O silêncio toma conta da sala.


A testemunha mais inesperada

Então entra uma testemunha curiosa.

Ela usa camiseta.

Tênis.

Notebook.

Visual Studio Code aberto.

Git.

Python instalado.

Containers.

Kubernetes.

O juiz pergunta:

— Quem é você?

Ele responde.

— Sou um desenvolvedor de 2026.

— O senhor trabalha com Mainframe?

— Sim.

— Mas... o senhor não parece um programador de Mainframe.

O jovem sorri.

— Porque o senhor ainda imagina o Mainframe de 1989.

Eu trabalho com:

Git.

VS Code.

Python.

Zowe.

Ansible.

OpenShift.

DevOps.

REST.

JSON.

watsonx.

COBOL.

Tudo no mesmo ambiente.

O juiz faz uma anotação.


A acusação insiste

O promotor tenta recuperar o controle.

— Mas Excelência...

O Mainframe era fechado.

Centralizado.

Antigo.

O juiz olha para o IBM z17 projetado na tela.

Pergunta:

— Ele continua fechado?

A defesa responde.

— Linux.

Containers.

Kubernetes.

OpenShift.

REST.

Python.

Git.

Java.

Node.js.

Go.

Open APIs.

Cloud híbrida.

IA.

O promotor permanece em silêncio.


Chama-se a Inteligência Artificial

A próxima testemunha surpreende a todos.

É uma Inteligência Artificial.

O juiz pergunta:

— Você trabalha contra o Mainframe?

Ela responde.

— Não.

Trabalho com ele.

— Explique.

— Auxilio desenvolvedores COBOL.

Documento aplicações.

Analiso SQL.

Interpreto JCL.

Explico programas.

Ajudo DBAs.

Auxilio Sysprogs.

Analiso logs.

Automatizo operações.

O juiz sorri discretamente.

Mais uma previsão acabava de perder força.


O depoimento do COBOL

As portas do tribunal se abrem.

Entra um senhor elegante.

Sessenta e seis anos de idade.

Terno impecável.

Calmo.

Seguro.

O juiz pergunta.

— Nome?

— COBOL.

— Profissão?

— Regras de negócio.

— O senhor ainda trabalha?

Ele responde.

— Nunca trabalhei tanto.

A plateia ri.

Mas todos sabem que aquela resposta contém mais verdade do que humor.


O depoimento do JCL

Logo depois entra outro veterano.

Pouco falador.

Muito organizado.

— Nome?

— JCL.

— Idade?

— Não gosto de falar sobre isso.

— O senhor ainda possui utilidade?

Ele responde calmamente.

— Todos os dias organizo milhares de processos batch.

Controlo dependências.

Gerencio datasets.

Inicio cargas.

Executo backups.

Produzo relatórios.

Enquanto todos dormem.

A plateia aplaude.


O Db2 pede a palavra

O banco de dados aproxima-se da tribuna.

— Senhor Db2...

O senhor gostaria de dizer alguma coisa?

— Apenas uma observação.

Enquanto discutiam minha morte...

Continuei armazenando informações críticas de bancos, governos, seguradoras e empresas no mundo inteiro.

Hoje também trabalho com IA, análise em tempo real e integração híbrida.

Nada mais.

O depoimento dura menos de um minuto.

Suficiente.


O CICS também comparece

O juiz pergunta.

— Senhor CICS...

O senhor ainda recebe transações?

O velho monitor transacional responde.

— Algumas.

— Quantas?

— Bilhões.

Novo silêncio.


A última testemunha

O juiz chama Wolfgang Spruth.

Infelizmente ele já não está entre nós.

Mas seu trabalho permanece.

Sobre a mesa repousa sua apresentação.

"The Death of the Mainframe."

O juiz folheia lentamente.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas as manchetes.

Todas preservadas.

O juiz olha para a plateia.

Comenta.

— Este material nunca foi sobre provar quem estava certo.

Sempre foi sobre ensinar como a História acontece.

Talvez esse seja o maior legado do Professor Spruth.


O veredito

Depois de horas de audiência...

O juiz retorna.

Toda a sala permanece em silêncio.

Ele começa.

— Este tribunal conclui que...

As reportagens analisadas refletiam honestamente o conhecimento disponível em sua época.

Não houve má-fé.

Houve entusiasmo.

Houve confiança excessiva.

Houve extrapolação de tendências.

Houve influência do marketing.

Houve simplificações inevitáveis.

Mas também houve inovação verdadeira.

Client/Server mudou o mercado.

Internet mudou o planeta.

Linux mudou os datacenters.

Cloud mudou a infraestrutura.

IA está mudando a computação.

Nada disso pode ser negado.

O juiz faz uma pausa.

Continua.

— O erro ocorreu quando essas inovações passaram a ser apresentadas como substitutas inevitáveis de tudo o que existia anteriormente.

A História mostrou outro caminho.

Integração.

Compatibilidade.

Evolução.


A sentença

O juiz bate o martelo.

— O IBM Mainframe não é culpado.

A sala sorri.

Ele continua.

— Também declaro inocentes os jornalistas.

A plateia estranha.

O juiz explica.

— Eles apenas tentaram prever o futuro.

Como todos nós fazemos.

A diferença é que o futuro resolveu escrever outra história.


O verdadeiro vencedor

Chega então a última pergunta.

Quem venceu?

IBM?

UNIX?

Linux?

Cloud?

Open Source?

IA?

O juiz responde.

Nenhum deles.

Quem venceu foi a Engenharia.

Porque ela conseguiu integrar todos.

Hoje um único fluxo de negócio pode envolver:

Um aplicativo móvel.

Uma API.

Um microsserviço.

Kafka.

Containers.

Kubernetes.

OpenShift.

Java.

Python.

COBOL.

CICS.

Db2.

MQ.

IBM z17.

watsonx.

Tudo trabalhando junto.

Se isso não é evolução...

O que seria?


A herança para os próximos quarenta anos

Você, Padawan COBOL, talvez leia este artigo em 2036.

Ou 2046.

Quem sabe em 2056.

Talvez novas manchetes estejam dizendo:

"O fim da Inteligência Artificial."

"O fim do Cloud."

"O fim do Kubernetes."

"O fim dos LLMs."

"O fim dos Agentes."

Quando esse dia chegar...

Lembre-se deste julgamento.

Lembre-se de Forbes.

Lembre-se do New York Times.

Lembre-se da InfoWorld.

Lembre-se da Business Week.

Lembre-se do Professor Wolfgang Spruth.

E faça apenas uma pergunta.

Essa tecnologia ainda resolve problemas reais?

Se resolver...

Provavelmente continuará evoluindo.


A última xícara de café

Este não foi um artigo sobre computadores.

Nem sobre COBOL.

Nem sobre IBM.

Foi um artigo sobre humildade.

Humildade para reconhecer que prever o futuro é difícil.

Humildade para admitir erros.

Humildade para estudar a História antes de repetir slogans.

Humildade para entender que tecnologias realmente importantes raramente desaparecem de um dia para o outro.

Elas evoluem.

Adaptam-se.

Integram-se.

Transformam-se.

Foi isso que aconteceu com o Mainframe.

Foi isso que provavelmente acontecerá com muitas tecnologias atuais.


Encerramento

Quando você terminar este capítulo...

Olhe novamente para o IBM z17.

Não veja apenas um computador.

Veja sessenta anos de engenharia.

Milhões de horas de desenvolvimento.

Décadas de compatibilidade.

Bilhões de linhas de código.

Trilhões de dólares processados.

Milhões de profissionais que dedicaram suas carreiras para que o mundo continuasse funcionando.

Depois olhe para as manchetes da década de 1990.

Elas continuam importantes.

Porque nos lembram de algo extremamente valioso.

Buzzwords escrevem capas de revistas.

Engenharia escreve a História.

E a História, felizmente, costuma ter muito mais paciência do que os ciclos do marketing.


Epílogo Final

O Professor Wolfgang Spruth preservou o passado.

Os engenheiros construíram o presente.

Agora cabe aos novos Padawans construir o futuro.

Mas façam um favor à próxima geração.

Antes de anunciar a morte de qualquer tecnologia...

Esperem alguns anos.

A História agradece.

E o IBM Mainframe também.

Bellacosa Mainframe e o Funeral que nunca aconteceu

























C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

domingo, 12 de julho de 2026

Capítulo 12 — O Legado dos Profetas e a Grande Lição para 2026

Bellacosa Mainframe e o legado dos profetas do apocalipse mainframe

☕ Um Café no Bellacosa Mainframe

Capítulo 12 — O Legado dos Profetas e a Grande Lição para 2026

O Mainframe Nunca Venceu a Guerra. Porque Ela Nunca Existiu.

Uma reflexão sobre quatro décadas de previsões, mostrando que a verdadeira evolução da computação ocorreu pela integração de tecnologias, e não pela substituição completa das anteriores.

Por

A evolução do IBM Mainframe até o IBM z17 simbolizando o legado da engenharia
A história do mainframe demonstra que inovação não significa destruir o passado, mas incorporar novas tecnologias preservando décadas de engenharia e conhecimento.

"A melhor previsão sobre tecnologia é construída observando décadas de engenharia, não meses de marketing."

— Bellacosa Mainframe

A guerra que nunca existiu

Durante décadas, parte da indústria apresentou a evolução tecnológica como uma sequência de substituições definitivas: mainframe versus Client/Server, servidores versus cloud, cloud versus edge, IA versus programação tradicional.

Na prática, a história mostrou que as plataformas bem-sucedidas coexistem, integram-se e evoluem continuamente para atender às necessidades do negócio.

O verdadeiro diferencial

A permanência do IBM Z decorre da combinação entre inovação constante e compatibilidade com décadas de aplicações críticas. Recursos modernos como Linux, OpenShift, APIs, DevOps, containers, automação e watsonx foram incorporados sem abandonar COBOL, CICS, Db2 e z/OS.

A grande lição para 2026

A computação corporativa não evolui por rupturas absolutas, mas pela capacidade de integrar novas ideias preservando segurança, disponibilidade, desempenho e regras de negócio construídas ao longo de muitas décadas.


Chegamos ao fim da jornada...

Ou talvez...

Ao começo de outra.

Durante este artigo viajamos quase quarenta anos pela História da Computação.

Visitamos redações.

Conferências.

Centros de pesquisa.

CPDs.

Datacenters.

Conhecemos jornalistas.

Analistas.

Consultores.

Professores.

Arquitetos.

E acompanhamos uma sequência impressionante de manchetes anunciando, repetidamente, o fim do IBM Mainframe.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas refletiam um momento específico da história.

Nenhuma delas foi escrita com má intenção.

Todas tentavam responder à mesma pergunta.

Como será a computação do futuro?

Essa continua sendo uma das perguntas mais difíceis da Engenharia.


Bellacosa Mainframe agradece ao professor Wolfgang Spruth

O maior personagem desta história

Curiosamente...

O protagonista deste artigo nunca foi a IBM.

Nem o COBOL.

Nem o CICS.

Nem o Db2.

Muito menos o z17.

O verdadeiro protagonista foi algo muito maior.

A evolução da Engenharia.

Porque, enquanto manchetes mudavam de direção a cada nova tendência...

A Engenharia seguia outro ritmo.

Mais lento.

Mais cuidadoso.

Mais pragmático.

Mais responsável.

Enquanto alguns prometiam revoluções anuais...

Os engenheiros pensavam em plataformas capazes de durar décadas.

E essa diferença explica praticamente toda esta história.


O professor que nos deixou um espelho

Se hoje podemos revisitar todas essas previsões, devemos isso ao Professor Wolfgang Spruth.

Seu trabalho The Death of the Mainframe não foi uma crítica à imprensa.

Foi um presente para as futuras gerações.

Spruth poderia simplesmente ter respondido aos artigos.

Não fez isso.

Preferiu arquivá-los.

Organizá-los.

Contextualizá-los.

Transformá-los em História.

Foi uma atitude tipicamente acadêmica.

Porque pesquisadores sabem que a memória também é uma forma de conhecimento.

Sem aquele pequeno conjunto de slides...

Grande parte dessas manchetes estaria perdida em arquivos esquecidos.

Graças a ele, hoje podemos estudá-las com calma, entender seu contexto e aprender com seus acertos e seus erros.


2026 é muito diferente de 1993

Imagine mostrar a um jornalista de 1993 um IBM z17.

Provavelmente ele perguntaria:

— Onde está o terminal verde?

Você responderia:

— Ainda existe.

Mas agora também existem:

  • APIs REST;

  • JSON;

  • OpenAPI;

  • Linux;

  • Containers;

  • Kubernetes;

  • OpenShift;

  • Git;

  • GitHub;

  • VS Code;

  • Python;

  • Java;

  • Node.js;

  • Go;

  • Zowe;

  • Ansible;

  • DevOps;

  • CI/CD;

  • watsonx;

  • Inteligência Artificial embarcada.

Talvez ele olhasse novamente para a máquina.

Depois perguntasse:

— Então isso ainda é um mainframe?

Você sorriria.

— Sim.

E talvez seja exatamente isso que torna essa plataforma tão fascinante.

Ela mudou completamente...

Sem deixar de ser ela mesma.


O COBOL também não ficou parado

Existe outra injustiça histórica.

Muitos imaginam COBOL como uma linguagem congelada em 1974.

Nada poderia estar mais distante da realidade.

O COBOL moderno conversa com:

JSON.

XML.

UTF-8.

APIs.

Serviços REST.

C.

Java.

Db2.

CICS.

MQ.

Git.

Pipelines DevOps.

Compiladores inteligentes.

Análise estática.

Testes automatizados.

Performance extremamente otimizada.

O COBOL não permaneceu vivo porque ficou parado.

Permaneceu vivo porque evoluiu.

Exatamente como qualquer tecnologia saudável deveria fazer.


O Db2, o CICS e o z/OS seguiram o mesmo caminho

O mesmo vale para todo o ecossistema IBM Z.

O Db2 evoluiu para um banco de dados altamente otimizado para cargas analíticas e transacionais.

O CICS transformou-se em uma plataforma moderna de serviços, APIs e integração.

O z/OS incorporou automação, segurança avançada, observabilidade, cloud híbrida e ferramentas abertas.

O BOB simplificou pipelines de build.

O Zowe aproximou novos desenvolvedores.

O Ansible levou automação moderna para o ambiente IBM Z.

O watsonx colocou Inteligência Artificial dentro da estratégia corporativa.

Nada disso existia quando aquelas manchetes foram escritas.


O maior erro continua acontecendo

Talvez a parte mais interessante desta história seja perceber que ela continua se repetindo.

Hoje o discurso mudou.

Não ouvimos mais:

"O Client/Server acabará com o Mainframe."

Agora ouvimos:

"A Inteligência Artificial acabará com os programadores."

Ou:

"LLMs substituirão arquitetos."

Ou:

"Ninguém mais precisará aprender linguagens de programação."

Será?

Talvez.

Talvez não.

Mas depois de estudar quarenta anos de História...

Aprendemos uma lição importante.

Desconfie sempre das previsões absolutas.

Principalmente quando elas envolvem palavras como:

"Nunca."

"Sempre."

"Definitivamente."

"Até 2030."

"A última."

A História da Computação costuma ser muito mais criativa do que qualquer cronograma.


O velho Jedi explica o segredo

Nosso Padawan encontra novamente o velho mestre.

Depois de toda essa jornada ele faz apenas uma pergunta.

— Mestre...

Qual foi o segredo do Mainframe?

O velho engenheiro permanece alguns segundos em silêncio.

Depois responde.

— O segredo nunca foi o hardware.

— Então foi o COBOL?

— Também não.

— O CICS?

— Não.

— O Db2?

— Ainda não.

— Então o que foi?

O mestre sorri.

Aponta para uma palavra escrita em um quadro branco.

Compatibilidade.

Depois escreve outra.

Evolução.

E mais uma.

Confiabilidade.

Por fim conclui.

— O Mainframe nunca obrigou seus clientes a jogar fora quarenta anos de investimento para aproveitar uma inovação.

Ele carregou o passado junto com o futuro.

Essa talvez tenha sido sua maior invenção.


A verdadeira Estrela da Morte

Como todo bom Bellacosa Mainframe...

Precisamos terminar com uma referência a Star Wars.

Durante anos o mercado enxergou o IBM Mainframe como se fosse a Estrela da Morte.

Gigante.

Antigo.

Centralizado.

Imponente.

Mas talvez a comparação correta seja outra.

O IBM Mainframe nunca foi a Estrela da Morte.

Ele sempre foi o Mestre Yoda.

Enquanto todos corriam atrás da próxima moda...

Ele permanecia em silêncio.

Aprendendo.

Evoluindo.

Adaptando-se.

Observando gerações inteiras de tecnologias nascerem.

Algumas brilharem intensamente.

Outras desaparecerem.

No final...

Ainda estava lá.

Mais experiente.

Mais moderno.

Mais forte.


Uma carta ao Padawan COBOL

Se você chegou até aqui...

Talvez esteja começando sua carreira.

Talvez já tenha décadas de experiência.

Não importa.

Existe uma única mensagem que gostaria que permanecesse com você.

Nunca estude uma tecnologia apenas porque ela está na moda.

Estude porque ela resolve um problema.

Nunca abandone uma tecnologia apenas porque alguém a chamou de "legado".

Descubra primeiro se ela continua gerando valor.

Nunca confunda marketing com arquitetura.

Nunca confunda novidade com inovação.

Nunca confunda interface bonita com engenharia sólida.

E, acima de tudo...

Nunca deixe de aprender.

Porque foi exatamente isso que permitiu ao IBM Mainframe atravessar mais de seis décadas.


A História escreveu seu próprio final

Em 1989 disseram que era um dinossauro.

Em 1991 marcaram a data de sua morte.

Em 1993 afirmaram que caminhava para a extinção.

Em 1994 começaram a perceber que talvez estivessem enganados.

Em 2026...

O IBM z17 executa Inteligência Artificial.

O watsonx auxilia empresas em escala global.

O COBOL continua movimentando trilhões de dólares.

O Db2 continua protegendo informações críticas.

O CICS continua processando bilhões de transações.

O z/OS continua sendo referência em disponibilidade e segurança.

E milhares de novos Padawans continuam aprendendo essa plataforma extraordinária.

A História foi generosa.

Ela não humilhou quem errou.

Apenas mostrou que prever o futuro é muito mais difícil do que construir um bom sistema.


Epílogo

Quando terminar este café...

Feche o navegador.

Abra seu editor.

Entre no TSO.

Compile um programa COBOL.

Execute um JCL.

Faça um SELECT no Db2.

Chame uma transação CICS.

Observe tudo funcionando.

Então lembre-se de uma frase.

O Mainframe nunca sobreviveu porque resistiu ao futuro.

Ele sobreviveu porque aprendeu a evoluir junto com ele.

Essa talvez seja a maior lição deixada por Wolfgang Spruth.

E certamente é a maior herança que podemos transmitir para a próxima geração de Programadores COBOL Padawans.

Que a Engenharia esteja com você.

Sempre.

Bellacosa Mainframe e o Funeral que nunca aconteceu



C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

quinta-feira, 25 de junho de 2026

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe


Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...