 |
| Bellacosa Mainframe apresenta uma viagem ao fundo dos sistemas legados onde o cobol é o protagonista |
☕ Um Café no Bellacosa Mainframe
Voyage to the Bottom of the Legacy System
Quando um Programador COBOL Descobre que as Economias do Mundo Estão Guardadas no Fundo de um Oceano de Código — e Quase Ninguém Ainda Possui o Mapa
Há uma frase que deveria estar impressa na entrada de cada banco, seguradora, fundo de pensão, bolsa de valores e grande instituição financeira do planeta:
“Conheço exatamente cinco pessoas que entendem como as economias do mundo realmente funcionam. Quatro delas estão aposentadas.”
Isso parece uma piada.
Parece exagero de consultor.
Parece uma daquelas frases dramáticas usadas para vender projetos de modernização, inteligência artificial, transformação digital e mais uma tonelada de apresentações em PowerPoint com setas coloridas. Também conhecida por Buzzwords e incentivando o uso de Balas de Prata.
Mas quem já desceu alguns níveis abaixo da interface elegante de um aplicativo bancário sabe que existe algo assustadoramente verdadeiro nessa afirmação.
O dinheiro moderno não repousa em cofres.
Ele repousa em registros.
Os registros repousam em arquivos, tabelas , mensagens, logs, programas e processos.
E boa parte desses processos ainda é executada por sistemas construídos em COBOL, JCL, CICS, IMS, Db2, Adabas, QSAM, VSAM, Assembler, MQ e outras criaturas que vivem nas profundezas do data center.
Para o programador COBOL iniciante, entrar nesse ambiente é como embarcar no submarino Seaview, da série clássica Voyage to the Bottom of the Sea.
Na superfície, tudo parece tranquilo.
O mar está calmo.
Os clientes consultam saldos.
As transferências acontecem.
Os cartões funcionam.
Os investimentos rendem.
As aposentadorias são pagas e nosso velhinhos aposentados felizes saindo das agencias com seu rico dinheiro na algibeira.
Mas, centenas de metros abaixo, existe uma estrutura monumental enfrentando pressão extrema, correntes invisíveis, monstros desconhecidos e compartimentos que ninguém abre desde 1900 e ventania.
E, em algum lugar da sala de máquinas, existe um programa chamado PGMFIN47 que ninguém ousa alterar. Causando tremores, calafrios e insonia na equipe da sustentação e deixando os operadores da produção em alerta vermelho em cada diaria.
Bem-vindo ao fundo do sistema legado.
1. O dinheiro não está no aplicativo
Quando um cliente abre o aplicativo do banco e vê um saldo de R$ 3.457,82, ele imagina que aquele número simplesmente “está lá”.
Mas aquele saldo é o resultado final de uma longa cadeia de decisões (logado e auditado).
Antes de aparecer na tela, ele pode ter passado por:
lançamentos de crédito e débito;
compensação;
reconciliação;
bloqueios;
tarifas;
impostos;
juros;
arredondamentos;
regras contratuais;
limites;
autorizações;
lotes noturnos;
eventos em tempo real;
ajustes manuais;
ordens judiciais;
validações antifraude;
integração com sistemas externos.
O valor exibido é apenas a ponta do periscópio.
Debaixo da água existe uma frota inteira de programas.
Um simples depósito pode ativar:
IF CONTA-ATIVA
IF VALOR-DEPOSITO > ZERO
ADD VALOR-DEPOSITO TO SALDO-CONTA
ELSE
MOVE 'VALOR INVALIDO' TO MENSAGEM-ERRO
END-IF
END-IF
Bonito, simples e didático.
Mas um sistema real dificilmente termina aí.
Talvez a conta esteja bloqueada.
Talvez seja uma conta conjunta.
Talvez o depósito tenha sido realizado após o horário de corte.
Talvez haja incidência tributária.
Talvez exista um limite diário.
Talvez a origem do dinheiro exija análise.
Talvez o cliente esteja sujeito a uma regra antiga preservada por obrigação judicial.
O código começa simples e cresce como o submarino avançando para uma região do oceano onde os mapas ficam cada vez menos confiáveis.
2. O banco não guarda apenas dinheiro: ele guarda regras
Essa é uma das primeiras grandes lições para um programador COBOL iniciante.
Um sistema bancário não é apenas uma calculadora gigante.
Ele é uma máquina de aplicar regras.
Cada produto financeiro contém uma coleção de decisões.
Uma aplicação pode ter:
forma de cálculo;
taxa;
prazo;
carência;
vencimento;
tributação;
liquidez;
arredondamento;
herança;
transferência;
resgate antecipado;
penalidade;
exceção.
Essas regras podem ter origem em:
leis;
contratos;
resoluções;
circulares;
normas internas;
decisões judiciais;
aquisições;
fusões;
migrações;
acordos comerciais;
correções de incidentes antigos.
O programa COBOL é apenas uma das formas pelas quais essas regras foram cristalizadas.
Por isso, uma linha aparentemente estranha pode ser muito mais importante do que parece:
IF DATA-ADESAO < 19940701
PERFORM CALCULO-ANTIGO
ELSE
PERFORM CALCULO-NOVO
END-IF
Um iniciante pode pensar:
“Isso está feio. Vou simplificar.”
Só que a data de 1º de julho de 1994 pode estar relacionada a uma mudança monetária, regulatória, contratual ou operacional.
Remover a condição sem compreender sua origem é como abrir uma escotilha externa do submarino porque ela parece enferrujada.
A escotilha pode estar feia.
Mas talvez esteja impedindo o oceano inteiro de entrar.
3. Código não é a mesma coisa que conhecimento
Um programa pode mostrar o que acontece.
Nem sempre mostra por que acontece.
Considere:
IF WS-TIPO-CLIENTE = '09'
MOVE 0 TO WS-TAXA
END-IF
A sintaxe é fácil.
O comportamento é claro.
Clientes do tipo 09 recebem taxa zero.
Mas por quê?
São funcionários?
São clientes judiciais?
São contas herdadas de outro banco?
São contratos especiais?
São beneficiários de uma legislação?
São contas de teste?
São clientes de uma campanha encerrada há vinte anos?
O código não responde automaticamente.
Esse é o ponto central de toda a discussão.
Existe uma diferença entre:
O que o sistema faz
e
Por que o sistema faz
A primeira pergunta pode ser respondida por análise de código.
A segunda exige contexto histórico, regulatório, comercial e humano.
Muitos projetos fracassam porque tratam essas duas perguntas como se fossem iguais.
4. A tripulação que conhece o fundo do oceano
Em grandes instituições, sempre existem profissionais que parecem possuir um sonar interno.
Eles olham um erro e dizem:
“Isso começou depois da conversão de arquivos de 2003.”
Ou:
“Esse campo não pode ficar em branco porque o sistema de previdência antigo usa espaço como indicador de benefício vitalício.”
Ou ainda:
“Não altere essa ordenação. O arquivo precisa chegar desse jeito porque o processo noturno compara registros por posição, não por chave.”
Esses profissionais não apenas conhecem o código.
Eles conhecem a história.
Eles lembram:
de incidentes;
de migrações;
de auditorias;
de exceções;
de soluções provisórias;
de clientes especiais;
de mudanças regulatórias;
de sistemas desativados que ainda deixam rastros.
Eles são a documentação viva da organização.
O problema é que muitos estão se aposentando.
Quando essas pessoas saem, a instituição não perde apenas mão de obra.
Ela perde contexto.
É como se o capitão do Seaview abandonasse o submarino levando consigo a única carta náutica da região.
Os motores continuam funcionando.
Os painéis continuam acesos.
Mas ninguém sabe exatamente o que existe adiante.
5. Conhecimento explícito e conhecimento tácito
Existem dois tipos principais de conhecimento dentro de uma organização.
Conhecimento explícito
É aquele que pode ser registrado.
Exemplos:
manuais;
diagramas;
wikis;
especificações;
normas;
comentários;
fluxos;
casos de teste;
atas de reunião;
registros de mudança.
Conhecimento tácito
É aquele que vive na experiência das pessoas.
Exemplos:
perceber que determinado erro costuma indicar arquivo incompleto;
saber qual sistema costuma atrasar o processamento;
reconhecer um padrão estranho em um relatório;
lembrar que uma exceção existe por causa de um processo judicial antigo;
saber quem deve ser consultado antes de alterar uma regra.
O conhecimento tácito é poderoso, mas frágil.
Ele não é facilmente pesquisável.
Não aparece em diagramas.
Não pode ser encontrado com CTRL+F.
E desaparece quando a pessoa muda de área, se aposenta ou simplesmente esquece.
O verdadeiro risco dos sistemas legados não está apenas em sua idade.
Está na distância crescente entre o comportamento do sistema e a compreensão humana desse comportamento.
6. O comentário mais perigoso do mainframe
Todo programador COBOL eventualmente encontra um comentário assim:
* NAO ALTERAR
Ou:
* CORRECAO TEMPORARIA
Ou o clássico:
* AJUSTE ESPECIAL
A pergunta imediata deveria ser:
Por quê?
Mas muitas vezes não existe resposta.
A correção temporária foi criada em 1996.
O autor saiu da empresa em 2008.
O sistema que gerava o problema foi desativado em 2014.
Mesmo assim, o código continua lá.
É possível que não seja mais necessário.
Também é possível que seja a única coisa impedindo um desastre.
Esse tipo de situação transforma manutenção em arqueologia.
O programador deixa de ser apenas desenvolvedor.
Ele se torna investigador.
Cada comentário é um fragmento de mapa.
Cada IF é uma pista.
Cada arquivo antigo é uma caixa-preta retirada de um naufrágio.
7. O problema nunca foi simplesmente o COBOL
É comum ouvir:
“O problema é que o sistema está em COBOL.”
Isso é uma simplificação confortável.
COBOL pode ser antigo, mas isso não significa que seja incapaz.
Ele continua sendo eficiente para processamento de grandes volumes de dados, regras de negócio, cálculos financeiros e operações transacionais.
O problema real costuma ser outro:
arquitetura não documentada;
dependências ocultas;
regras espalhadas;
ausência de testes;
falta de rastreabilidade;
conhecimento concentrado;
décadas de mudanças incrementais;
integrações pouco compreendidas.
Reescrever tudo em Java, C#, Python, Go ou qualquer outra linguagem não corrige automaticamente essas falhas.
Você pode transportar uma regra mal compreendida para uma tecnologia moderna e continuar tendo um sistema mal compreendido.
Agora ele terá contêineres, APIs e dashboards coloridos.
Mas continuará sendo um mistério.
É como trocar o casco do submarino sem saber por que alguns compartimentos precisam permanecer isolados.
8. Por que microserviços não são uma boia salva-vidas
Microserviços podem ser excelentes.
Eles ajudam a separar responsabilidades, escalar componentes, melhorar implantações e reduzir acoplamentos.
Mas não resolvem desconhecimento.
Imagine um programa legado com cinquenta regras pouco compreendidas.
A equipe decide dividi-lo em vinte microserviços.
Agora existem vinte componentes carregando regras pouco compreendidas.
Antes, o mistério estava em um programa.
Agora está distribuído pela rede.
Você também ganhou:
APIs;
autenticação;
latência;
filas;
observabilidade;
versionamento;
tolerância a falhas;
consistência distribuída;
retries;
circuit breakers.
Os microserviços não eliminaram o problema.
Eles adicionaram novas camadas ao oceano.
A modernização correta começa por entendimento, não por tecnologia.
9. “Show your work”: mostre como chegou ao resultado
Reguladores e auditores estão cada vez menos satisfeitos com a resposta:
“O sistema sempre funcionou assim.”
Eles querem evidências.
Querem saber:
qual regra foi aplicada;
qual dado foi usado;
quem alterou o programa;
quem aprovou;
qual teste foi executado;
qual requisito justificou a mudança;
qual impacto foi analisado;
como o resultado pode ser reproduzido.
Isso aparece em diferentes regulações, normas e políticas.
A mensagem geral é simples:
Mostre como chegou ao resultado.
Em matemática escolar, não basta escrever a resposta.
É preciso demonstrar o cálculo.
Em sistemas críticos, ocorre o mesmo.
Não basta o programa gerar o valor correto.
É preciso explicar:
o fluxo;
a decisão;
a origem;
a evidência;
a responsabilidade.
Essa exigência afeta tanto sistemas tradicionais quanto soluções com inteligência artificial.
10. O que reguladores estão enxergando
Durante décadas, muitas instituições conviveram com sistemas que funcionavam, mas eram pouco explicáveis.
Enquanto os resultados estavam corretos, o risco parecia aceitável.
Agora isso mudou.
Regulações relacionadas à proteção de dados, resiliência operacional, governança, risco e inteligência artificial aumentaram a pressão por:
transparência;
documentação;
rastreabilidade;
responsabilidade;
explicabilidade;
controle de mudanças;
gestão de terceiros;
continuidade operacional.
Um sistema que ninguém compreende completamente deixa de ser apenas um problema técnico.
Ele se torna um risco de conformidade.
Imagine um cálculo de benefício financeiro contestado por um cliente.
A instituição precisa responder:
Por que esse valor foi calculado?
Qual regra foi aplicada?
Em qual versão do programa?
Com quais dados?
Quem aprovou aquela regra?
Se a única resposta for:
“O senhor Antônio sabia, mas se aposentou há três anos”,
o problema já ultrapassou o departamento de tecnologia.
11. Por que o ChatGPT sozinho não salvará o submarino
Modelos de linguagem podem ajudar muito na análise de código.
Eles podem:
explicar trechos;
resumir programas;
sugerir documentação;
gerar casos de teste;
identificar estruturas;
converter pseudocódigo;
apontar possíveis inconsistências;
criar diagramas conceituais;
auxiliar novos profissionais.
Mas existe um limite essencial.
A IA só pode trabalhar com o contexto disponível.
Se determinada regra não está:
no código;
nos documentos;
nos testes;
nos tickets;
nos manuais;
nos registros;
nas conversas preservadas;
a IA não pode recuperar magicamente sua intenção original.
Ela pode inferir.
Mas inferência não é certeza.
Considere:
IF IDADE-CLIENTE > 65
COMPUTE TAXA = TAXA * 0.75
END-IF
A IA pode dizer:
“O programa aplica desconto de 25% para clientes com mais de 65 anos.”
Isso descreve o comportamento.
Mas não explica:
se é obrigação legal;
se é benefício promocional;
se vale para todos os produtos;
se a idade correta deveria ser 60;
se a regra ainda está vigente;
se existem exceções.
A IA genérica entende a linha.
Não necessariamente entende o mundo que criou a linha.
12. IA genérica versus IA de domínio
Uma IA genérica conhece muitos assuntos.
Uma IA de domínio é construída ou enriquecida para compreender profundamente um contexto específico.
Em um ambiente bancário, uma solução realmente útil precisaria relacionar:
código COBOL;
copybooks;
JCL;
tabelas Db2;
arquivos VSAM;
transações CICS;
mensagens MQ;
normas internas;
legislação;
casos de teste;
tickets;
documentação;
histórico de mudanças;
entrevistas com especialistas.
Não basta alimentar um modelo com um único programa.
É preciso criar uma visão do ecossistema.
Essa abordagem pode envolver:
mecanismos de busca semântica;
catálogos de metadados;
grafos de dependência;
análise estática;
documentação recuperada;
bases vetoriais;
trilhas de auditoria;
validação humana;
controle de acesso.
A IA torna-se um sonar.
Ela ajuda a mapear o oceano.
Mas ainda é necessário um comandante humano para interpretar o que aparece na tela.
13. Passo a passo para compreender um sistema legado
Para o programador COBOL iniciante, a melhor estratégia não é tentar entender tudo de uma vez.
Um sistema crítico precisa ser explorado por camadas.
Passo 1 — Descubra a entrada
Pergunte:
O programa recebe arquivo?
Recebe COMMAREA?
Lê fila MQ?
Usa parâmetros?
Consulta banco?
É chamado por outro programa?
Identifique os dados de entrada.
Passo 2 — Descubra a saída
O programa:
grava arquivo;
atualiza tabela;
retorna código;
envia mensagem;
imprime relatório;
chama outro módulo?
Saber o que entra e o que sai ajuda a delimitar a responsabilidade.
Passo 3 — Mapeie os acessos
Procure:
SELECT;FD;EXEC SQL;EXEC CICS;CALL;LINK;XCTL;READ;WRITE;REWRITE;DELETE.
Esses comandos mostram conexões importantes.
Passo 4 — Identifique regras
Procure decisões:
IF
EVALUATE
PERFORM
COMPUTE
ADD
SUBTRACT
MULTIPLY
DIVIDE
Registre cada regra com linguagem simples.
Exemplo:
“Clientes com adesão anterior a julho de 1994 utilizam cálculo histórico.”
Passo 5 — Procure datas e códigos mágicos
Valores fixos são pistas.
IF WS-CODIGO = 47
Por que 47?
IF WS-DATA < 20010101
O que aconteceu em 2001?
Todo número mágico merece investigação.
Passo 6 — Leia o JCL
O JCL pode explicar mais do que o programa.
Ele mostra:
arquivos;
etapas;
ordenações;
parâmetros;
programas anteriores;
programas posteriores;
condições;
utilitários.
O programa é apenas um compartimento do submarino.
O JCL mostra a rota da missão.
Passo 7 — Converse com especialistas
Pergunte:
Que problema esse processo resolve?
O que acontece se ele falhar?
Quais clientes são afetados?
Quais exceções existem?
Que parte ninguém deve alterar?
Qual incidente antigo explica essa regra?
Grave ou documente as respostas de forma autorizada e organizada.
Passo 8 — Crie testes de caracterização
Antes de alterar o sistema, registre seu comportamento atual.
Forneça entradas conhecidas.
Capture saídas.
Esses testes funcionam como fotografias do sistema antes da reforma.
Passo 9 — Valide com o negócio
Não confie apenas na interpretação técnica.
Uma regra pode estar implementada de determinada forma e ainda assim não refletir a política atual.
A área de negócio precisa validar.
Passo 10 — Documente enquanto aprende
Não deixe para o final.
O final nunca chega.
Documente:
fluxo;
regras;
dependências;
dúvidas;
exceções;
responsáveis;
fontes;
testes.
14. Um mapa mínimo para cada programa
Todo programa importante deveria possuir uma ficha simples:
Identificação
Nome do programa;
sistema;
módulo;
responsável;
criticidade.
Objetivo
Uma frase clara:
“Calcula o valor líquido de resgate de contratos de previdência.”
Entradas
arquivos;
tabelas;
parâmetros;
mensagens;
chamadas.
Saídas
tabelas atualizadas;
arquivos gerados;
códigos de retorno;
mensagens.
Regras principais
Uma lista de regras de negócio compreensíveis.
Dependências
programas chamados;
transações;
filas;
bancos;
jobs.
Exceções
Casos especiais e históricos.
Evidências
documentos;
tickets;
legislação;
testes;
entrevistas.
Riscos
O que pode acontecer se houver alteração incorreta.
Essa ficha não precisa começar perfeita.
Ela precisa começar.
15. Testes são caixas-pretas de sobrevivência
Em sistemas pouco documentados, testes automatizados são fundamentais.
Um teste de caracterização não pergunta inicialmente se o comportamento está certo.
Ele registra o que o sistema faz hoje.
Exemplo:
Entrada:
IDADE = 67
SALDO = 10000
TIPO = 09
Saída atual:
TAXA = 0
VALOR-LIQUIDO = 10000
Mesmo que você ainda não saiba por que o tipo 09 recebe taxa zero, agora existe uma evidência do comportamento.
Depois, especialistas e analistas podem decidir se a regra deve continuar.
Sem testes, cada mudança é uma descida em águas desconhecidas.
Com testes, pelo menos existem boias marcando o caminho de volta.
16. O perigo da reescrita heroica
Existe um tipo de projeto que aparece ciclicamente:
“Vamos reescrever tudo.”
A proposta parece corajosa.
A equipe escolhe uma tecnologia moderna.
Cria uma nova arquitetura.
Desenha diagramas.
Depois começa a descobrir que o sistema antigo possui milhares de regras não documentadas.
A reescrita passa a exigir decisões sobre comportamentos que ninguém consegue explicar.
O novo sistema pode ficar mais bonito, mas incompleto.
Reescrever sem compreender é como construir outro submarino usando fotografias externas do antigo.
Você copia o formato.
Mas não entende os sistemas internos que o mantinham vivo sob pressão.
17. Estratégias de modernização mais seguras
Modernização não precisa significar destruição total.
Existem abordagens graduais.
Encapsular
Expor funções existentes por APIs sem reescrever imediatamente a lógica.
Refatorar
Melhorar a estrutura interna preservando o comportamento.
Extrair regras
Separar regras de negócio de partes técnicas.
Substituir por etapas
Migrar componentes de menor risco primeiro.
Manter onde faz sentido
Nem tudo precisa ser reescrito.
Um programa estável, eficiente, bem testado e compreendido pode continuar cumprindo sua função.
Criar observabilidade
Adicionar logs, métricas, rastreamento e evidências.
Preservar conhecimento
Transformar entrevistas, código, documentação e testes em uma base pesquisável.
A modernização madura pergunta:
“Qual problema precisamos resolver?”
A modernização imatura pergunta:
“Qual tecnologia está na moda?”
18. Curiosidades das profundezas do legado
Curiosidade 1 — Muitos sistemas antigos são extremamente rápidos
Programas batch bem construídos conseguem processar volumes gigantescos com eficiência impressionante.
Curiosidade 2 — O código antigo pode estar correto há décadas
Antigo não significa defeituoso.
Às vezes, o código permaneceu porque funciona.
Curiosidade 3 — A regra mais estranha pode ser a mais importante
Exceções esquisitas frequentemente revelam contratos, leis ou incidentes históricos.
Curiosidade 4 — O melhor documento pode estar no JCL
A sequência de steps mostra como o negócio realmente é processado.
Curiosidade 5 — Arquivos de teste antigos são tesouros
Eles revelam cenários, combinações e resultados esperados.
Curiosidade 6 — O nome do programa pode enganar
CALCJURO talvez calcule imposto, tarifa, comissão e arredondamento além de juros.
Curiosidade 7 — O sistema real ultrapassa o código
Parte da lógica pode estar em:
parâmetros;
tabelas;
procedimentos;
agendamentos;
configurações;
arquivos;
rotinas operacionais.
19. Dicas para o programador COBOL padawan
Não tenha vergonha de perguntar
O sistema pode ser mais velho do que sua carreira.
Ninguém espera compreensão instantânea.
Evite assumir
Confirme.
O nome de um campo nem sempre reflete seu uso atual.
Não altere números mágicos sem investigar
Datas, códigos e percentuais fixos quase sempre possuem uma história.
Leia os dados
Um copybook pode revelar mais do domínio do que várias páginas de documentação.
Aprenda o negócio
O melhor programador de sistemas financeiros não é apenas quem domina PERFORM.
É quem entende:
contrato;
saldo;
juros;
imposto;
compensação;
liquidação;
risco;
exceção.
Crie diagramas simples
Não espere uma arquitetura perfeita.
Comece com:
Arquivo → Job → Programa → Db2 → Relatório
Depois aprofunde.
Registre dúvidas
Uma dúvida esquecida vira um problema futuro.
Preserve a voz dos veteranos
Entrevistas estruturadas podem recuperar histórias que nunca foram escritas.
Não confunda confiança com certeza
Um sistema pode parecer simples porque você ainda não descobriu suas exceções.
20. Easter eggs do Bellacosa Mainframe
Todo grande sistema legado possui seus easter eggs.
Não necessariamente piadas escondidas, mas pequenos sinais de sua história.
Pode ser:
um campo com nome de projeto extinto;
uma data que marca uma mudança econômica;
um código de retorno que ninguém mais usa;
um comentário com iniciais de um programador;
uma condição criada para um único cliente;
uma rotina chamada
FINAL-FINAL;um programa chamado
NOVOcriado em 1989;uma variável chamada
TEMPusada há trinta anos.
E existe o easter egg supremo:
* RETIRAR DEPOIS DA MIGRACAO
A migração ocorreu em 1997.
A linha continua em produção.
Ao encontrá-la, o programador iniciante deve resistir à tentação de apagar.
Primeiro investigue.
Talvez seja apenas um fóssil.
Talvez seja a coluna estrutural secreta do submarino.
21. A inteligência artificial como novo sonar
Usada corretamente, a IA pode acelerar enormemente o trabalho de compreensão.
Ela pode ajudar a:
resumir programas;
explicar parágrafos;
sugerir nomes melhores;
encontrar padrões repetidos;
correlacionar copybooks;
gerar perguntas para especialistas;
criar documentação inicial;
propor testes;
identificar regras candidatas;
montar mapas de chamadas.
Mas o fluxo seguro é:
A IA analisa.
O especialista revisa.
O negócio valida.
O teste comprova.
A documentação registra.
A governança aprova.
A IA não deve ser tratada como oráculo.
Ela é um instrumento de navegação.
Um sonar pode indicar uma grande massa à frente.
Mas cabe à tripulação decidir se é uma montanha submarina, um navio naufragado ou um monstro marinho de um episódio de 1966.
22. Onde estamos indo
O futuro não será simplesmente “COBOL versus IA”.
Nem “mainframe versus cloud”.
Nem “monólito versus microserviços”.
O futuro mais provável será híbrido.
Sistemas críticos continuarão executando regras maduras.
APIs facilitarão integração.
Cloud fornecerá elasticidade e novos serviços.
IA ajudará na compreensão.
Grafos mapearão dependências.
Testes automatizados protegerão comportamentos.
Documentação viva conectará código, regra, requisito e evidência.
O objetivo não é apagar o passado.
É tornar o passado compreensível.
Porque somente aquilo que pode ser compreendido pode ser modernizado com segurança.
23. O verdadeiro risco sistêmico
Falamos muito sobre:
ataques;
falhas de hardware;
indisponibilidade;
fraude;
ransomware;
bugs;
desastres naturais.
Mas existe um risco mais silencioso:
A organização continuar operando sistemas que ninguém consegue explicar.
Esse risco cresce lentamente.
Primeiro sai um especialista.
Depois outro.
A documentação envelhece.
As equipes mudam.
Os fornecedores trocam.
As tecnologias são empilhadas.
Até que, um dia, ocorre um incidente.
E todos percebem que o sistema ainda funciona, mas a instituição já não sabe completamente por quê.
Esse é o verdadeiro Voyage to the Bottom of the Legacy System.
A descida não é em direção ao fundo do mar.
É em direção às camadas de decisões acumuladas por décadas.
Conclusão: não desligue os motores antes de encontrar o mapa
O maior patrimônio de um banco não está apenas em seus cofres, prédios, servidores ou aplicações.
Está no conhecimento que conecta tudo isso.
COBOL não é apenas uma linguagem antiga.
Em muitos ambientes, ele é o idioma em que décadas de decisões financeiras foram registradas.
O perigo não é o código ser velho.
O perigo é ninguém mais conseguir explicar suas escolhas.
Para o programador iniciante, a missão não é apenas aprender PIC, MOVE, PERFORM, EVALUATE e EXEC SQL.
A missão é aprender a fazer perguntas.
Por que essa regra existe?
De onde vem esse valor?
Quem depende desse processamento?
Qual documento comprova esse comportamento?
O que acontece se eu alterar?
Que parte do negócio este código representa?
No fundo do oceano, coragem sem mapa é imprudência.
No fundo do sistema legado, modernização sem compreensão é apenas uma forma mais cara de se perder.
Portanto, antes de reescrever, compreenda.
Antes de apagar, investigue.
Antes de automatizar, documente.
Antes de confiar na IA, forneça contexto.
E antes que o último especialista se aposente, sente-se ao lado dele, abra o código, prepare o café e pergunte:
“Pode me explicar por que esse IF existe?”
Talvez a resposta salve não apenas um programa.
Talvez salve parte das economias do mundo.
Mensagem recebida via telegrafo
Seja um mainframer, aprenda COBOL e participe desta missão nas profundezas do CPD, os famosos Centros de Processamento de Dados.
