☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta IBM ADDI. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM ADDI. Mostrar todas as mensagens

sexta-feira, 30 de maio de 2025

CASE Tools - Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

 

Bellacosa Mainframe e os primeiros passos em Case Tools

☕ Um Café no Bellacosa Mainframe

CASE Tools

Muito Além da Geração de Código: A Tecnologia que Mudou a Engenharia de Software para Sempre

"As CASE Tools nunca tiveram como objetivo substituir programadores. Elas nasceram para transformar programação em Engenharia de Software. Quarenta anos depois, continuam influenciando praticamente todas as ferramentas modernas, da UML à Inteligência Artificial."


Introdução

Quando alguém fala em CASE Tools, é comum ouvir a resposta:

"Isso é tecnologia antiga."

Na realidade, poucas afirmações estão tão distantes da verdade.

As CASE Tools podem até não aparecer mais nas manchetes, mas seus conceitos continuam presentes em praticamente todas as plataformas modernas de desenvolvimento.

Se você utiliza:

  • UML;

  • Enterprise Architect;

  • IBM Application Discovery;

  • IBM Developer for z/OS;

  • GitHub Copilot;

  • IBM watsonx Code Assistant;

  • Low-Code;

  • No-Code;

  • DevOps;

  • Model Driven Engineering;

você está, direta ou indiretamente, utilizando ideias que nasceram há mais de quatro décadas.

Para quem trabalha com IBM Mainframe, compreender CASE Tools significa entender a origem da engenharia que permitiu a bancos, seguradoras e governos manterem sistemas críticos funcionando por décadas.


Afinal, o que são CASE Tools?

CASE significa:

Computer-Aided Software Engineering

ou

Engenharia de Software Assistida por Computador.

O objetivo nunca foi substituir programadores.

O objetivo sempre foi automatizar tarefas repetitivas da Engenharia de Software.

Em vez de começar escrevendo código, a ideia era começar criando modelos.

A partir desses modelos, as ferramentas poderiam gerar:

  • programas COBOL;

  • tabelas DB2;

  • layouts VSAM;

  • telas CICS;

  • documentação;

  • diagramas;

  • dicionários de dados;

  • especificações técnicas.

O código passava a ser consequência do projeto, não seu ponto de partida.


Por que elas surgiram?

Durante as décadas de 1970 e 1980 a indústria enfrentou a chamada Crise do Software.

Os computadores evoluíam rapidamente, mas os sistemas tornavam-se cada vez maiores e mais difíceis de manter.

Projetos atrasavam.

Custos aumentavam.

A documentação ficava desatualizada.

Mudanças simples provocavam erros inesperados.

As CASE Tools surgiram para trazer disciplina, padronização, rastreabilidade e reutilização ao desenvolvimento de software.


O grande diferencial

A maior inovação das CASE Tools não foi a geração automática de código.

Foi a criação de um repositório de conhecimento.

Nele eram armazenados:

  • processos;

  • entidades;

  • regras de negócio;

  • relacionamentos;

  • programas;

  • tabelas;

  • dependências;

  • documentação.

Hoje chamamos isso de metadados.

Na época, era uma revolução.


O papel no IBM Mainframe

Foi no Mainframe que as CASE Tools demonstraram todo o seu potencial.

Imagine uma instituição financeira com:

  • milhões de clientes;

  • milhares de transações CICS;

  • centenas de bancos DB2;

  • milhares de arquivos VSAM;

  • milhões de linhas de COBOL.

Sem uma visão integrada, compreender o impacto de uma simples alteração seria praticamente impossível.

As CASE Tools permitiram analisar dependências, gerar documentação, identificar impactos e padronizar o desenvolvimento, tornando viável a evolução contínua desses sistemas.


Elas desapareceram?

Não.

Mudaram de nome.

Os princípios continuam presentes em tecnologias modernas como:

  • UML;

  • Model Driven Development (MDD);

  • Model Driven Engineering (MDE);

  • Domain-Driven Design (DDD);

  • Low-Code;

  • No-Code;

  • DevOps;

  • Infrastructure as Code;

  • Inteligência Artificial aplicada ao desenvolvimento.

A engenharia baseada em modelos continua mais viva do que nunca.


O que isso significa para o programador COBOL?

Significa que escrever código já não é suficiente.

O profissional moderno precisa compreender:

  • arquitetura;

  • modelagem;

  • regras de negócio;

  • engenharia reversa;

  • análise de impacto;

  • documentação automática;

  • integração entre sistemas;

  • automação.

Quem domina esses conceitos consegue evoluir sistemas complexos com muito mais segurança.


Esta série completa

Para explorar esse universo em profundidade, preparamos uma série especial dividida em quatro artigos.

📘 Parte 1 — A origem das CASE Tools

Conheça a história da Crise do Software, o nascimento da Engenharia de Software, os primeiros CASE Tools e como surgiu a ideia de modelar sistemas antes de escrever código.

Você entenderá por que essa tecnologia foi considerada revolucionária e como ela mudou a forma de construir aplicações corporativas.

https://eljefemidnightlunch.blogspot.com/2025/01/case-tools-tecnologia-que-tentou.html


📗 Parte 2 — Upper CASE, Lower CASE e Integrated CASE

Descubra como funcionavam as diferentes categorias de CASE Tools.

Entenda conceitos como:

  • Upper CASE;

  • Lower CASE;

  • I-CASE;

  • Forward Engineering;

  • Reverse Engineering;

  • Round Trip Engineering;

  • Repositórios;

  • Dicionários de Dados;

  • Metodologias clássicas de Engenharia de Software.

É a base conceitual que influenciou praticamente todas as ferramentas modernas.

https://eljefemidnightlunch.blogspot.com/2025/02/case-tools-upper-case-lower-case-i-case.html


📙 Parte 3 — CASE Tools no IBM Mainframe

Veja como bancos, seguradoras e órgãos governamentais utilizaram CASE Tools para administrar enormes ambientes COBOL.

Conheça a relação dessas ferramentas com:

  • COBOL;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • JCL;

  • IBM Application Discovery (ADDI);

  • IBM Developer for z/OS;

  • CA Gen;

  • Enterprise Architect;

  • PowerDesigner.

Uma leitura indispensável para quem trabalha com IBM Z.

https://eljefemidnightlunch.blogspot.com/2025/03/case-tools-case-tools-no-ibm-mainframe.html


📕 Parte 4 — Das CASE Tools à Inteligência Artificial

Entenda por que Low-Code, No-Code, MDD, MDE, DDD, DevOps e Inteligência Artificial representam uma evolução natural dos princípios introduzidos pelas CASE Tools.

Descubra como ferramentas como o IBM watsonx Code Assistant e assistentes baseados em IA continuam seguindo a mesma filosofia: automatizar tarefas repetitivas para que os engenheiros concentrem seus esforços na solução dos problemas de negócio.

https://eljefemidnightlunch.blogspot.com/2025/04/case-tools-das-case-tools-inteligencia.html


O maior legado das CASE Tools

Talvez a maior contribuição das CASE Tools tenha sido mudar a forma como enxergamos o desenvolvimento de software.

Elas mostraram que sistemas complexos não sobrevivem por décadas apenas porque utilizam uma boa linguagem de programação.

Eles sobrevivem porque foram construídos sobre princípios sólidos de engenharia.

Modelagem.

Padronização.

Rastreabilidade.

Reutilização.

Documentação.

Governança.

Esses conceitos permanecem essenciais, independentemente da linguagem, da plataforma ou da tecnologia utilizada.


Conclusão

A história das CASE Tools é, na verdade, a história da própria Engenharia de Software moderna.

O nome pode ter desaparecido das apresentações comerciais, mas suas ideias continuam presentes em praticamente todas as tecnologias atuais.

Quando utilizamos UML, geramos APIs automaticamente, criamos pipelines DevOps, fazemos engenharia reversa de aplicações COBOL ou pedimos que uma Inteligência Artificial produza código, estamos ampliando um conceito que nasceu há mais de quarenta anos.

Para o profissional de IBM Mainframe, conhecer CASE Tools não significa estudar uma tecnologia do passado.

Significa compreender por que os sistemas que movimentam bancos, seguradoras, bolsas de valores e governos continuam evoluindo com segurança após décadas de operação.

A tecnologia muda.

As ferramentas mudam.

As linguagens mudam.

Mas a Engenharia de Software continua sendo o verdadeiro diferencial.

"Quem aprende apenas uma linguagem de programação constrói aplicações. Quem compreende Engenharia de Software constrói sistemas capazes de atravessar gerações. Esse sempre foi o legado das CASE Tools."

 

segunda-feira, 24 de março de 2025

CASE Tools : CASE Tools no IBM Mainframe – Parte III

 

Bellacosa Mainframe apresenta case tools parte III

☕ Um Café no Bellacosa Mainframe

CASE Tools – Parte 3

CASE Tools no IBM Mainframe

Como Bancos, Seguradoras e Governos Construíram Sistemas que Duram Décadas

"Quem olha apenas para milhões de linhas de COBOL imagina um oceano de código. Quem conhece as CASE Tools enxerga algo muito maior: um enorme mapa de conhecimento que permitiu manter esses sistemas vivos por décadas."


Introdução

Até agora vimos como nasceram as CASE Tools e como elas transformaram a Engenharia de Software.

Mas existe uma pergunta que muitos programadores COBOL fazem:

O que isso tem a ver com Mainframe?

A resposta é:

Tudo.

Na verdade, poucos ambientes aproveitaram tanto as CASE Tools quanto o IBM Mainframe.

Enquanto aplicações desktop normalmente possuíam dezenas de programas, um banco podia possuir:

  • 200.000 programas COBOL

  • milhares de transações CICS

  • milhares de Jobs

  • centenas de bancos DB2

  • milhares de arquivos VSAM

  • milhões de regras de negócio

Gerenciar tudo isso manualmente seria impossível.

Foi justamente aí que as CASE Tools encontraram seu ambiente ideal.


O Mainframe sempre foi uma plataforma de engenharia

Existe um mito curioso.

Muitas pessoas imaginam que o Mainframe nasceu para executar COBOL.

Na realidade, ele nasceu para executar negócios.

O COBOL é apenas um dos componentes.

Um sistema bancário normalmente envolve:

Usuários

↓

Canais Digitais

↓

APIs

↓

CICS

↓

Programas COBOL

↓

DB2

↓

VSAM

↓

IMS

↓

MQ

↓

Batch

↓

Relatórios

↓

Auditoria

Agora imagine documentar isso manualmente.

Quase impossível.


A explosão dos sistemas corporativos

Durante os anos 80 surgiram projetos gigantescos.

Bancos nacionais.

Seguradoras.

Previdência.

Telecomunicações.

Receita Federal.

INSS.

Grandes varejistas.

Cada organização possuía milhares de programas.

Um simples cadastro de cliente podia depender de centenas de componentes.


O problema da documentação

Imagine um programa COBOL chamado

CB0010

O que ele faz?

Ninguém sabe.

Agora imagine milhares deles.

CB0011

CB0012

CB0013

CB0014

...

CB8945

Sem documentação isso vira um pesadelo.

Foi exatamente esse cenário que impulsionou as CASE Tools.


O repositório virou o coração da empresa

As CASE Tools introduziram uma ideia revolucionária.

O conhecimento do sistema não deveria estar apenas no código.

Ele deveria existir em um repositório corporativo.

Nesse repositório eram registrados:

  • programas

  • tabelas

  • arquivos

  • transações

  • telas

  • menus

  • relacionamentos

  • processos

  • regras

  • usuários

  • departamentos

  • dependências

Hoje chamaríamos isso de metadados.

Na época era algo extremamente inovador.


Um programa nunca trabalha sozinho

Considere um simples saque em caixa eletrônico.

O cliente vê apenas uma tela.

Por trás dela, entretanto, ocorre uma verdadeira orquestra.

ATM

↓

API

↓

CICS

↓

COBOL

↓

DB2

↓

VSAM

↓

MQ

↓

Auditoria

↓

SMF

↓

Logs

Cada componente depende do outro.

Modificar apenas um pode afetar dezenas de sistemas.


É aqui que nasce a Análise de Impacto

Imagine alterar um campo.

CPF

↓

11 posições

↓

14 posições

O desenvolvedor pensa:

"É apenas um campo."

A CASE Tool responde:

Não.

Ela afeta:

  • 1.842 programas COBOL

  • 216 transações CICS

  • 437 Jobs

  • 52 Stored Procedures

  • 31 APIs

  • 418 telas

  • 97 relatórios

Esse tipo de informação vale milhões de reais em grandes instituições.


COBOL e CASE

Ao contrário do que muitos imaginam, CASE não substituía COBOL.

Ela produzia COBOL.

Por exemplo.

O analista modelava:

Cliente

Conta

Saldo

Extrato

A ferramenta podia gerar automaticamente:

  • Data Division

  • File Section

  • Working-Storage

  • SQL

  • CICS Commands

  • Skeleton do programa

O desenvolvedor implementava apenas as regras específicas.


O ganho de produtividade

Considere dois cenários.

Desenvolvimento tradicional

Analista

↓

Documento

↓

Programador

↓

COBOL

↓

Testes

↓

Documentação

Agora utilizando CASE.

Modelo

↓

Repository

↓

COBOL

↓

DB2

↓

Documentação

↓

Testes

Observe que várias atividades repetitivas desaparecem.


CASE e CICS

Imagine desenvolver uma nova transação.

Sem CASE.

Era necessário:

  • criar BMS Map;

  • definir transação;

  • programar COBOL;

  • criar documentação;

  • atualizar diagramas;

  • registrar dependências.

Com CASE.

Grande parte disso era produzida automaticamente.


CASE e DB2

Outro grande benefício.

Imagine criar uma nova entidade.

CLIENTE

A ferramenta poderia gerar:

CREATE TABLE CLIENTE

Depois.

Gerar automaticamente:

  • programa COBOL;

  • SQL;

  • cursores;

  • layouts;

  • documentação;

  • dicionário de dados.

Tudo sincronizado.


CASE e VSAM

Mesmo bancos que utilizavam VSAM eram beneficiados.

A ferramenta conhecia:

  • KSDS

  • ESDS

  • RRDS

  • campos

  • chaves

  • índices

  • layouts

Se um campo aumentasse de tamanho.

Todo o ambiente poderia ser atualizado.


CASE e IMS

O mesmo acontecia com IMS.

Imagine modificar um segmento.

A CASE Tool informava imediatamente:

  • DBD

  • PSB

  • Programas COBOL

  • Batchs

  • Transações IMS/DC

Tudo relacionado.


CASE e JCL

Pouca gente lembra.

Mas diversas CASE Tools também geravam JCL.

Por exemplo.

Após criar um novo programa.

Ela podia produzir automaticamente.

  • Compile JCL

  • Link-edit

  • Bind DB2

  • Execução Batch

  • Testes

Hoje pipelines de DevOps fazem exatamente isso.


CASE e documentação

Um dos maiores custos da TI sempre foi manter documentação atualizada.

Imagine alterar um campo.

Sem CASE.

Era necessário atualizar:

  • documento funcional;

  • documento técnico;

  • layout;

  • diagrama;

  • especificação;

  • manual.

Com CASE.

Tudo era atualizado automaticamente.


Engenharia Reversa em Mainframe

Imagine um banco comprado por outro banco.

O novo proprietário encontra.

27 milhões

de linhas COBOL

Sem documentação.

Como entender?

A solução.

Reverse Engineering.

Ferramentas analisam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • IMS

  • MQ

Depois produzem.

  • diagramas

  • mapas

  • dependências

  • arquitetura

Hoje isso continua acontecendo.


IBM AD — O sucessor moderno

Uma das ferramentas mais conhecidas atualmente é o

IBM Application Discovery and Delivery Intelligence (IBM ADDI).

Ela faz exatamente o que as antigas CASE Tools faziam.

Por exemplo.

Analisa:

  • COBOL

  • PL/I

  • JCL

  • Easytrieve

  • Assembler

  • CICS

  • IMS

  • DB2

Depois constrói um enorme mapa de dependências.

É uma CASE Tool moderna.

Embora o nome tenha mudado.


IBM Developer for z/OS

O IDz também herdou diversos conceitos CASE.

Ele permite:

  • navegação entre programas;

  • referências cruzadas;

  • análise de chamadas;

  • impacto;

  • documentação;

  • integração Git.

Não é apenas uma IDE.

É uma ferramenta de engenharia.


Rational Rose

Durante muitos anos.

Foi praticamente sinônimo de UML.

Diversas empresas modelavam sistemas inteiros.

Depois implementavam COBOL.

Java.

C++.

PL/I.

Tudo a partir desses modelos.


Enterprise Architect

Ainda hoje é uma das ferramentas preferidas para arquitetura corporativa.

Permite modelar:

  • processos;

  • aplicações;

  • infraestrutura;

  • APIs;

  • bancos de dados.

É um descendente direto da filosofia CASE.


CA Gen

Talvez o exemplo mais famoso.

Antigamente chamado

Texas Instruments IEF.

Depois

COOL:Gen.

Mais tarde

CA Gen.

Ele conseguia gerar aplicações corporativas completas.

Milhares de sistemas bancários nasceram dessa ferramenta.

Muitos continuam em produção.


Oracle Designer

Muito utilizado em ambientes Oracle.

Gerava:

  • banco;

  • forms;

  • reports;

  • documentação;

  • SQL.

Outro exemplo clássico de CASE.


PowerDesigner

Muito conhecido entre DBAs.

Excelente para:

  • modelagem;

  • engenharia reversa;

  • documentação;

  • impacto.

Continua extremamente utilizado.


O que mudou com DevOps?

Muitos acreditam que DevOps substituiu CASE.

Na realidade.

DevOps automatiza outra parte do processo.

CASE automatiza engenharia.

DevOps automatiza entrega.

Os dois se complementam.

Veja.

CASE

↓

Modelo

↓

Código

↓

Git

↓

Pipeline

↓

Testes

↓

Deploy

Hoje eles trabalham juntos.


E a Inteligência Artificial?

A IA trouxe uma nova camada.

Antes.

O modelo gerava código.

Hoje.

O engenheiro descreve um requisito.

A IA cria:

  • código;

  • documentação;

  • testes;

  • diagramas.

Mas existe uma diferença importante.

A CASE conhecia toda a arquitetura.

A IA normalmente conhece apenas o contexto fornecido.

Quando ambas trabalham juntas, os resultados são muito mais consistentes.


O impacto na carreira do programador COBOL

Há vinte anos, conhecer apenas COBOL era suficiente para muitos projetos.

Hoje, o profissional mais valorizado entende também:

  • arquitetura corporativa;

  • modelagem;

  • engenharia reversa;

  • análise de impacto;

  • documentação automática;

  • pipelines de DevOps;

  • APIs;

  • governança de software.

Essas competências tornam o desenvolvedor capaz de evoluir sistemas críticos sem comprometer sua estabilidade.


Como um banco moderno trabalha

Imagine a solicitação:

"Adicionar PIX Internacional."

O processo raramente começa pelo código.

Normalmente segue um fluxo semelhante:

Requisito

↓

Modelagem

↓

Impacto

↓

Arquitetura

↓

Análise CASE

↓

COBOL

↓

Testes

↓

Produção

Observe que programar representa apenas uma etapa.

As CASE Tools ensinaram exatamente isso.


O futuro do Mainframe

Muito se fala em modernização.

Mas modernizar não significa reescrever tudo.

Na maioria das vezes significa:

  • compreender;

  • documentar;

  • medir impactos;

  • expor APIs;

  • integrar novas tecnologias;

  • preservar regras de negócio.

E isso sempre foi a essência das CASE Tools.


Lições para o programador COBOL

Se você trabalha com Mainframe, algumas conclusões são inevitáveis:

  • O código é apenas uma parte do sistema.

  • A documentação deve refletir a realidade do ambiente.

  • Toda alteração precisa ser analisada antes da implementação.

  • Modelagem reduz riscos e facilita a manutenção.

  • Ferramentas de engenharia aumentam produtividade sem substituir o desenvolvedor.

  • Sistemas legados bem documentados tornam-se ativos estratégicos para a organização.

  • IA e CASE não competem; juntas, ampliam a capacidade dos engenheiros de software.


Conclusão

O IBM Mainframe foi um dos maiores laboratórios da Engenharia de Software corporativa. Em ambientes onde um erro pode interromper pagamentos, comprometer milhões de clientes ou afetar serviços essenciais, improvisação nunca foi uma opção.

Foi nesse contexto que as CASE Tools encontraram seu maior valor. Elas transformaram conhecimento em modelos, modelos em código, código em documentação e documentação em governança.

Embora muitas ferramentas clássicas tenham desaparecido ou mudado de nome, seus princípios permanecem vivos em soluções como IBM ADDI, IBM Developer for z/OS, Enterprise Architect, PowerDesigner e em plataformas modernas de DevOps e Inteligência Artificial.

Para o programador COBOL, compreender CASE não é estudar uma tecnologia antiga. É entender como grandes organizações conseguem manter aplicações críticas evoluindo por décadas com segurança, rastreabilidade e qualidade.

No próximo artigo encerraremos esta série explorando a evolução das CASE Tools para Low-Code, No-Code, Model Driven Development (MDD), Model Driven Engineering (MDE) e Inteligência Artificial, mostrando por que a automação da engenharia de software continua mais relevante do que nunca.

"As melhores ferramentas nunca tiveram como objetivo substituir engenheiros. Elas existem para que os engenheiros gastem menos tempo repetindo tarefas e mais tempo resolvendo problemas que realmente importam. Essa era a missão das CASE Tools ontem. Continua sendo a missão da Inteligência Artificial hoje."

 

segunda-feira, 4 de janeiro de 2021

Big Ball of Mud Rules: Quando um Programador COBOL Descobriu que a Matrix Não Era um Sistema... Era uma Enorme Bola de Lama Digital

 

Bellacosa Mainframe e a big ball of mud rules

☕ Um Café no Bellacosa Mainframe

Big Ball of Mud Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era um Sistema... Era uma Enorme Bola de Lama Digital

"A Matrix não caiu porque era antiga. Ela quase caiu porque ninguém mais conseguia explicar onde começava, onde terminava e por que tudo dependia de tudo."


Prólogo — A Cidade Perdida Dentro da Matrix

Neo recebe sua missão mais difícil.

Não é derrotar o Agente Smith.

Não é salvar Zion.

Não é conversar com o Arquiteto.

Sua missão é muito pior.

Documentar um sistema legado.

Morpheus entrega um HD antigo.

Na etiqueta existe apenas uma inscrição.

COREBANK
1986

Neo pergunta:

— Quantos programas existem?

Morpheus responde:

— Não sabemos.

— Quantos bancos de dados?

— Também não.

— Existe documentação?

Morpheus sorri.

— Existia...

em 1994.

Neo conecta o sistema.

Começa a navegar.

Programa chama programa.

Programa chama JCL.

JCL chama PROC.

PROC chama SORT.

SORT chama outro programa.

CICS chama MQ.

MQ chama outro CICS.

Db2 chama Stored Procedure.

Stored Procedure chama Java.

Java chama REST.

REST chama Python.

Python grava novamente no Db2.

Neo pergunta:

— Onde começa a transação?

Morpheus responde:

— Essa pergunta já destruiu a sanidade de muitos arquitetos.

O Oráculo aproxima-se.

Olha para Neo.

E diz:

"Você não entrou em um sistema. Você entrou em uma Big Ball of Mud."


O que é Big Ball of Mud?

Big Ball of Mud (Grande Bola de Lama) é um antipadrão arquitetural que descreve um sistema gigantesco, complexo e sem uma arquitetura clara.

Ao contrário do Spaghetti Code, que normalmente se refere ao código interno de um programa...

A Big Ball of Mud descreve:

o sistema inteiro.

Ela representa aplicações que cresceram durante anos ou décadas sem planejamento arquitetural consistente.

Tudo funciona.

Mas ninguém sabe exatamente por quê.


A origem do termo

O conceito foi formalizado em 1997 por:

  • Brian Foote

  • Joseph Yoder

No famoso artigo:

Big Ball of Mud

Eles observaram que muitos sistemas corporativos bem-sucedidos não possuíam arquitetura elegante.

Mesmo assim...

continuavam funcionando.

Esses sistemas cresciam organicamente.

Como uma bola de lama rolando morro abaixo.

Cada alteração adicionava mais material.

Sem nunca reorganizar a estrutura.


Matrix explica perfeitamente

Imagine a Matrix.

Milhões de linhas de código.

Milhares de programas.

Centenas de agentes.

Regras antigas.

Novas regras.

Exceções.

Correções.

Remendos.

Durante décadas.

Agora imagine.

Ninguém mais possui o diagrama original.

Essa é exatamente uma Big Ball of Mud.


O nascimento da Bola de Lama

Curiosamente...

ela raramente nasce por incompetência.

Ela nasce por sucesso.

O sistema funciona.

Recebe novas funcionalidades.

Mais clientes.

Mais integrações.

Mais regras.

Mais urgências.

Mais exceções.

Mais mudanças.

Depois de trinta anos.

Virou um universo próprio.


O COBOL conhece bem isso

Muitos sistemas bancários começaram assim.

Programa pequeno.

Novo módulo.

Internet Banking.

Mobile.

APIs.

Cloud.

Open Finance.

IA Generativa.

Tudo conectado.

Sem jamais parar para reorganizar completamente.


Um exemplo simples

Sistema original.

Tela

↓

COBOL

↓

Db2

Quarenta anos depois.

Internet

↓

Portal

↓

Gateway

↓

API

↓

MQ

↓

Java

↓

REST

↓

CICS

↓

COBOL

↓

Db2

↓

ETL

↓

Data Lake

↓

Kafka

↓

Analytics

↓

IA

Nenhuma etapa é necessariamente ruim.

O problema é:

ninguém possui a visão completa.


O Programador COBOL Padawan

Imagine.

Primeiro dia na empresa.

Seu líder diz.

"Você ficará responsável pelo CORE."

Você pergunta.

"Existe documentação?"

Resposta.

"Boa sorte."


Como reconhecer?

Existem sinais muito claros.

Tudo depende de tudo

Alterar um campo quebra cinco sistemas.


Não existe dono

Todos mexem.

Ninguém conhece.


Documentação desatualizada

Fluxos reais são diferentes.


Regras duplicadas

Mesma regra aparece vinte vezes.


Arquitetura desconhecida

Cada desenvolvedor explica de um jeito.


Matrix Reloaded

Neo conversa com o Arquiteto.

O Arquiteto mostra diversas versões anteriores da Matrix.

Cada uma herdou partes da anterior.

Nenhuma foi totalmente reconstruída.

Software corporativo evolui exatamente assim.


O efeito psicológico

Existe um fenômeno interessante.

Quanto maior o sistema...

menor a coragem para reorganizá-lo.

Então cada desenvolvedor pensa:

"Vou alterar só este pedacinho."

Todos fazem isso.

Durante vinte anos.

A lama cresce.


O Agente Smith adora isso

Porque sistemas gigantescos produzem:

medo.

Especialistas tornam-se indispensáveis.

Mudanças ficam lentas.

Arquitetura desaparece.

Smith não precisa atacar.

O próprio sistema torna-se resistente à evolução.


Um exemplo COBOL

Imagine.

Existem.

4.200 programas.

3.800 COPYBOOKs.

1.600 JCLs.

780 PROCs.

320 CICS.

410 tabelas Db2.

Pergunta.

Existe mapa de dependências?

Não.

Bem-vindo.


Como nasce?

Etapa 1.

Sistema simples.

Etapa 2.

Urgências.

Etapa 3.

Novos clientes.

Etapa 4.

Integrações.

Etapa 5.

Exceções.

Etapa 6.

Mais remendos.

Etapa 7.

Ninguém mais entende.


O custo invisível

Nova funcionalidade.

Implementação:

2 dias.

Descobrir impacto:

3 semanas.


O impacto financeiro

Mais testes.

Mais homologação.

Mais reuniões.

Mais especialistas.

Mais CPU.

Mais incidentes.

Tudo fica caro.


Atenção!

Big Ball of Mud não significa:

Sistema ruim.

Muitos dos maiores bancos do mundo operam sistemas extremamente antigos.

Que continuam confiáveis.

O problema não é idade.

É ausência de organização.


Curiosidade

Alguns sistemas COBOL possuem mais de:

50 milhões de linhas de código.

Mesmo assim.

Continuam processando bilhões de dólares diariamente.

Isso mostra que:

idade

não é defeito.


A diferença

Sistema Legado

Pode possuir excelente arquitetura.


Big Ball of Mud

Arquitetura praticamente desapareceu.


Como evitar?

Documentação contínua

Nunca espere o projeto acabar.


Diagramas

Fluxos atualizados.


Refatoração

Pequenas melhorias constantes.


Modularização

Divida responsabilidades.


APIs

Reduza acoplamento.


Testes

Protegem mudanças.


Descoberta arquitetural

Ferramentas ajudam.


Ferramentas modernas

IBM possui soluções excelentes.

  • IBM ADDI

  • Application Discovery

  • IBM Developer for z/OS

  • IBM COBOL Check

  • Z Open Editor

  • Instana

  • OpenTelemetry

Elas conseguem descobrir dependências automaticamente.


O papel da IA

Hoje IA ajuda muito.

Ela pode:

explicar programas.

Criar diagramas.

Resumir módulos.

Encontrar dependências.

Mas existe um limite.

Se o sistema inteiro virou lama...

nem a IA faz milagres.


Matrix e Zion

Imagine Zion construída durante cem anos.

Sem planta.

Sem mapas.

Cada engenheiro criou túneis.

Cada geração abriu novos corredores.

Depois de décadas.

Ninguém sabe onde passam todos os cabos.

É exatamente isso.


Os riscos

Mudanças lentas


Bugs inesperados


Alto acoplamento


Baixa produtividade


Custos elevados


Dependência de especialistas


Dificuldade para integrar IA


Big Ball of Mud e DevOps

DevOps acelera deploy.

Mas não resolve arquitetura ruim.

Aliás.

Pode acelerar problemas.


O papel do Arquiteto

Arquitetos modernos fazem uma pergunta simples.

"Este sistema ainda possui forma?"

Se ninguém conseguir responder.

Talvez a bola de lama já exista.


Um exemplo inspirado na Matrix

Neo pergunta.

"Qual programa calcula o saldo?"

Resposta.

"Depende."

"Depende do quê?"

"Da agência."

"E se for PIX?"

"Outro programa."

"E TED?"

"Outro."

"DOC?"

"Também."

"Open Finance?"

"Mais três."

"Cartão?"

"Depende."

Neo suspira.


Existe cura?

Sim.

Mas ela raramente acontece através de uma grande reescrita.

O caminho normalmente é:

Mapear.

Entender.

Documentar.

Refatorar.

Modularizar.

Modernizar.

Gradualmente.


Erros clássicos

  • Reescrever tudo.

  • Não documentar.

  • Misturar responsabilidades.

  • Criar dependências ocultas.

  • Duplicar regras.

  • Ignorar arquitetura.


Aplicabilidade

Big Ball of Mud aparece em:

  • COBOL

  • Java

  • ERP

  • Sistemas Bancários

  • Telecom

  • Governo

  • Seguradoras

  • Cloud

  • Microsserviços

  • ERPs gigantes


Curiosidades

O artigo original afirma algo curioso.

Muitas Big Balls of Mud foram extremamente lucrativas.

Porque resolviam problemas reais.

O problema aparecia décadas depois.

Quando evoluir passou a ser mais caro que criar.


O ensinamento do Oráculo

O Oráculo entrega uma pequena esfera de barro para Neo.

Ela pergunta.

"O que você vê?"

Neo responde.

"Lama."

Ela amassa.

A esfera cresce.

Depois cresce novamente.

Depois outra vez.

Ela sorri.

"Toda exceção adiciona um pouco mais."


Lições para um Programador COBOL Padawan

Você provavelmente trabalhará em sistemas que nasceram antes mesmo da Internet comercial. Não tenha preconceito com isso. Muitos desses sistemas sustentam operações críticas de bancos, seguradoras e governos com níveis de disponibilidade impressionantes.

Ao mesmo tempo, não aceite a desorganização como algo inevitável. Sempre que possível:

  • documente o que descobrir;

  • desenhe fluxos;

  • elimine duplicações;

  • isole responsabilidades;

  • proponha APIs claras;

  • registre decisões arquiteturais;

  • compartilhe conhecimento com a equipe.

Cada pequena melhoria reduz um pouco da lama acumulada ao longo dos anos e prepara o sistema para as próximas décadas.


Conclusão — A Matrix Não Era um Monólito... Era uma Bola de Lama Viva

No final da saga Matrix, Neo entende que o sistema nunca foi estático. Ele evoluiu continuamente, acumulando regras, exceções e adaptações para sobreviver.

Os grandes sistemas corporativos fazem exatamente o mesmo.

Uma Big Ball of Mud não surge porque alguém decidiu construir um software ruim. Ela surge porque o sistema foi útil durante muito tempo, recebeu centenas de melhorias, integrou novas tecnologias e continuou entregando valor ao negócio sem uma renovação arquitetural proporcional.

Para um Programador COBOL, essa é uma lição fundamental. O legado não deve ser visto como inimigo, mas como um organismo vivo que precisa de cuidados constantes. Modernizar não significa destruir; significa compreender, documentar, simplificar e evoluir.

No universo Bellacosa Mainframe existe uma máxima digna do Arquiteto da Matrix:

"Todo sistema começa como uma ideia elegante. O que determina seu futuro é a disciplina com que ele evolui."

Porque a verdadeira missão do Programador COBOL Padawan não é apenas manter a Matrix funcionando.

É impedir que ela se transforme em uma bola de lama tão grande que ninguém mais consiga encontrar a saída.

sexta-feira, 4 de dezembro de 2020

Lava Flow Rules: Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

 

Bellacosa Mainframe e a lava flow rules

☕ Um Café no Bellacosa Mainframe

Lava Flow Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

"O maior perigo dos sistemas legados nem sempre é o código que executa. Muitas vezes é o código que ninguém ousa apagar."


Prólogo — A Sala Proibida da Matrix

Depois de inúmeras batalhas contra o Agente Smith, Neo acreditava conhecer praticamente toda a Matrix.

Foi então que o Arquiteto abriu uma porta que nunca havia sido mostrada.

Atrás dela existia um gigantesco datacenter.

Milhares de programas.

Milhões de linhas de código.

No centro da sala havia uma placa metálica.

NÃO MODIFICAR

Neo perguntou:

— O que existe aí?

O Arquiteto respondeu:

— Não sabemos exatamente.

Neo estranhou.

— Como assim?

— Esse código foi escrito antes mesmo da sexta versão da Matrix.

— Ele ainda é usado?

O Arquiteto permaneceu em silêncio.

O Oráculo apareceu.

Olhou para Neo.

Depois para o enorme programa.

Sorriu.

— Talvez sim.

Talvez não.

Neo perguntou:

— Então por que ninguém remove?

O Oráculo respondeu:

"Porque ninguém quer descobrir a resposta em plena produção."

Bem-vindo ao Lava Flow.


O que é Lava Flow?

Lava Flow é um antipadrão de software onde partes antigas do sistema permanecem indefinidamente porque ninguém sabe se ainda são utilizadas.

São blocos de código que:

  • ninguém compreende completamente;

  • aparentemente não possuem função;

  • não aparecem na documentação;

  • mas continuam existindo por medo de removê-los.

Eles se tornam verdadeiros fósseis digitais.


A origem do nome

O termo surgiu no livro clássico AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, publicado em 1998 por William J. Brown, Raphael Malveau, Hays McCormick III e Thomas Mowbray.

A metáfora é brilhante.

Quando um vulcão entra em erupção, a lava escorre livremente.

Depois de esfriar...

ela endurece.

Com o tempo ninguém consegue mais movê-la.

Mesmo que atrapalhe a construção de estradas ou cidades.

No software acontece exatamente isso.

Uma decisão antiga endurece.

Ninguém mais consegue removê-la.


Matrix explica perfeitamente

Imagine que cada versão da Matrix deixa pequenos trechos de código esquecidos.

Programas antigos.

Rotinas obsoletas.

Protocolos desativados.

Funções nunca mais chamadas.

Mas ninguém ousa apagar.

Porque talvez...

alguma parte escondida ainda dependa delas.


Como nasce um Lava Flow?

Quase sempre começa assim.

Um projeto urgente.

Uma solução temporária.

O desenvolvedor comenta:

"Depois limpamos."

Mas o projeto termina.

A equipe muda.

O conhecimento desaparece.

O código continua.


O COBOL conhece muito bem esse fenômeno

Imagine um programa escrito em 1989.

Em determinado momento existia uma regra para calcular uma antiga taxa bancária.

Essa taxa deixou de existir em 1998.

Mas a rotina continua lá.

Em 2004 alguém perguntou:

— Podemos apagar?

Resposta:

— Melhor não...

Vai que algum lote ainda usa.

Em 2012 outra pessoa perguntou.

Mesma resposta.

Em 2026...

A rotina continua.


Um exemplo clássico

Imagine um trecho como este.

IF WS-TIPO = "X"
    PERFORM CALCULA-TAXA-ESPECIAL
END-IF

Pergunta.

Existe algum cliente com tipo X?

Ninguém sabe.

A consulta nunca foi feita.

Então o código permanece.


Outro exemplo COBOL

Você encontra:

PERFORM ROTINA-LEGADA.

Procura quem chama essa rotina.

Descobre que:

ninguém.

Mas ninguém remove.

Porque talvez exista:

  • um JCL antigo;

  • um programa batch esquecido;

  • uma PROC histórica;

  • um processo anual.


Matrix Reloaded

Lembra dos programas exilados?

Merovíngio abriga programas antigos que deveriam ter sido removidos.

Eles continuam existindo porque encontraram maneiras de sobreviver.

Esses personagens representam perfeitamente o conceito de Lava Flow.

São códigos que perderam sua função original, mas continuam ocupando espaço na Matrix.


O efeito psicológico

Existe uma frase muito conhecida em equipes de manutenção.

"Se está funcionando, não mexa."

Ela protege a estabilidade.

Mas também pode proteger código morto.

O medo da mudança faz com que partes inteiras do sistema permaneçam congeladas por décadas.


O Programador COBOL Padawan

Você abre um programa.

Encontra:

IF WS-FLAG-1987 = "S"

Pergunta ao analista mais experiente.

— O que significa?

Resposta.

— Acho que tem relação com um produto antigo.

"Acho."

Essa palavra deveria acender um alerta.


O Agente Smith adora Lava Flow

Porque código morto aumenta:

  • complexidade;

  • tempo de leitura;

  • dificuldade de testes;

  • risco de manutenção.

Quanto mais difícil compreender o sistema, mais fácil ele se torna de dominar.


Um exemplo inspirado na Matrix

Neo encontra uma porta.

Ela não leva a lugar nenhum.

Pergunta ao Chaveiro.

— Posso removê-la?

O Chaveiro responde.

— Talvez.

Neo insiste.

— Alguém usa?

O Chaveiro sorri.

— Faz muito tempo que ninguém passa por ela...

Mas ninguém quer ser o primeiro a descobrir.


Como reconhecer Lava Flow?

Alguns sinais são clássicos.

Comentários antigos

TEMPORÁRIO
REMOVER DEPOIS

E o comentário tem quinze anos.


Código nunca executado

Cobertura de testes mostra zero chamadas.


Variáveis sem uso

Declaradas.

Nunca lidas.


COPYBOOKs esquecidos

Presentes.

Jamais referenciados.


JCLs históricos

Executados pela última vez em 2014.


O custo invisível

Cada novo desenvolvedor precisa entender:

o código ativo

o código morto.

Mesmo que metade nunca execute.


O impacto no Mainframe

Mainframes corporativos costumam preservar compatibilidade por décadas.

Isso é excelente para o negócio.

Mas também significa que:

  • programas antigos sobrevivem;

  • interfaces antigas permanecem;

  • layouts históricos continuam disponíveis.

Nem tudo pode ser removido imediatamente.


Atenção!

Lava Flow não significa simplesmente "código antigo".

Código antigo pode ser extremamente importante.

O problema é:

código antigo

sem propósito conhecido.


A diferença

Legado

Ainda possui função.


Lava Flow

Ninguém sabe se possui função.


Curiosidade

Diversos sistemas bancários ainda mantêm rotinas para formatos de arquivos que não são utilizados há muitos anos, apenas porque existe a possibilidade de algum cliente institucional ainda depender deles em um processamento específico.


Ferramentas ajudam

Hoje é possível descobrir muito mais do que antigamente.

Ferramentas como:

  • IBM Application Discovery and Delivery Intelligence (ADDI);

  • IBM Developer for z/OS;

  • IBM COBOL Check;

  • SonarQube;

  • Enterprise Analyzer;

permitem identificar:

  • programas sem referências;

  • COPYBOOKs não utilizados;

  • dependências reais;

  • fluxo de chamadas;

  • cobertura de execução.

Elas reduzem significativamente o medo de remover código.


Como evitar?

Descoberta arquitetural

Conheça dependências reais.


Testes automatizados

Eles fornecem confiança.


Monitoramento

Descubra quem realmente utiliza cada componente.


Refatoração contínua

Pequenas limpezas são mais seguras do que grandes reescritas.


Documentação viva

Explique por que algo permanece.


Revisões periódicas

Reserve tempo para eliminar o que perdeu utilidade.


O perigo da limpeza precipitada

O extremo oposto também é perigoso.

Imagine remover uma rotina porque "parece inútil".

Na madrugada do último dia útil do ano...

ela é executada pelo fechamento contábil.

Resultado:

ABEND.

Incidente crítico.

Por isso remover exige evidências.

Nunca intuição.


Matrix e os Programas Exilados

O Merovíngio colecionava programas antigos.

Eles não tinham mais função oficial.

Mesmo assim continuavam vivos.

Esses personagens representam exatamente os componentes esquecidos que permanecem escondidos em sistemas corporativos.

Nem todos causam problemas.

Mas todos aumentam a complexidade.


O papel da IA

Ferramentas baseadas em IA podem:

  • localizar código aparentemente morto;

  • resumir módulos antigos;

  • mapear dependências;

  • identificar duplicações;

  • sugerir candidatos à remoção.

Entretanto, a decisão final continua sendo humana.

Especialmente em ambientes críticos.


Os riscos

Complexidade crescente

Mais código para entender.


Testes maiores

Mais cenários.


Custos

Mais manutenção.


Bugs

Mudanças evitadas por medo.


Segurança

Bibliotecas antigas podem permanecer vulneráveis.


Conhecimento perdido

Ninguém sabe mais o propósito original.


Erros clássicos

  • Nunca revisar código legado.

  • Confundir estabilidade com imobilidade.

  • Manter funcionalidades desativadas indefinidamente.

  • Não registrar decisões arquiteturais.

  • Ignorar ferramentas de análise de dependência.


Boas práticas

  • Mantenha inventário de componentes.

  • Monitore utilização real.

  • Elimine código comprovadamente morto.

  • Escreva testes antes de remover.

  • Documente exceções de negócio.

  • Faça limpezas graduais.


Aplicabilidade

Lava Flow aparece em praticamente qualquer tecnologia:

  • COBOL;

  • PL/I;

  • Java;

  • C#;

  • Python;

  • C++;

  • APIs;

  • microsserviços;

  • aplicações em nuvem;

  • sistemas embarcados.

Quanto maior a vida útil do software, maior a chance desse antipadrão surgir.


O ensinamento do Oráculo

O Oráculo leva Neo até um antigo rio de lava endurecida.

Ela pergunta:

— O que você vê?

Neo responde.

— Pedra.

Ela toca a superfície.

Debaixo dela ainda existe calor.

Então diz:

"No software acontece igual. O código pode parecer morto, mas ainda pode sustentar parte da montanha."

Antes de remover.

Investigue.


Lições para um Programador COBOL Padawan

Ao iniciar sua carreira no universo IBM Z, você encontrará programas com décadas de existência. Alguns conterão comentários escritos por pessoas que já se aposentaram. Outros farão referência a produtos, moedas, legislações e tecnologias que nem existem mais.

Não assuma que tudo isso é lixo.

Também não assuma que tudo é indispensável.

Seu papel é agir como um arqueólogo digital:

  • entender o contexto;

  • mapear dependências;

  • conversar com especialistas;

  • validar com testes;

  • registrar descobertas;

  • remover apenas aquilo cuja inutilidade esteja comprovada.

Essa disciplina preserva a estabilidade do negócio e, ao mesmo tempo, impede que a lama endurecida continue crescendo indefinidamente.


Conclusão — Nem Toda Rocha Deve Permanecer Para Sempre

Na Matrix, programas antigos podiam sobreviver escondidos entre versões sucessivas da simulação. Alguns ainda tinham propósito. Outros apenas ocupavam espaço.

Nos sistemas corporativos acontece exatamente o mesmo.

O Lava Flow representa decisões antigas que endureceram com o tempo. Elas deixaram de ser questionadas porque questioná-las parece perigoso.

Mas engenharia madura não significa apagar tudo.

Significa compreender antes de agir.

Para um Programador COBOL, essa é uma das maiores demonstrações de responsabilidade profissional. Cada remoção deve ser sustentada por evidências, testes, monitoramento e conhecimento do negócio.

No universo Bellacosa Mainframe existe uma máxima que o próprio Oráculo aprovaria:

"O código mais perigoso não é o antigo. É aquele cujo propósito ninguém mais consegue explicar."

Porque, assim como na Matrix, o verdadeiro desafio não é destruir o passado.

É descobrir quais partes dele ainda sustentam o presente e quais já podem, finalmente, descansar.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...