Lei de Conway para alinhar arquitetura e organização

A arquitetura de software tende a seguir os caminhos reais de comunicação da organização, mesmo quando ninguém planejou isso. Na palestra de Kevin Goldsmith, CTO da Anaconda, a Lei de Conway aparece menos como um slogan antigo e mais como uma ferramenta de projeto: se a empresa muda quem conversa com quem, muda também as soluções que essas pessoas conseguem construir. Goldsmith recupera a formulação original de Mel Conway e a ideia de uma “força homomórfica”, uma correspondência entre o mapa do sistema e o mapa da organização.

O mecanismo fica claro no caso do Adobe Revel, produto de fotografia conectado que Goldsmith liderou. A arquitetura em camadas parecia natural: clientes móveis e desktop, biblioteca comum, servidor e infraestrutura. A organização seguiu o mesmo desenho. O problema surgiu no fluxo de entrega. Uma pequena funcionalidade começava no time cliente, dependia da biblioteca comum, depois de uma API no servidor e, em seguida, de uma mudança de infraestrutura. Cada passagem entrava no sprint seguinte. Uma função simples podia levar sete sprints, cerca de 14 semanas. Quando os times tentavam contornar o gargalo falando diretamente com o servidor, surgiam diferenças de implementação entre Android e iOS.

A alternativa descrita por Goldsmith não é negar a Lei de Conway, mas usá-la. No Spotify, a resposta foi reorganizar o trabalho em squads de funcionalidade, com competências suficientes para reduzir dependências externas. A arquitetura também precisou mudar: menos camadas compartilhadas, mais serviços independentes, mais autonomia para cada time entregar. Isso aumentou a velocidade, mas trouxe custos reconhecidos na própria conversa: duplicação de esforço, inconsistências de produto e necessidade de alguém olhar transversalmente para a experiência. Em empresas menores, como a Avo, Goldsmith adotou um modelo menos radical, com mais compartilhamento e componentes migrando para plataforma quando um terceiro time passava a precisar deles.

A consequência prática é evitar tanto o organograma herdado quanto a cópia mecânica de modelos famosos. Se a meta é uma arquitetura mais independente, os padrões de comunicação precisam permitir independência. Se a empresa reorganiza equipes sem pensar no sistema, deve esperar mudanças arquiteturais indesejadas. Às vezes, criar silos é uma decisão útil; em outras, compartilhamento reduz desperdício. A pergunta concreta antes de uma reestruturação ou de uma mudança técnica é simples: o desenho das conversas favorece a arquitetura que se quer ter?

Assistir ao episódio original

Leia também: Modelo Spotify: copiar squads não resolve a organização, Team Topologies: salário pode bloquear a autonomia, Arquitetura corporativa deve governar a complexidade.

Referências encontradas

Livros

• O Mítico Homem-mês: Ensaios Sobre Engenharia de Software, de Frederick P. Brooks Jr. — Ver livro na Amazon
• A Startup Enxuta, de Eric Ries — Ver livro na Amazon
• Criando Microsserviços: Projetando Sistemas com Componentes Menores e Mais Especializados, de Sam Newman — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.