Lei de Conway
Melvin Conway publicou a observação em 1968, e ela envelheceu bem:
Organizações que projetam sistemas produzem projetos que copiam a estrutura de comunicação dessas organizações.
Não é uma lei física nem uma maldição. É uma consequência prática: as partes do sistema que precisam de acordo constante são construídas por pessoas que conversam constantemente. Onde a comunicação é difícil, aparece uma interface — porque interface é justamente o que reduz a necessidade de conversar.
Evidências no seu próprio sistema
Seção intitulada “Evidências no seu próprio sistema”O teste é rápido. Compare o organograma com o diagrama de arquitetura:
- Time de frontend, time de backend e time de banco → sistema em três camadas, com uma reunião no meio de cada mudança.
- Time por produto, com autonomia → serviços por domínio de negócio.
- Time de operação separado → uma fronteira entre “código” e “produção”, geralmente com um formulário no meio.
- Empresa adquirida, mantida como unidade separada → integração via API, mesmo quando os dois sistemas fariam mais sentido juntos.
- Um time em outro fuso → interface assíncrona, com contrato mais explícito.
Repare que nenhum desses resultados foi decidido em reunião de arquitetura. Eles emergem.
A manobra reversa
Seção intitulada “A manobra reversa”Se a estrutura produz a arquitetura, dá para inverter: organize os times como você quer que o sistema fique. É a “manobra reversa de Conway”, e é a razão de Team Topologies existir.
Quer serviços com fronteiras claras, cada um operado por quem o escreve? Monte times alinhados a fluxo, com autonomia de ponta a ponta, e reduza as dependências entre eles. Quer que a plataforma seja consumida como serviço e não por ticket? Trate o time de plataforma como fornecedor de produto, com interface estável.
O corolário desconfortável: não adianta desenhar microsserviços e manter times por camada. O desenho não sobrevive ao primeiro trimestre — as fronteiras vão migrar de volta para onde a comunicação é fácil.
Limites de time e limites de serviço
Seção intitulada “Limites de time e limites de serviço”A lei ajuda a decidir onde cortar um sistema. Uma fronteira de serviço saudável coincide com uma fronteira de time:
- Um serviço deve ter um time dono. Serviço com três donos não tem nenhum.
- Um time pode ter vários serviços, desde que caibam na sua carga cognitiva.
- Se dois times precisam sincronizar deploy, provavelmente há um serviço só, dividido no lugar errado.
- Se um time precisa de aprovação de outro para entregar valor, você desenhou uma dependência que vai aparecer como lentidão nas métricas de fluxo.
Isso também explica por que microsserviços frequentemente falham em organizações pequenas: com quinze pessoas e trinta serviços, não há times suficientes para dar dono a cada um, e o custo de coordenação supera qualquer benefício de isolamento.
O limite honesto
Seção intitulada “O limite honesto”A lei descreve uma tendência forte, não um determinismo. Ela não diz que a arquitetura é boa quando espelha a organização — apenas que ela vai espelhar. Uma organização mal desenhada produz uma arquitetura mal desenhada com a mesma fidelidade.
Reorganizar também tem custo alto e frequentemente subestimado: times novos levam meses para recuperar confiança e contexto, e reorganização frequente destrói os dois permanentemente. Usar a manobra reversa como justificativa para mudar times a cada semestre é pior que a arquitetura que se queria corrigir.
O uso mais produtivo da lei não é reorganizar: é explicar. Quando alguém pergunta por que o sistema tem aquela fronteira estranha, a resposta costuma estar no organograma de três anos atrás — e saber disso muda a conversa de “quem escreveu essa porcaria” para “que estrutura produziu isso, e ela ainda existe?”.