Translate

Mostrar mensagens com a etiqueta Carreira Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Carreira Mainframe. Mostrar todas as mensagens

terça-feira, 23 de junho de 2026

A Saga de Vagner Bellacosa no Reino dos Mainframes

 



☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe


Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.


O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.


O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.


Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.


O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."


O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.


O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.


Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

sexta-feira, 12 de junho de 2026

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

 

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/








segunda-feira, 1 de junho de 2026

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

 

Bellacosa Mainframe e o monstro da divida tecnica 

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

"O sistema funciona perfeitamente. Só ninguém sabe como."

Se você trabalha com Mainframe há algum tempo, provavelmente já ouviu frases como:

  • "Não mexe nisso que funciona."

  • "Esse programa está em produção há 20 anos."

  • "Só o João sabe alterar esse módulo."

  • "Depois a gente documenta."

  • "Precisamos entregar hoje."

Parabéns.

Você acabou de encontrar alguns dos maiores sintomas de uma das doenças mais comuns da tecnologia moderna:

A Dívida Técnica.

E não, ela não acontece apenas em Java, Python ou aplicações web modernas.

Na verdade, muitos dos maiores casos de dívida técnica do planeta estão rodando neste exato momento em sistemas COBOL responsáveis por bancos, seguradoras, governos, companhias aéreas e bolsas de valores.

Vamos entender o que é, como identificar, controlar e principalmente como sobreviver a ela.


O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida Técnica é o custo futuro gerado quando escolhemos uma solução rápida hoje em vez da melhor solução possível.

Imagine que você recebeu uma demanda urgente.

O gerente aparece correndo:

"Precisamos colocar essa alteração em produção amanhã."

Você sabe que o correto seria:

  • revisar a arquitetura;

  • atualizar documentação;

  • criar casos de teste;

  • revisar impactos;

  • atualizar fluxogramas.

Mas o prazo não permite.

Então você faz um ajuste rápido.

Entrega.

Todo mundo feliz.

Até que seis meses depois alguém precisa alterar novamente aquele trecho.

Agora ninguém entende mais nada.

A dívida venceu.

E os juros começaram a ser cobrados.


A ANALOGIA COM O CARTÃO DE CRÉDITO

A comparação mais famosa é com uma dívida financeira.

Quando você compra algo parcelado:

Você ganha agora.

Mas paga depois.

Na dívida técnica acontece exatamente o mesmo.

Você ganha:

  • velocidade;

  • prazo;

  • entrega rápida.

Mas paga depois com:

  • bugs;

  • retrabalho;

  • manutenção cara;

  • incidentes de produção.

Quanto mais tempo passa, maiores ficam os juros.


O COBOL NÃO CRIA DÍVIDA TÉCNICA

Essa é uma das maiores injustiças da informática.

Muitos dizem:

"Cobol é dívida técnica."

Errado.

COBOL não é dívida técnica.

COBOL mal mantido é dívida técnica.

Existem programas COBOL escritos há 30 anos que continuam:

  • legíveis;

  • documentados;

  • organizados;

  • eficientes.

E existem aplicações modernas escritas há seis meses que já parecem um filme de terror.

A linguagem não é o problema.

A disciplina é.


COMO A DÍVIDA TÉCNICA NASCE

Ela normalmente surge de quatro formas.

1. Pressão por prazo

O caso mais comum.

"Entrega primeiro."

"Arruma depois."

O problema é que o depois quase nunca chega.


2. Falta de documentação

O desenvolvedor conhece tudo.

Então ele pensa:

"Não preciso documentar."

Dois anos depois ele muda de empresa.

Agora ninguém entende o programa.


3. Correções emergenciais

Produção caiu.

Cliente está ligando.

Diretoria está nervosa.

O objetivo vira apenas:

"Faça voltar."

Nesse momento quase ninguém pensa em qualidade.


4. Sistemas legados

Bibliotecas antigas.

COPYBOOKs herdados.

Macros esquecidas.

JCLs copiados durante décadas.

Tudo isso acumula dívida.


EXEMPLO REAL DE DÍVIDA TÉCNICA EM COBOL

Imagine um cálculo de desconto.

Versão original:

IF CLIENTE-VIP
   COMPUTE DESCONTO = VALOR * 0.15
END-IF

Simples.

Legível.

Agora passam dez anos.

Novas regras surgem.

Resultado:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...

Mais tarde:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
ELSE
IF REGIAO = 'S'
...

Depois de centenas de mudanças:

Ninguém sabe mais como o cálculo funciona.

O programa funciona.

Mas ninguém entende.

Isso é dívida técnica.


OS SINTOMAS MAIS PERIGOSOS

Se você encontrar estes sinais, ligue o alerta.

Programas gigantes

Mais de 10.000 linhas.

COPYBOOKs duplicados

A mesma estrutura em vários lugares.

JCLs clonados

Mudam apenas o nome do JOB.

Falta de comentários

Tudo depende da memória dos analistas.

Testes manuais

Ninguém consegue validar rapidamente.

Dependência de uma pessoa

"O Carlos sabe."

Quando você ouve isso, existe dívida técnica.


O EFEITO JUROS COMPOSTOS

Aqui está a parte assustadora.

Dívida técnica cresce de forma parecida com juros compostos.

Um bug gera:

  • remendo;

  • novo remendo;

  • ajuste do remendo;

  • correção da correção.

Depois de alguns anos ninguém consegue alterar sem medo.

O custo explode.


COMO MAPEAR DÍVIDA TÉCNICA

Primeiro passo:

Pare de adivinhar.

Crie um inventário.

Faça uma planilha simples.

Colunas:

  • Sistema

  • Programa

  • Problema

  • Impacto

  • Complexidade

  • Prioridade

Exemplo:

ProgramaProblemaImpacto
COBCLI01Sem documentaçãoAlto
COBFAT0212.000 linhasAlto
COBPAG03Sem testesMédio

Agora a dívida virou algo visível.


MÉTRICAS IMPORTANTES

Um programador júnior deve aprender a medir.

Algumas métricas úteis:

Número de ABENDs

Se cresce continuamente:

há algo errado.


Tempo de correção

Quanto tempo leva para corrigir um incidente?

Quanto maior, maior a dívida.


Quantidade de módulos sem documentação

Métrica simples e poderosa.


Cobertura de testes

Quanto mais baixa, maior o risco.


FERRAMENTAS ÚTEIS NO MAINFRAME

Muitos iniciantes acham que Mainframe não possui ferramentas modernas.

Possui.

E muitas.

IBM Application Discovery

Mapeia dependências.

Excelente para sistemas gigantes.


IBM ADDI

Application Discovery and Delivery Intelligence.

Mostra relacionamentos entre:

  • COBOL

  • JCL

  • DB2

  • CICS


IBM Debug Tool

Ajuda a entender comportamento de programas complexos.


IBM Fault Analyzer

Investiga ABENDs.


IBM File Manager

Analisa arquivos rapidamente.


IBM Dependency Based Build

Automação moderna para pipelines Mainframe.


COMO REDUZIR A DÍVIDA

Agora vem a parte prática.


Passo 1 – Pare de criar dívida nova

Antes de pagar a antiga.

Evite criar mais.

Parece óbvio.

Mas é onde tudo começa.


Passo 2 – Refatore pequenos trechos

Não tente reescrever tudo.

Ataque pequenas áreas.

Exemplo:

  • nomes ruins;

  • IFs excessivos;

  • parágrafos gigantes.


Passo 3 – Documente enquanto aprende

Cada descoberta vira documentação.

Não espere um projeto oficial.


Passo 4 – Automatize testes

Mesmo testes simples ajudam.

Menos medo de alterar.

Mais velocidade.


Passo 5 – Padronize

Defina padrões.

Por exemplo:

  • nomenclatura;

  • comentários;

  • estrutura de programas;

  • organização de COPYBOOKs.


O ERRO MAIS COMUM DOS JUNIORES

Achar que refatorar significa reescrever tudo.

Não.

Refatoração significa melhorar sem alterar comportamento.

Você limpa.

Organiza.

Simplifica.

Sem mudar resultado.


O SEGREDO DOS ANALISTAS SENIORES

Muitos iniciantes acreditam que profissionais experientes sabem tudo.

Não sabem.

A diferença é que eles:

  • documentam mais;

  • investigam melhor;

  • evitam atalhos perigosos;

  • controlam a dívida técnica.

O conhecimento não está apenas no código.

Está na disciplina.


EASTER EGG DOS MAINFRAMEIROS

Se encontrar um comentário parecido com:

* NÃO REMOVER
* FUNCIONA ASSIM DESDE 1994

Você provavelmente encontrou um artefato arqueológico corporativo.

Trate com respeito.

Mas investigue.

Porque muitas vezes ele esconde uma dívida técnica histórica.


A REGRA DOS 5 MINUTOS

Uma dica poderosa.

Se você gastou cinco minutos para entender algo complicado:

documente.

O próximo desenvolvedor agradecerá.

E talvez esse próximo desenvolvedor seja você daqui a seis meses.


COMO EVOLUIR NA CARREIRA ATRAVÉS DA DÍVIDA TÉCNICA

Os melhores profissionais não são os que criam mais código.

São os que reduzem complexidade.

Quando você aprende a:

  • mapear problemas;

  • documentar;

  • simplificar;

  • automatizar;

  • refatorar;

você deixa de ser apenas um programador.

Você passa a ser um engenheiro de software.


CONCLUSÃO

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

Não é um ABEND.

Não é um programa COBOL antigo.

Ela é o resultado de decisões acumuladas ao longo do tempo.

Algumas são necessárias.

Outras são perigosas.

O segredo não é eliminar toda dívida técnica.

Isso é impossível.

O segredo é conhecê-la, monitorá-la e pagá-la antes que ela assuma o controle do sistema.

Porque, no final das contas, o verdadeiro problema não é aquele programa COBOL de 1987.

O problema é ninguém mais entender por que ele ainda funciona.

E quando esse dia chega...

o próximo chamado de produção costuma acontecer às 03:17 da manhã de um domingo.

Aproveite e conheça BACKLOG

https://eljefemidnightlunch.blogspot.com/2025/01/backlog-o-arquivo-secreto-que-separa-um.html

Backlog


quarta-feira, 20 de maio de 2026

🔥☕ Do COBOL ao Arquiteto Enterprise Por Que Engenharia de Software Virou a Skill Mais Importante Para o Programador Mainframe Moderno

 

Bellacosa Mainframe e topicos de engenharia de software para mainframers


🔥☕ Do COBOL ao Arquiteto Enterprise

Por Que Engenharia de Software Virou a Skill Mais Importante Para o Programador Mainframe Moderno

Existe uma frase silenciosa que ecoa dentro dos grandes bancos, seguradoras e sistemas financeiros do planeta:

“O sistema pode até mudar de interface… mas o COBOL continua sustentando o mundo.”

E isso não é exagero.

Enquanto muita gente acredita que o universo enterprise vive apenas de microservices coloridos, containers e frameworks JavaScript da moda… milhões de transações financeiras continuam atravessando silenciosamente ambientes IBM Z, CICS, DB2 e aplicações COBOL gigantescas que nunca podem parar.

Mas algo mudou.

Muito.

O mercado não procura mais apenas:

  • “quem sabe COBOL”

Hoje o mercado procura:

  • engenheiros de software enterprise.

E existe uma diferença brutal entre essas duas coisas.


☕ O Antigo Programador COBOL

Durante décadas, muitos profissionais cresceram no modelo clássico:

  • alterar rotina

  • corrigir bug

  • compilar

  • subir pacote

  • fechar chamado

O foco era:

  • implementação

  • manutenção

  • operação

E isso funcionou por muito tempo.

Mas o mundo enterprise moderno virou um ecossistema absurdamente mais complexo.

Hoje um simples sistema bancário pode envolver:

  • APIs REST

  • aplicações mobile

  • cloud híbrida

  • microsserviços

  • observabilidade

  • CI/CD

  • autenticação distribuída

  • mensageria

  • integração em tempo real

  • analytics

  • IA

E no meio disso tudo…

o COBOL continua lá.

Silencioso.

Processando.

Confiável.


🏗️ O Que é Engenharia de Software de Verdade?

Muita gente acha que engenharia de software é:

  • aprender framework

  • decorar design pattern

  • usar UML

Mas engenharia de software é algo muito maior.

Ela existe para resolver um problema fundamental:

Como construir sistemas gigantes sem criar caos?

Porque sistemas enterprise crescem.

E crescem rápido.

Sem arquitetura:

  • o sistema vira espaguete

  • manutenção explode

  • bugs aumentam

  • deploys quebram produção

  • integração vira pesadelo

A engenharia surge para controlar complexidade.


🧱 Arquitetura Não É Luxo. É Sobrevivência.

O programador júnior normalmente olha para:

  • programas

  • copybooks

  • tabelas

  • jobs

O arquiteto olha para:

  • ecossistemas

  • fluxos

  • dependências

  • escalabilidade

  • disponibilidade

  • integração

Essa mudança de mentalidade é gigantesca.

Um banco não sobrevive décadas apenas porque tem “código”.

Ele sobrevive porque existe:

  • arquitetura

  • organização

  • separação de responsabilidades

  • governança

E curiosamente…

o mundo mainframe sempre fez isso muito antes da cloud existir.


☕ O Mainframe Já Pensava Como Cloud Décadas Atrás

Esse talvez seja um dos maiores segredos da computação enterprise.

Muitos conceitos vendidos hoje como “modernos” já existiam no ecossistema IBM há décadas.

Veja isso:

Mundo ModernoMainframe Enterprise
Alta disponibilidadeSysplex
Load BalancingCICSPlex
APIsz/OS Connect
TransactionsCICS
ObservabilidadeOMEGAMON
Segurança centralizadaRACF
MensageriaMQ

Ou seja…

o IBM Z nunca ficou ultrapassado.

O que aconteceu foi:

  • a interface mudou

  • o marketing mudou

  • o nome mudou

Mas os fundamentos de engenharia continuaram fortíssimos.


⚔️ O Problema do “Só Saber Programar”

Existe um erro muito comum entre iniciantes.

Acreditar que carreira se resume a:

  • linguagem

  • sintaxe

  • framework

Mas linguagens mudam.

Frameworks morrem.

Hypes desaparecem.

O que permanece é:

  • arquitetura

  • modelagem

  • design

  • integração

  • capacidade analítica

É exatamente por isso que engenheiros experientes continuam relevantes por décadas.

Eles entendem sistemas.

Não apenas ferramentas.


🧩 Design Patterns: O Conhecimento Condensado dos Veteranos

Quando um júnior vê:

  • Factory

  • Singleton

  • Observer

  • Strategy

ele normalmente pensa:

“isso parece complicado”

Mas design patterns são apenas soluções repetidas para problemas repetidos.

Eles nasceram porque grandes sistemas começaram a enfrentar:

  • acoplamento

  • manutenção impossível

  • crescimento descontrolado

  • dependências caóticas

Então engenheiros começaram a criar padrões reutilizáveis.

E isso mudou a indústria.

No fundo:

  • design patterns

  • clean code

  • arquitetura em camadas

  • UML

são tentativas humanas de controlar complexidade.


🧠 Clean Code Não É Frescura

Muitos sistemas COBOL antigos sofrem não por causa da idade.

Mas por causa da falta de engenharia.

Código ruim custa:

  • dinheiro

  • tempo

  • performance

  • estabilidade

  • saúde mental

E isso vale para qualquer linguagem.

Um programa COBOL bem escrito pode durar décadas.

Um programa moderno mal escrito pode virar lixo em seis meses.

A diferença está na engenharia.


🌐 O Novo COBOL Está Conectado

Hoje o programador mainframe moderno precisa entender:

  • APIs REST

  • JSON

  • integração

  • cloud híbrida

  • DevOps

  • pipelines

  • observabilidade

Porque o COBOL moderno não vive mais isolado.

Agora ele conversa com:

  • mobile

  • fintechs

  • microsserviços

  • IA

  • analytics

  • cloud pública

O COBOL deixou de ser “backoffice”.

Ele virou parte do ecossistema digital global.


🚀 DevOps Chegou ao IBM Z

Durante muito tempo existiu um mito:

“Mainframe não acompanha DevOps.”

Hoje isso caiu completamente.

O ecossistema IBM já possui:

  • Git

  • CI/CD

  • automação

  • pipelines

  • testes automatizados

  • observabilidade moderna

  • integração cloud-native

Ferramentas como:

  • Zowe

  • Jenkins

  • UrbanCode

  • GitHub

  • OpenShift

aproximaram ainda mais o IBM Z do universo moderno.


☕ O Que o Mercado Espera Agora?

O mercado não procura mais apenas:

  • operador

  • codificador

  • executor de tarefas

Ele procura:

  • solucionadores de problemas

O profissional valioso hoje entende:

  • negócio

  • arquitetura

  • integração

  • confiabilidade

  • escalabilidade

  • comunicação

E aqui existe uma vantagem absurda para quem vem do mainframe.

Porque poucos ambientes ensinam:

  • sistemas críticos

  • alta disponibilidade

  • milhões de transações reais

  • tolerância zero para falhas

O programador COBOL enterprise já nasce perto de problemas gigantes.


🧭 O Roadmap do Programador COBOL Moderno

A evolução natural hoje passa por:

Base

  • COBOL

  • JCL

  • VSAM

  • SDSF

Intermediário

  • DB2

  • CICS

  • SQL

  • MQ

Modernização

  • APIs

  • JSON

  • REST

  • Git

  • DevOps

Engenharia

  • Arquitetura

  • Design Patterns

  • UML

  • Observabilidade

  • Segurança

Próximo nível

  • Cloud híbrida

  • SRE

  • Performance

  • Integração distribuída

  • Engenharia enterprise


🔥 O Grande Erro do Mercado

Enquanto muitos perseguem apenas:

  • hype

  • frameworks

  • modinhas

o mundo enterprise continua valorizando:

  • confiabilidade

  • estabilidade

  • engenharia sólida

E é exatamente aí que o profissional IBM Z moderno pode se tornar raro.

Porque ele entende:

  • legado

  • missão crítica

  • integração

  • arquitetura real


☕ O Futuro Não Está Escolhendo Entre COBOL ou Cloud

O futuro está integrando os dois.

Os sistemas modernos não vão substituir completamente o mainframe.

Eles vão conversar com ele.

Porque no final:

  • o aplicativo pode mudar

  • a interface pode mudar

  • a cloud pode mudar

Mas alguém ainda precisa garantir:

  • consistência

  • transação

  • segurança

  • disponibilidade

E silenciosamente…

o IBM Z continua fazendo isso melhor do que quase qualquer outra plataforma do planeta.


🔥☕ Conclusão Bellacosa Mainframe

O programador COBOL que entender engenharia de software deixará de ser apenas:

  • “o cara do legado”

e começará a se tornar:

  • arquiteto

  • integrador

  • especialista enterprise

  • engenheiro de sistemas críticos

Porque no final…

o verdadeiro diferencial nunca foi apenas a linguagem.

Sempre foi:

entender como sistemas gigantes funcionam.