In partnership with

ED 034

O tradutor de COBOL e a regra que ninguém escreveu

A ferramenta converte a sintaxe do programa antigo em segundos, e o banco continua sem saber por que aquela linha desconta 0,7% de um grupo de contas.

Terminal verde de mainframe aceso numa sala de operação escura, com fichário de anotações manuscritas aberto ao lado.

O código traduziu, a razão do número não

▼

Aos 52 anos, o programador de mainframe Sérgio Baptista abriu um programa de 1987 numa terça de março e leu uma linha que descontava 0,7% de um grupo específico de contas, sem um comentário sequer dizendo quem eram aquelas contas.

A rotina dele era a mesma desde 1994. Receber o chamado, localizar o programa em COBOL (Common Business-Oriented Language, a linguagem comum voltada a negócios), entender o trecho que travava o fechamento noturno, corrigir, testar e devolver o sistema no ar antes das seis da manhã. O mainframe (o computador central de grande porte que roda o núcleo de contas do banco) nunca parou.

A IBM anunciou o watsonx Code Assistant for Z em 22 de agosto de 2023, num comunicado assinado por Kareem Yusuf, então vice-presidente sênior de gestão de produto e crescimento da IBM Software. A ferramenta faz refactoring (reestruturação do código sem mudar o comportamento dele) e converte trechos de COBOL para Java, a linguagem que a maior parte dos times novos do banco já domina.

A conversão automática resolve bem tudo que está escrito. Ela lê a sintaxe, reconhece estrutura de arquivo, reorganiza rotina de cálculo e devolve em minutos um serviço em Java que o time levava semanas para reescrever à mão.

O que ela não devolve é a razão do 0,7%. Nenhum tradutor recupera a decisão tomada numa reunião de 1987 quando ela nunca foi escrita em lugar nenhum além do próprio código.

Sérgio saiu da manutenção corretiva e entendeu que o serviço novo dele não era digitar COBOL mais rápido que a máquina: era dizer, com data e fonte, o que cada regra decide e por quê.

A travessia de hoje é de um programador que viu a tradução sair do escopo dele, passou catorze meses interrogando 3.180 programas de fechamento noturno, e descobriu que 19 regras vivas do banco não existiam em documento nenhum.

Continue lendo ↓

I A história de quem atravessou

De 3.180 programas herdados a 19 regras com dono

Catorze meses de interrogatório, 3.180 programas de fechamento noturno abertos um a um, e 19 regras de negócio rodando todo dia sem uma linha de documentação no banco.

Sérgio Baptista tem 52 anos e mora em Osasco, a cinquenta minutos do prédio de tecnologia do banco onde entrou como estagiário. Trinta e um anos de casa, os últimos onze no núcleo de contas correntes. O nome aqui vai trocado, e as duas instituições que hoje pagam pelo trabalho dele nunca tinham comprado esse serviço.

A mudança de função veio com o programa de modernização aprovado pela diretoria. No contrato antigo, o pagamento juntava plantão noturno, correção de programa quebrado e reescrita de rotina pedida pela área de negócio. No desenho novo, a reescrita foi para a ferramenta e para o time de Java, e sobrou o plantão.

Antes, salário de analista sênior de mainframe com escala de plantão noturno e adicional: R$ 18.400 por mês

Depois da ferramenta de conversão, mesma função sem a fila de reescrita, com adicional de plantão reduzido: R$ 13.900 por mês

A virada veio da teimosia de quem já tinha explicado o mesmo cálculo para seis gerentes. Sérgio passou a registrar, numa planilha simples, cada programa do fechamento noturno com cinco campos: qual decisão o código toma, qual valor ou percentual aplica, qual área responde por ela hoje, qual documento sustenta o número, e o que acontece com o cliente se o trecho for removido.

O retrato apareceu no fim do primeiro ano de planilha. Dos 3.180 programas, 412 tomavam decisão de negócio própria, 187 aplicavam percentual ou limite fixo escrito direto no código, e 19 desses valores não tinham norma, circular, contrato ou ata que explicasse a origem. O 0,7% do programa de 1987 era um deles: desconto aplicado a contas de convênio de uma empresa comprada pelo banco em 1991.

Sérgio montou então um dossiê por regra, com o que precisa estar registrado para uma decisão ser convertida com segurança: qual trecho de código a implementa, qual área assina hoje, qual documento sustenta o valor e qual o impacto financeiro mensal se ela deixar de rodar.

O banco sempre teve duas coisas dentro do mesmo programa, pagas embrulhadas num salário de manutenção. Uma era o código, que qualquer tradutor lê. A outra era a decisão de negócio tomada há trinta anos por gente aposentada, que só existe escrita em COBOL e em nenhum outro lugar do mundo.

Com o dossiê em uso, a conversão de dois módulos parada havia sete meses saiu do papel: o time de Java recebeu a regra escrita antes do código traduzido, e o teste de paridade deixou de acusar diferença de centavos. Quando o diretor de tecnologia perguntou por que aquela fila tinha destravado, Sérgio mandou o dossiê das 19 regras.

A proposta nova saiu no trimestre seguinte, com a unidade trocada para regra assinada:

Levantamento de regra de negócio por módulo crítico, com trecho de código, área responsável, documento de origem e impacto: R$ 22.000 por módulo

Dossiê de paridade para conversão de COBOL para Java, com casos de teste derivados da regra: R$ 16.500 por sistema

Formação de time de negócio em leitura de código legado, turma de até 10 pessoas: R$ 7.800 por turma

Um banco médio e uma processadora de cartões fecharam contrato de ano. Dez meses depois, sem abrir um chamado de plantão noturno, Sérgio fechou um mês em R$ 38 mil com 1 levantamento de módulo e 1 dossiê de paridade.

II Radar de Automação

O tradutor converte sintaxe, e a intenção fica de fora

A automação não apagou o programador de mainframe. Ela apagou o trecho que só transcrevia estrutura de um idioma para outro, deixou exposto o trecho que depende de alguém reconstituir uma decisão antiga, e virou produto o que o banco tratava como conversa de corredor: quem decidiu, quando, com base em qual norma.

O radar de hoje está na tradução com material completo à vista. Estrutura de arquivo, laço de repetição, cálculo aritmético, formatação de campo: tudo que está inteiro dentro do código chega convertido em minutos, e a ferramenta repete a operação em milhares de programas.

A dependência de gente que conhece o sistema não nasceu com a conversão automática. A IBM, no material de lançamento do watsonx Code Assistant for Z em agosto de 2023, falou em 775 bilhões de linhas de COBOL em produção no mundo, e traduzir linguagem não cria dentro do banco a lembrança de por que um desconto de 0,7% foi criado em 1987.

O que mudou foi o preço relativo. Escrever COBOL contra o relógio virou capacidade de assinatura mensal, disponível a qualquer banco que pague a mesma licença. Saber o que o programa decide, com documento e área atrás, custa o que custa quem passou catorze meses interrogando código.

Programas de fechamento noturno abertos e classificados, 3.180 no total

Desses, com decisão de negócio própria dentro do código, 412 no total

Regras vivas sem norma, contrato ou ata que explicasse o valor, 19 no total

A assimetria que o mercado bancário ainda digere tem prazo. A economia da conversão aparece rápido, em custo por linha traduzida e em tamanho de time. O custo de converter uma regra que ninguém entendeu aparece devagar, num fechamento com diferença de centavos e num cliente que liga perguntando por que a tarifa mudou.

"O watsonx Code Assistant for Z permite transformar de forma seletiva e incremental os serviços de negócio em COBOL para código Java bem estruturado."

Kareem Yusuf, IBM, comunicado de lançamento do watsonx Code Assistant for Z, 22 de agosto de 2023

O comunicado descreve bem o lugar que sobrou para quem conhece o sistema: dentro da palavra seletiva. Alguém precisa dizer qual serviço de negócio entra na conversão e o que ele decide antes de virar Java.

Quem segue pago por hora de manutenção é pago por uma etapa que a ferramenta executa mais rápido, e herda o preço dessa comparação. Quem é pago por regra documentada é pago por uma reconstituição com data, fonte e responsável, do tipo que o auditor cobra quando o valor no extrato do cliente muda de um mês para o outro.

Quem banca a edição de hoje

How Jennifer Aniston’s LolaVie brand grew sales 40% with CTV ads

For its first CTV campaign, Jennifer Aniston’s DTC haircare brand LolaVie had a few non-negotiables. The campaign had to be simple. It had to demonstrate measurable impact. And it had to be full-funnel.

LolaVie used Roku Ads Manager to test and optimize creatives — reaching millions of potential customers at all stages of their purchase journeys. Roku Ads Manager helped the brand convey LolaVie’s playful voice while helping drive omnichannel sales across both ecommerce and retail touchpoints.

The campaign included an Action Ad overlay that let viewers shop directly from their TVs by clicking OK on their Roku remote. This guided them to the website to buy LolaVie products.

Discover how Roku Ads Manager helped LolaVie drive big sales and customer growth with self-serve TV ads.

The DTC beauty category is crowded. To break through, Jennifer Aniston’s brand LolaVie, worked with Roku Ads Manager to easily set up, test, and optimize CTV ad creatives. The campaign helped drive a big lift in sales and customer growth, helping LolaVie break through in the crowded beauty category.

Learn more.

Patrocinadores mantêm a edição gratuita

III O movimento de hoje

Um inventário de regra de negócio com dono e data

O movimento de hoje cabe numa planilha de cinco colunas. Ela separa em linhas o que sempre foi pago embrulhado numa hora de manutenção, bem onde a ferramenta entrou.

1. Escolha um sistema que você já sustenta e reconstitua os cinquenta programas mais acionados. Cada linha entra com cinco campos: qual decisão o código toma, qual valor ou percentual aplica, qual área responde por ela hoje, qual documento sustenta o número, e o que muda para o cliente se o trecho sair do ar.

2. Transforme a planilha num dossiê por regra, com data e dono: o trecho que a implementa, a área que assina hoje, o documento de origem quando existe e o impacto financeiro mensal. Marque em vermelho toda regra sem documento. A coluna vermelha separa quem transcreve código de quem reconstitui decisão.

3. Escreva o que o seu dossiê cobre e o que fica de fora. Duas frases bastam: assumo o levantamento, a rastreabilidade até o documento de origem, os casos de teste derivados da regra e a resposta a quem contestar o número; não respondo por regra criada depois da entrega nem por alteração no código sem meu aceite. O limite escrito separa favor de função com preço.

A recusa aparece rápido: a ferramenta converte, o time de Java testa, e o banco sempre teve um veterano no corredor. Quem não paga pelo inventário descobre o preço dele no dia em que o veterano se aposenta e a regra sem documento entra em produção traduzida errada.

A conta ainda está aberta do lado da indústria. A IBM não publica quantas conversões feitas com a ferramenta chegaram a produção sem intervenção humana, e os bancos tratam o resultado como informação interna. Sem número público e auditado, cada instituição decide pela própria medição de paridade, e alguém precisa conduzi-la.

A travessia aqui não é de profissão. Sérgio segue programador, com o mesmo olho para fechamento noturno, arquivo sequencial e teste de paridade. O que ele trocou foi o item do contrato: saiu a hora de manutenção, entrou a regra reconstituída, documentada e assinada.

Recalcular a rota, aqui, começa por uma escolha que cabe no fim de qualquer conversa sobre modernização bancária. Continuar sendo pago por hora de manutenção de código legado, sabendo que a ferramenta traduz o programa antes do seu primeiro chamado, ou cobrar por regra de negócio reconstituída, assumindo a pesquisa, a rastreabilidade e a defesa do número com o seu nome embaixo. As duas contas estão acima.

"Quanto do meu salário pagava a digitação, e quanto pagava a memória do sistema?"