 |
| 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.
Sem comentários:
Enviar um comentário