Bellacosa Mainframe e o Gravity do Santander

☕🚀 PADAWAN COBOL, O QUE É O GRAVITY DO SANTANDER?

"Imagine que alguém pegasse décadas de COBOL, CICS, DB2 e Mainframe, colocasse tudo dentro de um foguete espacial e o lançasse rumo à nuvem. Esse foguete atende pelo nome de Gravity."

---

📖 Sinopse

O Gravity é a plataforma tecnológica criada pelo Banco Santander para modernizar seu núcleo bancário (Core Banking).

Não é apenas um software.

Não é apenas uma migração para nuvem.

É uma estratégia completa para permitir que sistemas bancários gigantescos deixem de depender exclusivamente de ambientes tradicionais de mainframe e passem a operar em arquitetura cloud moderna.

O objetivo é simples:

Fazer um banco de 180 milhões de clientes funcionar com a velocidade de uma fintech sem perder a robustez de um mainframe.

---

🏛 História

Durante décadas o Santander construiu seus sistemas bancários sobre tecnologias tradicionais:

• COBOL

• Mainframe IBM

• Bancos relacionais

• Sistemas batch

• Processamento transacional

Essas plataformas eram extremamente confiáveis.

O problema?

O mercado mudou.

Clientes passaram a exigir:

• PIX instantâneo

• Aplicativos móveis

• APIs

• Open Finance

• Integração em tempo real

O modelo tradicional começou a limitar a velocidade de inovação.

Por volta da década de 2010 o Santander iniciou um programa de transformação que culminou no Gravity.

Em 2022 o projeto ganhou notoriedade internacional quando o Google anunciou o uso da tecnologia por trás do Gravity no serviço Dual Run.

Em 2025 o Santander informou que mais de 90% de sua infraestrutura tecnológica já estava em nuvem.

---

Bellacosa Mainframe visuliza o Gravity

🚀 O que é o Gravity?

Pense nele como um:

Tradutor Universal Bancário

Ele permite que aplicações que antes viviam exclusivamente no mainframe possam operar em ambiente cloud.

Sua função principal é:

• Modernizar o Core Banking

• Executar processamento distribuído

• Operar em nuvem

• Facilitar migrações

• Reduzir dependência de hardware especializado

---

Bellacosa Mainframe uma visao geral do gravity

🏦 O que é Core Banking?

Padawan...

Quando você consulta saldo no aplicativo...

Quando faz um PIX...

Quando recebe salário...

Quando solicita empréstimo...

Tudo isso acaba passando pelo Core Banking.

É o coração do banco.

Sem ele:

💀 nada funciona.

---

⚙ Como funciona?

O segredo do Gravity é o conceito chamado:

Dual Run

Imagine duas locomotivas andando lado a lado.

Locomotiva 1

Mainframe

• COBOL

• CICS

• DB2

Locomotiva 2

Cloud

• Microservices

• Containers

• APIs

Durante um período ambas executam simultaneamente.

Os resultados são comparados.

Se tudo bater:

✅ a aplicação pode ser movida para nuvem.

Isso reduz enormemente o risco da migração.

---

🖥 Tecnologias Envolvidas

Embora o Santander não revele todos os detalhes internos, sabe-se que o projeto envolve:

Cloud Computing

• Google Cloud

• Kubernetes

• Containers

APIs

• REST

• Open Banking

DevOps

• CI/CD

• Deploy automatizado

Data

• Processamento distribuído

• Streaming

Engenharia Moderna

• Observabilidade

• Telemetria

• Monitoramento

---

☕ O que acontece com o COBOL?

A pergunta de um milhão de dólares.

Muitos imaginam:

"Migrar para nuvem significa jogar COBOL fora."

Errado.

O próprio Santander declarou que muitos dos profissionais que criaram os sistemas de mainframe há 20 anos participam do Gravity.

Isso revela algo importante:

O conhecimento de negócio continua valendo ouro.

A linguagem muda.

O negócio permanece.

---

🔥 Pontos Fortes

Escalabilidade

Pode crescer rapidamente conforme a demanda.

---

Agilidade

Novas funcionalidades podem ser liberadas em horas.

Antes levavam dias ou semanas.

---

Menor Dependência de Hardware

Não exige expansão física de datacenters.

---

Automação

Reduz atividades operacionais repetitivas.

---

Modernização

Facilita integração com:

• APIs

• Open Finance

• IA

• Aplicativos móveis

---

💣 Pontos Fracos

Complexidade

Migrar um banco não é igual migrar um site.

É extremamente complexo.

---

Custos Elevados

Projetos dessa magnitude custam bilhões.

---

Dependência da Cloud

O banco passa a depender mais dos provedores de nuvem.

---

Escassez de Talentos

Encontrar profissionais que entendam:

• Mainframe

• Cloud

• DevOps

• Negócio bancário

não é simples.

---

🤔 Curiosidades

Curiosidade 1

O Gravity não foi comprado.

Foi desenvolvido pelo próprio Santander.

---

Curiosidade 2

O Google aproveitou conceitos da tecnologia para construir o Dual Run.

---

Curiosidade 3

Poucos bancos do tamanho do Santander tentaram uma transformação tão profunda.

---

Curiosidade 4

O conhecimento dos especialistas de mainframe foi considerado fundamental.

---

Curiosidade 5

Mais de 1 trilhão de operações técnicas por ano deverão ser executadas através da plataforma.

---

🌎 Impacto no Mercado

O Gravity é observado por:

• BBVA

• HSBC

• ING

• Barclays

• Deutsche Bank

• Itaú

• Bradesco

• Banco do Brasil

Todos enfrentam o mesmo desafio:

Como modernizar décadas de sistemas sem parar o banco?

---

👨‍💻 O que muda para o Desenvolvedor COBOL?

Antigamente:

COBOL
 ↓
CICS
 ↓
DB2
 ↓
Produção

Agora:

COBOL
 ↓
API
 ↓
Container
 ↓
Cloud
 ↓
Observabilidade
 ↓
Produção

O desenvolvedor moderno precisa entender:

• APIs

• JSON

• Git

• DevOps

• Cloud

• Segurança

---

⚠ Riscos para a Carreira

Se o profissional pensar:

"Vou aprender apenas COBOL e parar no tempo."

Existe risco.

O mercado quer cada vez mais:

Profissionais Híbridos

• COBOL + Cloud

• COBOL + APIs

• COBOL + Java

• COBOL + Python

• COBOL + DevOps

O especialista puro continua existindo.

Mas o híbrido tende a ser mais valorizado.

---

🎯 Vantagens para o Profissional Mainframe

O Padawan costuma acreditar que:

"Cloud vai matar o Mainframe."

Na prática acontece o contrário.

Quem entende:

• Batch

• Integridade transacional

• Recuperação

• Consistência

• Alta disponibilidade

possui conhecimentos raros que muitos profissionais cloud nunca estudaram.

Por isso diversos arquitetos de transformação digital vieram do mundo mainframe.

---

☕ Resumo Bellacosa Mainframe

Gravity em uma frase

"É a ponte construída pelo Santander para levar décadas de conhecimento em COBOL e Mainframe para a nuvem sem destruir aquilo que fez o banco funcionar durante gerações."

O Padawan precisa aprender?

✅ Sim.

Precisa abandonar COBOL?

❌ Não.

Precisa aprender cloud?

✅ Sim.

O Mainframe vai acabar amanhã?

❌ Não.

O mercado está mudando?

✅ Muito rápido.

Quem será mais valorizado?

🚀 O profissional que souber conversar tanto com o veterano de JCL quanto com o engenheiro de Kubernetes.

Porque o futuro não é COBOL contra Cloud.

O futuro é COBOL + Cloud, e o Gravity talvez seja um dos maiores exemplos dessa convergência já vistos na indústria bancária mundial. ☕🔥🚀🏦💻

Gravity https://www.santander.com/en/press-room/press-releases/2025/06/santander-completes-the-digitalization-of-its-technology-infrastructure-in-spain-with-the-deployment-of-gravity

Gravity Power https://www.jornalintegracao.com/noticia/40336/revista-britanica-the-banker-elege-o-banco-mais-inovador-do-mundo

Inovação https://jornaleconomico.sapo.pt/noticias/santander-escolhido-como-mais-inovador-por-causa-da-plataforma-gravity/

Gravity - https://sapo.pt/artigo/santander-torna-se-o-primeiro-grande-banco-ocidental-a-operar-100-na-cloud-6865c821bf6e672c9d4acb54

Gravity - https://thedigitalbanker.com/santander-passes-key-milestone-in-its-transformation-after-migrating-its-cib-banking-platform-to-the-cloud/

 

Bellacosa Mainframe como pagar dividas tecnicas em mainframe

☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

Existe uma frase muito conhecida no mercado de tecnologia:

"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."

Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.

Mas a verdade é muito mais divertida.

Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.

Toda vez que alguém dizia:

"Depois a gente arruma."

Nascia uma nova parcela.

E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.

Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.

---

O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.

Imagine um programa COBOL.

Você precisa entregar uma alteração urgente.

O correto seria:

• Revisar arquitetura

• Atualizar documentação

• Criar testes

• Refatorar módulos

Mas o prazo é amanhã.

Então alguém faz:

IF CLIENTE = '999999'
    GO TO TRATAMENTO-ESPECIAL.

Entrega.

Produção funciona.

Cliente feliz.

Projeto encerrado.

Mas daqui a dois anos ninguém lembra por que aquele IF existe.

A dívida nasceu.

---

O MAIOR MITO DO MAINFRAME

Muita gente acredita que:

"Código antigo é dívida técnica."

Errado.

Código antigo pode ser excelente.

Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.

Por outro lado, existem programas escritos há seis meses que já nasceram endividados.

A idade do código não importa.

O que importa é:

• Complexidade

• Manutenibilidade

• Clareza

• Testabilidade

• Documentação

---

COMO IDENTIFICAR DÍVIDA TÉCNICA

O primeiro passo é aprender a enxergá-la.

Alguns sintomas clássicos:

Programa que ninguém quer alterar

Quando uma demanda chega e todos falam:

"Tomara que não seja naquele programa..."

Existe dívida.

---

Alteração simples demora dias

Mudança:

Trocar 20 para 25.

Tempo gasto:

3 dias

Existe dívida.

---

Muitos abends

Se o mesmo módulo gera incidentes frequentemente:

• S0C7

• S0C4

• SQLCODE negativos

• Arquivos inconsistentes

Existe dívida.

---

Dependência de especialistas

Quando apenas uma pessoa entende o sistema.

Isso é uma dívida técnica humana.

Extremamente perigosa.

---

A METÁFORA DO CARTÃO DE CRÉDITO

A IBM utiliza uma analogia excelente.

Imagine um cartão.

Você compra algo hoje.

O benefício é imediato.

O pagamento fica para depois.

Dívida técnica funciona igual.

Benefício imediato:

Entreguei no prazo

Pagamento futuro:

Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho

O problema não é usar o cartão.

O problema é esquecer da fatura.

---

COMO MAPEAR A DÍVIDA TÉCNICA

A primeira atividade prática é criar um inventário.

Monte uma planilha contendo:

Sistema	Problema	Impacto	Prioridade
Cadastro	GO TO excessivo	Médio	Média
Cobrança	Sem documentação	Alto	Alta
Faturamento	Alta complexidade	Alto	Alta

Você não consegue corrigir aquilo que não consegue enxergar.

---

MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA

Uma das métricas mais famosas.

Ela mede quantos caminhos lógicos existem em um programa.

Exemplo:

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

Pouca complexidade.

Agora imagine:

IF A
 IF B
  IF C
   IF D

A complexidade explode.

Quanto maior a complexidade:

• Mais difícil testar

• Mais difícil manter

• Maior risco de erro

Regra prática:

Valor	Situação
1 a 10	Boa
11 a 20	Atenção
Acima de 20	Risco

---

MÉTRICA 2 – TEMPO DE MANUTENÇÃO

Métrica simples.

Quanto tempo leva para implementar uma mudança?

Exemplo:

Alteração simples:

4 horas

Virou:

3 dias

A dívida está cobrando juros.

---

MÉTRICA 3 – QUANTIDADE DE INCIDENTES

Monitore:

• Chamados

• Tickets

• Problemas recorrentes

Se determinado programa gera:

20% dos incidentes

Ele deve entrar imediatamente no backlog técnico.

---

MÉTRICA 4 – COBERTURA DE TESTES

Quanto do sistema possui testes?

Exemplo:

10%

Muito arriscado.

80%

Muito saudável.

No mundo COBOL isso pode envolver:

• Unit Test

• Testes automatizados

• Batch Validation

---

MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO

MTTR

Mean Time To Recovery.

Quanto tempo leva para resolver um problema?

Exemplo:

10 minutos

Excelente.

8 horas

Existe forte dívida técnica.

---

A REGRA DOS 20%

Uma prática muito utilizada é reservar:

80% desenvolvimento
20% redução de dívida técnica

Isso impede que a dívida cresça infinitamente.

---

TÉCNICA 1 – REFATORAÇÃO CONTÍNUA

Refatorar significa melhorar sem alterar comportamento.

Exemplo:

Antes:

GO TO ERRO.
GO TO ERRO.
GO TO ERRO.

Depois:

PERFORM TRATA-ERRO.

Mesmo resultado.

Código mais limpo.

---

TÉCNICA 2 – MODULARIZAÇÃO

Programas gigantes são fábricas de dívida.

Já encontrei programas com:

80.000 linhas

Divida responsabilidades.

Crie módulos menores.

Mais simples de entender.

Mais simples de testar.

---

TÉCNICA 3 – DOCUMENTAÇÃO VIVA

Documentação morta é inútil.

Documentação viva é atualizada junto com o sistema.

Documente:

• Fluxos

• Arquivos

• Tabelas

• Regras de negócio

---

TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO

Existe um cemitério escondido em todo sistema.

Trechos como:

IF FLAG = 'X'

Que nunca mais executam.

Remover código morto reduz:

• Complexidade

• Risco

• Tempo de manutenção

---

TÉCNICA 5 – BACKLOG TÉCNICO

Crie um backlog específico.

Exemplo:

Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto

A dívida precisa aparecer oficialmente.

Caso contrário ela nunca será priorizada.

---

FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME

IBM Application Discovery

Mapeia dependências.

Mostra:

• Programas

• Arquivos

• CICS

• DB2

Excelente para arqueologia de sistemas.

---

IBM ADDI

Application Discovery and Delivery Intelligence.

Permite visualizar relacionamentos invisíveis.

Muito útil para sistemas legados.

---

SonarQube

Mesmo para COBOL.

Detecta:

• Complexidade

• Duplicação

• Código suspeito

---

IBM Developer for z/OS

Auxilia:

• Navegação

• Análise

• Refatoração

---

Jira

Controle de backlog técnico.

Muitas empresas utilizam para registrar dívida técnica.

---

EASTER EGG MAINFRAME

Quer descobrir rapidamente onde existe dívida?

Procure:

GO TO
ALTER
NEXT SENTENCE

Ou:

STEP099
STEP100
STEP101

Sem documentação.

Você provavelmente encontrou um sítio arqueológico corporativo.

---

O ERRO MAIS COMUM DOS JUNIORES

Pensar:

"Vou reescrever tudo."

Não.

Esse é o caminho para o desastre.

A melhor estratégia quase sempre é:

Pequenas melhorias contínuas.

Todo dia.

Toda sprint.

Todo projeto.

Toda manutenção.

---

COMO EVOLUIR COMO PROFISSIONAL

Programadores experientes não são aqueles que escrevem mais código.

São aqueles que reduzem complexidade.

Quando você consegue olhar para um sistema e dizer:

"Esse trecho vai gerar problema daqui a dois anos."

Você começou a pensar como arquiteto.

---

O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS

Eles não combatem apenas bugs.

Eles combatem as causas dos bugs.

Essa é a diferença entre apagar incêndios e construir sistemas duradouros.

---

CONCLUSÃO

Dívida técnica não é um defeito.

Ela é uma ferramenta.

Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.

O problema surge quando ninguém controla o saldo.

O programador COBOL júnior que aprender a:

• Identificar dívida

• Medir dívida

• Priorizar dívida

• Reduzir dívida

• Monitorar dívida

Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.

Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.

É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.

 

Bellacosa Mainframe divida tecnica decisões erradas que pagamos até hoje

☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

Existe uma lenda antiga nos CPDs.

Ela diz que, em algum lugar do ambiente de produção, existe um programa COBOL que ninguém entende.

Ninguém sabe quem escreveu.

Ninguém sabe por que funciona.

Ninguém sabe o que acontece se ele parar.

Mas todos sabem de uma coisa:

ninguém tem coragem de mexer nele.

Se você trabalha em Mainframe há algum tempo, provavelmente já encontrou um desses.

Talvez ele tenha 30 mil linhas.

Talvez possua 700 GO TO.

Talvez utilize arquivos VSAM que nem aparecem mais na documentação.

Talvez tenha comentários escritos por alguém que já se aposentou há vinte anos.

E talvez ele continue processando milhões de reais por dia.

Parabéns.

Você acabou de encontrar um dos sintomas mais clássicos da dívida técnica.

---

O QUE É DÍVIDA TÉCNICA?

O termo foi criado por Ward Cunningham.

A ideia é simples.

Você faz uma escolha rápida hoje para ganhar velocidade.

Em troca, aceita que precisará corrigir aquilo futuramente.

É exatamente igual a um empréstimo bancário.

Você recebe um benefício imediato.

Mas depois paga juros.

No software, os juros aparecem na forma de:

• retrabalho;

• manutenção mais lenta;

• defeitos;

• incidentes;

• dificuldade de evolução;

• dependência de especialistas.

O problema é que muitas empresas pegam esse empréstimo todos os dias.

E quase nunca pagam.

---

O DIA EM QUE O SISTEMA COMEÇA A COBRAR JUROS

Imagine um programador COBOL júnior.

Recebe uma demanda urgente.

Precisa incluir um novo código de operação.

O correto seria:

• revisar regras;

• criar módulo reutilizável;

• atualizar documentação;

• executar testes.

Mas o prazo está apertado.

Então ele faz:

IF COD-OPER = '99'
   MOVE 'S' TO FLAG-ESPECIAL
END-IF.

Entrega.

Funciona.

Todos ficam felizes.

Seis meses depois surge:

Operação 98.

Depois 97.

Depois 96.

Quando alguém percebe, existe:

IF COD-OPER = '99'
OR COD-OPER = '98'
OR COD-OPER = '97'
OR COD-OPER = '96'

O programa continua funcionando.

Mas ficou pior.

Essa diferença entre funcionar e ser saudável é onde mora a dívida técnica.

---

COMO IDENTIFICAR DÍVIDA TÉCNICA

Os sinais são sempre parecidos.

1. Programas gigantes

Quando um COBOL possui:

• 10 mil linhas;

• 20 mil linhas;

• 50 mil linhas;

ninguém consegue compreender tudo.

Complexidade gera risco.

---

2. Dependência de uma única pessoa

Quando você ouve:

"Somente o João conhece esse sistema."

Acenda o alerta vermelho.

O João pode tirar férias.

O João pode mudar de empresa.

O João pode se aposentar.

O sistema precisa sobreviver sem heróis.

---

3. Medo de alterar

Se toda mudança gera receio:

"Vamos torcer para não derrubar produção."

Existe dívida técnica.

---

4. Muitas correções

Quando a equipe passa mais tempo corrigindo do que evoluindo.

O sistema está pagando juros elevados.

---

AS PRINCIPAIS MÉTRICAS

Métricas transformam sensação em informação.

Sem métricas ninguém sabe se está melhorando.

---

1. LEAD TIME

Tempo entre solicitação e entrega.

Exemplo:

Pedido feito em:

01/06

Produção:

10/06

Lead Time = 9 dias

Quanto menor melhor.

---

2. CYCLE TIME

Tempo efetivamente gasto desenvolvendo.

Exemplo:

Demanda recebida.

Ficou parada cinco dias.

Desenvolvimento levou dois dias.

Cycle Time = 2 dias.

---

3. CHANGE FAILURE RATE

Percentual de mudanças que causam problemas.

Exemplo:

100 implantações.

10 causaram incidentes.

Taxa:

10%

Quanto menor melhor.

---

4. MTTR

Mean Time To Recovery.

Tempo médio para recuperar produção.

Exemplo:

ABEND às 10h.

Sistema normal às 11h.

MTTR = 1 hora.

---

5. REWORK

Retrabalho.

Mede quanto esforço foi gasto corrigindo erros.

Imagine:

100 horas trabalhadas.

25 horas corrigindo problemas.

Rework:

25%

Muito alto.

---

6. REFATORAÇÃO

Esforço dedicado a melhorar código existente.

Uma equipe saudável normalmente reserva tempo para:

• limpeza;

• reorganização;

• modularização.

---

ENTENDENDO O GRÁFICO DA LINEARB

Imagine:

59% Novo Trabalho

17% Refatoração

24% Retrabalho

Significa:

A cada 100 horas:

59 horas criam valor.

17 horas melhoram qualidade.

24 horas apagam incêndios.

Quase um quarto da energia da equipe foi desperdiçada.

---

COMO REDUZIR DÍVIDA TÉCNICA

Agora chegamos ao ponto mais importante.

---

PASSO 1 — MAPEAR O PROBLEMA

Não tente resolver tudo.

Primeiro descubra:

• quais programas mudam mais;

• quais causam mais incidentes;

• quais possuem maior complexidade.

Faça uma planilha simples.

Programa	Alterações	Incidentes
FIN001	120	15
FIN002	10	0
FIN003	95	12

Comece pelos maiores problemas.

---

PASSO 2 — CRIAR BACKLOG TÉCNICO

Muitas empresas possuem backlog funcional.

Poucas possuem backlog técnico.

Crie itens como:

• remover código morto;

• modularizar rotina;

• eliminar duplicação;

• documentar interfaces.

Essas atividades precisam ser visíveis.

---

PASSO 3 — REFATORAR PEQUENO

Erro clássico:

"Vamos reescrever tudo."

Não faça isso.

Melhore gradualmente.

Hoje:

• extrair um parágrafo.

Amanhã:

• eliminar duplicação.

Depois:

• criar módulo reutilizável.

Pequenas vitórias acumulam grandes resultados.

---

PASSO 4 — DOCUMENTAR

Documentação não precisa ser um livro.

Basta responder:

• o que faz;

• entradas;

• saídas;

• dependências.

Já ajuda enormemente.

---

PASSO 5 — REVISÃO DE CÓDIGO

Mesmo no Mainframe.

Principalmente no Mainframe.

Checklist simples:

✓ Nome adequado

✓ Lógica clara

✓ Tratamento de erro

✓ Performance

✓ Documentação

✓ Testes

---

PASSO 6 — TESTES

O segredo dos sistemas modernos.

Sem testes:

refatorar é perigoso.

Com testes:

refatorar é seguro.

Mesmo em COBOL.

Ferramentas como:

• IBM Debug Tool

• IBM Application Discovery

• IBM ZUnit

• Micro Focus Unit Testing

ajudam muito.

---

PASSO 7 — REDUZIR COMPLEXIDADE

Pergunta mágica:

"Existe uma forma mais simples?"

Sempre existe.

Quanto mais simples:

• menor risco;

• menor manutenção;

• menor custo.

---

FERRAMENTAS ÚTEIS

IBM Application Discovery

Mapeia dependências.

Mostra:

• programas;

• copybooks;

• arquivos;

• fluxos.

Excelente para arqueologia de sistemas.

---

SonarQube

Analisa qualidade.

Detecta:

• duplicação;

• complexidade;

• vulnerabilidades.

---

Git

Mesmo para Mainframe.

Ajuda a controlar mudanças.

---

Jira

Controle de backlog técnico.

---

ServiceNow

Correlação entre incidentes e sistemas.

---

O SEGREDO QUE NINGUÉM CONTA

A maioria das dívidas técnicas não nasce do código.

Nasce da organização.

Promessas irreais.

Prazos impossíveis.

Mudanças constantes.

Prioridades conflitantes.

O código apenas reflete o ambiente em que foi criado.

---

EASTER EGG MAINFRAME

Existe um teste simples.

Abra um programa COBOL.

Role até o final.

Se encontrar:

GO TO FIM-PROGRAMA

não se assuste.

Se encontrar:

GO TO INICIO

fique atento.

Se encontrar:

GO TO PARAGRAFO-XYZ

que chama outro GO TO que chama outro GO TO...

Parabéns.

Você encontrou uma relíquia arqueológica do período Jurássico dos sistemas corporativos.

---

O CAMINHO DE EVOLUÇÃO DO PROGRAMADOR JÚNIOR

Nível 1:

Faz funcionar.

Nível 2:

Faz funcionar corretamente.

Nível 3:

Faz funcionar de forma simples.

Nível 4:

Faz funcionar de forma sustentável.

Nível 5:

Melhora o sistema toda vez que toca nele.

É nesse último estágio que nasce o verdadeiro arquiteto de sistemas.

---

A GRANDE LIÇÃO

O programador iniciante acredita que seu trabalho é escrever código.

O programador experiente descobre que seu trabalho é reduzir complexidade.

Código novo gera valor.

Mas código limpo preserva valor.

A dívida técnica não explode como um ABEND.

Ela cresce silenciosamente.

Linha após linha.

Workaround após workaround.

Correção após correção.

Até o dia em que uma mudança de cinco minutos passa a exigir três semanas.

Nesse momento os juros finalmente chegaram.

E como qualquer empréstimo antigo, quanto mais tempo você esperar para pagar, mais caro ficará.

 

Bellacosa Mainframe CICS e throughput

💣🔥 TPS NÃO É THROUGHPUT — É O SEU “COMMIT FINANCEIRO” PASSANDO NO CICS 🔥💣

Se você entrou numa discussão de arquitetura falando de fila, banco NoSQL e multi-região antes de entender o que é dinheiro sendo movimentado, já começou igual job com JCL errado: vai rodar… mas vai dar abend.

---

⚙️ TPS vs Throughput — visão Bellacosa Mainframe

No mundo raiz (sim, aquele do CICS + DB2 + commit de verdade):

• TPS (Transactions Per Second)
  👉 É o COMMIT EXECUTADO
  👉 É o dinheiro que mudou de dono
  👉 É o ponto sem volta
• Throughput
  👉 É o volume de processamento
  👉 Inclui request, fila, validação, retry
  👉 Muito barulho… nem sempre dinheiro

💥 Tradução brutal:

Throughput é fila cheia.
TPS é saldo alterado com sucesso.

Se você tem:

• 20k req/s entrando
• 3k virando transação

👉 Você NÃO tem um sistema de 20k.
👉 Você tem um sistema de 3k TPS financeiro.

---

🌍 Multi-região — quando o sistema vira “sysplex global sem JES”

Quando você sai de uma região…

Você não escalou.
Você entrou em guerra.

Agora você tem:

• 🌐 Latência: 100–200ms (no mínimo)
• 🔄 Consistência distribuída
• ⚠️ Conflito de escrita
• 🔁 Failover real (não o de slide de PowerPoint)

💣 E aqui vem o ponto que derruba sistema:

TPS deixa de ser capacidade e vira problema de coordenação global.

---

💥 Onde TODO mundo quebra (sem exceção)

1. Consistência forte global

👉 “Vamos manter saldo sincronizado em todas regiões”

Resultado:

• Lock distribuído
• Round-trip global
• TPS despenca mais rápido que job mal indexado

💣 Isso aqui mata performance.

---

2. Dependência síncrona entre regiões

👉 API Brasil → chama EUA → espera resposta

Resultado:

• Cada request carrega latência global
• Você virou refém da pior região

💣 É o equivalente moderno de:

“esperar fita montar pra continuar o batch”

---

3. Hotspot de dados

👉 Conta sendo acessada globalmente

Resultado:

• Contenção
• Locking
• Throughput artificialmente alto… TPS real baixo

💣 Clássico erro de modelagem.

---

☠️ O ERRO RAIZ (o mais perigoso)

“Vamos usar Kafka”
“Vamos usar Cassandra”
“Vamos fazer active-active”

🚫 Errado.

Isso é igual dizer:

“Vamos usar DFSORT” antes de saber o layout do arquivo.

---

🧠 Modelo mental Bellacosa (nível arquiteto de guerra)

Antes de falar de tecnologia, responda:

1. Tipo de operação

• 💰 Financeira crítica?
• 🔁 Pode reprocessar?
• ♻️ É idempotente?

---

2. Consistência

• 🔒 Forte → saldo, ledger
• 📊 Eventual → extrato, notificação

💣 Regra de ouro:

Quanto mais consistência, menor o TPS possível.

---

3. Latência aceitável

• ⚡ 100ms?
• 🕒 500ms?
• 🔁 segundos com retry?

👉 Isso define TUDO.

---

4. Distribuição geográfica

• Usuário local?
• Cross-border?

👉 Se for global, esqueça sonho de consistência forte em tudo.

---

5. Perfil de carga

• 📈 Constante?
• 🚀 Pico violento?

👉 Sistema que aguenta pico não nasce por acidente.

---

🏦 Caso real (estilo “produção sem desculpa”)

Cenário:

• 10k TPS global
• Brasil + México
• Transferência financeira

Estratégia inteligente

👉 Saldo = consistente localmente
👉 Cross-region = assíncrono

Fluxo mental:

• Região BR resolve BR rápido
• Região MX resolve MX rápido
• Entre regiões → evento + reconciliação

---

⚖️ O trade-off que ninguém escapa

Você sempre escolhe entre:

• 🔒 Consistência
• ⚡ Latência
• 🚀 Throughput

💣 Não existe arquitetura perfeita.
Existe arquitetura assumida com responsabilidade.

---

🔥 Conclusão estilo Bellacosa

Sistema financeiro não é sobre tecnologia.

É sobre decisão sob restrição real.

💣 Engenheiro júnior:

“Qual tecnologia usar?”

🔥 Engenheiro sênior:

“Qual risco eu posso aceitar?”

---

☕ Verdade final (nível mainframe raiz)

Se o seu TPS depende de coordenação global síncrona…

👉 você não construiu escala
👉 você construiu um gargalo distribuído

Como Construir um Agente de IA sem Criar Mais um "Chatbot Bonitinho"

 

Bellacosa Mainframe como construir um agente de ia

☕ Um Café no Bellacosa Mainframe

Como Construir um Agente de IA sem Criar Mais um "Chatbot Bonitinho"

O Guia Definitivo para um Programador COBOL Padawan Entender por que um AI Agent se Parece Muito Mais com um Sistema Bancário no IBM Z do que com um ChatGPT

"Os iniciantes acreditam que Inteligência Artificial é escolher o melhor modelo. Os veteranos sabem que o modelo é apenas mais um componente da arquitetura."

Durante muitos anos ouvimos que o Mainframe era um ambiente complexo demais para ser compreendido pelos desenvolvedores modernos. Curiosamente, agora estamos vendo exatamente o caminho inverso.

À medida que os chamados AI Agents começam a dominar as discussões sobre Inteligência Artificial, profissionais vindos do mundo web descobrem que construir um agente realmente confiável é muito mais difícil do que simplesmente conectar um LLM a algumas APIs.

Na verdade, quanto mais sofisticado um agente se torna, mais ele começa a lembrar... um sistema corporativo executando sobre IBM Z.

Sim.

Pode parecer exagero.

Mas não é.

Enquanto muitos imaginam que um agente é apenas um ChatGPT "turbinado", quem trabalhou anos com COBOL, CICS, Db2, MQ, JES2, RACF, WLM e z/OS rapidamente percebe algo curioso:

quase todos os conceitos fundamentais dos AI Agents já existem no Mainframe há décadas.

E isso muda completamente a forma como um Programador COBOL Padawan deve enxergar essa nova revolução.

Pegue sua caneca de café.

Hoje vamos desmontar essa arquitetura peça por peça.

---

O maior erro dos iniciantes

Imagine alguém dizendo:

"Vou construir um banco."

Você pergunta:

— Banco de quê?

Ele responde:

— Ainda não sei.

— Para quem?

— Também não pensei.

— Qual problema resolve?

— Depois vejo.

Parece absurdo.

Mas exatamente isso acontece com inúmeros projetos de IA.

As pessoas começam perguntando:

Qual modelo devo usar?

Quando deveriam perguntar:

Que problema estou resolvendo?

No Mainframe aprendemos isso logo no primeiro projeto COBOL.

Ninguém escreve um programa antes de entender:

• regra de negócio;

• layout dos arquivos;

• usuários;

• volume;

• desempenho;

• segurança;

• auditoria.

IA não muda essa ordem.

---

Passo 1 — O propósito vem antes da inteligência

A primeira caixa do diagrama parece simples:

Define Purpose & Scope

Mas ela provavelmente representa mais da metade do sucesso do projeto.

Imagine um agente para bancos.

Objetivo ruim:

"Responder perguntas sobre contas."

Objetivo excelente:

"Auxiliar operadores de produção na investigação inicial de ABENDs batch relacionados a pagamentos, consultando logs, dumps e documentação interna antes do escalonamento para especialistas."

Perceba a diferença.

Agora sabemos:

• quem usa;

• quando usa;

• quais dados possui;

• quais limitações existem;

• quando deve parar.

No IBM Z chamamos isso de...

levantamento de requisitos.

Nada mudou.

---

O Padawan pensa no modelo.

O Mestre pensa no problema.

Existe uma enorme diferença entre estas duas perguntas.

Pergunta do iniciante

Qual é o melhor LLM?

Pergunta do arquiteto

Qual trabalho preciso executar?

São perguntas completamente diferentes.

Porque diferentes tarefas exigem modelos diferentes.

Algumas precisam velocidade.

Outras precisam enorme contexto.

Outras precisam baixo custo.

Outras precisam excelente raciocínio.

Exatamente como escolher entre:

• COBOL

• PL/I

• Assembler

• Java

• REXX

Nenhuma linguagem vence todas.

---

O cérebro não faz tudo sozinho

Uma das maiores ilusões criadas pelo marketing é imaginar o LLM como uma espécie de cérebro universal.

Na prática ele funciona mais como...

...um excelente analista.

Ele raciocina.

Interpreta.

Planeja.

Mas não faz quase nada sozinho.

Imagine um gerente de banco.

Ele decide.

Mas quem movimenta dinheiro?

Quem consulta saldo?

Quem imprime boleto?

Quem abre chamado?

Quem consulta cliente?

São dezenas de sistemas especializados.

O mesmo acontece com IA.

---

Ferramentas são os CALLs do mundo moderno

Todo COBOL conhece algo parecido.

CALL 'CONSCLI'
CALL 'CALCJURO'
CALL 'ENVIA-MQ'
CALL 'GRAVA-DB2'

O programa principal não faz tudo.

Ele delega.

Nos agentes acontece exatamente igual.

O LLM pensa.

Depois chama ferramentas.

Exemplo:

Consultar clima

↓

Pesquisar banco

↓

Enviar e-mail

↓

Criar ticket

↓

Consultar documentação

↓

Executar SQL

Cada ferramenta representa um pequeno programa especializado.

Na prática...

Estamos reinventando os velhos módulos reutilizáveis.

---

APIs são os novos Program Calls

Na década de 80:

Programa COBOL chamava outro programa COBOL.

Hoje:

O agente chama uma API REST.

A filosofia continua igual.

Existe apenas uma diferença.

Antes:

CALL "PROG001"

Hoje:

POST /consultar_cliente

Mudou o protocolo.

Não mudou a arquitetura.

---

MCP lembra muito um Middleware Corporativo

Uma parte interessante do diagrama apresenta o MCP Server.

Muita gente acha complicado.

Mas para um profissional IBM Z isso lembra imediatamente:

• CICS

• IMS TM

• MQ

• z/OS Connect

• Enterprise Service Bus

O MCP padroniza como ferramentas são descobertas e utilizadas.

É parecido com um catálogo corporativo.

Em vez de ensinar o agente cada integração individualmente...

Criamos uma camada intermediária.

Isso reduz acoplamento.

O Mainframe faz isso há décadas.

---

Memória não significa lembrar tudo

Talvez esta seja a maior confusão existente hoje.

Quando alguém fala:

"O agente possui memória."

Muitos imaginam algo parecido com um cérebro humano.

Não é isso.

Existem vários tipos de memória.

---

Memória de Conversa

Equivale ao contexto atual.

É semelhante ao conteúdo de uma COMMAREA.

Enquanto a transação está ativa...

Ela existe.

Depois desaparece.

---

Memória de Trabalho

É parecida com Working Storage.

Informações temporárias.

Variáveis.

Resultados intermediários.

Estado atual.

Nada permanente.

---

Memória Vetorial

Aqui aparece algo realmente novo.

Imagine uma biblioteca.

Você pergunta:

"Mostre tudo relacionado a VSAM."

O sistema encontra:

• KSDS

• RRDS

• ESDS

• RLS

• IDCAMS

Mesmo sem procurar exatamente essas palavras.

Ele procura significado.

É diferente de um índice Db2.

É mais parecido com associação de ideias.

---

Banco Relacional continua existindo

Muitos imaginam que bancos vetoriais substituirão SQL.

Não vão.

Pergunta:

Qual é o saldo da conta?

Resposta precisa.

SQL.

Pergunta:

Quais documentos falam sobre fraude semelhante?

Resposta aproximada.

Banco vetorial.

Cada tecnologia possui seu espaço.

---

Escolher modelo lembra escolher CPU

Outra caixa interessante é:

Choose LLM.

O Padawan pergunta:

Qual é o melhor?

O veterano responde:

Depende.

Exatamente como escolher processador.

Você não compra um z17 para rodar uma calculadora.

Nem usa um Raspberry Pi para processar milhões de transações financeiras.

Modelos possuem:

• custo

• latência

• contexto

• precisão

• velocidade

Tudo é compromisso.

---

O Prompt virou a nova Especificação Funcional

No início da IA muitos tratavam prompts como frases mágicas.

Hoje sabemos que um bom prompt parece muito mais uma documentação técnica.

Ele define:

Objetivo.

Escopo.

Restrições.

Formato.

Limitações.

Critérios.

Responsabilidades.

Em outras palavras...

É quase uma especificação funcional.

---

Guardrails são o novo RACF

Esta talvez seja minha comparação favorita.

Um agente sem guardrails é parecido com um usuário SPECIAL no RACF.

Pode fazer qualquer coisa.

E isso é perigoso.

Imagine um agente que possa:

Excluir arquivos.

Enviar e-mails.

Mover dinheiro.

Executar comandos.

Sem controle.

Seria um desastre.

Por isso criamos regras.

Assim como RACF protege datasets...

Os guardrails protegem ferramentas.

---

Orquestração lembra o JES2

Muitos pensam que um agente simplesmente responde.

Na prática existe uma enorme infraestrutura por trás.

Primeiro chega a solicitação.

Depois ela é classificada.

Depois o sistema decide quais ferramentas usar.

Depois verifica resultados.

Depois tenta novamente se houver erro.

Depois registra tudo.

Isso lembra muito:

JES2.

Schedulers.

Control-M.

OPC.

TWS.

Fluxos batch.

Mudou o nome.

A ideia continua idêntica.

---

Um agente também faz tratamento de erro

Imagine esta situação.

Ferramenta indisponível.

API fora do ar.

Banco lento.

Resposta inválida.

Timeout.

O que acontece?

Um bom agente precisa decidir.

Tentar novamente?

Trocar ferramenta?

Perguntar ao usuário?

Cancelar?

Escalar para humano?

Quem trabalhou anos corrigindo ABENDs sabe exatamente a importância disso.

---

O verdadeiro segredo está na observabilidade

Pouca gente fala nisso.

Mas empresas não compram IA porque ela responde bonito.

Compram porque conseguem confiar nela.

Para isso precisamos registrar tudo.

Qual modelo respondeu?

Qual prompt?

Quais ferramentas?

Quanto custou?

Quanto demorou?

Quem autorizou?

Quais documentos consultou?

No Mainframe isso lembra:

SMF.

RMF.

SYSLOG.

JESLOG.

Dump.

Trace.

Sem logs...

Não existe produção.

---

Testes nunca terminam

Outra excelente observação do diagrama.

Testing & Evals.

Muitos acreditam que basta testar uma vez.

Mas IA aprende.

Modelos mudam.

Ferramentas mudam.

Documentos mudam.

Usuários mudam.

Logo...

O teste nunca acaba.

É um ciclo permanente.

Muito parecido com:

Teste unitário.

Teste integrado.

Teste de regressão.

Teste de performance.

Teste de produção.

---

O maior erro dos projetos de IA

Hoje vejo centenas de agentes fazendo isto:

Pergunta.

Resposta.

Fim.

Mas empresas reais precisam de muito mais.

Precisam de:

Auditoria.

Segurança.

Escalabilidade.

Versionamento.

Logs.

Controle de acesso.

Custos.

Explicabilidade.

Resiliência.

Recuperação.

Exatamente as características que fizeram o Mainframe sobreviver durante mais de seis décadas.

---

O Mainframe já conhecia quase tudo isso

Observe esta tabela.

Mundo IA	IBM Z
LLM	Programa especialista
Prompt	Especificação funcional
Ferramenta	CALL
API	Programa remoto
MCP	Middleware
Memória	VSAM/Db2/Storage
Orquestração	JES2 / Scheduler
Guardrails	RACF
Observabilidade	SMF/RMF
Logs	SYSLOG
Workflow	Batch
Estado	COMMAREA / Working Storage
Aprovação humana	Operador / Change Management

Curiosamente...

A arquitetura moderna está caminhando para conceitos que o Mainframe já dominava.

---

O verdadeiro diferencial continua sendo Engenharia

Existe uma frase que gosto muito.

"Modelos impressionam. Arquiteturas sobrevivem."

Qualquer pessoa consegue criar um chatbot em poucos minutos.

Criar um agente que opere meses em produção...

É outra história.

Esse agente precisa:

• resistir a erros;

• proteger dados;

• registrar auditoria;

• controlar custos;

• explicar decisões;

• evoluir continuamente.

Isso é Engenharia de Software.

Não Engenharia de Prompt.

---

O Padawan do futuro

Se você programa COBOL hoje, talvez esteja pensando:

"Onde entro nessa história?"

A resposta é:

Em praticamente tudo.

Porque empresas não querem apenas alguém que saiba conversar com um LLM.

Elas precisam de profissionais capazes de integrar IA aos sistemas que realmente movem o negócio.

E esses sistemas continuam sendo, em grande parte, os que executam em plataformas como IBM Z.

O Programador COBOL Padawan que compreender agentes de IA terá uma vantagem rara: enxergará a IA não como um brinquedo de linguagem, mas como mais um componente de uma arquitetura corporativa robusta. Ele saberá que um bom agente precisa de regras de negócio, integração, segurança, persistência, tratamento de erros e observabilidade — exatamente os pilares que sempre sustentaram as aplicações de missão crítica.

---

O Café Terminou, mas a Jornada Está Apenas Começando

Quando observamos um diagrama de "How to Build an AI Agent", é fácil acreditar que tudo se resume a oito caixas conectadas por setas. Porém, a realidade é muito mais rica. Cada uma dessas caixas representa disciplinas inteiras: arquitetura, engenharia de software, segurança, infraestrutura, governança de dados, experiência do usuário e operações.

Para o Programador COBOL Padawan, talvez a maior descoberta seja perceber que a revolução da IA não invalida tudo o que foi aprendido no Mainframe. Pelo contrário: ela confirma que os princípios que mantêm bancos, seguradoras e governos funcionando há décadas continuam válidos. O que muda são as ferramentas; os fundamentos permanecem.

No fim das contas, um agente de IA realmente confiável não nasce do modelo mais poderoso, nem do prompt mais elaborado. Ele nasce de uma arquitetura sólida, de decisões bem fundamentadas e da disciplina de engenharia.

E essa sempre foi a maior lição do IBM Z.

Porque, no Bellacosa Mainframe, aprendemos uma verdade que a indústria de IA está redescobrindo apenas agora: inteligência impressiona nas demonstrações; arquitetura confiável sustenta a produção.

Metodologia Waterfall, o que é, para que serve, virtudes e defeitos

Bellacosa Mainframe apresenta a metodologia waterfall

Metodologia Waterfall: O Modelo Clássico que Ainda Sustenta os Maiores Sistemas do Mundo

Muito antes de termos Scrum, Kanban, DevOps, CI/CD e equipes ágeis entregando software em ciclos rápidos, existia uma metodologia que estabeleceu as bases da engenharia de software moderna: a Metodologia Waterfall, também conhecida como Modelo em Cascata. Criada para organizar projetos complexos de forma previsível e controlada, ela continua sendo amplamente utilizada em setores onde segurança, conformidade, documentação e rastreabilidade são essenciais, como bancos, seguradoras, governos, indústrias, telecomunicações, aeroespacial e, principalmente, no universo dos IBM Mainframes.

O princípio do Waterfall é simples e poderoso: cada fase do projeto deve ser concluída antes do início da próxima. Dessa forma, levantamento de requisitos, análise, projeto, desenvolvimento, testes, implantação e manutenção seguem uma sequência lógica, reduzindo ambiguidades e permitindo um rigoroso controle de qualidade.

Embora muitos considerem o Waterfall ultrapassado diante das metodologias ágeis, a realidade é bem diferente. Bilhões de transações financeiras executadas diariamente em sistemas COBOL, CICS, Db2 e IBM Z continuam sendo desenvolvidas e mantidas utilizando princípios herdados desse modelo. Em ambientes onde uma alteração incorreta pode causar prejuízos milionários, previsibilidade vale mais do que velocidade.

Neste artigo você entenderá o que é a Metodologia Waterfall, como ela surgiu, quais são suas etapas, vantagens, desvantagens, diferenças em relação ao Agile, Scrum e DevOps, quando ela ainda representa a melhor escolha e por que continua sendo um dos pilares da engenharia de software corporativa. Seja você um estudante, desenvolvedor, analista de sistemas ou profissional de Mainframe, conhecer o Waterfall é compreender as origens da disciplina que moldou praticamente toda a indústria de desenvolvimento de software moderna.

Bellacosa Mainframe e a metodologia de desenvolvimento waterfall

Muitas linhas foram escritas, defensores e detratores, propagandistas de outras metodologias, coachs e consultores tentando vender seu peixe, pintando um monstro, atacando uma metodologia, que como tudo na vida, ela tem seus pros e contras.

 

 

Bellacosa Mainframe e o problema do vendor lock-in

☕🚀 PADAWAN, O QUE É VENDOR LOCK-IN?

Imagine que você comprou uma cafeteira que só aceita cápsulas de uma única marca.

Enquanto tudo funciona, parece ótimo. Mas quando você descobre que as cápsulas são caras, difíceis de encontrar ou a empresa muda as regras, trocar de sistema vira um pesadelo.

Isso é Vendor Lock-In.

Definição Simples

Vendor Lock-In (aprisionamento ao fornecedor) é a situação em que uma empresa se torna tão dependente de uma tecnologia, produto ou fornecedor específico que mudar para outro se torna caro, complexo ou praticamente impossível.

Em outras palavras:

"Entrar foi fácil. Sair virou uma missão impossível."

---

Exemplo do Mundo Mainframe

Imagine um sistema COBOL rodando há 30 anos:

• Milhões de linhas de código

• JCLs personalizados

• CICS

• DB2

• RACF

• Ferramentas de monitoramento específicas

Tudo foi construído para funcionar perfeitamente naquele ambiente.

Migrar para outra plataforma exigiria:

• Reescrever aplicações

• Treinar equipes

• Alterar integrações

• Testar tudo novamente

O custo pode chegar a dezenas ou centenas de milhões de dólares.

Resultado?

A empresa fica "presa" ao fornecedor.

---

Exemplos Modernos

Cloud Computing

Uma empresa usa:

• AWS Lambda

• DynamoDB

• SQS

• Step Functions

Quanto mais utiliza serviços exclusivos da AWS, mais difícil fica migrar para:

• Azure

• Google Cloud

• Oracle Cloud

---

Banco de Dados

Aplicação criada usando recursos específicos do Oracle:

• PL/SQL

• Packages

• Procedures proprietárias

Migrar para PostgreSQL pode exigir anos de trabalho.

---

ERP

Uma empresa adota um ERP gigantesco.

Após anos:

• Processos foram customizados

• Integrações foram criadas

• Equipe foi treinada

Trocar de ERP pode ser mais caro que continuar usando o atual.

---

Como o Lock-In Acontece?

1. Tecnologia Proprietária

Somente aquele fornecedor possui a solução.

Exemplo:

• Linguagem exclusiva

• Banco de dados proprietário

• APIs fechadas

---

2. Dados Difíceis de Exportar

Os dados ficam presos.

Você até consegue sair...

Mas não consegue levar tudo junto.

---

3. Alto Custo de Migração

O sistema funciona tão bem que reescrevê-lo custa uma fortuna.

---

4. Falta de Conhecimento

A equipe só conhece aquela tecnologia.

Treinar todos em outra plataforma custa tempo e dinheiro.

---

Vendor Lock-In é Sempre Ruim?

Não.

Muitas vezes ele é uma consequência natural do sucesso.

Se um banco investiu bilhões em uma plataforma que funciona perfeitamente:

• Alta disponibilidade

• Segurança

• Performance

Talvez não faça sentido trocar.

Nesse caso, o lock-in é um risco controlado.

---

Como Reduzir o Vendor Lock-In?

Use Padrões Abertos

• REST

• JSON

• XML

• SQL padrão

---

Evite Recursos Exclusivos

Quanto mais código específico do fornecedor:

Mais difícil será sair depois.

---

Utilize Containers

• Docker

• Kubernetes

Facilitam mover aplicações entre ambientes.

---

Mantenha Documentação

Muitas empresas descobrem que não conseguem migrar porque ninguém sabe mais como o sistema funciona.

---

Curiosidade Histórica

O termo ganhou força nos anos 1980 e 1990, quando empresas começaram a depender fortemente de:

• IBM

• Oracle

• Microsoft

• SAP

Muitas organizações perceberam que o custo para trocar de fornecedor era maior do que o custo inicial da implementação.

---

☕ A Moral para o Padawan COBOL

Vendor Lock-In não significa que uma tecnologia é ruim.

Significa apenas que:

Quanto mais valor você constrói sobre uma plataforma, mais caro fica abandoná-la.

Isso vale para:

• Mainframe

• Cloud

• ERP

• Banco de Dados

• IA

• Ferramentas DevOps

Até mesmo linguagens modernas podem gerar lock-in.

A verdadeira arquitetura corporativa não busca eliminar completamente o Vendor Lock-In — isso é quase impossível. Ela busca entender, medir e controlar o nível de dependência do fornecedor, para que a empresa tenha opções quando precisar mudar de rumo. 🚀☕

Eastereggs

Sim. Embora o vendor lock-in nem sempre seja ruim, existem casos famosos em que a dependência excessiva de um fornecedor gerou enormes prejuízos, atrasos ou até fracassos de projetos.

☕🚀 1. O Caso Oracle e os Sistemas Legados Governamentais

Diversos governos ao redor do mundo construíram aplicações usando:

• Oracle Database

• Oracle Forms

• Oracle Reports

• PL/SQL

Após 15 ou 20 anos, descobriram que:

• Licenças ficaram muito caras

• Profissionais especializados eram raros

• Migração era extremamente complexa

Em alguns casos, o custo da migração ultrapassava o custo de continuar pagando as licenças.

Resultado:

Milhões gastos apenas para manter sistemas antigos funcionando.

---

☕🚀 2. O Drama do VMware após a Broadcom

Em 2023 a Broadcom adquiriu a VMware.

Muitas empresas possuíam:

• milhares de VMs

• automações

• processos

• treinamento

inteiramente dependentes do ecossistema VMware.

Após mudanças de licenciamento, diversas organizações relataram aumentos expressivos nos custos de renovação. Muitas iniciaram projetos emergenciais para migrar para:

• Hyper-V

• Proxmox

• Nutanix

• OpenShift Virtualization

O problema?

Anos de dependência tornaram a saída lenta e cara.

---

☕🚀 3. O Windows Phone

A Microsoft criou um ecossistema próprio.

Desenvolvedores precisavam:

• ferramentas específicas

• APIs específicas

• marketplace próprio

Quando a plataforma fracassou comercialmente:

• milhares de aplicativos perderam valor

• empresas tiveram que reescrever aplicações para Android e iOS

Foi um lock-in que terminou em um beco sem saída.

---

☕🚀 4. Salesforce Excessivamente Customizado

Muitas empresas adotaram Salesforce.

Depois de anos:

• workflows complexos

• Apex

• integrações proprietárias

ficaram profundamente acoplados.

Em alguns casos a organização descobriu que:

Trocar de CRM custaria mais do que continuar pagando o Salesforce.

O fornecedor virou praticamente parte da arquitetura da empresa.

---

☕🚀 5. SAP e os Projetos Bilionários

Existem empresas que investiram centenas de milhões de dólares em customizações SAP.

Anos depois:

• a versão ficou obsoleta

• o fabricante mudou a estratégia

• surgiu a necessidade de migrar para S/4HANA

Muitas organizações enfrentaram projetos enormes de conversão.

Algumas gastaram mais na migração do que no projeto original.

---

☕🚀 6. AWS e o "Cloud Shock"

Na década de 2010 muitas empresas migraram rapidamente para a AWS.

Utilizaram serviços exclusivos como:

• Lambda

• DynamoDB

• Aurora

• Step Functions

Anos depois perceberam que:

• custos cresceram

• negociar preços ficou difícil

• migrar para Azure ou GCP exigiria reescrever aplicações inteiras

Nasceu o movimento chamado:

Cloud Repatriation

Ou seja:

trazer sistemas de volta para datacenters próprios.

---

☕🚀 7. O Fracasso do Google App Engine Original

Nos primeiros anos, o Google App Engine exigia uma arquitetura bastante específica.

Muitas aplicações foram escritas para aquele modelo.

Quando as necessidades cresceram:

• migrar para outras clouds era complicado

• várias empresas reescreveram aplicações inteiras

Foi uma das razões para a popularização dos containers e Kubernetes.

---

☕🚀 8. Lotus Notes

Quem viveu os anos 90 e 2000 conhece.

Muitas empresas criaram:

• workflows

• aplicações

• bases documentais

inteiramente dentro do Lotus Notes.

Quando surgiu a necessidade de migrar:

• milhares de aplicações precisaram ser convertidas

• regras de negócio estavam escondidas nos bancos Notes

Alguns projetos levaram anos.

---

☕🚀 9. Mainframe: O Lock-In Mais Famoso (e Talvez o Mais Justificado)

Muitos executivos enxergam o Mainframe como exemplo clássico de lock-in.

Mas existe um detalhe interessante:

Os bancos normalmente permanecem porque:

• funciona

• é seguro

• é rápido

• processa bilhões de transações

Muitas tentativas de migração fracassaram porque o custo era gigantesco.

Um exemplo famoso foi o esforço de alguns bancos europeus e seguradoras que investiram centenas de milhões de euros em projetos de "saída do mainframe" e acabaram cancelando ou reduzindo o escopo após anos de trabalho.

O lock-in existia.

Mas o valor entregue pelo sistema também.

---

☕🚀 O Caso Mais Trágico: Quando o Fornecedor Morre

Existe algo ainda pior.

Imagine:

• software proprietário

• banco de dados proprietário

• fabricante pequeno

A empresa fecha as portas.

Agora você possui:

• sistema crítico

• sem suporte

• sem código-fonte

• sem atualização

Isso aconteceu inúmeras vezes com ERPs regionais, softwares hospitalares e sistemas industriais.

Nesse momento o vendor lock-in vira um risco existencial.

---

☕ A Grande Lição

O maior prejuízo não ocorre quando você compra uma tecnologia proprietária.

O maior prejuízo ocorre quando você constrói toda a sua estratégia acreditando que nunca precisará sair dela.

Os maiores desastres de TI costumam acontecer quando a organização descobre, tarde demais, que:

"Entrar levou seis meses. Sair levará seis anos e custará dez vezes mais." 🚀☕

EBCDIC: O Código que o Mundo Chama de Legado, Mas que Ainda Move Bilhões de Transações Todos os Dias

 

Bellacosa Mainframe iniciando no EBCDIC e cartão perfurado

☕ Um Café no Bellacosa Mainframe

EBCDIC: O Código que o Mundo Chama de Legado, Mas que Ainda Move Bilhões de Transações Todos os Dias

"Quem ri do EBCDIC normalmente nunca precisou garantir que um banco inteiro fechasse o balanço sem perder um único centavo."

Existe um momento na vida de praticamente todo programador que começa a trabalhar com Mainframe.

Você recebe um arquivo vindo do z/OS.

Abre no Notepad.

E aparece algo parecido com isto:

ÁêØ¢ËÑÇ@@@âÑÄÅ...

A primeira reação costuma ser:

"O arquivo está corrompido."

A segunda:

"Alguém esqueceu de salvar em UTF-8."

A terceira:

"Isso é tecnologia dos dinossauros."

Nenhuma delas está correta.

Na verdade, aquele arquivo está absolutamente perfeito.

O problema é que você está tentando ler um livro escrito em outro alfabeto.

Esse alfabeto chama-se EBCDIC (Extended Binary Coded Decimal Interchange Code).

E, apesar de muita gente tratá-lo como uma curiosidade histórica, ele continua presente nos maiores bancos, seguradoras, governos e companhias aéreas do planeta.

Hoje vamos tomar um café e desmistificar um dos assuntos mais mal compreendidos do universo IBM Z.

---

Bellacosa Mainframe apresenta o ebcdic

O maior mito sobre o EBCDIC

Pergunte para dez desenvolvedores que nunca trabalharam com Mainframe:

"Por que existe EBCDIC?"

As respostas costumam ser parecidas.

"Porque a IBM queria prender os clientes."

É uma boa história.

Mas é falsa.

Quando o EBCDIC nasceu, em 1963, praticamente ninguém utilizava ASCII.

Aliás...

Nem mesmo o ASCII era um padrão consolidado.

Cada fabricante possuía sua própria codificação.

Burroughs.

Honeywell.

CDC.

UNIVAC.

ICL.

Todos tinham soluções próprias.

A IBM simplesmente continuou evoluindo aquilo que ela já utilizava desde os computadores baseados em cartões perfurados.

Não era uma conspiração.

Era evolução tecnológica.

---

O mundo era completamente diferente

Hoje pensamos em computadores conectados pela Internet.

Em 1963...

Não havia Internet.

Não havia Wi-Fi.

Não havia APIs.

Não havia JSON.

Muito menos ChatGPT.

O computador era uma máquina corporativa.

Seu trabalho era processar:

• folhas de pagamento;

• contas bancárias;

• extratos;

• impostos;

• seguros;

• notas fiscais;

• cartões perfurados.

O objetivo não era conversar com outros computadores.

Era processar documentos com absoluta confiabilidade.

Essa diferença muda tudo.

---

ASCII nasceu para conversar

O ASCII descende do Código Baudot, criado para telegrafia.

Imagine um cabo atravessando centenas de quilômetros.

Cada bit enviado custava tempo.

Tempo custava dinheiro.

Por isso o ASCII foi pensado para transmissão serial.

Seu projeto privilegiava simplicidade eletrônica.

Existe uma curiosidade fantástica.

Observe:

A = 65
a = 97

A diferença entre as duas letras é praticamente um único bit.

Isso permitia que um circuito eletrônico transformasse letras maiúsculas em minúsculas simplesmente alterando um sinal elétrico.

Hoje parece detalhe.

Na época era genial.

---

Enquanto isso...

Na IBM...

O problema era outro.

Ela precisava representar cartões perfurados.

E aí entra um personagem quase esquecido da computação moderna.

---

Bellacosa Mainframe e a anatomia de um cartão perfurado

O cartão perfurado

Imagine uma folha de papel rígido.

Ela possui 80 colunas.

Cada coluna representa um caractere.

Cada coluna possui 12 posições possíveis para perfuração.

12
11
0
1
2
3
4
5
6
7
8
9

As três primeiras posições eram chamadas de Zona.

As demais eram os Dígitos.

Para escrever uma letra não bastava perfurar um único lugar.

Era necessário combinar uma zona com um dígito.

Por exemplo:

Zona 12 + Dígito 1 = A

Esse padrão tornou-se tão importante que a IBM decidiu preservá-lo quando criou o System/360.

---

O nascimento do EBCDIC

Em vez de inventar um alfabeto completamente novo...

A IBM fez algo extremamente inteligente.

Ela traduziu a lógica física do cartão diretamente para um byte.

Cada caractere passou a ocupar:

4 bits
+
4 bits

Ou seja:

Nibble superior
↓

Zona

Nibble inferior
↓

Dígito

É por isso que o EBCDIC parece "bagunçado".

Na verdade...

Ele apenas respeita a lógica física do cartão.

---

O famoso buraco entre I e J

Essa é uma das primeiras coisas que um curioso percebe.

No ASCII temos:

ABCDEFGHIJKLMN...

Tudo contínuo.

Já no EBCDIC acontece algo diferente.

As letras ficam divididas em blocos.

A até I

↓

salto

↓

J até R

↓

salto

↓

S até Z

Por quê?

Porque era exatamente assim que funcionava o cartão perfurado.

O que parece estranho hoje fazia todo sentido em 1964.

---

O EBCDIC não é uma tabela.

Ele é uma filosofia.

Essa talvez seja a maior diferença.

ASCII resolve um problema.

Representar caracteres.

O EBCDIC fazia parte de uma arquitetura inteira.

Quando a IBM lançou o System/360 ela criou uma plataforma capaz de durar décadas.

E conseguiu.

Hoje, mais de sessenta anos depois, conceitos daquela arquitetura continuam presentes no IBM Z.

Entre eles:

• canais de I/O;

• processamento batch;

• registros de tamanho fixo;

• decimal compactado;

• formatos de impressão;

• arquivos VSAM;

• e o EBCDIC.

Nada disso surgiu isoladamente.

Tudo fazia parte da mesma visão de engenharia.

---

"Então por que não mudar para UTF-8?"

Essa pergunta aparece em praticamente toda palestra.

A resposta curta é:

Porque não faz sentido.

Imagine um banco.

Ele possui cinquenta anos de software.

Bilhões de linhas em:

• COBOL;

• PL/I;

• Assembler.

Agora imagine alterar a representação interna dos caracteres.

O que precisaria ser testado?

Tudo.

Literalmente tudo.

Comparações.

Ordenações.

Relatórios.

Impressoras.

Interfaces.

Conversões.

Milhões de programas.

Décadas de auditoria.

Bilhões de registros históricos.

O custo seria gigantesco.

O benefício?

Praticamente nenhum.

---

O IBM Z odeia UTF-8?

Muito pelo contrário.

Esse é outro mito.

Hoje o IBM Z executa naturalmente:

• Java;

• Python;

• Node.js;

• Go;

• C/C++;

• OpenJDK;

• OpenSSH;

• Linux on Z;

• Docker;

• Kubernetes;

• APIs REST;

• GraphQL;

• OpenAPI.

Todos utilizando UTF-8.

O segredo está na arquitetura.

As aplicações modernas trabalham em UTF-8.

Os componentes tradicionais continuam utilizando EBCDIC.

Entre eles:

• COBOL;

• CICS;

• IMS;

• DB2;

• arquivos sequenciais.

No meio do caminho existem conversores.

Tudo acontece automaticamente.

Na maioria das vezes o desenvolvedor nem percebe.

---

Um exemplo simples

Imagine um aplicativo no celular.

Cliente

↓

API REST

↓

z/OS Connect

↓

COBOL

↓

DB2

O celular envia UTF-8.

O z/OS Connect converte.

O COBOL recebe EBCDIC.

Na volta acontece exatamente o contrário.

Para quem usa o aplicativo...

Nada muda.

---

Curiosidade nº 1

Existe apenas um EBCDIC?

Não.

Existem centenas.

São chamadas de Code Pages.

Algumas famosas:

• CP037

• CP500

• CP273

• CP1047

• CP1140

Cada uma adapta caracteres para determinados idiomas.

É parecido com as antigas páginas de código do Windows.

---

Curiosidade nº 2

Nem todo problema é "EBCDIC".

Muitas vezes o arquivo já está em EBCDIC.

Mas você está usando a página errada.

É como abrir um texto em português utilizando uma fonte chinesa.

Os bytes continuam corretos.

A interpretação é que muda.

---

Curiosidade nº 3

COBOL também depende do EBCDIC.

Quando você escreve:

IF CLIENTE-A > CLIENTE-B

Ou executa:

SORT

Existe uma sequência de classificação.

Essa sequência depende da codificação utilizada.

No Mainframe ela normalmente segue o EBCDIC.

Isso significa que uma ordenação feita no Windows pode produzir resultados diferentes daquela executada no z/OS.

---

Curiosidade nº 4

No ASCII:

9

↓

A

↓

a

No EBCDIC...

A ordem muda.

Esse pequeno detalhe já causou inúmeros bugs em integrações entre plataformas.

---

Curiosidade nº 5

Você provavelmente usa EBCDIC sem perceber.

Quando um banco expõe uma API REST.

Quando um PIX consulta uma conta.

Quando um cartão de crédito é autorizado.

Quando uma companhia aérea consulta uma reserva.

Quando um caixa eletrônico responde.

Existe uma enorme chance de existir um programa COBOL falando EBCDIC em algum lugar da infraestrutura.

---

Easter Egg para Padawans 🥚

Se você assistir ao filme Apollo 13, verá computadores IBM em operação.

Se visitar museus de computação encontrará cartões perfurados.

Se estudar a arquitetura do System/360 descobrirá que muitas decisões tomadas naquela época continuam influenciando os processadores IBM Z atuais.

É como encontrar fósseis vivos.

Só que ainda processando bilhões de dólares por dia.

---

Outro Easter Egg

O EBCDIC costuma ser chamado de "dinossauro".

Mas existe uma ironia divertida.

Grande parte das aplicações modernas utiliza JSON.

JSON é texto.

Texto precisa de codificação.

Sem um padrão de caracteres...

Nem mesmo APIs modernas existiriam.

No fim das contas...

Todo sistema continua dependendo de um "alfabeto".

A diferença é apenas qual deles.

---

Dicas para quem está começando no Mainframe

Nunca abra arquivos EBCDIC diretamente no Notepad.

Use ferramentas que suportem conversão.

---

Aprenda a diferença entre arquivo texto e arquivo binário.

Nem tudo pode ser convertido.

Campos COMP, COMP-3 e binários jamais devem ser tratados como texto.

---

Conheça sua Code Page.

CP037 não é igual à CP1047.

Esse detalhe salva horas de investigação.

---

Aprenda como funciona FTP ASCII e FTP Binary.

Uma configuração incorreta pode "corromper" um arquivo apenas durante a transferência.

Na verdade, o arquivo original continua íntegro.

---

Não tenha medo do EBCDIC.

Ele parece estranho apenas porque crescemos utilizando ASCII e UTF-8.

Depois de alguns dias convivendo com Mainframe ele se torna completamente natural.

---

O verdadeiro legado do EBCDIC

Existe uma frase famosa na engenharia:

"Se algo funciona perfeitamente há cinquenta anos, talvez exista uma boa razão para não mexer."

O EBCDIC sobreviveu não porque o mercado ficou parado.

Mas porque ele faz parte de uma arquitetura extremamente estável.

Enquanto tecnologias aparecem e desaparecem a cada cinco anos...

O IBM Z continua processando alguns dos sistemas mais críticos do planeta.

Não porque seja antigo.

Mas porque foi projetado para durar.

---

Um Café Antes de Ir...

O programador júnior normalmente olha para o EBCDIC e enxerga um problema.

O desenvolvedor experiente enxerga compatibilidade.

O arquiteto enxerga engenharia.

E o engenheiro de Mainframe enxerga algo ainda maior: uma decisão de projeto que atravessou gerações sem interromper negócios, preservando décadas de investimentos e garantindo que milhões de pessoas possam sacar dinheiro, comprar passagens, pagar contas e realizar transações todos os dias.

Da próxima vez que você abrir um arquivo EBCDIC e encontrar uma "sopa de caracteres", lembre-se: o arquivo não está errado. Apenas está falando a língua nativa de um dos ecossistemas computacionais mais robustos já construídos.

Porque, no fim das contas, o EBCDIC nunca foi um obstáculo ao futuro. Ele sempre foi a ponte silenciosa entre mais de 60 anos de história da computação e o IBM Z que continua sustentando o mundo digital de hoje.

E essa, meu colega Padawan, é uma das maiores lições que o Mainframe pode ensinar: boas arquiteturas envelhecem muito melhor do que modismos tecnológicos. ☕