Replataformar ou reestruturar? Como escolher o caminho certo para a modernização de sistemas COBOL legados?

Duas organizações com portfólios COBOL de tamanho semelhante tomam decisões de modernização diferentes. Uma delas opta pela replataforma: migra os programas COBOL para infraestrutura em nuvem usando o AWS Mainframe Modernization ou uma camada de emulação COBOL, preservando o código e eliminando o mainframe físico. Em dezoito meses, reduz os custos de infraestrutura em 40% e o programa é considerado um sucesso. A outra organização tenta a mesma abordagem, encontra dificuldades após doze meses e muda para uma reestruturação arquitetônica, reconstruindo os programas mais críticos como microsserviços Java. Essa mudança custa o dobro do orçamento inicial e leva mais três anos.

Mesmo ponto de partida. Resultados radicalmente diferentes. A diferença não estava nas ferramentas, nos fornecedores ou nas equipes. Estava no fato de que a segunda organização optou pela replataforma para sistemas que apresentavam restrições arquitetônicas que a nova plataforma não conseguia acomodar, dependências de transações CICS, estruturas de arquivos VSAM e requisitos de tempo real que o código replataformado não conseguia satisfazer sem uma reformulação fundamental. A decisão foi tomada antes que alguém compreendesse os sistemas suficientemente bem para tomá-la corretamente.

O que cada caminho realmente significa para o COBOL

As definições genéricas são bem conhecidas. O que importa é o que cada caminho significa especificamente para programas COBOL, onde a arquitetura, o modelo de execução e as estruturas de dados diferem das aplicações modernas de maneiras que afetam diretamente qual caminho é viável.

Replataformando COBOL

A replataformação migra programas COBOL para um novo ambiente operacional, normalmente infraestrutura em nuvem, preservando o código praticamente inalterado. O COBOL é compilado e executado na nova plataforma, seja nativamente (usando o compilador COBOL da IBM no Linux) ou por meio de uma camada de emulação que intercepta chamadas específicas de mainframe (CICS, VSAM, JES) e as traduz para equivalentes nativos da nuvem.

O que a reformulação de uma plataforma mantém:

• O código-fonte COBOL
• A lógica, os cálculos e as regras de negócio do programa.
• O modelo de execução em lote (loops PERFORM, processamento sequencial de arquivos)
• As estruturas de dados (layouts de registro, definições de copybook)
• A estrutura de tarefas JCL (reescrita para o novo agendador, mas logicamente equivalente)

O que a replataforma altera:

• A infraestrutura física (z/OS → Linux na nuvem)
• O subsistema de E/S (VSAM → armazenamento de arquivos gerenciado ou banco de dados, dependendo da ferramenta)
• O agendador de tarefas (JES2/JES3 → AWS Batch, Azure Logic Apps ou equivalente)
• O modelo de custos (faturamento baseado em MIPS → faturamento em nuvem baseado no consumo)

Ponto principal: A replataformação é correta quando o problema reside na plataforma, no custo de execução do z/OS, na dependência da infraestrutura ou no modelo de faturamento do MIPS. É o caminho errado quando o problema está no código ou na arquitetura.

Reestruturação de COBOL

A reestruturação altera o projeto fundamental do sistema. A lógica de negócios é preservada ou derivada novamente do código-fonte COBOL, mas é implementada em uma nova linguagem, com um novo modelo de execução e em uma nova camada de dados. O resultado é um sistema que faz o que o COBOL fazia, mas que não se assemelha ao COBOL em estrutura.

Que mudanças de reestruturação:

• A linguagem de programação (COBOL → Java, Python, Go, C#)
• O modelo de execução (em lote → orientado a eventos, em fluxo contínuo ou baseado em API)
• A camada de dados (arquivos VSAM → banco de dados relacional, NoSQL, armazenamento nativo da nuvem)
• O modelo de transação (CICS pseudo-conversacional → serviços RESTful sem estado)
• O padrão de integração (conjuntos de dados compartilhados → contratos de API, filas de mensagens)

O que a reestruturação arquitetônica deve preservar:

• Todas as regras de negócio implementadas pelo COBOL, incluindo casos extremos não documentados.
• Cada cálculo, incluindo as características de precisão numérica da aritmética decimal compactada
• Toda transformação de dados, incluindo conversões implícitas em instruções MOVE.
• Todas as condições de erro, incluindo os códigos de STATUS DE ARQUIVO específicos e os comportamentos de término anormal dos quais os sistemas subsequentes podem depender.

Atenção: O modo de falha mais comum em reestruturações é descobrir que o COBOL continha regras de negócio que nunca foram documentadas em nenhum outro lugar. O novo sistema se comporta de maneira diferente do antigo em casos específicos, não por erro de implementação, mas porque a especificação estava incompleta. A lógica de negócio deve ser extraída e documentada do código-fonte COBOL antes do início da reestruturação.

Fatores específicos do COBOL que alteram essa decisão

As estruturas genéricas de modernização tratam a replataforma e a reestruturação como decisões baseadas principalmente em custo, cronograma e risco. Para COBOL, diversos fatores técnicos específicos da linguagem e de seu ambiente de execução influenciam fortemente a decisão em uma ou outra direção.

Dependências de transação CICS

O CICS (Customer Information Control System) é o middleware de processamento de transações que muitos programas COBOL utilizam para cargas de trabalho interativas. Um programa COBOL que realiza chamadas EXEC CICS possui uma dependência implícita do servidor de transações CICS para gerenciamento de telas, comunicação com terminais, distribuição de tarefas e controle de programas.

Implicações da replataforma: Ferramentas como a emulação CICS da Micro Focus, o OpenFrame e alguns recursos de Modernização de Mainframe da AWS emulam a semântica do CICS. Se o uso do CICS for padrão e bem-comportado, a emulação pode funcionar. Se o programa depender de funcionalidades internas do CICS, manipulação de áreas de comunicação, controle de pontos de sincronização, armazenamento em nível de tarefa, a fidelidade da emulação será prejudicada.

Implicação da reestruturação arquitetônica: Um programa CICS convertido para uma API REST deve ter seu modelo de transação pseudoconversacional redesenhado como interações sem estado. Esta é uma mudança arquitetural, não uma tradução de código.

Sinalizador que aponta para a necessidade de reestruturação: Uso intensivo de CICS com manipulação complexa de áreas de comunicação, encadeamento de transações no back-end ou lógica de ponto de sincronização.

Arquitetura de Arquivos VSAM

VSAM (Virtual Storage Access Method) é o sistema de arquivos indexado usado pela maioria dos programas de produção COBOL. Os arquivos VSAM possuem padrões de acesso específicos, como KSDS (sequencial com chave), ESDS (sequencial por entrada) e RRDS (registro relativo), que não têm equivalentes diretos no armazenamento nativo em nuvem.

Implicações da replataforma: As camadas de emulação traduzem as operações de leitura e gravação do VSAM para as operações subjacentes de arquivo ou banco de dados. Para acesso sequencial simples ou baseado em chave, isso funciona. No entanto, para acessos complexos com chaves alternativas, clusters VSAM compartilhados entre vários programas ou padrões de acesso aleatório que exigem alto desempenho, a emulação adiciona latência e complexidade.

Implicações da reestruturação: Substituir o VSAM por um banco de dados relacional exige mapear os layouts de registro para os esquemas de tabela, lidar com as conversões implícitas de tipo de dados e reescrever todos os acessos a arquivos para usar SQL ou um ORM.

Sinalizando a necessidade de uma reestruturação: arquivos VSAM compartilhados entre vários programas, padrões alternativos de acesso ao índice ou requisitos de desempenho em tempo real que a emulação não consegue atender.

Requisitos de processamento em lote versus em tempo real

Os programas em lote COBOL são projetados para processar grandes volumes de registros sequencialmente em janelas de processamento agendadas. Muitos sistemas bancários, de seguros e governamentais ainda executam trabalhos em lote noturnos que processam milhões de transações, geram relatórios e atualizam arquivos mestres.

Implicações da replataforma: A semântica de processamento em lote se adapta bem à execução em lote na nuvem (AWS Batch, Azure Batch). O modelo de processamento sequencial sobrevive à mudança de plataforma. Se o requisito for simplesmente executar o mesmo trabalho em lote em uma infraestrutura mais barata, a replataforma resolve isso diretamente.

Implicações da reestruturação da arquitetura: Se os requisitos de negócio mudaram — de processamento em lote noturno para processamento quase em tempo real, de troca de arquivos para integração de APIs, de execuções em lote monolíticas para microsserviços acionados individualmente —, a replataforma não atenderá aos novos requisitos. A arquitetura precisa ser alterada.

Sinalizando a necessidade de uma reestruturação: Requisitos das partes interessadas para processamento em tempo real, integração baseada em API, arquitetura orientada a eventos ou tempos de resposta inferiores a um segundo, que a semântica de lote não consegue fornecer.

Lógica de negócios incorporada sem especificação externa

Este é o fator específico do COBOL mais subestimado. Os principais riscos incluem a perda de regras de negócio críticas incorporadas em código com décadas de existência e a documentação insuficiente do comportamento do sistema. Os programas COBOL frequentemente contêm a única especificação sobrevivente de uma regra de negócio. A regulamentação que exigia um cálculo específico foi escrita em 1983. O analista de negócios que a compreendia aposentou-se em 2001. O código COBOL não é apenas uma implementação, é a documentação.

Implicação da replataforma: As regras de negócio permanecem intactas porque o código é preservado. Este é um dos argumentos mais fortes a favor da replataforma.

Implicação para a reestruturação: As regras de negócio devem ser extraídas do código-fonte COBOL antes de serem reimplementadas. <cite index=”28-1″>Código não documentado e fortemente acoplado multiplica o esforço em todas as fases.</cite> Se essa extração for incompleta, o novo sistema terá uma especificação diferente da antiga, e essas diferenças aparecerão em produção.

Uma estrutura de decisão: oito perguntas

Antes de escolher um caminho, estas oito perguntas fornecem as evidências necessárias para tomar a decisão com confiança, em vez de com base em suposições.

1. Qual é o principal fator que impulsiona essa modernização?

• Custo da infraestrutura → a reformulação da plataforma é suficiente
• Dependência de plataforma (z/OS) → a replataforma é suficiente
• Requisitos em tempo real → é necessário reestruturar a arquitetura
• Requisitos de integração (API) → provavelmente será necessário reestruturar a arquitetura
• Manutenibilidade / disponibilidade de talentos → reestruturar ou refatorar

2. Qual é o nível de acoplamento com o CICS? Enumere todas as chamadas EXEC do CICS. Conte os programas com mais de vinte comandos CICS distintos. Programas com alto nível de acoplamento com o CICS são candidatos inadequados para replataforma se a fidelidade da emulação for incerta.

3. Quais são os padrões de acesso ao VSAM? Identifique programas que acessam arquivos VSAM com chaves alternativas, clusters compartilhados ou acesso aleatório que impacta o desempenho. Esses são indicadores de risco de replataforma.

4. A lógica de negócios foi documentada externamente? Se o código-fonte COBOL for a única especificação autorizada, a reestruturação requer a extração da lógica de negócios como etapa prévia, e não como uma tarefa paralela.

5. Qual é a tolerância da janela de lote? Se a empresa exigir o mesmo modelo de processamento em lote a um custo menor, migre a plataforma. Se a empresa exigir que o mesmo processamento esteja disponível em tempo real, reestruture a arquitetura.

6. Qual é a complexidade de dependência? Um programa com cinquenta dependências downstream, conjuntos de dados, chamados subprogramas e chamadores JCL, apresenta um risco de reestruturação maior do que um utilitário independente. A estrutura de dependência determina a sequência de migração e o escopo dos testes.

7. Qual a porcentagem do código que está morto? O código morto excluído do escopo antes de qualquer conversão reduz o esforço em ambos os caminhos. Para programas de reestruturação, o código morto que não for excluído é convertido com custo total e, em seguida, descartado.

8. Qual é a distribuição de complexidade? Complexidade ciclomática acima de 50 por programa, ou mais de vinte copybooks incluídos, indica programas que exigem reestruturação dispendiosa e apresentam risco de replataforma. Estes justificam atenção individual em vez de atribuição em massa de caminhos.

Aplicando a estrutura: quatro perfis de sistema COBOL

Perfil	Particularidades	Caminho recomendado	análise racional
utilitário de lote estável	Entrada/saída sequencial de arquivos, sem CICS, lógica bem documentada, baixa complexidade.	Replataforma	O problema é o custo da plataforma; o código não é a restrição.
transação online com uso intensivo de CICS	Uso intensivo de EXEC CICS, dependências de comarea, modelo pseudoconversacional	Rearquitetar	O risco de emulação do CICS é alto; é provável que haja requisitos de tempo real.
processador de arquivos mestre VSAM	Padrões de acesso VSAM complexos, compartilhados por vários programas, alto volume de leitura	Primeiro, avalie a fidelidade da emulação; se a emulação se mantiver, mude de plataforma.	A emulação VSAM é a variável de decisão.
tesouraria de lógica de negócios	Regras não documentadas, sem especificação externa, alta importância regulatória	Primeiro, extraia a lógica e, em seguida, escolha.	Reestruturar a arquitetura sem a extração prévia da lógica de negócios é inaceitável.

Ponto-chave: <cite index=”30-1″>Na prática, grandes empresas adotam abordagens mistas: replataformam as partes estáveis, refatoram o código de difícil manutenção, reescrevem os poucos sistemas que precisam de novas funcionalidades e desativam o que não é mais utilizado.</cite> A decisão não é tomada em nível de portfólio, mas sim em nível de carga de trabalho, sendo aplicada individualmente a cada programa ou grupo de programas com base nas evidências.

A abordagem híbrida: primeiro, reformule a plataforma; depois, reestruture quando necessário.

Uma regra prática: para estancar rapidamente as perdas, mude a hospedagem ou a plataforma e, em seguida, refatore ou reestruture os sistemas que são verdadeiros diferenciais competitivos.

Para a maioria das organizações com grandes portfólios de COBOL, a sequência prática é:

Fase 1: Reestruturar as plataformas dos candidatos mais óbvios. Programas sem CICS, com E/S sequencial simples, lógica documentada e baixa complexidade podem ser reestruturados com esforço e risco previsíveis. Isso proporciona uma rápida redução nos custos de infraestrutura e aumenta a confiança organizacional.

Fase 2: Avaliar os programas complexos. Programas com acoplamento CICS, padrões VSAM complexos ou lógica de negócios não documentada exigem análise individual antes da escolha de um caminho. É aqui que a extração da lógica de negócios e a análise estrutural determinam se a reestruturação é necessária e qual seria o seu escopo.

Fase 3: Reestruturar os programas com bloqueios arquitetônicos. Os programas que não conseguem atender aos requisitos de negócio na infraestrutura replataformada, aos requisitos de tempo real, à integração de APIs e ao processamento orientado a eventos são reestruturados usando o padrão Strangler Fig: construindo o novo serviço em paralelo com o programa replataformado, roteando o tráfego progressivamente para a nova implementação à medida que cada componente é validado e desativando o programa antigo quando todo o tráfego tiver migrado.

Fase 4: Desativar código obsoleto. Os programas identificados como obsoletos durante a análise estrutural são excluídos de ambos os caminhos e desativados, reduzindo os custos contínuos de manutenção sem qualquer esforço de conversão.

---

O que a análise deve produzir antes de qualquer decisão ser tomada.

A estrutura de decisão acima produz melhores respostas quando as entradas são evidências em vez de estimativas. A análise estrutural que fornece essas entradas requer a análise do código-fonte COBOL propriamente dito, em vez de depender da documentação ou do conhecimento do desenvolvedor.

O que a análise deve estabelecer para cada programa:

Um inventário completo de programas, incluindo aqueles que não estão documentados. Em grandes ambientes COBOL, o número de programas não documentados frequentemente ultrapassa 20% do total. Um gráfico de dependências mostrando quais programas chamam quais outros, quais conjuntos de dados são compartilhados e quais jobs JCL invocam quais programas. Inventário de comandos CICS para cada programa, incluindo a quantidade, os tipos e a complexidade das chamadas. Análise de padrões de acesso VSAM, incluindo os métodos de acesso, os arquivos compartilhados entre os programas e os arquivos com índices alternativos. Distribuição da complexidade ciclomática, indicando quais programas são estruturalmente simples e quais apresentam alto risco de conversão. Identificação de código morto, ou seja, quais programas e parágrafos não possuem caminhos de execução de entrada. Extração da lógica de negócios, identificando as regras implementadas por cada programa, em um formato que possa ser usado para validar a saída de qualquer um dos caminhos.

Sem esse inventário, a decisão sobre o caminho a seguir é tomada com base em informações incompletas. Os programas são designados para replataforma com base em suposições que se mostram errôneas quando a emulação revela restrições arquitetônicas que não eram visíveis durante o planejamento.

Como SMART TS XL Produz as evidências pré-decisão.

SMART TS XL'S modernização legada A análise automatiza o inventário estrutural descrito acima, analisando simultaneamente cada programa COBOL, copybook, job JCL e referência de arquivo VSAM para construir o modelo de dependência unificado que torna a decisão de caminho baseada em evidências.

O mapeamento de dependências da aplicação gera o grafo de chamadas entre programas e o mapa de compartilhamento de conjuntos de dados que determina a complexidade das dependências, o fator que afeta mais diretamente tanto o risco de emulação de replataforma quanto o escopo e a sequência da reestruturação da arquitetura.

A análise estática de código gera métricas de complexidade, inventários de chamadas CICS e identificação de código morto para cada programa no portfólio. Programas acima do limite de complexidade ciclomática e com forte acoplamento CICS são automaticamente identificados como candidatos a reestruturação ou avaliação, em vez de serem atribuídos em massa para replataforma.

A expansão JCL resolve parâmetros simbólicos e constrói a cadeia de dependência completa da execução em lote, definindo quais tarefas JCL invocam quais programas, em qual sequência e com quais conjuntos de dados, fornecendo o contexto operacional que determina como a saída de cada caminho deve se comportar para atender ao agendamento do lote.

A capacidade de análise de impacto torna o escopo de cada caminho concreto antes do início do programa: para qualquer programa selecionado para reestruturação, a análise de impacto enumera todos os programas dependentes que devem ser atualizados, retestados ou coordenados com o componente reestruturado. Para candidatos à replataforma, a mesma análise identifica quais conjuntos de dados e subprogramas compartilhados criam dependências entre programas que devem ser tratadas de forma consistente.

A busca corporativa torna todo o inventário consultável em todo o programa: encontre todos os programas que usam um comando CICS específico, todos os programas que acessam um cluster VSAM específico, todos os copybooks que definem uma estrutura de dados específica, em segundos, em milhões de linhas de COBOL.

As organizações que tomam essa decisão corretamente são aquelas que a baseiam em evidências estruturais, e não em suposições do plano do projeto. A evidência estrutural é o que SMART TS XL produz.