 |
| Bellacosa Mainframe e os 10 desafios para modernizar sistemas legados |
☕ Um Café no Bellacosa Mainframe
CSI Mainframe: Os 10 Desafios de Modernizar Sistemas Legados sem Destruir a Cena do Crime
Quando um Programador COBOL Descobre que o Sistema Antigo Não é o Suspeito — É a Principal Testemunha do Caso
Era pouco depois das três da manhã quando o telefone tocou.
No Data Center, as luzes permaneciam frias, constantes, quase indiferentes ao drama humano. No console, uma sequência de mensagens indicava que alguma coisa havia parado. Não era ainda um desastre completo, mas havia sinais suficientes para mobilizar a equipe.
Uma aplicação recém-modernizada havia entrado em produção poucas horas antes. O projeto prometia velocidade, flexibilidade, economia e uma experiência de usuário moderna. A apresentação para a diretoria havia usado palavras como transformação digital, inovação, nuvem, agilidade e arquitetura de próxima geração.
Agora, porém, ninguém queria falar sobre os slides.
Um processo de conciliação financeira não havia sido executado.
O sistema novo afirmava que tudo estava correto.
O sistema antigo, que deveria ter sido aposentado, havia deixado um arquivo vazio em uma biblioteca temporária.
Um programador iniciante olhou para a tela e fez a pergunta mais perigosa de toda a investigação:
— Mas esse programa não tinha sido desativado?
O analista mais experiente tomou um gole de café, observou o job no SDSF e respondeu:
— Oficialmente, sim.
Naquele instante, o jovem programador descobriu uma verdade fundamental do ambiente corporativo:
um sistema legado nunca desaparece apenas porque alguém escreveu “desativado” em uma planilha.
Ele desaparece quando todas as dependências foram identificadas, todos os usuários foram preparados, todas as regras foram compreendidas, todos os dados foram preservados, todos os testes foram executados e todos os caminhos de retorno foram planejados.
Até lá, o sistema continua presente.
Às vezes como aplicação.
Às vezes como arquivo.
Às vezes como interface.
Às vezes como hábito.
E, em muitos casos, como fantasma.
Bem-vindo ao laboratório forense do Bellacosa Mainframe.
Hoje, o caso investigado é complexo:
Quais são os verdadeiros desafios envolvidos na atualização de sistemas legados?
Coloque as luvas.
Ligue a luz ultravioleta.
Abra o código COBOL.
A cena do crime está esperando.
1. Antes da investigação: o que é realmente um sistema legado?
Um erro comum entre profissionais iniciantes é imaginar que sistema legado significa necessariamente um sistema velho, ultrapassado ou inútil.
Essa associação é sedutora, porém perigosa.
Um programa escrito há quarenta anos pode ser tecnicamente antigo, mas ainda cumprir sua função com precisão, desempenho e disponibilidade extraordinários.
Ao mesmo tempo, uma aplicação criada há oito meses pode já ser considerada legado se:
ninguém compreende sua arquitetura;
não existe documentação;
o fornecedor encerrou o suporte;
o código depende de uma biblioteca abandonada;
a aplicação não pode ser modificada sem provocar falhas;
ela se tornou indispensável ao negócio.
No ambiente mainframe, o termo “legado” frequentemente descreve sistemas que concentram décadas de conhecimento de negócio.
Eles processam:
contas bancárias;
seguros;
folhas de pagamento;
arrecadação de impostos;
cartões de crédito;
reservas aéreas;
benefícios previdenciários;
faturamento;
logística;
operações governamentais.
Portanto, o sistema legado não é apenas um conjunto de programas.
Ele representa uma combinação de:
código;
dados;
regras;
contratos;
procedimentos;
conhecimento humano;
integrações;
exceções;
decisões históricas.
Um sistema assim se parece menos com um software isolado e mais com uma cidade construída ao longo de décadas.
Existem ruas principais, túneis, atalhos, passagens subterrâneas e construções que ninguém lembra por que foram erguidas.
Modernizar essa cidade não significa simplesmente demolir tudo e construir novamente.
Significa descobrir quem vive nela, por onde passam os recursos, quais pontes ainda são usadas e quais estruturas não podem cair.
2. Primeira evidência: a aceitação do usuário
Na investigação de uma modernização, o primeiro suspeito costuma ser a resistência dos usuários.
A equipe técnica apresenta a nova solução e fica surpresa quando os operadores demonstram desconfiança.
O novo sistema tem:
gráficos;
menus;
ícones;
dashboards;
botões coloridos;
pesquisa inteligente;
interface responsiva.
Mesmo assim, o usuário prefere a antiga tela 3270.
O programador iniciante pensa:
— Como alguém pode preferir uma tela preta com letras verdes?
A resposta é simples:
porque aquela tela não é apenas uma interface. Ela é uma extensão da memória operacional do usuário.
Um operador experiente pode saber exatamente quantas vezes pressionar TAB para chegar a um campo. Ele conhece as teclas de função. Sabe interpretar mensagens abreviadas. Reconhece situações anormais antes mesmo que apareça uma mensagem de erro.
Ele não lê a tela como um iniciante.
Ele opera por memória muscular.
É semelhante a um pianista experiente. O músico não precisa procurar cada tecla. Seus dedos reconhecem o caminho.
Quando uma interface é substituída, todo esse conhecimento pode ser perdido.
Exemplo prático
Imagine uma tela CICS utilizada por uma equipe de atendimento:
TRAN: C001
CLIENTE: ___________
CONTA: ___________
OPÇÃO: _
O operador sabe que:
F5 consulta;
F8 avança;
F3 retorna;
determinada mensagem exige nova autenticação;
um código específico indica bloqueio judicial;
outro código representa apenas atraso de atualização.
A nova interface web traduz todas essas mensagens, altera a navegação e exige cliques.
Tecnicamente, ela pode parecer superior.
Operacionalmente, pode ser mais lenta.
Lição forense
A resistência do usuário nem sempre é medo irracional.
Às vezes é evidência de que a equipe de modernização não compreendeu o processo real.
Por isso, os usuários devem participar desde o início:
Observe como trabalham.
Registre atalhos e hábitos.
Pergunte onde perdem tempo.
Identifique controles paralelos.
Crie protótipos.
Valide com usuários experientes.
Meça produtividade antes e depois.
Easter egg CSI
Em CSI, uma pequena marca em um objeto pode revelar toda a história de um crime.
Em sistemas corporativos, um simples atalho de teclado pode revelar vinte anos de adaptação operacional.
Não ignore as pequenas marcas.
3. Segunda evidência: os fluxos de trabalho ocultos
Um sistema raramente trabalha sozinho.
Quando uma aplicação é analisada superficialmente, ela parece executar uma função direta.
Por exemplo:
“Este programa calcula a parcela.”
Mas a função real pode ser muito maior.
O programa pode:
ler dados de um VSAM;
consultar informações em Db2;
receber parâmetros de uma transação CICS;
gravar uma TSQ;
enviar mensagem para MQ;
gerar arquivo para processamento batch;
alimentar relatórios;
atualizar um sistema regulatório;
acionar uma rotina de auditoria.
A aplicação não é um ponto.
Ela é um nó em uma rede.
A cadeia invisível
Considere o fluxo:
Aplicativo Mobile
↓
API
↓
z/OS Connect
↓
Programa COBOL
↓
Db2
↓
Fila MQ
↓
Batch noturno
↓
Arquivo regulatório
↓
Auditoria
Trocar o programa COBOL pode alterar a API.
Alterar a API pode afetar o aplicativo.
Modificar a estrutura do banco pode quebrar relatórios.
Mudar o formato do arquivo pode interromper o processo regulatório.
Esse é o motivo pelo qual modernizações aparentemente simples se tornam projetos enormes.
Dica para o programador iniciante
Antes de alterar uma aplicação, desenhe o fluxo completo.
Pergunte:
Quem chama este programa?
O que ele chama?
Quais arquivos lê?
Quais arquivos grava?
Quais tabelas acessa?
Quais filas utiliza?
Em quais jobs aparece?
Quais relatórios dependem dele?
Que sistemas externos recebem seus dados?
Essa investigação é conhecida como análise de impacto.
No mundo CSI, ninguém move uma evidência antes de fotografar a cena.
No mainframe, ninguém deveria alterar um programa antes de mapear suas dependências.
4. Terceira evidência: dependências desconhecidas
Aqui encontramos um dos maiores perigos de toda modernização.
As dependências conhecidas são trabalhosas.
As desconhecidas são perigosas.
Um programa pode parecer sem uso porque:
não aparece em uma documentação recente;
não foi alterado em anos;
não possui um responsável definido;
não é executado diariamente;
nenhum usuário admite conhecê-lo.
Isso não significa que esteja inutilizado.
Talvez ele execute:
apenas no último dia do mês;
somente no fechamento anual;
em anos bissextos;
quando ocorre uma falha específica;
durante recuperação de desastre;
para um produto antigo ainda ativo;
em um processo judicial raro.
O programa que acordava uma vez por ano
Imagine um módulo chamado PGMIRP99.
Seu nome não ajuda.
A documentação não existe.
O histórico mostra que ninguém o alterou desde 2003.
A equipe decide removê-lo.
Onze meses depois, no fechamento do exercício fiscal, um job tenta executá-lo.
Resultado:
CSV003I REQUESTED MODULE PGMIRP99 NOT FOUND
O sistema falha.
A investigação começa.
Descobre-se que o programa calculava uma regra específica usada apenas no último fechamento anual.
O código parecia morto.
Na verdade, estava hibernando.
Como investigar dependências
Uma análise séria pode envolver:
busca em bibliotecas JCL;
análise de PROCs;
pesquisa em schedulers;
consulta a históricos SMF;
análise de chamadas estáticas e dinâmicas;
rastreamento de transações CICS;
inspeção de filas MQ;
análise de logs;
entrevistas com usuários;
análise de catálogos;
pesquisa em repositórios de código;
consulta a sistemas de gerenciamento de mudanças.
Atenção ao CALL dinâmico
Em COBOL, uma chamada pode ser direta:
CALL 'PGMCALC' USING WS-DADOS
Mas também pode ser dinâmica:
MOVE WS-NOME-PROGRAMA TO WS-PGM
CALL WS-PGM USING WS-DADOS
No segundo caso, procurar apenas pelo nome do programa pode não revelar a dependência.
O módulo é definido em tempo de execução.
É como procurar um suspeito cujo nome nunca aparece nos documentos.
5. Quarta evidência: não planejar a substituição
Muitas organizações constroem sistemas como se eles fossem eternos.
O código nasce fortemente acoplado:
ao banco;
ao fornecedor;
ao sistema operacional;
ao formato dos arquivos;
às interfaces;
aos processos;
aos nomes de bibliotecas.
Quando chega o momento de substituir uma parte, tudo está conectado.
Esse problema não pertence apenas aos sistemas antigos.
Aplicações modernas também podem ser criadas dessa forma.
Um sistema em nuvem pode se tornar prisioneiro de serviços proprietários e ser mais difícil de migrar do que uma aplicação COBOL bem estruturada.
Planejar a saída desde a entrada
Uma boa arquitetura deve considerar:
substituição futura;
portabilidade;
versionamento;
interfaces bem definidas;
abstração;
desacoplamento;
observabilidade;
documentação;
testes.
No mainframe, uma estratégia eficiente é proteger o núcleo do negócio por meio de camadas.
Exemplo:
Canal Mobile
↓
API REST
↓
Camada de Integração
↓
COBOL/CICS
↓
Db2
O programa COBOL continua executando a regra crítica.
A camada de integração permite novos canais.
Dessa maneira, modernizar não significa necessariamente reescrever.
Pode significar expor, organizar, automatizar e integrar.
6. Quinta evidência: reescrever quando necessário
Existem situações em que uma reescrita é justificável.
Por exemplo:
tecnologia sem suporte;
hardware impossível de manter;
código irrecuperável;
risco de segurança;
incapacidade de escalar;
custo operacional insustentável;
ausência total de profissionais;
necessidade de mudança radical do negócio.
Mas a decisão não pode ser ideológica.
A frase “vamos reescrever tudo” costuma parecer corajosa em uma reunião.
Na prática, pode iniciar uma operação de altíssimo risco.
O código como documento histórico
Considere este trecho:
IF WS-TIPO-CONTRATO = 'A'
AND WS-DATA-ADESAO < 20030101
AND WS-REGIAO = '03'
COMPUTE WS-TAXA = WS-TAXA * 0.875
END-IF
O programador iniciante pode considerar essa lógica estranha.
Talvez ela represente:
uma legislação antiga;
uma decisão judicial;
uma condição contratual;
um acordo comercial;
uma exceção regulatória.
Sem investigação, alguém pode “simplificar” o código.
A simplificação pode criar prejuízos, multas ou ações judiciais.
Reescrever não é traduzir
Converter COBOL para Java linha por linha não moderniza necessariamente o sistema.
É possível criar um programa Java com arquitetura de 1975.
Da mesma forma, é possível manter COBOL dentro de uma arquitetura moderna com:
APIs;
CI/CD;
testes automatizados;
Git;
observabilidade;
integração com cloud;
containers em componentes complementares.
Linguagem não define sozinha a modernidade.
Arquitetura, governança, automação e capacidade de evolução importam muito mais.
7. Sexta evidência: o investimento acumulado
Quando uma empresa analisa um sistema legado, costuma enxergar custos:
licenças;
hardware;
suporte;
profissionais;
manutenção.
Mas existe um investimento invisível.
O sistema contém milhares de decisões tomadas ao longo de décadas.
Cada correção representa uma lição.
Cada exceção representa um caso real.
Cada validação representa uma falha que alguém decidiu impedir.
Portanto, o código acumulou conhecimento.
Uma conta que não aparece no balanço
Imagine um sistema com dez milhões de linhas, construído durante trinta anos.
Não seria correto calcular seu valor apenas pelo custo atual de manutenção.
Seria necessário considerar:
horas de desenvolvimento;
análise de negócio;
testes;
auditorias;
adaptações legais;
integração com parceiros;
correções de incidentes;
conhecimento dos especialistas.
Esse patrimônio pode valer muito mais do que o próprio hardware.
É como um laboratório forense com décadas de evidências organizadas.
Você pode substituir os computadores.
Não pode reconstruir facilmente o conhecimento perdido.
8. Sétima evidência: evitar tempo de inatividade
Em sistemas críticos, parar não é uma opção simples.
Uma indisponibilidade pode impedir:
pagamentos;
transferências;
compras;
embarques;
atendimentos;
autorizações;
emissão de documentos;
processamento de salários.
Por isso, a migração deve prever continuidade.
Estratégias de transição
Execução paralela
O sistema antigo e o novo processam os mesmos dados.
Depois, os resultados são comparados.
Entrada
├── Sistema Antigo → Resultado A
└── Sistema Novo → Resultado B
Comparação: A = B?
Shadow processing
O novo sistema recebe cópias das transações, mas ainda não responde oficialmente.
Ele trabalha nas sombras, como um laboratório analisando evidências sem interferir na operação.
Blue-Green Deployment
Dois ambientes são mantidos:
Blue: versão atual;
Green: nova versão.
Quando o novo ambiente está validado, o tráfego é redirecionado.
Canary Release
A nova versão atende uma pequena parcela dos usuários.
Se os indicadores forem bons, a liberação aumenta gradualmente.
Rollback
Toda implantação deve possuir um plano de retorno.
Perguntas fundamentais:
Como voltar?
Em quanto tempo?
Os dados continuam compatíveis?
Existe backup?
As transações podem ser reprocessadas?
O retorno já foi testado?
Um rollback não testado é apenas esperança documentada.
9. Oitava evidência: retorno sobre investimento
Muitas modernizações são aprovadas com base em uma promessa:
“A nova tecnologia reduzirá custos.”
Mas o cálculo do ROI costuma ser incompleto.
É necessário comparar:
custo de manutenção;
custo de migração;
custo de treinamento;
custo de indisponibilidade;
custo de erros;
custo de coexistência;
custo de licenças;
custo de segurança;
custo de auditoria;
custo de oportunidade.
ROI invisível
Nem todo retorno aparece como aumento direto de receita.
Modernizar pode trazer:
menor risco;
maior velocidade de entrega;
melhor rastreabilidade;
facilidade de integração;
redução de incidentes;
automação de testes;
recuperação mais rápida;
maior segurança.
Imagine um projeto que custa R$ 5 milhões e evita uma falha potencial de R$ 50 milhões.
O retorno não está apenas no que a empresa ganhou.
Está também no que deixou de perder.
Armadilha da economia imaginária
Um projeto pode prometer economia ao retirar o mainframe.
Porém, depois surgem custos com:
dezenas de servidores;
bancos distribuídos;
redes;
especialistas;
observabilidade;
redundância;
segurança;
licenças;
tráfego de dados;
indisponibilidades.
O custo precisa ser comparado de ponta a ponta.
Não basta comparar o preço de uma plataforma com o preço de outra.
É necessário comparar a capacidade entregue, a disponibilidade, o desempenho, a segurança e o risco operacional.
10. Nona evidência: comunicação aberta
A modernização não ocorre apenas dentro dos computadores.
Ela acontece na cabeça das pessoas.
Quando uma empresa anuncia uma grande transformação, surgem medos:
“Meu conhecimento ficará inútil?”
“Perderei meu emprego?”
“O sistema novo vai substituir minha função?”
“Serei responsabilizado se falhar?”
“Vou conseguir aprender?”
Ignorar esses medos cria resistência.
E resistência silenciosa pode ser mais perigosa do que oposição explícita.
O especialista tratado como obstáculo
Um erro frequente é tratar profissionais antigos como inimigos da inovação.
Eles podem parecer conservadores porque conhecem falhas que os recém-chegados nunca viram.
O especialista lembra:
do processamento que falhou em 1999;
da regra criada após uma auditoria;
do arquivo que não pode ser ordenado;
da transação que exige commit em determinado momento;
da rotina usada durante contingência.
Esse profissional não deve ser descartado.
Ele deve ser incorporado à investigação.
Comunicação eficiente
Uma estratégia saudável explica:
Por que a mudança é necessária.
O que será preservado.
O que será substituído.
Como os profissionais participarão.
Quais competências serão valorizadas.
Como ocorrerá o treinamento.
Quais riscos estão sendo controlados.
Como o sucesso será medido.
Modernização sem comunicação cria boatos.
Boatos criam medo.
Medo cria sabotagem involuntária, omissão de conhecimento e baixa adesão.
11. Décima evidência: escolher entre opções demais
O mercado oferece inúmeras alternativas:
nuvem pública;
nuvem privada;
nuvem híbrida;
containers;
SaaS;
PaaS;
bancos distribuídos;
eventos;
APIs;
plataformas low-code;
inteligência artificial;
microsserviços.
O problema não é a falta de opções.
É o excesso.
A organização pode escolher uma tecnologia porque:
está na moda;
aparece em eventos;
foi recomendada por consultorias;
o concorrente utiliza;
o fornecedor oferece desconto;
a diretoria assistiu a uma apresentação convincente.
Nenhuma dessas razões é suficiente.
A tecnologia deve seguir o caso
A escolha precisa considerar:
volume de transações;
latência;
disponibilidade;
consistência;
segurança;
regulação;
custo;
competências internas;
integração;
prazo;
recuperação de desastre;
soberania de dados;
dependência de fornecedor.
Em alguns casos, cloud é excelente.
Em outros, manter o processamento central no mainframe e integrar com cloud é melhor.
O futuro corporativo tende a ser híbrido.
Não existe obrigação de mover tudo para um único lugar.
O objetivo é posicionar cada carga onde ela funciona melhor.
12. Evidência adicional: documentação inexistente
O artigo original apresenta dez desafios importantes, mas deixa uma cadeira vazia na sala de interrogatório.
A documentação.
Em muitos ambientes, o único documento confiável é o código-fonte.
Você encontra:
IF WS-FLAG-X = 'S'
PERFORM 9000-AJUSTE-ESPECIAL
END-IF
Pergunta:
— O que significa WS-FLAG-X?
Resposta:
— Não sabemos.
Pergunta:
— Por que chama 9000-AJUSTE-ESPECIAL?
Resposta:
— Foi criado antes de eu entrar.
Pergunta:
— Podemos remover?
Silêncio.
Esse é o momento em que o programador COBOL se transforma em investigador.
Ele precisa:
rastrear origem do campo;
localizar onde recebe valor;
analisar arquivos;
examinar copybooks;
encontrar chamadas;
comparar versões;
buscar documentação antiga;
consultar especialistas;
testar cenários.
Regra de ouro
Nunca presuma que código estranho é código inútil.
Código estranho pode ser uma pista.
13. Evidência adicional: conhecimento humano
Parte do sistema não está gravada em disco.
Está na memória das pessoas.
O operador sabe que determinado arquivo chega atrasado em feriados.
O DBA sabe que uma tabela não pode receber determinado índice.
O analista conhece uma exceção contratual.
O programador lembra que um job precisa executar após outro, embora o scheduler não indique dependência formal.
Quando essas pessoas saem, o sistema perde contexto.
Como preservar conhecimento
entrevistas estruturadas;
sessões gravadas;
documentação de incidentes;
mapas de fluxo;
catálogos de regras;
revisão de código;
programação em dupla;
comunidades internas;
mentoria;
laboratórios práticos;
registro de decisões arquiteturais.
O conhecimento precisa sair da cabeça e entrar no processo.
14. Evidência adicional: testes insuficientes
O novo sistema pode funcionar em demonstração.
Isso não significa que esteja pronto para produção.
O ambiente real contém:
dados incompletos;
contratos antigos;
clientes especiais;
caracteres inesperados;
datas inválidas;
arquivos atrasados;
duplicidades;
volumes extremos;
falhas de rede;
concorrência;
reprocessamentos.
Testar o caminho feliz não basta
Considere um cálculo de juros.
O teste comum verifica:
valor normal;
prazo normal;
taxa normal.
Mas o sistema real pode precisar tratar:
contrato suspenso;
pagamento parcial;
cliente falecido;
decisão judicial;
feriado regional;
moeda histórica;
migração de produto;
arredondamento especial;
renegociação.
Esses casos vivem nos cantos escuros do sistema.
É exatamente onde a luz ultravioleta deve ser aplicada.
Tipos de teste necessários
teste unitário;
teste de integração;
teste de regressão;
teste de volume;
teste de desempenho;
teste de recuperação;
teste de segurança;
teste de coexistência;
teste de reconciliação;
teste de rollback;
teste de desastre.
Modernizar sem regressão automatizada é caminhar pela cena do crime com os olhos fechados.
15. Evidência adicional: auditoria e conformidade
Em ambientes regulados, funcionar não basta.
O sistema precisa provar que funcionou corretamente.
Isso exige:
trilhas de auditoria;
logs confiáveis;
segregação de funções;
rastreabilidade;
controle de acesso;
retenção de dados;
versionamento;
evidências de aprovação;
conformidade legal.
Uma nova aplicação pode ser tecnicamente excelente e ainda assim ser rejeitada porque não consegue responder:
Quem alterou?
Quando alterou?
Qual era o valor anterior?
Quem aprovou?
Qual versão estava em produção?
Qual regra foi aplicada?
No mainframe, tecnologias como RACF, SMF, logs de CICS e mecanismos de auditoria fornecem um histórico extremamente rico.
Ao modernizar, essa capacidade não pode desaparecer.
16. O roteiro CSI para modernizar com segurança
Agora chegamos ao procedimento de investigação.
Passo 1 — Isolar a cena
Defina claramente:
sistema;
escopo;
módulos;
interfaces;
dados;
usuários;
objetivos.
Sem limite, o projeto se transforma em uma investigação infinita.
Passo 2 — Fotografar o ambiente atual
Documente:
arquitetura;
fluxos;
bibliotecas;
jobs;
tabelas;
transações;
arquivos;
integrações;
horários;
volumes.
Antes de mudar, registre.
Passo 3 — Coletar depoimentos
Converse com:
usuários;
operadores;
programadores;
analistas;
DBAs;
segurança;
auditoria;
suporte;
fornecedores.
Cada grupo conhece uma parte da história.
Passo 4 — Mapear dependências
Use ferramentas e análise manual para localizar:
chamadas;
arquivos;
filas;
tabelas;
APIs;
schedulers;
relatórios;
sistemas consumidores.
Passo 5 — Identificar regras críticas
Separe:
regra de negócio;
regra técnica;
exceção;
contorno;
código morto;
comportamento desconhecido.
Não elimine nada antes de compreender.
Passo 6 — Criar uma linha de base
Registre:
tempos;
resultados;
volumes;
consumo;
erros;
disponibilidade.
A modernização deve ser comparada com algo concreto.
Passo 7 — Construir testes
Transforme o comportamento atual em evidência reproduzível.
Crie massas de teste e resultados esperados.
Passo 8 — Modernizar em pequenas partes
Evite o chamado Big Bang.
Prefira:
APIs;
desacoplamento;
extração gradual;
componentes substituíveis;
coexistência.
Passo 9 — Executar em paralelo
Compare antigo e novo.
Não confie apenas em demonstrações.
Use dados reais controlados.
Passo 10 — Preparar retorno
Todo avanço precisa de uma rota de fuga.
Teste rollback antes da produção.
Passo 11 — Medir resultados
Avalie:
desempenho;
estabilidade;
custo;
produtividade;
adesão;
erros;
segurança.
Passo 12 — Desativar com evidência
Somente aposente o sistema antigo quando puder provar que:
não existem consumidores;
dados foram preservados;
requisitos legais foram atendidos;
rollback não é mais necessário;
usuários estão preparados;
suporte está estruturado.
Desativar não é apagar uma biblioteca.
É encerrar um ciclo com segurança.
Curiosidades do laboratório Bellacosa
Curiosidade 1 — COBOL pode ser antigo e moderno ao mesmo tempo
O COBOL surgiu em 1959, mas continua sendo atualizado.
Compiladores modernos oferecem:
otimizações;
integração com JSON;
XML;
APIs;
Java;
Db2;
CICS;
ferramentas DevOps.
A idade da linguagem não determina a idade da arquitetura.
Curiosidade 2 — Tela verde pode ser mais eficiente que mouse
Interfaces 3270 foram projetadas para alta produtividade transacional.
Em determinadas operações, teclado e teclas de função são mais rápidos do que interfaces gráficas.
Curiosidade 3 — Sistemas modernos também viram legado
Código Java, Python, JavaScript ou Kubernetes pode se tornar legado rapidamente.
Basta que ninguém consiga mantê-lo.
Curiosidade 4 — O maior risco pode estar na exceção
A rotina principal costuma ser compreendida.
As falhas aparecem em:
fim de mês;
feriados;
datas especiais;
produtos antigos;
contingências;
reprocessamentos.
Curiosidade 5 — O programa “inútil” pode ser o mais importante
Alguns módulos são executados raramente porque foram criados para situações críticas.
Eles parecem mortos até o dia em que salvam a operação.
Easter eggs para os investigadores de plantão
O laboratório CSI possuía luzes, microscópios e análises químicas.
O laboratório mainframe possui:
dumps;
Abend-AID;
Fault Analyzer;
SDSF;
SMF;
logs;
traces;
listings;
sysouts;
históricos de scheduler.
Um cabelo encontrado em uma cena pode identificar um suspeito.
Um byte encontrado em um dump pode identificar a instrução que causou um S0C7.
Uma impressão digital pode revelar quem tocou em uma arma.
Um registro SMF pode revelar quem acessou um recurso.
Uma mancha de sangue pode indicar a sequência do crime.
Um log pode revelar a sequência da transação.
No universo CSI, toda evidência conta.
No mainframe, também.
As três perguntas que todo Padawan COBOL deve fazer
Antes de alterar qualquer sistema crítico, pergunte:
1. Quem depende disso?
Não apenas usuários diretos.
Inclua programas, arquivos, relatórios, APIs, filas, jobs e auditorias.
2. O que acontece se estiver errado?
Calcule impacto financeiro, operacional, legal e reputacional.
3. Como provar que continua correto?
A resposta deve envolver testes, comparação, logs e métricas.
Se ninguém consegue responder essas três perguntas, a investigação ainda não terminou.
Conclusão: o legado não é o cadáver
Ao final desta investigação, o programador COBOL iniciante retorna à tela do SDSF.
Agora ele enxerga o sistema de outra forma.
Antes, via programas antigos.
Agora, vê relações.
Antes, via código estranho.
Agora, vê decisões históricas.
Antes, via resistência dos usuários.
Agora, vê conhecimento operacional.
Antes, via custo.
Agora, vê patrimônio.
Antes, via um sistema que deveria ser substituído.
Agora, vê uma testemunha que precisa ser ouvida.
Esse é o segredo da modernização responsável:
o objetivo não é apagar o passado. É entender o passado o suficiente para construir o futuro sem repetir seus erros e sem destruir seus acertos.
Sistemas legados precisam evoluir.
Mas evolução não significa desprezo.
Ela exige investigação.
Exige respeito pelas evidências.
Exige compreensão das dependências.
Exige testes.
Exige comunicação.
Exige planejamento.
Exige humildade.
Um sistema crítico não pode ser tratado como um velho computador esquecido em um depósito.
Ele é o resultado de milhares de incidentes resolvidos, regras incorporadas, exceções descobertas e decisões acumuladas.
Talvez sua interface seja antiga.
Talvez seu código tenha sido escrito antes do nascimento de muitos profissionais da equipe.
Mas, enquanto processa corretamente milhões de transações, ele não é apenas passado.
Ele é infraestrutura viva.
Por isso, quando alguém entrar em uma reunião e disser:
— Precisamos acabar com o legado.
Respire.
Tome um gole de café.
Ligue a luz ultravioleta.
E pergunte:
— Quais evidências provam que compreendemos tudo o que ele faz?
Se a sala ficar em silêncio, o caso ainda está aberto.
E, em algum lugar do Data Center, um programa COBOL que ninguém lembra continua executando às 03h17, protegendo uma regra que todos esqueceram, mas que o negócio ainda precisa.
Caso encerrado?
Ainda não.
Em sistemas legados, nenhum caso termina até que o último job retorne RC=0000.
