Translate

segunda-feira, 20 de outubro de 2025

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

Bellacosa Mainframe o cobol nao é o problema



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

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



A Guerra Contra o COBOL

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

"Precisamos eliminar o COBOL."

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

  • pagando aposentadorias;

  • processando cartões;

  • calculando seguros;

  • movimentando bilhões em transações;

  • sustentando governos inteiros.

O COBOL nunca foi o problema.

O problema sempre foi outro:

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


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

Imagine um banco.

Ele possui:

  • 18 milhões de linhas COBOL;

  • 4.000 jobs batch;

  • 1.500 copybooks;

  • centenas de tabelas DB2;

  • regras de negócio escritas desde 1987.

Um consultor chega e diz:

"Vamos converter tudo para Java."

A diretoria aprova.

O projeto custa dezenas de milhões.

Três anos depois...

O sistema agora roda em Java.

E o problema continua exatamente igual.

Porque ninguém entendeu o negócio.

Apenas trocaram a sintaxe.


O Efeito "Jobol"

O artigo menciona um termo fantástico:

JOBOL

Java + COBOL

Código Java que continua pensando como COBOL.

Exemplo:

COBOL

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

Convertido automaticamente:

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

Parece moderno.

Mas pergunte:

  • Por que 10%?

  • Desde quando?

  • Existe legislação envolvida?

  • Existe exceção?

Ninguém sabe.

A lógica foi transportada.

O conhecimento não.


O Easter Egg Mais Perigoso do Mainframe

Todo sistema antigo possui algo parecido.

Um trecho de código aparentemente absurdo:

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

O programador novo pergunta:

"Quem colocou isso?"

Ninguém sabe.

Remove.

Produção explode.

Meses depois descobrem:

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

O código era feio.

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


O Mainframe Guarda Mais Conhecimento Que os Documentos

Muitas empresas acreditam que possuem documentação.

Não possuem.

Possuem:

  • manuais desatualizados;

  • diagramas antigos;

  • apresentações esquecidas.

O verdadeiro conhecimento está em:

  • COBOL;

  • PL/I;

  • Natural;

  • JCL;

  • PROC;

  • CICS;

  • IMS;

  • DB2;

  • VSAM.

O código virou documentação viva.


Laboratório Bellacosa

Descobrindo Conhecimento Escondido

Imagine um programa de cálculo de seguro.

Passo 1

Procure constantes misteriosas.

MOVE 0.732 TO FATOR-AJUSTE

Pergunta:

Por que 0.732?


Passo 2

Procure datas mágicas.

IF DATA > '01012015'

Pergunta:

O que aconteceu em 2015?


Passo 3

Procure exceções.

IF UF = 'SP'

Pergunta:

Por que somente São Paulo?


Passo 4

Converse com usuários antigos.

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


Resultado

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

Exatamente o que o DDD propõe.


Domain Driven Design Explicado Para Mainframeiros

Muita gente acha que DDD é moda.

Na verdade, o mainframe fazia DDD sem saber.


Exemplo

Sistema de seguros.

Temos:

Domínio

Seguros

Subdomínio

Sinistros

Contexto delimitado

Regulação

Linguagem ubíqua

Termos que o negócio entende:

  • apólice;

  • prêmio;

  • segurado;

  • franquia;

  • indenização.


O Erro Clássico

Código moderno:

processEntity()

Código orientado ao domínio:

aprovarIndenizacao()

Qual transmite melhor o negócio?


O Grande Segredo dos Batchs

Existe uma verdade inconveniente.

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

Estão na sequência dos jobs.


Exemplo:

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

Troque a ordem.

O banco para.

O fluxo batch também é conhecimento corporativo.


O Perigo da Reescrita Total

Todo arquiteto sonha com:

"Vamos reescrever tudo."

Na prática:

Forças

  • arquitetura limpa;

  • tecnologias novas;

  • documentação moderna.

Fraquezas

  • altíssimo risco;

  • anos de projeto;

  • perda de regras escondidas.

Perigos

  • divergência de cálculo;

  • problemas regulatórios;

  • inconsistências financeiras.


A Estratégia Que Mais Funciona

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

Strangler Fig

A Figueira Estranguladora.

Ela cresce ao redor da árvore antiga.

Até substituí-la.


No Mainframe

Fase 1

COBOL continua funcionando.

Fase 2

Criamos APIs.

Fase 3

Novos sistemas consomem APIs.

Fase 4

Partes são substituídas.

Fase 5

O legado diminui gradualmente.

Sem Big Bang.

Sem suicídio corporativo.


Raincode: O Que Muita Gente Não Entendeu

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

Na verdade:

É uma ferramenta de sobrevivência.

Ela permite:

  • retirar carga do Z;

  • migrar gradualmente;

  • reduzir custos;

  • ganhar tempo.

Mas atenção:

Ela não resolve:

  • arquitetura ruim;

  • regras escondidas;

  • documentação ausente.


A Nova Função do Especialista COBOL

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

O programador COBOL deixa de ser:

  • mantenedor;

  • bombeiro de produção;

  • operador de emergência.

E passa a ser:

Arqueólogo Digital

A pessoa capaz de responder:

"Por que o sistema faz isso?"

Essa resposta vale mais que escrever código.


Curiosidade Histórica

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

Mesmo assim:

  • seus algoritmos continuam rodando;

  • suas decisões continuam afetando clientes;

  • suas validações continuam protegendo empresas.

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


O Verdadeiro Inimigo

Não é COBOL.

Não é JCL.

Não é CICS.

Não é IMS.

Não é DB2.

O verdadeiro inimigo é:

🚨 conhecimento implícito.

Aquilo que ninguém documentou.

Aquilo que ninguém explica.

Aquilo que só existe dentro do código.


Conclusão Bellacosa Mainframe

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

Perguntavam:

"Como eliminamos o COBOL?"

Quando deveriam perguntar:

"Como preservamos o conhecimento do negócio?"

Porque uma empresa pode trocar:

  • COBOL por Java;

  • Java por C#;

  • C# por Rust;

  • Rust por IA Generativa.

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

não estará modernizando.

Estará apenas reconstruindo um problema antigo com ferramentas novas.

E como todo velho operador sabe:

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

Sem comentários:

Enviar um comentário