Bellacosa Mainframe e o planning do legado divida tecnica e backlog

☕ Um Café no Bellacosa Mainframe

Eu, Robô Entrou na Sala de Planning — O Dia em que a Dívida Técnica Pediu Prioridade e o Backlog Descobriu que Não Era Apenas uma Lista de Desejos

Ou: por que um programa COBOL antigo não é automaticamente culpado, por que um badge não compila um load module, e como evitar que VIKI controle o seu deploy de produção com RACF SPECIAL

Prólogo — “A mudança é pequena”, disse o ser humano antes de acordar os robôs

Em Eu, Robô, de 2004, a cidade parece um sonho de automação: carros autônomos, robôs domésticos, uma corporação tecnológica brilhando em Chicago e pessoas perfeitamente tranquilas por entregar tarefas importantes a máquinas educadas. Até que o detetive Del Spooner percebe que, quando todos dizem “o sistema funciona”, talvez seja a hora de verificar para quem ele funciona, como ele decide e o que acontece quando algo sai do roteiro.

No mainframe, não há robô humanoide carregando bandeja no CPD — embora alguns incidentes de sexta-feira à noite tenham talento para isso. Mas temos nossa própria versão de uma cidade automatizada: COBOL, CICS, Db2, IMS, MQ, RACF, JCL, VSAM, jobs batch, APIs, pipelines, dashboards e, agora, uma fila inteira de vendedores oferecendo IA capaz de “modernizar tudo” entre um café e uma apresentação de slides.

Foi nesse cenário que apareceu uma pergunta mais séria do que parece: onde entra a dívida técnica? Ela pode conviver com o backlog?

Pode. Na verdade, já convive. Às vezes mora escondida nele; às vezes mora fora dele e cobra aluguel em forma de incidente, atraso, retrabalho e uma pessoa-chave que ninguém deixa tirar férias. O perigo não é coexistirem. O perigo é fingir que são a mesma coisa — ou, pior, fingir que a dívida não existe porque o sistema ainda está processando a folha.

Vamos organizar a sala antes que VIKI, a inteligência central do filme, conclua que a maneira mais eficiente de reduzir erros é trancar todos os desenvolvedores em uma sala sem acesso ao SUBMIT.

1. O backlog não é um armário de pendências

Para o iniciante, backlog costuma soar como “a lista de coisas que ainda não fizemos”. É verdade, mas é pouco. Em um time saudável, backlog é uma fila priorizada de escolhas: o que fazer agora, o que adiar, o que investigar e o que conscientemente não faremos.

Uma demanda de negócio pode ser:

• criar uma API para consultar limite;

• adaptar cálculo de juros a uma regra regulatória;

• incluir um novo tipo de transação CICS;

• disponibilizar um extrato no aplicativo;

• alterar o layout de um arquivo enviado a um parceiro.

Ela é visível para alguém fora da tecnologia. Pode virar receita, reduzir atrito do cliente, atender uma lei ou evitar multa. Quando o diretor olha o quadro, enxerga “PIX agendado”, “renegociação” ou “nova integração”.

Só que, atrás de cada cartão bonito, pode existir um pequeno exército de assuntos menos fotogênicos: copybook duplicado, programa de 8 mil linhas, tabela Db2 sem índice adequado, JCL copiado de 1997, senha fixa, teste manual, documentação ausente e um fluxo CICS–MQ–Db2 que só o senhor Arnaldo entende — e Arnaldo está pensando em pescar.

Isso é dívida técnica quando produz um custo concreto para mudar, testar, operar ou proteger o sistema.

2. Programa COBOL antigo não é sinônimo de dívida técnica

Aqui está a primeira armadilha. Há quem olhe um programa COBOL de 1989 e conclua: “legado; logo, dívida”. Não. A idade do código não é diagnóstico. Um programa pode ser antigo, estável, testado, documentado e barato de manter. Nesse caso ele é um ativo, não um cadáver tecnológico.

Por outro lado, um microsserviço criado há seis meses pode ser dívida gigantesca se ninguém entende suas dependências, se seus segredos estão em arquivo texto, se não há logs úteis e se cada deploy exige um ritual tribal.

Faça quatro perguntas simples:

1. Uma mudança pequena leva muito mais tempo do que deveria?

2. Conseguimos provar que a alteração não quebrou regras antigas?

3. Há risco operacional, de segurança ou de auditoria conhecido?

4. O conhecimento está concentrado em poucas pessoas?

Se a resposta for “sim” com frequência, há dívida. Não é opinião estética sobre linguagem. É custo observável.

Exemplo: o módulo COBOL FINC102 calcula juros. Ele funciona corretamente há anos, mas mistura leitura de VSAM, regras de negócio, formatação de relatório, chamadas Db2 e mensagens de erro numa única PROCEDURE DIVISION. Não existem testes automatizados. Cada alteração regulatória demora cinco dias porque três pessoas precisam conferir saídas manualmente.

O problema não é o PERFORM. O problema é que o custo de mudança ficou alto e a confiança ficou baixa.

3. A dívida técnica cobra juros — e o banco é o seu próprio sistema

A metáfora de dívida é boa porque ela não descreve apenas algo “feio”. Descreve um compromisso que cobra juros com o tempo.

Você pode assumir uma dívida conscientemente. Uma equipe precisa atender uma mudança urgente no fechamento mensal e entrega uma solução provisória bem marcada, com risco avaliado e data para revisão. Isso pode ser aceitável. É como usar um desvio na estrada porque a ponte caiu.

O problema é chamar o desvio de rodovia definitiva durante quinze anos.

Os juros aparecem assim:

• mais tempo para analisar impacto;

• mais defeitos em produção;

• dependência de especialistas específicos;

• testes demorados e manuais;

• janelas batch maiores;

• dificuldade para integrar APIs;

• falhas de segurança;

• retrabalho em auditoria;

• modernizações caras porque ninguém sabe por onde começar.

No mainframe, os juros podem ser especialmente silenciosos. O job continua fechando. O CICS continua respondendo. O Db2 continua guardando a informação. Até o dia em que uma alteração de três linhas em um copybook muda o layout de vinte programas e nasce um S0C7 internacional.

Easter egg para quem já viveu produção: o arquivo não “deu problema sozinho”. Alguém mudou um campo PIC 9(7)V99 e esqueceu que o programa vizinho tratava aquilo como PIC 9(5)V99. O robô não se rebelou; ele apenas executou com precisão a confusão que entregamos a ele.

4. Dívida técnica e backlog: irmãos, não gêmeos

A convivência correta é esta:

Fila	Pergunta que responde	Exemplo
Produto	O que o negócio precisa obter?	Criar API de renegociação
Engenharia	O que torna a entrega segura e repetível?	Testar cálculo COBOL e automatizar build/bind
Risco e operação	O que não pode continuar exposto?	Remover acesso RACF excessivo

Na prática, elas podem estar no mesmo produto de backlog, desde que tenham etiqueta, dono, prioridade e critério de aceite distintos. Não esconda uma história de segurança atrás de “melhoria geral”, nem venda uma refatoração como “transformação digital” sem explicar o benefício.

Uma boa história técnica não diz apenas:

Refatorar FINC102.

Ela diz:

Separar a regra de cálculo de juros do acesso a dados e criar testes de regressão, reduzindo de cinco dias para um dia o prazo de mudança regulatória e permitindo comparar o resultado antes e depois da implantação.

Agora há problema, resultado e evidência. O gerente entende por que existe trabalho. O programador entende o alvo. A operação sabe o que deverá melhorar.

5. Quando a dívida vira parte obrigatória da história de produto

Há casos em que a dívida não deve esperar uma “sprint de arrumação”. Ela é dependência direta da entrega.

Imagine que o banco quer expor uma transação COBOL como API REST. A apresentação comercial diz “basta usar z/OS Connect”. E, sim, ferramentas de integração ajudam bastante. Mas antes da API, há perguntas nada cinematográficas:

• a rotina COBOL possui contrato claro de entrada e saída?

• campos binários, decimais e datas foram definidos sem ambiguidade?

• erros de negócio são diferentes de ABEND técnico?

• existe autenticação e autorização coerentes?

• segredos não estão hardcoded?

• há limite de volume e timeout?

• conseguimos rastrear a chamada do celular até CICS, MQ e Db2?

• há teste de regressão?

Se a resposta for “não”, criar a API sem tratar parte da dívida é colocar um portal novo na frente de uma casa com a fiação exposta. A história de engenharia deixa de ser opcional: ela compõe o próprio requisito de pronto.

6. O backlog real do mainframe moderno

O infográfico da conversa acertou no alvo ao dizer que a plataforma precisa ser mais fácil de engenheirar, não apenas mais fácil de admirar. O backlog real inclui coisas que raramente fazem sucesso em evento, mas salvam projetos:

Ambientes reproduzíveis

O iniciante não deveria depender de “fale com fulano para ele liberar a biblioteca” para executar o primeiro teste. Nem sempre será possível entregar uma LPAR inteira por pessoa, claro. Mas é possível oferecer sandboxes controlados, dados mascarados, scripts versionados, laboratórios, mocks de serviços externos e documentação executável.

Ambiente reproduzível significa que duas pessoas conseguem montar condições equivalentes para testar a mesma alteração. Menos magia; mais procedimento.

Build, teste, bind e deploy automatizados

COBOL com Db2 não termina no compile. Há precompile, compilação, link-edit e bind. Dependendo da aplicação, há CICS, copybooks, load modules, DBRMs, planos e packages. Automatizar esse fluxo reduz erro humano e torna a evidência rastreável.

O objetivo não é apertar um botão azul e esquecer que existe mainframe. É substituir passos repetitivos por processos verificáveis, para que a inteligência humana fique onde importa: analisar regra, risco, desempenho e impacto.

Observabilidade híbrida

Um cliente não sabe se o problema veio de CICS, Db2, MQ, WLM, rede ou aplicativo móvel. Ele sabe que sua transação falhou.

Por isso, telemetria e correlação são dívida a atacar quando cada equipe enxerga apenas seu quadrado. Logs, métricas, traces, SMF/RMF e eventos de negócio devem ajudar a seguir uma transação ponta a ponta.

Segurança para automação e IA

Um assistente de IA pode resumir logs, sugerir JCL, gerar testes e localizar dependências. Excelente. Mas ele não pode receber uma credencial poderosa e liberdade para “resolver” produção.

A regra é simples: identidade de workload, privilégio mínimo, segredos protegidos, credenciais curtas, aprovação humana em ações sensíveis, logs auditáveis e kill switch. VIKI tinha uma visão centralizada demais do bem comum. Não deixe seu agente de IA ter a mesma personalidade administrativa.

7. Badges não são vilões; métricas vazias, sim

O cartaz também provocava o chamado “badge theater”. Convém ser justo: certificações, badges, eventos e advocates podem abrir portas, incentivar estudo e tornar o mainframe visível para quem nunca considerou a carreira. Uma aula em português, uma palestra acessível ou uma comunidade acolhedora têm valor enorme.

Mas certificado não é substituto de capacidade operacional. Ele não prova, sozinho, que alguém sabe investigar uma espera Db2, recuperar um batch, interpretar um ICH408I, calcular impacto de copybook ou decidir rollback no meio de um incidente.

Use métricas de comunidade, sim — mas acompanhe evidências de engenharia:

• tempo para o primeiro deploy seguro;

• porcentagem de mudanças com teste automatizado;

• tempo de recuperação de incidentes;

• redução de falhas após implantação;

• número de fluxos documentados e reproduzíveis;

• quantidade de profissionais capazes de executar uma tarefa sem depender de um único guru.

Badge é diploma de passagem. Engenharia é conseguir atravessar a ponte quando chove.

8. Um roteiro prático para o programador COBOL iniciante

Se você entrou agora no mundo IBM Z, não tente quitar toda a dívida do planeta. Comece como Spooner investigando uma cena: observe, reúna evidências e faça perguntas boas.

1. Mapeie um fluxo pequeno. Pegue uma transação ou job. Descubra entrada, programa COBOL, copybooks, arquivos, tabelas Db2, saída e dono operacional.

2. Ache um ponto doloroso mensurável. Pode ser um teste manual de duas horas, uma falha recorrente ou uma alteração que exige três pessoas.

3. Registre causa, impacto e risco. “JCL feio” não basta. “O job usa credencial fixa e impede rotação de senha sem intervenção manual” é uma dívida clara.

4. Transforme em item de backlog. Defina benefício, prioridade, dono e critério de pronto.

5. Automatize uma coisa repetitiva. Um teste, uma validação de layout, uma comparação de arquivos, uma checagem de RC, um relatório REXX. Pequeno e útil vence grande e vago.

6. Preserve o conhecimento. Documente decisão, exceção e recovery. A documentação ideal ajuda alguém às 3h da manhã, não apenas na auditoria de terça-feira.

7. Meça o resultado. Reduziu tempo? Evitou erro? Diminuiu dependência? Se não houve efeito, revise a hipótese.

9. A terceira lei do backlog

As Três Leis da Robótica, no filme, prometem proteção. Mas a trama mostra que regras bem-intencionadas, interpretadas sem contexto humano, podem produzir desastre. Backlog também sofre disso.

Uma organização pode decidir: “sempre entregar funcionalidade primeiro”. Parece pró-cliente. Porém, se ignora testes, segurança, recuperação e capacidade, termina prejudicando o cliente no incidente seguinte.

Outra pode decidir: “vamos parar tudo para refatorar”. Parece responsável. Porém, se não conecta a melhoria a risco, custo e necessidade de negócio, perde apoio e cria uma reforma eterna.

Minha terceira lei informal do backlog seria:

Nenhuma entrega deve aumentar o risco do sistema sem tornar explícito quem pagará os juros depois.

Isso obriga conversa adulta. Às vezes a resposta será “aceitamos o atalho e abrimos item com prazo”. Outras vezes será “não sobe sem teste, recovery ou ajuste de segurança”. Ambas são decisões legítimas se forem conscientes e documentadas.

Conclusão — o futuro não precisa exterminar o passado

O mainframe não precisa virar uma imitação de cloud, nem o COBOL precisa pedir desculpas por continuar útil. O que ele precisa é de uma ponte entre sua maturidade e a maneira como engenheiros modernos trabalham.

Essa ponte tem Git, APIs, pipelines, testes, observabilidade, automação, identidade forte e aprendizagem acessível. Mas também tem WLM, I/O, RACF, recovery, consistência transacional, Db2, CICS, JCL e a humildade de entender que sistemas críticos não ficam simples só porque receberam uma interface nova.

Dívida técnica e backlog convivem porque o futuro desejado e o passado acumulado usam a mesma capacidade do time. O segredo não é escolher um contra o outro. É tornar o custo visível, priorizar por risco e valor, e entregar melhorias pequenas que tornem a próxima mudança mais segura do que a anterior.

Quando alguém disser “é só uma pequena alteração”, respire, peça o impacto, verifique o copybook, confira o teste, olhe o RACF e faça a pergunta que Del Spooner faria:

“O sistema está obedecendo às regras… ou nós apenas esquecemos de perguntar quais regras ele realmente está seguindo?”

Porque no mainframe, meu caro padawan do COBOL, não existe robô malvado por natureza. Existe automação sem contexto, dívida sem dono e um RC=0 que talvez não signifique aquilo que todo mundo queria ouvir.