 |
| Bellacosa Mainframe e a conways law rules |
☕ Um Café no Bellacosa Mainframe
Conway's Law Rules sem Mistérios
Quando um Programador COBOL Descobriu que a Matrix Não Era Apenas um Software… Era o Espelho de Quem a Construiu
"As organizações desenham sistemas que refletem sua própria forma de comunicação." — Melvin Conway (1967)
Prólogo — A Matrix Tinha o Mesmo Formato de Zion
Neo caminhava pelos corredores da Cidade das Máquinas.
Esperava encontrar servidores.
Processadores.
Centrais de controle.
Mas encontrou algo muito mais curioso.
Cada setor da Matrix era administrado por um grupo diferente.
O setor dos Agentes nunca conversava diretamente com o setor do Oráculo.
O setor do Merovíngio possuía seus próprios protocolos.
O Chaveiro trabalhava isolado.
Os Sentinelas recebiam ordens por outro canal.
Neo percebeu algo estranho.
Cada módulo da Matrix parecia exatamente igual ao departamento que o desenvolvia.
Morpheus perguntou:
— O que está vendo?
Neo respondeu:
— Não estou olhando apenas para um software...
Estou olhando para o organograma da empresa.
O Oráculo sorriu.
— Finalmente você encontrou a Lei de Conway.
O que é a Lei de Conway?
A Conway's Law afirma:
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Em português:
"As organizações que desenvolvem sistemas acabam produzindo arquiteturas que refletem sua própria estrutura de comunicação."
Ou seja...
O software não nasce apenas das decisões técnicas.
Ele nasce da forma como as pessoas trabalham juntas.
A origem da Lei de Conway
A lei foi proposta em 1967 por Melvin E. Conway, cientista da computação.
Na época, Conway observou algo curioso.
Empresas organizadas em departamentos independentes acabavam criando softwares igualmente divididos.
Não era coincidência.
Era consequência direta da comunicação humana.
Décadas depois, essa observação continua sendo uma das ideias mais influentes da arquitetura de software.
Matrix explica perfeitamente
Imagine que a Matrix fosse construída por quatro equipes.
Equipe A.
Cuida da autenticação.
Equipe B.
Cuida da economia.
Equipe C.
Cuida dos Agentes.
Equipe D.
Cuida dos Sentinelas.
Se essas equipes quase não conversam...
o software também ficará separado.
Cada módulo desenvolverá sua própria visão da realidade.
O nascimento da Lei
Conway percebeu que a arquitetura técnica segue a arquitetura social.
Se duas equipes possuem dificuldades para conversar...
os sistemas também terão dificuldades para se integrar.
O COBOL conhece isso muito bem
Imagine um grande banco.
Departamento de Cartões.
↓
Equipe própria.
↓
Sistema próprio.
Departamento de PIX.
↓
Equipe diferente.
↓
API diferente.
Departamento de Crédito.
↓
Outro time.
↓
Outro banco de dados.
Departamento de Investimentos.
↓
Outro padrão.
↓
Outro framework.
O resultado?
Integrações complexas.
Duplicação de dados.
Interfaces difíceis.
Não porque os desenvolvedores desejavam isso.
Mas porque a organização já funcionava dessa maneira.
Um exemplo simples
Empresa.
Financeiro
RH
Comercial
Software.
Sistema Financeiro
Sistema RH
Sistema Comercial
Parece natural.
Agora imagine.
Cada departamento possui regras próprias de cadastro.
Logo surgem:
três cadastros de clientes;
quatro cadastros de funcionários;
cinco cadastros de endereços.
O software apenas refletiu a organização.
Matrix Reloaded
Observe os personagens.
O Oráculo não faz o trabalho do Arquiteto.
O Merovíngio não administra Zion.
O Chaveiro não controla os Agentes.
Cada grupo possui funções próprias.
Agora imagine.
Nenhum deles conversa.
A Matrix rapidamente se fragmentaria.
O efeito psicológico
As pessoas tendem a conversar mais com quem está próximo.
Mesmo dentro da mesma empresa.
Logo.
Os sistemas acompanham essa divisão.
O Programador COBOL Padawan
Imagine que você trabalhe no time de CICS.
Nunca conversa com o pessoal de APIs.
Nem conhece a equipe de Open Finance.
Depois de dois anos...
as integrações começam a falhar.
Não por culpa do COBOL.
Mas porque a comunicação humana falhou antes da comunicação entre sistemas.
O Agente Smith adora isso
Smith sabe que basta dividir as pessoas.
O restante acontece sozinho.
Cada equipe cria:
padrões próprios;
nomenclaturas próprias;
APIs próprias;
documentação própria.
Pouco tempo depois.
Os sistemas deixam de conversar.
Um exemplo inspirado na Matrix
Neo pergunta.
— Quem controla o cadastro dos humanos?
Resposta.
— Depende.
A equipe dos Agentes possui um.
O Merovíngio outro.
O Oráculo outro.
Zion outro.
Neo pergunta.
— Por que existem quatro?
O Arquiteto responde.
— Porque existiam quatro departamentos.
Como reconhecer?
Existem sinais muito claros.
APIs incompatíveis
Cada área cria seu padrão.
Bancos duplicados
Mesma informação.
Vários lugares.
Nomenclaturas diferentes
CPF.
CPF_NUM.
DOCUMENTO.
CLIENT_ID.
Tudo significa a mesma coisa.
Integrações difíceis
Equipes precisam negociar constantemente.
Regras repetidas
Cada departamento implementa novamente.
O impacto no Mainframe
Grandes ambientes IBM Z frequentemente atendem diversas áreas de negócio.
Se cada área evolui isoladamente.
Logo aparecem:
duplicação de COPYBOOKs;
layouts diferentes;
APIs redundantes;
programas semelhantes;
tabelas quase idênticas.
Tudo consequência da estrutura organizacional.
Curiosidade
Existe um conceito moderno chamado:
Reverse Conway Maneuver
A ideia é justamente o contrário.
Em vez de deixar a arquitetura seguir a organização...
a empresa reorganiza as equipes para produzir a arquitetura desejada.
Se deseja microsserviços independentes.
Cria equipes independentes.
Se deseja plataforma integrada.
Organiza equipes integradas.
Atenção!
Conway's Law não é uma crítica.
Ela é uma observação.
Toda organização sofre sua influência.
O importante é reconhecê-la.
O custo invisível
Quando departamentos não conversam.
Surgem:
retrabalho;
integrações caras;
conflitos de requisitos;
inconsistências.
Tudo isso custa tempo.
Dinheiro.
CPU.
Produtividade.
O papel do Arquiteto
Arquitetos não desenham apenas software.
Eles aproximam equipes.
Porque sabem.
Sem comunicação.
Não existe boa arquitetura.
Matrix e Zion
Imagine Zion dividida.
Cada setor constrói um pedaço da cidade.
Sem conversar.
Resultado.
Canos que não se conectam.
Cabos incompatíveis.
Portas que não levam a lugar nenhum.
Software funciona exatamente assim.
Ferramentas ajudam
Hoje usamos:
Enterprise Architecture.
Event Storming.
Domain Driven Design.
IBM ADDI.
OpenAPI.
AsyncAPI.
Catálogos corporativos.
Mas nenhuma ferramenta substitui comunicação humana.
O papel da IA
A IA pode:
documentar APIs;
comparar contratos;
identificar duplicações;
sugerir padronizações.
Mas não resolve conflitos organizacionais.
Os riscos
Sistemas duplicados
APIs redundantes
Custos maiores
Integrações frágeis
Visão fragmentada do negócio
Arquitetura inconsistente
Erros clássicos
Criar sistemas sem envolver outras áreas.
Duplicar cadastros.
Não compartilhar padrões.
Cada equipe inventar sua arquitetura.
Ignorar governança.
Boas práticas
Comunicação frequente.
Arquitetura corporativa.
Catálogo de APIs.
Padrões comuns.
Revisões interequipes.
Compartilhamento de conhecimento.
Domínios bem definidos.
Aplicabilidade
A Lei de Conway aparece em:
COBOL.
Java.
Cloud.
Microsserviços.
ERP.
APIs.
DevOps.
Bancos.
Governo.
Telecom.
Ela independe da tecnologia.
Um exemplo COBOL
Imagine.
Equipe A.
Cria COPYBOOK:
CLIENTE.
Equipe B.
Cria outro.
CLIENTE-NEW.
Equipe C.
Outro.
CLIENTE-V2.
Nenhum é compatível.
O problema começou muito antes do compilador.
O ensinamento do Oráculo
O Oráculo leva Neo até um enorme espelho.
Cada equipe da Matrix aparece refletida.
Depois o espelho se transforma.
Agora revela o software.
Neo percebe algo impressionante.
As divisões eram exatamente iguais.
Ela pergunta:
— O que mudou?
Neo responde.
— Nada.
O software apenas copiou as pessoas.
Ela sorri.
"É exatamente isso que Conway descobriu."
Lições para um Programador COBOL Padawan
Ao iniciar sua carreira em um ambiente corporativo, você perceberá que muitos desafios técnicos têm origem muito antes do código ser escrito.
Às vezes o problema não está no COBOL, no CICS ou no Db2.
Está no fato de que:
as equipes não compartilham conhecimento;
cada área cria suas próprias definições;
os requisitos chegam incompletos;
não existe uma linguagem comum entre negócio e tecnologia.
Por isso, desenvolva não apenas habilidades técnicas.
Aprenda também a:
comunicar-se claramente;
participar de revisões arquiteturais;
documentar decisões;
compreender o domínio de negócio;
construir pontes entre equipes.
Grandes arquitetos de software são, antes de tudo, excelentes comunicadores.
Curiosidades
A influência da Lei de Conway é tão grande que ela aparece indiretamente em diversos movimentos modernos:
Domain-Driven Design (DDD) incentiva equipes alinhadas aos domínios de negócio.
Team Topologies propõe estruturas organizacionais que favorecem fluxos de software saudáveis.
Microservices funcionam melhor quando as equipes possuem autonomia compatível com os serviços que mantêm.
DevOps surgiu justamente para reduzir barreiras entre desenvolvimento e operações.
Todos esses movimentos reconhecem, de alguma forma, a observação feita por Melvin Conway em 1967.
Conclusão — A Matrix Refletia Quem a Construía
No universo Matrix, Neo descobriu que a simulação não era apenas um conjunto de programas.
Ela refletia as decisões, os conflitos e a forma como seus criadores trabalhavam.
Na Engenharia de Software acontece exatamente o mesmo.
A Lei de Conway nos lembra que sistemas não são produzidos apenas por compiladores ou linguagens de programação.
Eles são produzidos por pessoas.
Se as equipes colaboram, o software tende a ser integrado.
Se as equipes vivem isoladas, o software também se fragmenta.
Para um Programador COBOL que atua em ambientes IBM Z, essa é uma lição valiosa. O sucesso de um sistema bancário depende tanto da qualidade do código quanto da qualidade da comunicação entre analistas de negócio, arquitetos, desenvolvedores, DBAs, administradores CICS, especialistas em segurança e operações.
No universo Bellacosa Mainframe existe uma máxima que certamente poderia estar gravada na entrada de Zion:
"Antes de desenhar a arquitetura do software, observe a arquitetura da empresa. Muito provavelmente uma será o reflexo da outra."
Porque, no fim, a Matrix nunca foi apenas feita de linhas de código.
Ela sempre foi feita das pessoas que aprenderam — ou deixaram de aprender — a trabalhar juntas.
