Bellacosa Mainframe e o cemiterio dos Buzzwords

☕ Um Café no Bellacosa Mainframe

Capítulo 11 — O Cemitério dos Buzzwords

Enquanto Enterravam o Mainframe, os Modismos É que Foram Desaparecendo

Uma viagem bem-humorada pelos grandes modismos da indústria de TI que, em diferentes épocas, prometeram substituir completamente o mainframe, mas acabaram tornando-se apenas mais um capítulo da história da computação.

Por Vagner Bellacosa

Client/Server, Downsizing, Rightsizing, Cloud, Blockchain, Metaverso e outros modismos passaram. O IBM Mainframe continuou evoluindo e integrando cada uma dessas tecnologias.

"Na Tecnologia da Informação existem duas certezas: sempre surgirá um novo buzzword e alguém dirá que ele acabará com tudo o que veio antes."

— Bellacosa Mainframe

O ciclo dos buzzwords

Ao longo das últimas décadas, diversos conceitos ganharam enorme popularidade: Client/Server, Downsizing, Rightsizing, SOA, BPM, Virtualização, Cloud Computing, Containers, Blockchain, Metaverso e, mais recentemente, Inteligência Artificial.

Todos trouxeram contribuições importantes para a indústria. O erro não foi sua existência, mas a crença recorrente de que cada novidade eliminaria completamente tudo o que existia antes.

A estratégia vencedora

Enquanto o mercado frequentemente falava em substituição, o ecossistema IBM Z seguiu outro caminho: integração. Linux, Java, APIs REST, containers, OpenShift, Git, DevOps, Ansible, watsonx e IA passaram a conviver naturalmente com COBOL, CICS, Db2 e z/OS.

A grande lição

A História mostra que tecnologias realmente bem-sucedidas raramente eliminam completamente as anteriores. Elas evoluem, coexistem e se integram para resolver problemas de negócio de forma cada vez mais eficiente.

---

Bellacosa Mainframe e o museu da computação

Bem-vindo ao Museu da Computação

Imagine que exista um enorme museu.

Não um museu de computadores.

Um museu de previsões.

Cada sala possui um cartaz.

Um slogan.

Uma promessa.

Uma tecnologia revolucionária.

Ao lado...

Uma frase.

"Agora o Mainframe acabou de verdade."

Você entra na primeira sala.

Depois na segunda.

Na terceira.

Na décima.

Na vigésima.

E começa a perceber um padrão curioso.

Os nomes mudam.

A promessa continua exatamente a mesma.

---

Sala 1 — Client/Server

Ano: 1990.

A promessa:

"Agora tudo ficará distribuído."

O que realmente aconteceu?

Sim.

Aplicações distribuídas conquistaram o mercado.

Mas os grandes sistemas transacionais continuaram centralizados.

Hoje praticamente toda grande empresa utiliza ambos.

Resultado:

✔ Client/Server venceu.

✔ Mainframe também.

Empate por integração.

---

Sala 2 — RISC vai acabar com CISC

Ano: 1992.

Naquela época parecia que a arquitetura RISC resolveria todos os problemas da computação.

PowerPC.

SPARC.

MIPS.

Alpha.

PA-RISC.

Cada fabricante prometia o mesmo.

Mais desempenho.

Mais simplicidade.

Mais futuro.

Enquanto isso...

Os engenheiros da IBM continuavam evoluindo a arquitetura do mainframe.

Resultado?

RISC tornou-se extremamente importante.

Mas o IBM Z continuou evoluindo em paralelo.

Mais uma previsão que confundiu inovação com substituição.

---

Sala 3 — Windows NT dominará os datacenters

Quem viveu os anos 90 certamente se lembra.

Windows NT era apresentado como o sucessor natural dos grandes sistemas.

O marketing era gigantesco.

As demonstrações impressionavam.

As revistas adoravam.

O problema apareceu alguns anos depois.

Administrar milhares de servidores individuais revelou-se muito mais complexo do que muitos imaginavam.

Windows NT tornou-se uma plataforma importante.

Mas nunca substituiu o processamento crítico realizado pelos grandes sistemas corporativos.

---

Sala 4 — Java vai matar COBOL

Essa talvez seja uma das histórias mais divertidas.

Final da década de 1990.

Java dominava as conferências.

A frase mais comum era:

"Agora ninguém mais escreverá COBOL."

A IBM respondeu de maneira extremamente elegante.

Colocou Java dentro do mainframe.

Em vez de lutar contra Java...

Resolveu executá-lo.

Hoje Java e COBOL convivem naturalmente no IBM Z.

Mais uma vez...

Integração venceu.

---

Sala 5 — ERP elimina sistemas legados

Lembra dessa?

Bastaria instalar um grande ERP.

Pronto.

Todos os sistemas antigos desapareceriam.

Na prática...

Milhares de empresas descobriram que seus diferenciais competitivos estavam justamente naqueles sistemas chamados de "legado".

Resultado.

Os ERPs foram integrados aos sistemas existentes.

Não o contrário.

---

Sala 6 — SOA vai reescrever tudo

No início dos anos 2000 surgiu outro grande entusiasmo.

SOA.

Service-Oriented Architecture.

A promessa parecia familiar.

Tudo seria reescrito como serviços.

O que aconteceu?

Os serviços realmente apareceram.

Mas muitos deles passaram simplesmente a chamar programas COBOL já existentes.

CICS ganhou Web Services.

Depois REST.

Depois APIs modernas.

Mais uma vez...

O velho código apenas ganhou uma nova porta de entrada.

---

Sala 7 — Cloud vai acabar com os Datacenters

Essa previsão ainda aparece de tempos em tempos.

Segundo muitos especialistas...

Tudo iria para a nuvem.

Os datacenters desapareceriam.

Chegamos a 2026.

O que vemos?

Cloud.

Cloud híbrida.

Cloud privada.

Edge Computing.

IBM Z.

LinuxONE.

Todos convivendo.

A realidade novamente preferiu integração.

---

Sala 8 — Blockchain vai substituir bancos

Lembra de 2018?

Tudo seria Blockchain.

Contratos.

Documentos.

Identidade.

Cartórios.

Pagamentos.

Governos.

Algumas aplicações realmente prosperaram.

Outras desapareceram.

Os bancos?

Continuaram utilizando COBOL.

Db2.

CICS.

Mainframe.

E, curiosamente, várias soluções Blockchain passaram a integrar sistemas tradicionais.

---

Sala 9 — O Metaverso Corporativo

Talvez um dos buzzwords mais efêmeros.

Por algum tempo parecia que todas as reuniões aconteceriam em ambientes virtuais tridimensionais.

Empresas correram.

Investidores também.

Hoje...

As videoconferências continuam dominando.

O metaverso encontrou nichos específicos, mas não substituiu a forma como o mercado corporativo trabalha.

Mais uma previsão grandiosa que encontrou uma realidade bem mais pragmática.

---

Sala 10 — A Inteligência Artificial substituirá todos os programadores

Chegamos ao presente.

Agora o discurso mudou novamente.

A manchete da vez é:

"A IA escreverá todo o código."

Será?

A IA certamente mudou a forma como desenvolvemos software.

Produz documentação.

Sugere algoritmos.

Explica código.

Auxilia em testes.

Aumenta produtividade.

Mas alguém ainda precisa:

Entender o negócio.

Projetar arquitetura.

Validar regras.

Garantir segurança.

Tomar decisões.

Assim como aconteceu em 1990...

Existe uma enorme diferença entre automatizar tarefas e substituir conhecimento.

---

O padrão finalmente aparece

Observe todas essas previsões.

Client/Server.

RISC.

Windows NT.

Java.

ERP.

SOA.

Cloud.

Blockchain.

Metaverso.

IA.

Todas seguem praticamente o mesmo roteiro.

Primeiro aparece uma inovação verdadeira.

Depois surgem expectativas enormes.

Em seguida alguém anuncia:

"Agora acabou para o Mainframe."

Alguns anos passam.

A inovação permanece.

O Mainframe também.

---

A maior ironia de todas

Enquanto dezenas de tecnologias tentavam substituir o IBM Mainframe...

O IBM Mainframe fazia exatamente o contrário.

Incorporava cada uma delas.

Linux?

Venha.

Java?

Pode entrar.

REST?

Sem problema.

Containers?

Ótimo.

OpenShift?

Também.

Git?

Claro.

Python?

Bem-vindo.

Ansible?

Excelente.

Inteligência Artificial?

Vamos integrar.

Essa talvez seja a característica mais impressionante da plataforma IBM Z.

Ela raramente rejeita uma inovação.

Ela procura descobrir como utilizá-la.

---

O Padawan visita o cemitério

Nosso Padawan encontra um enorme portão.

Na entrada está escrito:

Cemitério dos Buzzwords

Ele começa a caminhar.

Primeira lápide.

"Client/Server substituirá tudo."

Segunda.

"COBOL acabou."

Terceira.

"O último mainframe será desligado."

Quarta.

"Cloud elimina os datacenters."

Quinta.

"IA elimina os programadores."

Ele continua andando.

Chega ao final do cemitério.

Olha para trás.

Percebe algo curioso.

Nenhuma lápide pertence ao IBM Mainframe.

Então escuta uma voz.

É o velho mestre.

— Está vendo?

— O quê?

— Buzzwords normalmente têm prazo de validade.

Arquiteturas bem projetadas costumam durar muito mais.

---

O segredo nunca foi resistir

Existe uma ideia equivocada.

Algumas pessoas imaginam que o IBM Mainframe sobreviveu porque resistiu às mudanças.

Não.

Ele sobreviveu justamente porque mudou.

Muito.

O System/360 de 1964 é completamente diferente do IBM z17 de 2026.

Mudaram:

Processadores.

Memória.

Compiladores.

Linguagens.

Virtualização.

Ferramentas.

Integração.

Observabilidade.

Automação.

DevOps.

Cloud.

IA.

O que permaneceu foi a filosofia.

Compatibilidade.

Disponibilidade.

Confiabilidade.

Escalabilidade.

---

O verdadeiro "dinossauro"

No primeiro capítulo vimos o mainframe ser chamado de dinossauro.

Chegamos agora ao final desta jornada.

E talvez possamos fazer uma pergunta provocativa.

Quem realmente envelheceu mal?

O IBM Mainframe?

Ou a ideia de que toda tecnologia nova precisa destruir completamente a anterior?

Porque o z17 continua evoluindo.

O COBOL continua recebendo novos recursos.

O Db2 continua inovando.

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

O z/OS continua sendo atualizado.

Muitos dos buzzwords que prometeram acabar com eles...

Hoje aparecem apenas em livros de História da Computação.

---

A última aula para o Padawan

Sempre que surgir um novo modismo...

Não pergunte:

"Isso vai matar o Mainframe?"

Pergunte:

"Como o Mainframe vai incorporar isso?"

Essa pergunta possui muito mais chances de acertar o futuro.

Foi assim com:

Internet.

Java.

Linux.

Web Services.

Open Source.

Containers.

Cloud.

OpenShift.

DevOps.

E agora...

Inteligência Artificial.

Talvez a maior habilidade do IBM Mainframe nunca tenha sido processar bilhões de transações.

Sua maior habilidade foi outra.

Aprender continuamente sem abandonar aquilo que já funcionava.

Essa é uma lição que vale não apenas para computadores.

Vale também para arquitetos.

Para desenvolvedores.

Para empresas.

E, principalmente, para cada novo Padawan COBOL que inicia sua jornada.

Porque buzzwords vêm e vão.

Mas engenharia bem construída continua escrevendo a História.

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

[ CAPÍTULOS ] [ SOBRE A SÉRIE ] [ BELLACOSA MAINFRAME ]

▼ DIRETÓRIO DE CAPÍTULOS ▼

CAPÍTULO 01 O Funeral que Nunca Aconteceu ABRIR CAPÍTULO 01 ↗	CAPÍTULO 02 A Década dos Buzzwords ABRIR CAPÍTULO 02 ↗
CAPÍTULO 03 O Professor que Arquivou o Funeral ABRIR CAPÍTULO 03 ↗	CAPÍTULO 04 Forbes (1989) ABRIR CAPÍTULO 04 ↗
CAPÍTULO 05 The New York Times (1989) ABRIR CAPÍTULO 05 ↗	CAPÍTULO 06 InfoWorld (1991) ABRIR CAPÍTULO 06 ↗
CAPÍTULO 07 The New York Times (1993) ABRIR CAPÍTULO 07 ↗	CAPÍTULO 08 Business Week (1994) ABRIR CAPÍTULO 08 ↗
CAPÍTULO 09 O Que Realmente Aconteceu ABRIR CAPÍTULO 09 ↗	CAPÍTULO 10 Por Que Tantas Previsões Erraram? ABRIR CAPÍTULO 10 ↗
CAPÍTULO 11 O Cemitério dos Buzzwords ABRIR CAPÍTULO 11 ↗	CAPÍTULO 12 O Legado dos Profetas e a Grande Lição para 2026 ABRIR CAPÍTULO 12 ↗
CAPÍTULO 13 Os Profetas da IA e o Próximo Funeral ABRIR CAPÍTULO 13 ↗	CAPÍTULO 14 — FINAL O Julgamento da História ABRIR CAPÍTULO FINAL ↗

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.

 

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.

Bellacosa Mainframe um pequeno exemplo de API REST no Mainframe

💣🔥 API REST no Mainframe — QUANDO O COBOL VIROU BACKEND DE APLICATIVO SEM PEDIR LICENÇA

Se você ainda acha que COBOL só roda batch, prepara o choque:
com z/OS Connect, seu programa vira API REST consumida por mobile, web e cloud.

---

🚀 O que é o z/OS Connect (explicado sem enrolação)

👉 É o “tradutor oficial” entre:

• 🌐 Mundo moderno (REST / JSON)
• 🏦 Mundo legado (COBOL / CICS / IMS)

Ele roda no z/OS e conversa direto com:

• CICS
• IMS

💣 Tradução Bellacosa:

“Ele pega um GET/POST da internet e transforma em chamada de programa COBOL… e volta como JSON.”

---

🧠 Arquitetura (visão de guerra)

Fluxo real:

📱 Mobile / Web
        ↓
🌐 API REST (HTTP/JSON)
        ↓
🔌 z/OS Connect
        ↓
🧠 CICS / IMS
        ↓
💾 COBOL
        ↓
📦 Dados (Db2 / VSAM / EzNoSQL)

---

🧪 Exemplo prático (nível COBOL júnior)

🎯 Cenário

Você tem um programa COBOL que consulta saldo.

---

🧩 1. COBOL (legado)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SALDO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WS-CONTA    PIC 9(10).
       01 WS-SALDO    PIC 9(10)V99.

       PROCEDURE DIVISION.
           MOVE 12345 TO WS-CONTA
           MOVE 1500.75 TO WS-SALDO
           DISPLAY "SALDO: " WS-SALDO
           STOP RUN.

---

🌐 2. API REST exposta

GET /api/saldo/12345

---

🔁 3. Resposta JSON

{
  "conta": "12345",
  "saldo": 1500.75
}

💣 Sem reescrever COBOL
💣 Sem migrar sistema
💣 Só expondo via z/OS Connect

---

⚙️ Como funciona por dentro (o pulo do gato)

O z/OS Connect usa:

• Service Definition (SAR) → define entrada/saída
• Data Mapping → JSON ↔ estrutura COBOL
• Runtime Liberty (Java) → engine REST

👉 Ele faz o binding automático entre:

JSON ↔ Copybook COBOL

---

🔐 Segurança nível banco

Tudo integrado com:

• RACF
• TLS / HTTPS
• Controle de identidade

💣 Diferente de API na cloud:
👉 aqui segurança já nasce pronta

---

🚀 Vantagens (o que faz isso ser absurdo)

⚡ Modernização instantânea

Seu COBOL vira backend REST

---

💰 Economia brutal

Sem reescrever sistema legado

---

🔗 Integração total

Funciona com:

• mobile
• fintech
• cloud
• parceiros

---

🧩 Plugável com EzNoSQL

Sim, o combo fica insano:

👉 API REST + JSON + mainframe
👉 💣 arquitetura híbrida real

---

⚠️ Desvantagens (real talk)

❌ Setup inicial não é trivial

Precisa entender:

• contratos
• mapping
• deploy

---

❌ Debug pode confundir iniciante

Problema pode estar em:

• JSON
• mapping
• COBOL
• CICS

---

🧠 Curiosidades (nível insider)

💡 Muitas fintechs usam isso escondido
👉 API moderna… backend COBOL

💡 Você pode versionar APIs
👉 v1, v2 sem quebrar legado

💡 Integra com Swagger/OpenAPI
👉 documentação automática

---

🥚 Easter Egg

💣 O maior hack corporativo:

Empresas dizem:

👉 “Somos cloud-native”

Mas o core…

👉 ainda é COBOL exposto via z/OS Connect 😎

---

🧠 Insight que muda carreira

👉 Aprender isso te coloca à frente de 90% dos devs COBOL

Porque você passa a ser:

💣 Dev de integração + legado + API

---

🚀 Conclusão

O z/OS Connect é a ponte definitiva:

👉 passado (COBOL)
👉 presente (REST)
👉 futuro (cloud híbrida)

 

Bellacosa Mainframe e as evoluções na codificação moderna

☕💣 OPERADOR, O MUNDO NÃO PAROU NO =>!

As Grandes Revoluções da Programação que Todo Programador COBOL Mainframe Deveria Conhecer

Se você aprendeu recentemente sobre Arrow Functions, saiba que elas representam apenas uma pequena peça de uma transformação gigantesca que aconteceu nas linguagens modernas nos últimos 20 anos.

Para um programador COBOL, é como se alguém tivesse adicionado ao COBOL:

• JCL inteligente

• SORT automático

• CICS embutido

• DB2 transparente

• IA integrada

• Processamento paralelo nativo

Tudo ao mesmo tempo.

---

1. Programação Funcional

Antes:

for (let i=0; i<clientes.length; i++) {
   console.log(clientes[i]);
}

Hoje:

clientes
   .filter(c => c.ativo)
   .map(c => c.nome)
   .forEach(nome => console.log(nome));

Conceitos:

• map()

• filter()

• reduce()

• lambda

• arrow functions

Muito inspirada em matemática.

---

2. Async/Await

Uma das maiores revoluções.

Antigamente:

lerArquivo(function(resultado){
   processar(resultado);
});

Virava um pesadelo.

Hoje:

const dados = await lerArquivo();

Para um coboleiro:

Parece um:

CALL "LERARQ"
CALL "PROCESSA"

Só que para internet, APIs e bancos.

---

3. APIs REST

Hoje praticamente tudo conversa por APIs.

Exemplo:

GET /clientes/123

Resposta:

{
  "nome":"Bellacosa",
  "cidade":"Santos"
}

É quase como fazer um:

READ CLIENTES
   KEY = 123

Mas através da internet.

---

4. JSON

O sucessor espiritual dos layouts COPYBOOK.

COBOL:

01 CLIENTE.
   05 NOME PIC X(30).
   05 IDADE PIC 999.

JSON:

{
  "nome":"Vagner",
  "idade":50
}

Hoje praticamente tudo usa JSON.

---

5. Containers (Docker)

Uma revolução enorme.

Antes:

Instale sistema
Instale bibliotecas
Configure ambiente
Configure servidor

Hoje:

docker run aplicacao

Tudo já vem pronto.

É como distribuir um ambiente z/OS inteiro dentro de uma imagem.

---

6. Cloud Computing

Antes:

Comprar servidor
Instalar servidor
Administrar servidor

Hoje:

AWS
Azure
Google Cloud
IBM Cloud

Você aluga recursos por minuto.

---

7. Microserviços

Antes:

Sistema gigante

Hoje:

Serviço Clientes
Serviço Pagamentos
Serviço Estoque
Serviço Vendas

Lembra bastante a filosofia de programas COBOL independentes.

---

8. Git

Outra revolução absurda.

Antes:

PROG1.CBL
PROG1NOVO.CBL
PROG1NOVOFINAL.CBL
PROG1FINALAGORA.CBL

Hoje:

git commit
git branch
git merge

Controle de versões profissional.

---

9. DevOps

Antes:

Programador desenvolvia.

Operação implantava.

Hoje:

As equipes trabalham juntas.

Ferramentas:

• GitHub

• GitLab

• Jenkins

• Azure DevOps

---

10. CI/CD

Integração Contínua.

Você salva:

git push

Automaticamente:

Compila
Testa
Valida
Publica

Lembra um pipeline JCL automático.

---

11. Inteligência Artificial

A maior revolução atual.

Exemplo:

def calcula_imposto():

IA:

Crie uma função para calcular imposto.

O código aparece pronto.

Ferramentas:

• ChatGPT

• GitHub Copilot

• Claude

• Gemini

---

12. Low-Code e No-Code

Ferramentas como:

• N8N

• Power Automate

• Zapier

Permitem criar automações sem programar muito.

Você literalmente desenha fluxos.

---

13. TypeScript

JavaScript moderno com tipagem.

JavaScript:

let valor = "100";

TypeScript:

let valor:number = 100;

Programadores COBOL costumam gostar muito porque lembra a disciplina dos PICs.

---

14. WebAssembly (WASM)

Uma das tecnologias mais promissoras.

Permite executar:

• C

• C++

• Rust

• COBOL

Dentro do navegador.

Imagine rodar um programa COBOL diretamente no Chrome.

Isso já existe.

---

15. Programação Reativa

Em vez de perguntar:

Mudou?
Mudou?
Mudou?

O sistema avisa sozinho.

Muito usada em:

• React

• Angular

• Vue

---

16. Rust

A estrela atual dos sistemas.

Criada pela Mozilla.

Promete:

• Velocidade de C

• Segurança de Java

• Menos bugs

Empresas usando:

• Microsoft

• Amazon

• Google

• Cloudflare

---

17. Kotlin

Substituindo Java em muitos projetos.

Mais simples.

Mais seguro.

Menos código.

---

18. GraphQL

Alternativa moderna ao REST.

Você pede exatamente os dados que deseja.

Exemplo:

{
   cliente {
      nome
      saldo
   }
}

---

19. Event Driven Architecture

Arquitetura baseada em eventos.

Exemplo:

Cliente comprou
↓
Evento gerado
↓
Pagamento processa
↓
Estoque atualiza
↓
Entrega inicia

Lembra MQSeries/MQ do Mainframe.

---

20. Agentes de IA

A próxima revolução.

Hoje a IA não apenas responde.

Ela:

• Pesquisa

• Programa

• Executa tarefas

• Toma decisões

• Chama APIs

• Cria workflows

Ferramentas:

• OpenAI Agents

• LangChain

• CrewAI

• AutoGen

• N8N AI Agents

---

O Que Eu Estudaria Primeiro Sendo um Coboleiro?

Ordem ideal:

Nível 1

✅ JSON
✅ APIs REST
✅ Git
✅ JavaScript Moderno
✅ Arrow Functions

---

Nível 2

✅ Node.js
✅ TypeScript
✅ Docker
✅ Cloud

---

Nível 3

✅ N8N
✅ IA Generativa
✅ Agentes de IA
✅ MCP (Model Context Protocol)

---

Nível 4

✅ Rust
✅ WebAssembly
✅ Arquiteturas Event Driven

---

Resumo Bellacosa Mainframe

Se em 1970 a revolução foi o surgimento do CICS, em 1980 o DB2, em 1990 a internet e em 2000 os Web Services, então a década atual está sendo marcada por cinco grandes pilares:

IA Generativa, Agentes de IA, Cloud Computing, Arquiteturas Baseadas em Eventos e Desenvolvimento Assistido por IA.

Para um profissional de Mainframe, aprender apenas JavaScript já não é suficiente. O diferencial moderno está em entender como conectar o mundo COBOL, CICS, DB2 e z/OS a APIs, nuvem, automação e inteligência artificial. É exatamente nessa integração que estão surgindo as oportunidades mais interessantes do mercado. 🚀☕💣

 

Bellacosa Mainframe e a cloud na Stack Mainframe

O que é Cloud no Mainframe?

Quando falamos em Cloud no Mainframe, muitas pessoas imaginam que Mainframe e Cloud são tecnologias concorrentes. Na realidade, elas são extremamente complementares.

Hoje, grande parte das soluções de Cloud corporativa se integra diretamente com Mainframes IBM Z e LinuxONE.

---

O que é Cloud?

Cloud Computing (Computação em Nuvem) é um modelo onde recursos computacionais são disponibilizados sob demanda.

Exemplos:

Servidores
Armazenamento
Banco de Dados
Containers
Inteligência Artificial
APIs

Tudo acessível pela rede.

---

Os Modelos de Cloud

Cloud Pública

Infraestrutura compartilhada.

Exemplos:

• AWS

• Microsoft Azure

• Google Cloud

---

Cloud Privada

Infraestrutura exclusiva da empresa.

Exemplo:

Data Center Corporativo
       ↓
IBM Z
       ↓
Cloud Privada

---

Cloud Híbrida

Combinação entre:

Cloud Pública
       +
Cloud Privada

É o modelo mais comum em ambientes Mainframe.

---

Onde o Mainframe Entra?

O Mainframe geralmente continua executando:

COBOL
CICS
IMS
DB2
VSAM

Enquanto aplicações modernas executam na Cloud.

---

Arquitetura Moderna

Aplicativo Mobile
        ↓
API REST
        ↓
Cloud
        ↓
z/OS Connect
        ↓
COBOL
        ↓
DB2

---

Por que Não Migrar Tudo Para a Cloud?

Porque o Mainframe possui características difíceis de substituir:

✅ Confiabilidade

✅ Segurança

✅ Escalabilidade

✅ Processamento transacional

✅ Disponibilidade

---

Exemplo Bancário

Quando você faz um PIX:

App Mobile
      ↓
Cloud API
      ↓
Mainframe
      ↓
CICS
      ↓
DB2
      ↓
Resposta

O usuário enxerga a Cloud.

A transação ocorre no Mainframe.

---

Mainframe como Cloud Privada

O IBM Z pode funcionar como uma enorme Cloud privada.

---

Exemplo:

Usuários
     ↓
Portal Cloud
     ↓
LinuxONE
     ↓
Máquinas Virtuais

---

Virtualização no Mainframe

Muito antes da Cloud existir, o Mainframe já possuía:

LPAR
PR/SM
z/VM

---

Capaz de executar:

Centenas
ou
Milhares
de VMs

simultaneamente.

---

LinuxONE e Cloud

O LinuxONE foi criado justamente para workloads Cloud.

Executa:

• Containers

• Kubernetes

• OpenShift

• IA

• APIs

---

Arquitetura:

OpenShift
      ↓
Containers
      ↓
LinuxONE

---

OpenShift no Mainframe

Uma das estratégias mais populares atualmente.

OpenShift
       ↓
Kubernetes
       ↓
LinuxONE
       ↓
IBM Z

---

Benefícios:

✅ Escalabilidade

✅ Containers

✅ DevOps

✅ Microsserviços

---

Cloud Híbrida

É o cenário mais comum.

---

Exemplo:

AWS
  ↓
API Gateway
  ↓
z/OS Connect
  ↓
COBOL

---

Ou:

Azure
   ↓
API REST
   ↓
CICS

---

Mainframe e Containers

Hoje é possível executar:

• Docker

• Podman

• Kubernetes

• OpenShift

sobre LinuxONE.

---

Mainframe e APIs

A Cloud conversa com Mainframe através de:

REST
JSON
SOAP
MQ
Kafka

---

z/OS Connect

Uma das tecnologias-chave.

Transforma:

Programa COBOL

em

API REST

---

Fluxo:

JSON
   ↓
REST
   ↓
z/OS Connect
   ↓
COBOL

---

DevOps no Mainframe

Cloud impulsionou:

• Git

• GitHub

• GitLab

• Jenkins

• Ansible

• Zowe

---

Pipeline moderno:

Git
 ↓
Build
 ↓
Teste
 ↓
Deploy
 ↓
z/OS

---

Cloud e Segurança

O Mainframe é conhecido por sua segurança.

Integra:

RACF
TLS
OAuth
JWT
MFA

com ambientes Cloud.

---

Cloud e Inteligência Artificial

Hoje o IBM Z e LinuxONE executam:

• Python

• TensorFlow

• PyTorch

• Watsonx

---

Exemplo:

Transação
      ↓
IA
      ↓
Detecção de Fraude

em tempo real.

---

Cloud e Open Banking

Open Finance normalmente utiliza:

REST
JSON
OAuth
APIs

integradas ao Mainframe.

---

Benefícios

✅ Modernização sem reescrever COBOL

✅ Integração com Cloud Pública

✅ APIs REST

✅ Containers

✅ Kubernetes

✅ DevOps

✅ IA

✅ Redução de custos

---

Desafios

❌ Integração de sistemas legados

❌ Segurança

❌ Governança

❌ Latência

❌ Capacitação profissional

---

Tecnologias Mais Utilizadas

Tecnologia	Função
IBM Z	Plataforma principal
LinuxONE	Linux corporativo
z/OS Connect	APIs REST
OpenShift	Containers
Kubernetes	Orquestração
Zowe	Ferramentas modernas
Git	Controle de versão
Ansible	Automação
RACF	Segurança
DB2	Banco de dados

---

Curiosidade Histórica

Muito antes do termo "Cloud Computing" existir, os Mainframes já ofereciam conceitos semelhantes através de:

VM/CMS (1972)
z/VM
LPAR
PR/SM

permitindo compartilhar recursos computacionais entre múltiplos usuários, algo que hoje é considerado um dos fundamentos da computação em nuvem.

---

Resumo Rápido

Mobile
   ↓
Cloud
   ↓
API
   ↓
z/OS Connect
   ↓
COBOL
   ↓
DB2

---

Conclusão

Cloud no Mainframe não significa substituir o IBM Z, mas sim integrá-lo ao ecossistema moderno de APIs, Containers, Kubernetes, OpenShift, DevOps e Inteligência Artificial. O resultado é uma arquitetura híbrida onde a inovação acontece na Cloud e o processamento crítico continua protegido pela confiabilidade, segurança e desempenho do Mainframe.