Bellacosa Mainframe compara o aws com o mainframe

☕ Um Café no Bellacosa Mainframe

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

Quando um Programador COBOL Descobre que a Nuvem Não Inventou Tudo... Apenas Deu Novos Nomes às Velhas Ideias

Existe uma frase muito conhecida entre os profissionais de tecnologia:

"Toda tecnologia nova parece revolucionária... até você descobrir que o mainframe já fazia algo parecido há décadas."

Naturalmente, essa frase é um exagero. A computação em nuvem trouxe inúmeras inovações reais: elasticidade praticamente infinita, cobrança sob demanda, infraestrutura global distribuída, APIs padronizadas e uma velocidade de provisionamento que seria impensável nos anos 1970.

Por outro lado...

Quem trabalhou muitos anos em IBM Z percebe rapidamente algo curioso.

Boa parte dos conceitos fundamentais da Cloud Computing já existiam, apenas recebiam outros nomes.

É justamente isso que o infográfico procura mostrar.

Não se trata de afirmar que AWS = Mainframe.

Muito menos que um substitui o outro.

A proposta é muito mais inteligente:

Traduzir conceitos.

Da mesma forma que um brasileiro aprende inglês associando "house" com "casa", um programador COBOL aprende AWS muito mais rapidamente quando pensa:

"EC2... isso lembra uma LPAR."

É exatamente essa mudança mental que acelera o aprendizado.

Vamos aprofundar essa comparação.

---

Antes de tudo...

Existe um erro extremamente comum.

Muitos profissionais perguntam:

"Qual é o equivalente do AWS Lambda no Mainframe?"

Na verdade essa pergunta está errada.

O correto seria perguntar:

"Qual tecnologia do Mainframe resolve um problema semelhante?"

Porque tecnologias diferentes podem resolver o mesmo problema de maneiras completamente distintas.

É exatamente isso que veremos.

---

EC2 × LPAR

AWS

EC2 fornece máquinas virtuais sob demanda.

Você cria.

Liga.

Desliga.

Apaga.

Escala.

Tudo em minutos.

---

Mainframe

A comparação natural é a LPAR (Logical Partition).

Mas aqui existe uma enorme diferença filosófica.

Uma instância EC2 normalmente é um servidor virtual.

Uma LPAR é praticamente um computador completo.

Dentro dela existe:

• z/OS

• JES

• RACF

• CICS

• Db2

• MQ

• milhares de usuários

Ou seja...

Uma única LPAR frequentemente faz o trabalho de centenas de servidores Linux.

Por isso muitos profissionais dizem:

"Comparar uma EC2 com uma LPAR é como comparar um apartamento com um condomínio inteiro."

---

Curiosidade

O conceito de particionamento lógico apareceu comercialmente décadas antes da virtualização popularizada pelo VMware.

A IBM fazia isso quando a maioria dos servidores ainda era física.

---

S3 × VSAM / DASD

Esta comparação merece cuidado.

S3 não é um disco.

É um armazenamento de objetos.

VSAM não é armazenamento de objetos.

É um método de acesso.

Então por que a comparação?

Porque ambos representam onde os dados vivem.

---

S3

Armazena objetos.

• fotos

• backups

• vídeos

• PDFs

• logs

Escala praticamente infinita.

---

Mainframe

No IBM Z os dados normalmente ficam em:

• DASD

• VSAM

• Sequential datasets

• GDGs

• PDS/PDSE

O conceito é diferente.

Enquanto S3 trabalha com objetos identificados por chaves, o mainframe trabalha com datasets catalogados e métodos de acesso especializados.

Um VSAM KSDS, por exemplo, comporta-se muito mais como um banco de dados indexado do que como um bucket S3.

---

Melhor analogia

Talvez fosse mais correto dizer:

S3 ≈ Conjunto de datasets altamente duráveis.

Não existe equivalente perfeito.

---

RDS × Db2 for z/OS

Aqui a aproximação é muito boa.

AWS oferece banco relacional gerenciado.

Db2 oferece banco relacional corporativo.

Mas termina aí.

---

O que muda?

No AWS:

Você administra menos infraestrutura.

No Mainframe:

Você administra muito mais parâmetros.

Em compensação...

Obtém níveis absurdos de disponibilidade.

Db2 z/OS foi construído para:

• bancos

• cartões

• bolsas

• governos

• seguradoras

Milhões de transações por segundo.

Décadas de evolução.

Consistência extrema.

---

Easter Egg

Quando alguém diz:

"Meu banco usa RDS."

O programador de mainframe responde:

"Interessante... o meu banco inteiro usa Db2."

---

Lambda × CICS

Essa comparação é conceitual.

Lambda executa código quando um evento ocorre.

CICS executa transações quando uma requisição chega.

Ambos respondem a eventos.

Mas de maneiras completamente diferentes.

---

Lambda

Sem servidor visível.

Escala automaticamente.

Cada chamada inicia uma execução.

---

CICS

Servidor transacional residente.

As tarefas reutilizam recursos.

Baixíssima latência.

Controle rigoroso.

Extrema confiabilidade.

---

Uma transação CICS pode durar poucos milissegundos.

E atender milhares de usuários simultaneamente.

Há bancos onde o cliente insere a senha no caixa eletrônico...

E em menos de um décimo de segundo:

• RACF valida

• CICS executa

• Db2 consulta

• MQ envia mensagens

• resposta retorna

Tudo isso antes do usuário piscar.

---

API Gateway × CICS Web Services

Nos últimos anos o CICS tornou-se um verdadeiro servidor de APIs.

Hoje é possível expor programas COBOL como:

• REST

• SOAP

• JSON

Sem reescrever décadas de código.

A ideia é semelhante ao API Gateway:

publicar serviços de forma segura.

A diferença é que no CICS o backend muitas vezes continua sendo um programa escrito em 1989.

E funcionando perfeitamente.

---

CloudWatch × RMF / SMF

Talvez uma das melhores comparações.

CloudWatch monitora.

RMF mede.

SMF registra praticamente tudo.

---

No mainframe existem registros para:

CPU.

I/O.

Memória.

Logons.

Jobs.

CICS.

Db2.

MQ.

Segurança.

Tudo vira SMF.

Depois essas informações alimentam:

• relatórios

• capacity planning

• billing interno

• auditoria

• performance

É praticamente uma caixa-preta de avião.

---

VPC × VTAM / TCP-IP

VPC cria uma rede privada lógica.

No mainframe temos:

• TCP/IP

• Enterprise Extender

• SNA

• VTAM (historicamente)

São tecnologias diferentes.

Mas ambas organizam comunicações seguras entre aplicações.

Hoje, o TCP/IP é predominante no z/OS, enquanto o VTAM permanece como parte importante da arquitetura SNA e do gerenciamento de sessões legadas.

---

IAM × RACF

Esta talvez seja a comparação mais intuitiva.

IAM controla identidades.

RACF controla identidades.

Mas RACF faz isso desde os anos 1970.

---

No RACF encontramos:

• usuários

• grupos

• perfis

• datasets

• transações

• comandos

• permissões

Tudo centralizado.

Em ambientes corporativos enormes, RACF continua sendo um dos sistemas de segurança mais robustos do mercado.

---

CloudFront

Aqui o infográfico coloca:

Sem equivalente.

Concordo parcialmente.

CloudFront é uma CDN.

Mainframe nunca precisou distribuir imagens para milhões de navegadores.

Mas existe um conceito parecido.

CICS, z/OS Connect e balanceadores corporativos podem distribuir carga entre regiões, embora isso não seja uma CDN. Portanto, realmente não há um equivalente direto.

---

DynamoDB

Também não existe equivalente perfeito.

O mainframe tradicional trabalha principalmente com:

• Db2

• IMS DB

• VSAM

Entretanto...

IMS Hierarchical Database possui algumas características que lembram bancos NoSQL modernos.

Não são iguais.

Mas resolvem certos problemas semelhantes.

---

SQS × IBM MQ

Esta comparação é excelente.

Ambos trabalham com filas.

Mensagens.

Processamento assíncrono.

Desacoplamento.

A principal diferença está no foco.

IBM MQ nasceu para ambientes corporativos críticos.

SQS nasceu para aplicações distribuídas na nuvem.

Ambos resolvem brilhantemente problemas de integração, mas IBM MQ oferece recursos avançados de transação, persistência e integração com sistemas legados que o tornam um pilar do processamento empresarial.

---

SNS × WTO / Console Messages

Aqui talvez seja a comparação mais discutível.

SNS distribui notificações para diversos assinantes.

Já WTO (Write To Operator) envia mensagens ao console do operador do z/OS.

Embora ambos "notifiquem", cumprem papéis muito diferentes.

Uma analogia funcional mais próxima seria:

• SNS ↔ combinação de IBM MQ + Event Notification + automação (como IBM Z System Automation ou NetView), dependendo do cenário.

WTO é muito mais voltado para operação do sistema do que para publicação de eventos para consumidores.

---

O que ficou faltando?

O universo AWS é enorme. Diversos serviços modernos também encontram paralelos conceituais no ecossistema IBM Z:

AWS	Mainframe
EBS	Volumes DASD
EFS	zFS / HFS
Elastic Load Balancer	Sysplex Distributor
Auto Scaling	WLM + Capacity on Demand
Secrets Manager	RACF Key Rings + ICSF
KMS	ICSF + Hardware Crypto Express
CloudTrail	SMF + RACF Auditing
Systems Manager	z/OSMF
ECS/EKS	zCX (z/OS Container Extensions)
EventBridge	IBM MQ + CICS START + automação
Step Functions	JCL + Scheduler (TWS/IWS, CA 7, Control-M)
Glue	DFSORT, SyncSort, DataStage e ferramentas ETL
Athena	Db2 Analytics, SQL Federation e consultas distribuídas
Redshift	Db2 Analytics Accelerator (IDAA)
Cognito	RACF + provedores de identidade (LDAP, SAF, z/OS Connect)

---

A Filosofia por Trás da Comparação

A maior lição do infográfico não é decorar equivalências.

É perceber que os problemas fundamentais da computação permanecem os mesmos:

• executar aplicações;

• armazenar dados;

• proteger acessos;

• integrar sistemas;

• monitorar ambientes;

• processar eventos;

• escalar capacidade.

O que muda é a forma como cada arquitetura resolve esses desafios.

O IBM Z foi concebido para oferecer estabilidade, consistência transacional e disponibilidade extrema em um ambiente centralizado. A AWS foi projetada para privilegiar elasticidade, automação, distribuição geográfica e provisionamento sob demanda em uma infraestrutura de nuvem.

Essas filosofias não são concorrentes em todos os casos — são frequentemente complementares. Hoje, é comum encontrar bancos, seguradoras e governos executando seus sistemas críticos em IBM Z enquanto utilizam AWS para APIs, analytics, inteligência artificial, aplicações móveis e serviços digitais.

---

Conclusão: O Melhor Profissional Fala Dois "Idiomas"

No início da carreira, muitos especialistas em mainframe enxergavam a nuvem como uma ameaça. Da mesma forma, muitos profissionais de cloud acreditavam que o mainframe era apenas uma tecnologia ultrapassada.

Com o tempo, o mercado mostrou uma realidade bem diferente.

Os ambientes corporativos mais sofisticados são híbridos.

O cartão de crédito pode ser autorizado por um programa COBOL executando em CICS e Db2 no IBM Z, enquanto o aplicativo móvel utiliza APIs hospedadas na AWS, com autenticação moderna, monitoramento em nuvem e microsserviços.

Em vez de escolher entre "mainframe ou cloud", as organizações escolhem mainframe e cloud.

Para o profissional de tecnologia, isso significa uma oportunidade extraordinária: dominar os dois mundos. Quem entende como traduzir conceitos entre AWS e IBM Z consegue atuar como uma ponte entre equipes, acelerar projetos de modernização e preservar décadas de conhecimento corporativo enquanto incorpora as práticas mais recentes da computação em nuvem.

No fim das contas, aprender AWS não exige esquecer o mainframe. Pelo contrário: para quem já conhece IBM Z, muitas ideias da nuvem deixam de parecer completamente novas e passam a ser apenas uma nova linguagem para resolver problemas que a computação empresarial enfrenta — e resolve — há mais de meio século.

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

 

Bellacosa Mainframe e a modernizacao na Stack mainframe

---

☕ Um Café no Bellacosa Mainframe

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

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

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

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.

---

2. Refatorar

Melhora código COBOL.

COBOL 74

↓

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.

---

3. Reescrever

Maior risco.

COBOL

→

Java

COBOL

→

Go

COBOL

→

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.

---

4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age

---

Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico

---

Bellacosa Mainframe e o mainframe no Brasil

Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.

---

Descobrir significa:

inventário

mapear

catalogar

entender

---

Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.

---

Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta

---

Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

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

---

A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.

---

Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

↓

Programa B

↓

VSAM

↓

MQ

↓

DB2

↓

Batch

↓

Scheduler

↓

API

---

Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.

---

Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes

---

Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.

---

Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.

---

Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks

---

IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid

---

Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.

---

Go

Ótimo.

Microserviços.

Baixo consumo.

---

Node

Excelente APIs.

Menor adequação para batchs enormes.

---

.NET

Muito usado em seguradoras.

---

E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.

---

Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.

---

Docker resolve.

Empacotamento.

Não arquitetura.

---

Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança

---

Para muitas empresas.

OpenShift.

É mais comum.

---

Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.

---

Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.

---

Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.

---

Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic

---

Imagine.

SMF 110

↓

OpenTelemetry

↓

Grafana

Isso já acontece.

---

O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.

---

Ela lê.

20 milhões linhas COBOL.

Em minutos.

---

Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.

---

Minha visão sobre a frase central

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

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

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

Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe

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

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

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

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

Bellacosa Mainframe quando a magia da migração via ia do mainframe falha

☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

O Dia em que o Mercado Percebeu que o ChatGPT Não Conhece o Batch das 02h17

Existe um momento na carreira de todo profissional de Mainframe em que ele aprende uma lição importante.

A primeira é que JCL não foi criado para ser bonito.

A segunda é que ninguém documenta adequadamente um scheduler.

A terceira é que sempre haverá alguém chegando com um PowerPoint dizendo:

— Vamos aposentar o Mainframe em doze meses.

Nos últimos vinte anos ouvi essa frase tantas vezes quanto mensagens $HASP373, IEC161I ou aquele clássico telefonema de sexta-feira às 18h:

— Bellacosa, caiu a produção.

Recentemente, entretanto, surgiu um ingrediente novo nessa antiga receita corporativa.

A Inteligência Artificial Generativa.

E, junto dela, uma nova promessa digna dos antigos alquimistas digitais:

"Nossa IA converte milhões de linhas COBOL para Java automaticamente."

"Seu CICS vira microsserviços em poucos cliques."

"Seu VSAM agora é PostgreSQL."

"Seu batch vira Kubernetes."

"Seu legado desaparece em seis meses."

Foi justamente nesse contexto que a Gartner publicou uma análise que talvez represente um dos maiores banhos de água fria já aplicados no mercado de migração de Mainframe.

Segundo a consultoria, mais de 70% dos projetos de saída do Mainframe iniciados em 2026 não entregarão os benefícios esperados.

E o motivo é simples.

As pessoas estão superestimando o que a IA realmente sabe fazer.

E subestimando brutalmente o que um ambiente IBM Z realmente é.

---

O Maior Equívoco da Década: Achar que Mainframe é Apenas COBOL

Quando alguém diz:

— Temos cinquenta milhões de linhas COBOL.

Meu primeiro pensamento nunca é sobre COBOL.

Meu primeiro pensamento é:

Quantos schedulers existem?

Quantos GDGs?

Quantos catálogos?

Quantos exits?

Quantos produtos ISV?

Quantos jobs dependem de um único arquivo VSAM aberto em RLS?

Porque o código é apenas a ponta visível do iceberg.

Abaixo da linha d'água vivem criaturas muito mais antigas e perigosas.

CA-7.

Control-M.

ESP.

Zeke.

NetView.

RACF.

DFSMS.

SMF.

RMF.

MQ.

WLM.

CICSplex.

IMS.

DB2 Packages.

Plan Stability.

PassTickets.

SAF.

Exit routines escritas em Assembler por alguém que se aposentou em 2009 e hoje cultiva orquídeas em Campinas.

A IA consegue interpretar um trecho como:

IF SALDO > LIMITE
   MOVE 'BLOQUEAR' TO ACAO
END-IF

Ela pode até gerar um Java elegante.

Mas dificilmente responderá perguntas como:

Por que esse programa executa apenas às terças-feiras?

Por que ele depende do fechamento do SMF?

Por que aguarda um arquivo SWIFT vindo da Bélgica?

Por que existe um passo IEBGENER aparentemente inútil?

Por que um job precisa terminar antes das 02h17?

E principalmente:

Quem será responsabilizado se o PIX parar durante duas horas?

---

O Conhecimento Tribal: A Tecnologia Mais Difícil de Migrar

Costumo dizer aos alunos do Bellacosa Mainframe:

O ativo mais caro de um banco não é o hardware.

Não é o software.

Nem mesmo os dados.

É o conhecimento acumulado por pessoas.

José está há trinta e dois anos na instituição.

Maria administra o RACF desde 1997.

Carlos conhece cada mensagem DFSxxxx de cabeça.

João sabe exatamente qual dataset pode ser apagado e qual causará um desastre regulatório.

Nenhum deles está em um repositório Git.

Nenhum deles está em um Wiki.

Nenhum deles aparece em um prompt.

Esse conhecimento mora na memória das pessoas.

E a IA não faz leitura telepática.

Ela apenas processa aquilo que recebeu.

Quando recebe documentação incompleta, devolve respostas incompletas.

Quando recebe caos, produz caos estatisticamente coerente.

---

O Marketing da Varinha Mágica Digital

Não tenho dúvidas.

Existe muita tecnologia impressionante surgindo.

Copilots.

Agentes autônomos.

Análise semântica.

Descoberta automática de dependências.

RAG.

Embeddings.

Vetorização.

Tudo isso possui enorme potencial.

Mas também estamos vivendo uma epidemia de apresentações corporativas.

Parece que alguns vendedores descobriram a Pedra Filosofal da Computação.

Basta enviar um ZIP contendo quarenta milhões de linhas COBOL.

E, algumas horas depois, nasce uma arquitetura nativa de nuvem.

Observabilidade pronta.

CI/CD configurado.

Microsserviços desacoplados.

Eventos Kafka.

Terraform.

OpenTelemetry.

Kubernetes.

Documentação impecável.

Testes automatizados.

Compliance.

Segurança.

Alta disponibilidade.

Tudo isso sem compreender uma única regra de negócio.

É quase uma versão tecnológica daquele vendedor de elixires do Velho Oeste.

Só que agora utilizando a palavra GenAI.

---

O Mainframe Continua Evoluindo

Enquanto parte do mercado tenta organizar funerais prematuros para o IBM Z, a IBM continua investindo bilhões de dólares na plataforma.

Hoje temos:

COBOL 6.x;

z/OS Connect;

OpenTelemetry;

Ansible;

Zowe;

Git integrado;

DevOps moderno;

API Economy;

Containers Linux on Z;

IA embarcada;

Criptografia acelerada por hardware;

Processadores especializados.

Ou seja.

O Mainframe não está parado.

O Mainframe está fazendo aquilo que sempre fez melhor.

Adaptando-se.

Em 1964 ele sobreviveu ao surgimento dos minicomputadores.

Nos anos 80 sobreviveu às workstations.

Nos anos 90 sobreviveu ao Client/Server.

Nos anos 2000 sobreviveu à internet.

Nos anos 2010 sobreviveu à cloud.

Nos anos 2020 provavelmente sobreviverá ao hype da IA Generativa.

Porque, no final das contas, bancos continuam precisando fechar o dia.

Companhias aéreas continuam emitindo passagens.

Governos continuam pagando benefícios.

Seguradoras continuam processando milhões de eventos.

E quase ninguém gosta quando esses sistemas param.

---

Talvez a Pergunta Esteja Errada

A pergunta nunca deveria ser:

"Como saímos do Mainframe?"

A pergunta correta talvez seja:

"Qual workload realmente precisa sair?"

Talvez um portal web de RH possa migrar.

Talvez um batch de impressão possa ser substituído.

Talvez um sistema satélite seja reescrito.

Mas talvez o motor central de compensação bancária deva permanecer exatamente onde está.

Porque engenharia não é religião.

Arquitetura não é ideologia.

Tecnologia não é torcida organizada.

A melhor plataforma é aquela que resolve o problema com menor risco, melhor disponibilidade, maior previsibilidade financeira e retorno sustentável.

---

Considerações Finais

Suspeito que a Gartner não esteja dizendo:

"Nunca migrem."

Também não está afirmando:

"Mainframe venceu."

A mensagem parece muito mais madura.

A IA Generativa será extraordinariamente útil para documentar, explicar, testar, modernizar e integrar aplicações existentes.

Mas ainda estamos distantes de confiar bilhões de dólares em transações financeiras a um modelo estatístico incapaz de compreender por que um velho JOB chamado FINA987 precisa começar precisamente às 02h17 da madrugada.

E talvez seja justamente aí que esteja a maior ironia desta década.

A tecnologia mais avançada da atualidade descobriu que o Mainframe nunca foi apenas COBOL.

Ele sempre foi memória institucional.

Processos.

Pessoas.

Histórias.

E algumas dezenas de milhares de linhas de JCL escritas por um Sysprog que provavelmente continua tendo razão.

https://www.gartner.com/en/newsroom/press-releases/2026-06-18-gartner-predicts-more-than-70-percent-of-mainframe-exit-projects-will-fail-due-to-overestimation-of-generative-ais-capabilities

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.

Bellacosa Mainframe e tenta entender a razao do Cobol nao existir fora do Mainframe

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?

Quando alguém fala em COBOL, a maioria das pessoas imediatamente imagina um enorme IBM Z, salas refrigeradas, bancos, seguradoras e sistemas que movimentam bilhões de dólares por dia.

Mas existe uma curiosidade que poucos conhecem:

O COBOL nunca foi exclusivo do Mainframe.

Durante décadas existiram versões para:

• MS-DOS

• Windows

• Linux

• Unix

• AIX

• HP-UX

• Solaris

• AS/400

• VMS

• até mesmo Raspberry Pi atualmente

Empresas como Micro Focus, Fujitsu, RM/COBOL, Acucobol, GNUCobol e outras investiram milhões tentando popularizar o COBOL fora do universo IBM.

Mesmo assim, quando ouvimos a palavra COBOL em 2026, quase todo mundo associa imediatamente ao Mainframe.

A pergunta é inevitável:

Por que isso aconteceu?

Por que Java virou universal?

Por que C conquistou sistemas operacionais?

Por que Python dominou a automação?

E por que COBOL permaneceu praticamente "preso" ao Mainframe?

A resposta envolve tecnologia, mercado, marketing, história, cultura corporativa e até psicologia.

Pegue seu café.

Hoje vamos mergulhar em uma das maiores curiosidades da história da computação.

---

O MAIOR MITO SOBRE COBOL

Existe uma crença popular:

"COBOL só funciona em Mainframe."

Isso nunca foi verdade.

Desde os anos 70 já existiam compiladores COBOL para minicomputadores.

Nos anos 80 surgiram versões para:

• DOS

• Unix

• VAX/VMS

Nos anos 90:

• Windows

• OS/2

• Linux

Nos anos 2000:

• .NET

• JVM

• Web Services

Tecnicamente falando, o COBOL poderia ter seguido praticamente qualquer caminho.

Mas não seguiu.

---

O PROBLEMA NUNCA FOI A LINGUAGEM

Essa é a primeira coisa que surpreende muita gente.

O COBOL não fracassou fora do Mainframe porque era ruim.

Na verdade ele possuía diversas vantagens.

Extremamente legível

Exemplo:

IF SALDO-CONTA IS GREATER THAN LIMITE-CREDITO
   DISPLAY "LIMITE EXCEDIDO"
END-IF

Até alguém sem conhecimento profundo consegue entender.

---

Excelente para regras de negócio

Bancos adoram COBOL porque ele descreve regras empresariais com clareza.

Por exemplo:

COMPUTE JUROS =
    VALOR * TAXA / 100

Não existe mistério.

---

Forte manipulação de registros

Antes dos bancos relacionais se popularizarem, isso era ouro.

---

Precisão decimal

Enquanto várias linguagens sofriam com arredondamentos, COBOL nasceu para dinheiro.

E dinheiro não aceita erro.

---

O VERDADEIRO PROBLEMA: O COBOL NASCEU PARA NEGÓCIOS

A palavra COBOL significa:

Common Business Oriented Language

Observe:

Não é:

• Common Game Language

• Common Scientific Language

• Common Internet Language

É:

Business.

Negócios.

Empresas.

Contabilidade.

Folha de pagamento.

Seguros.

Finanças.

Faturamento.

Desde o nascimento, ele tinha um propósito extremamente específico.

---

ENQUANTO ISSO, O MUNDO MUDOU

Na década de 1960 isso era perfeito.

Mas nas décadas seguintes surgiram novos mercados.

---

Computação científica

FORTRAN dominou.

---

Sistemas operacionais

C dominou.

---

Inteligência Artificial

LISP dominou inicialmente.

---

Aplicações gráficas

C++

---

Internet

Java

PHP

Perl

JavaScript

---

Ciência de Dados

Python

R

---

O mundo começou a exigir coisas que nunca foram prioridade para o COBOL.

---

O COBOL NÃO FOI FEITO PARA SER "COOL"

Aqui existe um fator psicológico interessantíssimo.

Pense nos heróis da programação:

• Linus Torvalds → C

• Guido van Rossum → Python

• Bjarne Stroustrup → C++

• James Gosling → Java

Agora pense em COBOL.

A maioria das pessoas nem sabe quem foi Grace Hopper.

Grace Hopper ajudou a criar conceitos fundamentais que levariam ao COBOL.

Mas a linguagem nunca foi vendida como algo revolucionário.

Ela foi vendida como algo:

• estável

• corporativo

• burocrático

E isso afasta jovens desenvolvedores.

---

O EFEITO "BANCO"

Imagine dois anúncios.

Linguagem A

"Crie jogos incríveis!"

Linguagem B

"Automatize cálculos atuariais."

Qual parece mais divertida?

Foi exatamente isso que aconteceu.

COBOL ficou associado a:

• bancos

• seguradoras

• governos

• sistemas legados

Enquanto outras linguagens ficaram associadas à inovação.

---

O ERRO DE MARKETING MAIS CARO DA HISTÓRIA

Durante os anos 80 e 90, universidades começaram a ensinar:

• C

• Pascal

• C++

• Java

COBOL desapareceu dos cursos.

A consequência foi devastadora.

Menos estudantes.

Menos projetos.

Menos comunidade.

Menos livros.

Menos ferramentas.

Menos conteúdo.

Menos adoção.

Criou-se um círculo vicioso.

---

O PROBLEMA DAS FERRAMENTAS

Vamos ser honestos.

Nos anos 90 era muito mais divertido programar Visual Basic do que COBOL.

Visual Basic tinha:

• botões

• janelas

• eventos

Você arrastava componentes.

Tudo aparecia na tela.

COBOL continuava focado em:

OPEN INPUT CLIENTES
READ CLIENTES

O apelo visual era praticamente zero.

---

O MUNDO APAIXONOU-SE POR INTERFACES GRÁFICAS

Quando o Windows explodiu, surgiu uma nova geração de desenvolvedores.

Eles queriam construir:

• telas

• jogos

• multimídia

COBOL não era o candidato natural.

---

O MAINFRAME PROTEGEU O COBOL

Aqui está a maior ironia.

O Mainframe foi simultaneamente:

• a maior força do COBOL

• e sua maior prisão

Sem Mainframe talvez COBOL tivesse desaparecido.

Mas graças ao Mainframe ele sobreviveu.

Por outro lado, o sucesso no Mainframe reduziu o incentivo para conquistar outros mercados.

Os bancos já estavam satisfeitos.

Por que mudar?

---

O FATOR ECONÔMICO

Imagine um banco.

Você possui:

• 50 milhões de linhas COBOL

• 40 anos de história

• bilhões movimentados diariamente

Qual decisão é mais segura?

Opção A

Migrar tudo.

Opção B

Continuar usando COBOL.

A resposta é óbvia.

---

O EFEITO "SE ESTÁ FUNCIONANDO, NÃO MEXA"

Poucas linguagens tiveram a sorte de trabalhar em ambientes tão conservadores.

Um sistema bancário precisa:

• estabilidade

• previsibilidade

• auditoria

Não precisa ser moderno.

Precisa funcionar.

E COBOL funciona.

Muito bem.

---

A CHEGADA DA INTERNET

Nos anos 90 surgiu a Web.

Foi uma nova corrida do ouro.

Linguagens correram para conquistar esse território.

• Java

• PHP

• Perl

• ASP

COBOL chegou depois.

Muito depois.

Quando chegou, o mercado já tinha donos.

---

O PROBLEMA DA COMUNIDADE

Uma linguagem vive ou morre pela comunidade.

Python possui:

• milhões de usuários

• milhares de bibliotecas

• eventos globais

Java possui ecossistema gigantesco.

COBOL sempre teve uma comunidade menor.

Extremamente qualificada.

Mas menor.

---

O FATOR OPEN SOURCE

Outro golpe importante.

O movimento Open Source impulsionou:

• Linux

• Python

• PHP

• Perl

COBOL permaneceu muito ligado ao mundo corporativo.

Licenças caras.

Compiladores pagos.

Ferramentas empresariais.

Isso limitou sua expansão.

---

MAS EXISTE COBOL OPEN SOURCE

Hoje existe o fantástico:

GNUCobol

GnuCOBOL Official Project

Ele compila COBOL para C e roda em:

• Linux

• Windows

• macOS

Mostrando que o COBOL continua vivo fora do Mainframe.

---

O COBOL É LENTO?

Outro mito.

Na verdade, muitas implementações COBOL são extremamente rápidas.

Especialmente em processamento transacional.

O problema nunca foi desempenho.

---

O COBOL É ANTIGO DEMAIS?

Também não.

Veja a ironia.

Hoje temos:

• APIs REST

• JSON

• XML

• Kafka

• Containers

• Docker

E o COBOL já conversa com tudo isso.

Inclusive o usuário Bellacosa Mainframe frequentemente explora integrações modernas entre COBOL, JSON, CICS Web Services e z/OS Connect.

O problema não é tecnológico.

É percepção de mercado.

---

O PARADOXO DO SUCESSO

O COBOL sofreu do mesmo problema que o DB2 Mainframe.

Ele ficou tão bom no que fazia que nunca precisou mudar radicalmente.

Enquanto outras linguagens lutavam para sobreviver, o COBOL já tinha conquistado o setor financeiro.

---

O QUE ACONTECERIA SE O COBOL FOSSE CRIADO HOJE?

Imagine uma linguagem com:

• sintaxe legível

• precisão decimal nativa

• foco em regras de negócio

• forte tipagem

• excelente auditoria

Provavelmente seria vendida como:

• FinTech Language

• Banking Language

• Enterprise Language

E talvez fosse considerada revolucionária.

---

O COBOL PERDEU A GUERRA?

Não.

Na verdade, ele venceu uma guerra diferente.

Enquanto milhares de linguagens nasceram e morreram, COBOL continua executando sistemas críticos após mais de seis décadas.

Poucas tecnologias na história conseguiram isso.

---

A VERDADE QUE POUCOS ADMITEM

Quando um programador Python cria um sistema hoje, ninguém sabe se ele existirá daqui a 30 anos.

Quando um programador COBOL cria um sistema bancário, existe uma boa chance de alguém ainda estar executando aquele código décadas depois.

Isso muda completamente a forma de projetar software.

---

A GRANDE LIÇÃO PARA OS PADAWANS

A pergunta correta não é:

"Por que COBOL ficou nichado no Mainframe?"

A pergunta correta é:

"Por que o Mainframe continuou sendo o melhor lugar para executar aquilo que o COBOL foi criado para fazer?"

Porque o COBOL nasceu para resolver problemas empresariais gigantescos.

E o Mainframe continua sendo a plataforma mais eficiente para executar esses processos com:

• confiabilidade

• segurança

• disponibilidade

• escalabilidade

• integridade transacional

O COBOL não ficou preso ao Mainframe.

Na realidade, ele encontrou seu habitat natural.

As versões para DOS, Windows e Linux sempre existiram, continuam existindo e funcionam muito bem.

Mas fora do Mainframe ele precisava competir com centenas de linguagens.

Dentro do Mainframe ele se tornou rei.

E existe uma enorme diferença entre participar de uma competição e dominar um reino.

Mais de 65 anos depois de seu nascimento, o COBOL continua processando salários, aposentadorias, seguros, cartões de crédito, transferências bancárias e operações financeiras que sustentam boa parte da economia mundial.

Poucas linguagens podem dizer isso.

E talvez esse seja o maior paradoxo da computação:

O COBOL não conquistou todas as plataformas porque nunca precisou.

Ele já estava ocupado movendo o mundo. ☕🚀

 

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.

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

Bellacosa Mainframe o cobol nao é o problema

---

☕💣🚨 PADAWAN, O COBOL NÃO É O PROBLEMA! O VERDADEIRO MONSTRO ESTÁ ESCONDIDO DENTRO DO SISTEMA

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

---

A Guerra Contra o COBOL

Existe uma frase que se repete há mais de 30 anos:

"Precisamos eliminar o COBOL."

O curioso é que enquanto essa frase era repetida por consultorias, vendors, CIOs e arquitetos corporativos, o COBOL continuava fazendo aquilo que sempre fez:

• pagando aposentadorias;

• processando cartões;

• calculando seguros;

• movimentando bilhões em transações;

• sustentando governos inteiros.

O COBOL nunca foi o problema.

O problema sempre foi outro:

ninguém mais sabia exatamente o que estava escondido dentro dele.

---

O Dia em Que a Empresa Descobriu Que Ninguém Entendia o Sistema

Imagine um banco.

Ele possui:

• 18 milhões de linhas COBOL;

• 4.000 jobs batch;

• 1.500 copybooks;

• centenas de tabelas DB2;

• regras de negócio escritas desde 1987.

Um consultor chega e diz:

"Vamos converter tudo para Java."

A diretoria aprova.

O projeto custa dezenas de milhões.

Três anos depois...

O sistema agora roda em Java.

E o problema continua exatamente igual.

Porque ninguém entendeu o negócio.

Apenas trocaram a sintaxe.

---

O Efeito "Jobol"

O artigo menciona um termo fantástico:

JOBOL

Java + COBOL

Código Java que continua pensando como COBOL.

Exemplo:

COBOL

IF CLIENTE-ATIVO = 'S'
   COMPUTE DESCONTO = VALOR * 0.10
END-IF

Convertido automaticamente:

if(clienteAtivo.equals("S")){
    desconto = valor * 0.10;
}

Parece moderno.

Mas pergunte:

• Por que 10%?

• Desde quando?

• Existe legislação envolvida?

• Existe exceção?

Ninguém sabe.

A lógica foi transportada.

O conhecimento não.

---

O Easter Egg Mais Perigoso do Mainframe

Todo sistema antigo possui algo parecido.

Um trecho de código aparentemente absurdo:

IF DATA = '31121999'
   MOVE ZERO TO TAXA
END-IF

O programador novo pergunta:

"Quem colocou isso?"

Ninguém sabe.

Remove.

Produção explode.

Meses depois descobrem:

Aquilo corrigia um problema de cálculo criado por uma mudança tributária em 1999.

O código era feio.

Mas carregava uma regra de negócio invisível.

---

O Mainframe Guarda Mais Conhecimento Que os Documentos

Muitas empresas acreditam que possuem documentação.

Não possuem.

Possuem:

• manuais desatualizados;

• diagramas antigos;

• apresentações esquecidas.

O verdadeiro conhecimento está em:

• COBOL;

• PL/I;

• Natural;

• JCL;

• PROC;

• CICS;

• IMS;

• DB2;

• VSAM.

O código virou documentação viva.

---

Laboratório Bellacosa

Descobrindo Conhecimento Escondido

Imagine um programa de cálculo de seguro.

Passo 1

Procure constantes misteriosas.

MOVE 0.732 TO FATOR-AJUSTE

Pergunta:

Por que 0.732?

---

Passo 2

Procure datas mágicas.

IF DATA > '01012015'

Pergunta:

O que aconteceu em 2015?

---

Passo 3

Procure exceções.

IF UF = 'SP'

Pergunta:

Por que somente São Paulo?

---

Passo 4

Converse com usuários antigos.

Muitas vezes eles sabem mais que a documentação.

---

Resultado

Você começa a reconstruir o domínio do negócio.

Exatamente o que o DDD propõe.

---

Domain Driven Design Explicado Para Mainframeiros

Muita gente acha que DDD é moda.

Na verdade, o mainframe fazia DDD sem saber.

---

Exemplo

Sistema de seguros.

Temos:

Domínio

Seguros

Subdomínio

Sinistros

Contexto delimitado

Regulação

Linguagem ubíqua

Termos que o negócio entende:

• apólice;

• prêmio;

• segurado;

• franquia;

• indenização.

---

O Erro Clássico

Código moderno:

processEntity()

Código orientado ao domínio:

aprovarIndenizacao()

Qual transmite melhor o negócio?

---

O Grande Segredo dos Batchs

Existe uma verdade inconveniente.

Muitas regras de negócio não estão nos programas.

Estão na sequência dos jobs.

---

Exemplo:

JOB001 - IMPORTA CLIENTES
JOB002 - CALCULA JUROS
JOB003 - EMITE FATURAS
JOB004 - GERA ARQUIVO BACEN

Troque a ordem.

O banco para.

O fluxo batch também é conhecimento corporativo.

---

O Perigo da Reescrita Total

Todo arquiteto sonha com:

"Vamos reescrever tudo."

Na prática:

Forças

• arquitetura limpa;

• tecnologias novas;

• documentação moderna.

Fraquezas

• altíssimo risco;

• anos de projeto;

• perda de regras escondidas.

Perigos

• divergência de cálculo;

• problemas regulatórios;

• inconsistências financeiras.

---

A Estratégia Que Mais Funciona

O artigo cita o conceito mais inteligente da modernização moderna.

Strangler Fig

A Figueira Estranguladora.

Ela cresce ao redor da árvore antiga.

Até substituí-la.

---

No Mainframe

Fase 1

COBOL continua funcionando.

Fase 2

Criamos APIs.

Fase 3

Novos sistemas consomem APIs.

Fase 4

Partes são substituídas.

Fase 5

O legado diminui gradualmente.

Sem Big Bang.

Sem suicídio corporativo.

---

Raincode: O Que Muita Gente Não Entendeu

Muitos acreditam que Raincode é uma ferramenta de migração.

Na verdade:

É uma ferramenta de sobrevivência.

Ela permite:

• retirar carga do Z;

• migrar gradualmente;

• reduzir custos;

• ganhar tempo.

Mas atenção:

Ela não resolve:

• arquitetura ruim;

• regras escondidas;

• documentação ausente.

---

A Nova Função do Especialista COBOL

Aqui está a maior mudança dos próximos anos.

O programador COBOL deixa de ser:

• mantenedor;

• bombeiro de produção;

• operador de emergência.

E passa a ser:

Arqueólogo Digital

A pessoa capaz de responder:

"Por que o sistema faz isso?"

Essa resposta vale mais que escrever código.

---

Curiosidade Histórica

Muitas regras de negócio existentes hoje foram criadas por programadores que já faleceram ou estão aposentados há décadas.

Mesmo assim:

• seus algoritmos continuam rodando;

• suas decisões continuam afetando clientes;

• suas validações continuam protegendo empresas.

Em alguns casos, o código virou literalmente um patrimônio intelectual da organização.

---

O Verdadeiro Inimigo

Não é COBOL.

Não é JCL.

Não é CICS.

Não é IMS.

Não é DB2.

O verdadeiro inimigo é:

🚨 conhecimento implícito.

Aquilo que ninguém documentou.

Aquilo que ninguém explica.

Aquilo que só existe dentro do código.

---

Conclusão Bellacosa Mainframe

O mercado passou décadas tentando responder à pergunta errada.

Perguntavam:

"Como eliminamos o COBOL?"

Quando deveriam perguntar:

"Como preservamos o conhecimento do negócio?"

Porque uma empresa pode trocar:

• COBOL por Java;

• Java por C#;

• C# por Rust;

• Rust por IA Generativa.

Mas se perder o conhecimento embutido em 40 anos de operação...

não estará modernizando.

Estará apenas reconstruindo um problema antigo com ferramentas novas.

E como todo velho operador sabe:

"Trocar a cor do terminal não muda o que acontece quando você aperta ENTER." ☕💣🚨

 

Bellacosa Mainframe apresenta o ibm bpm

☕💥 IBM BPM: O Reino dos Fluxos, Aprovações e Processos

Ou como um Padawan COBOL descobre que existe um CICS para humanos preencherem formulários

"Se CICS conversa com terminais 3270, IBM BPM conversa com pessoas, departamentos inteiros e regras de negócio espalhadas pelo planeta."

Bellacosa Mainframe

---

Introdução

Uma das maiores descobertas que um desenvolvedor COBOL faz ao sair do mundo Batch, CICS, VSAM e DB2 é perceber que muitas aplicações corporativas não processam apenas dados.

Elas processam algo muito mais complicado.

Elas processam pessoas.

E pessoas são extremamente difíceis de programar.

Arquivos VSAM obedecem.

DB2 obedece.

MQ obedece.

JCL obedece.

Usuários?

Nunca.

Um gerente pode aprovar em cinco minutos.

Outro pode levar três dias.

Compliance pode devolver.

Jurídico pode rejeitar.

Diretoria pode pedir ajustes.

É justamente para organizar esse caos corporativo que surgiu o BPM.

Business Process Management.

Ou simplesmente:

IBM BPM.

---

O que é IBM BPM?

IBM BPM significa:

Business Process Manager.

É uma plataforma destinada à modelagem, execução, monitoramento e automação de processos de negócio.

Pense nele como:

Um CICS para departamentos.

Um JES2 para aprovações.

Um Workflow Engine corporativo.

Um coordenador digital.

---

A origem do BPM

Década de 1980.

Empresas começaram a perceber algo curioso.

Automatizar programas não bastava.

Era preciso automatizar decisões.

Exemplo.

Solicitação de empréstimo.

Analista.

↓

Supervisor.

↓

Compliance.

↓

Diretor.

↓

Liberação.

Antes.

Tudo papel.

Depois.

Email.

Depois.

Workflow.

---

Década de 1990.

Surge o conceito BPM.

Business Process Management.

---

Aquisições importantes da IBM

A IBM percebeu o potencial.

Adquiriu duas empresas importantes.

Lombardi Software

Produto:

Teamworks

Especialidade:

Processos humanos

---

FileNet

Especialidade:

ECM

Documentos

Workflow

Case Management

---

Da união surgiu.

IBM BPM.

---

Primeiros releases

IBM BPM 7.5

2011

---

IBM BPM 8.0

2013

---

IBM BPM 8.5

2014

---

IBM BPM 8.6

2016

---

IBM BPM 8.6 CF

2017-2019

---

Posteriormente evoluiu para:

IBM Business Automation Workflow

BAW

Atualmente é o sucessor.

---

Filosofia

IBM BPM trabalha com:

Processos

Pessoas

Regras

Eventos

Integrações

---

Componentes

Process Designer

Desenha fluxos.

---

Process Center

Repositório.

---

Process Server

Executa.

---

Integration Designer

Integra sistemas.

---

Process Portal

Interface usuário.

---

Como funciona

Exemplo.

Solicitar cartão.

Cliente

↓

Abrir pedido

↓

Gerente

↓

Análise crédito

↓

Compliance

↓

Emitir cartão

↓

Fim

---

Cada etapa.

Pode esperar.

Horas.

Dias.

Semanas.

---

BPMN

IBM BPM usa.

BPMN 2.0

Business Process Model Notation

---

Elementos.

Evento

Tarefa

Gateway

Timer

Mensagem

---

Parece um fluxograma.

Só que muito mais poderoso.

---

Exemplo BPM

Solicitação de férias.

Start

↓

Funcionário

↓

Preencher formulário

↓

Gestor aprova?

Gateway

Sim

RH

Fim

Não

Retorna funcionário

---

Gateway

É praticamente.

Nosso velho losango.

---

COBOL

IF APROVADO='S'

BPM

Gateway.

---

Como um desenvolvedor COBOL deve enxergar IBM BPM

Pense assim.

COBOL

Processa registros.

IBM BPM

Processa pessoas.

---

COBOL

PERFORM

IBM BPM

Human Task

---

COBOL

IF

IBM BPM

Exclusive Gateway

---

COBOL

JCL

IBM BPM

Scheduler

---

COBOL

COMMIT

IBM BPM

Milestone

---

Exemplo integrando Mainframe

Cliente solicita empréstimo.

IBM BPM

↓

API

↓

zOS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

↓

BPM

↓

Gerente

↓

Aprovação

---

Passo a passo

Instalação

Necessário.

Linux

Windows

AIX

---

WebSphere Application Server

---

DB2

Oracle

SQL Server

---

Java

---

Deployment Manager

---

Cluster opcional.

---

Instalação resumida

Instalar WAS

Instalar BPM

Criar Profiles

Criar Deployment Manager

Criar Nodes

Configurar DB

Deploy

Subir ambiente

---

Técnicas importantes

SLA

Prazo.

Exemplo.

24 horas.

---

Escalation

Aprovação atrasou.

Enviar email.

---

Timer

Esperar 2 dias.

---

Human Task

Atividade humana.

---

Integration Service

Consumir API.

---

Coach

Tela Web.

---

Curiosidades

Easter Egg 1

BPM nasceu para substituir muitos workflows em Lotus Notes.

---

Easter Egg 2

Muitos bancos usam BPM apenas para aprovações.

---

Easter Egg 3

Boa parte dos usuários nem sabe que usa BPM.

Só recebem tarefas.

---

Easter Egg 4

O losango do fluxograma continua vivo.

Só ganhou nome novo.

Gateway.

---

Easter Egg 5

Muitos arquitetos IBM brincam:

"CICS fala com terminais."

"BPM fala com pessoas."

---

Vantagens

Excelente visibilidade.

KPIs.

Dashboards.

Auditoria.

SLA.

Escalabilidade.

Integração.

Baixo código.

---

Desvantagens

Curva aprendizado.

Infraestrutura pesada.

Licenciamento.

Dependência WebSphere.

Pode ser excessivo para processos simples.

---

Quando usar

Aprovações.

RH.

Compliance.

Jurídico.

Compras.

Contratos.

Onboarding.

KYC.

LGPD.

Fraude.

---

Quando não usar

Calcular juros.

Ordenar arquivos.

Batch noturno.

DFSORT.

ETL simples.

---

O futuro

IBM BPM praticamente se transformou.

Hoje falamos.

IBM BAW.

Business Automation Workflow.

Integrado com.

RPA.

IA.

OCR.

Watson.

Decision Server.

Process Mining.

---

Conclusão

Para um Padawan COBOL, IBM BPM é uma descoberta curiosa.

Passamos décadas modelando fluxos em papel.

Depois desenhamos fluxogramas.

Depois surgiram UML e BPMN.

E então alguém teve uma ideia brilhante:

"Se conseguimos desenhar processos, por que não executá-los?"

IBM BPM nasceu justamente dessa pergunta.

No mundo Bellacosa Mainframe, a analogia é simples:

• JCL orquestra jobs.

• CICS orquestra telas.

• DB2 orquestra dados.

• MQ orquestra mensagens.

• IBM BPM orquestra pessoas.

E descobrir isso é perceber que o verdadeiro desafio da computação corporativa nunca foi apenas programar máquinas.

Sempre foi organizar seres humanos.