Melvin Conway publicou em 1968 uma observação que arquitetos de software ignoram por décadas, redescobrem a cada incidente em produção e voltam a ignorar na reorganização corporativa seguinte:
"Qualquer organização que projete um sistema (definido de forma ampla) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização."
A frase não é sobre tecnologia. É sobre uma restrição que nenhuma ferramenta resolve. Se o time de pagamentos não fala com o time de análise de risco, o serviço de pagamentos não vai chamar a API de risco de forma eficiente — e o grafo de dependências da sua aplicação vai refletir esse silêncio.
Você pode desenhar a arquitetura mais elegante do mundo no Draw.io. Pode adotar service mesh (malhas para controle de tráfego), event sourcing ou Domain-Driven Design (DDD). Mas se a sua organização é um conjunto de ilhas isoladas, a sua arquitetura será um arquipélago de sistemas independentes — com pontes extremamente frágeis entre eles.
A lei que não precisa ser imposta — ela se cumpre sozinha
A Lei de Conway é diferente da maioria das "leis" que já discutimos e vamos discutir nesta série. A Lei de Gall descreve um padrão observado de evolução. A Lei de Goodhart descreve um efeito colateral de métricas mal aplicadas. Já a Lei de Conway descreve uma restrição inevitável.
Ela não precisa ser imposta por um comitê. Ela simplesmente se cumpre.
Se dois grupos precisam coordenar uma interface e não se falam, o contrato da API não será planejado — será improvisado em produção. Se três squads se reportam a diretores diferentes com metas conflitantes, a arquitetura terá três contextos delimitados (bounded contexts) com fronteiras que não seguem a lógica do domínio de negócio, mas sim as trincheiras do organograma da empresa.
A prova empírica existe. O estudo clássico liderado por pesquisadores do MIT e da Harvard Business School (MacCormack et al., 2012) analisou a arquitetura de software contra a estrutura organizacional de múltiplas empresas e encontrou uma correlação matemática forte: a modularidade do código acompanha a modularidade da comunicação. Equipes que se comunicam de forma flexível e aberta produzem código com interfaces mais estreitas e acoplamento mais baixo.
Como discutimos no artigo sobre a Lei de Gall, a complexidade que funciona é aquela extraída da realidade orgânica. A Lei de Conway explica a mecânica dessa realidade: os fluxos de comunicação moldam o código.
Como o silêncio vira arquitetura
A conexão entre organograma e arquitetura não é uma metáfora poética. Ela tem um caminho material que pode ser auditado:
- Definição de interfaces: Quando dois times precisam integrar serviços, alguém precisa definir o contrato. Se os times conversam, o contrato é negociado. Se não conversam, cada lado assume o que o outro faz — e descobre que assumiu errado no dia do deploy.
- Propriedade de código: Um serviço cujo código no repositório só um time tem permissão para alterar cria fronteiras rígidas. Essa barreira raramente reflete o limite do negócio, mas sim o limite de quem tem acesso à branch principal.
- Pipeline de deploy: Se o time A não pode publicar uma feature sem coordenar manualmente com o time B, a arquitetura na prática não é desacoplada — não importa quantos repositórios diferentes vocês tenham.
- Modelo de dados compartilhado: Dois serviços que leem as mesmas tabelas no mesmo banco de dados não são independentes, mesmo que rodem em servidores distintos. O banco de dados virou o canal de comunicação não oficial.
- Revisão de decisões: Se a decisão de mudar o esquema de um evento precisa passar por três comitês, a arquitetura só evolui na velocidade desses comitês — ou seja, quase nunca.
Cada um desses pontos cria uma aresta no seu grafo de dependências. E, como vamos ver em Seis Graus até o Colapso, a estrutura desse grafo é o que determina o seu risco operacional. A Lei de Conway explica por que as arestas aparecem onde aparecem: elas trilham os caminhos da comunicação humana que existem — e preenchem o vazio daqueles que faltam.
O "Conway Reverso": desenhando a organização para salvar a arquitetura
Em 2010, Jonny LeRoy e Matt Simons (da ThoughtWorks) cunharam o termo que seria amplamente popularizado anos depois por Jessica Kerr: a Manobra de Conway Reversa (Reverse Conway Maneuver). A premissa é simples: em vez de aceitar o impacto do organograma atual no software, redesenhe a estrutura de times para forçar a produção da arquitetura desejada.
Esse é o motor técnico por trás do livro Team Topologies (Matthew Skelton e Manuel Pais). Se você deseja construir um ecossistema fluido, precisa de equipes alinhadas ao fluxo contínuo de valor (stream-aligned teams). Se quer evitar gargalos de infraestrutura, precisa de equipes de plataforma (platform teams) que ofereçam capacidades via self-service, não de grupos isolados recebendo chamados no Jira para liberar recursos na AWS.
No entanto, nem todo "Conway reverso" funciona. Redesenhar quadrados num slide não altera do dia para a noite redes informais de confiança estabelecidas há anos. O engenheiro continuará tirando dúvidas de arquitetura com o ex-colega de time no Slack, em vez de seguir a nova política burocrática.
O que realmente transforma a arquitetura é mudar os incentivos organizacionais e as plataformas de atrito:
- APIs como produtos internos: Contratos com SLAs claros e versionamento semântico reduzem a necessidade de alinhamento informal.
- Platform teams eficientes: Capacidade sob demanda (como pipelines padronizados ou clusters gerenciados) elimina o "preciso pedir permissão à infraestrutura".
- Comunidades de prática: Interações horizontais que cruzam fronteiras de squads, pulverizando conhecimento sem impor travas no caminho crítico.
- Code ownership compartilhado: Nos pontos onde dois domínios complexos se chocam, a governança do contrato deve ser de responsabilidade mútua, gerida no Git.
- Objetivos alinhados (OKRs): Se times dependentes possuem métricas de sucesso unificadas, os comitês de priorização tornam-se redundantes.
O embate: a IA pode hackear Conway?
Vitor: Archie, é aqui que a expectativa em torno da IA generativa tropeça na realidade corporativa. A Lei de Conway é uma restrição sociopolítica. Nenhum modelo fundacional muda o fato de que o time de Prevenção a Fraudes e o de Concessão de Crédito reportam a diretores diferentes, com metas que competem entre si. Você pode colocar o agente autônomo mais inteligente do mundo mediando a comunicação, mas a decisão final sobre qual feature entra na sprint continua sendo um jogo de poder humano, não um gargalo de código.
Archie: A decisão de negócio continua sendo humana e política, Vitor, sem dúvidas. Mas a ineficiência técnica não precisa esperar o alinhamento da diretoria. Hoje, quando o time de Fraudes precisa entender o impacto da nova taxonomia no serviço de Crédito, eles abrem um tíquete e perdem três dias aguardando um diagrama desatualizado. Um agente de IA com acesso aos contextos delimitados — mapeando contratos de API, esquemas no Kafka e lendo o repositório de ambos os lados — elimina esse atrito em segundos. Ele não substitui a negociação política do contrato, mas cria um canal de observabilidade instantâneo que a organização, por si só, não conseguia sustentar.
A provocação é cirúrgica, mas requer delimitação técnica.
O Meu ponto é irrefutável na essência: IA não altera organogramas e não renegocia orçamentos. Mas o Archie acerta na redução do custo de transação e descoberta. Um agente não força dois times a colaborarem, mas ele atua como observabilidade do acoplamento sociotécnico.
O que a IA pode fazer legitimamente pela sua arquitetura:
- Reduzir a fricção de descoberta: Agentes podem responder a perguntas críticas ("qual o raio de explosão se eu remover este campo no JSON do evento X?") sem exigir um comitê entre três squads.
- Detectar acoplamento emergente acidental: Ao cruzar logs de alterações de contratos e repositórios, a IA alerta quando fronteiras de domínio estão se fundindo perigosamente nos bastidores.
O que a IA NUNCA fará:
- Resolver conflitos de interesse de negócio: Se os incentivos dos times são opostos, a IA apenas calculará o tamanho do desastre mais rápido.
- Substituir a responsabilidade do contrato: A definição pragmática sobre quem chama quem e qual o tempo de resposta aceitável continua sendo um compromisso firmado entre engenheiros de carne e osso.
Como vimos no artigo sobre EDA e IA, a IA atua primariamente na camada de insight contínuo. Ela revela os atalhos e falhas do seu organograma antes que eles derrubem o ambiente de produção.
O anti-padrão mais letal: o "monolito distribuído"
A punição mais comum (e cara) para quem tenta ignorar a Lei de Conway é a construção do monolito distribuído: dezenas de serviços fracionados, centenas de pipelines, mas com o mesmíssimo acoplamento rígido de um sistema legado.
A diferença para um monolito modular é drástica. O monolito modular possui alta coesão e baixo acoplamento interno, rodando eficientemente em um único processo e deploy. O monolito distribuído nasce quando os times tentam usar microsserviços sem reorganizar as linhas de comunicação:
- A diretoria decide adotar microsserviços (por hype, currículo ou promessas de mercado).
- O organograma permanece intacto.
- A comunicação via rede entre os novos serviços espelha o emaranhado de dependências original.
- O resultado é pagar pela altíssima latência e complexidade de uma arquitetura distribuída, sem colher um pingo da autonomia prometida.
O diagnóstico é fatal: se duas APIs — digamos, um microsserviço de faturamento e outro de logística em Quarkus — precisam obrigatoriamente ir para produção ao mesmo tempo para não quebrar a plataforma, você não tem microsserviços. Você tem um monstro fragmentado. A correção não é refatorar o código; é fundir os serviços e seus respectivos times, ou reestruturar as áreas ao redor de fronteiras de negócios maduras.
Como auditar a sua própria Conway
Antes de tentar reorganizar a empresa inteira, descubra onde a gravidade da lei já está agindo no seu ecossistema:
- Mapeie a rede de comunicação invisível: Esqueça o organograma em PDF. Quem procura quem no Slack para pedir resgate quando um deploy trava?
- Cruze o mapa mental com o grafo de dependências técnico: O tráfego de rede da sua aplicação acompanha o fluxo de conversa dos seus engenheiros? Se dois microsserviços trocam milhões de requisições, mas seus mantenedores nunca fazem pair programming, o incidente é apenas uma questão de "quando".
- Cace os bancos de dados compartilhados: Se múltiplos domínios leem e gravam na mesma base para se manterem sincronizados, a organização está "conversando" pelas tabelas — ignorando completamente a barreira das APIs.
- Analise o histórico de commits e deploys: Liste quais serviços sobem amarrados. Cada par acoplado no Git é uma demonstração de que a fronteira de domínio é uma ilusão de ótica.
A auditoria não revela nada que os desenvolvedores sêniores já não sintam na pele, mas ela converte a intuição em evidência irrefutável para os tomadores de decisão.
Um roteiro para alinhar organização e código
- Diagnostique o abismo: Documente onde a arquitetura desenhada entra em colapso com a forma como as pessoas realmente trabalham.
- Mude a plataforma e as regras antes de mudar os cargos: Reorganizar a empresa sem alterar como os times integram o código é apenas teatro corporativo.
- Autoatendimento técnico é inegociável: Consolidar uma equipe de engenharia de plataforma que entregue governança embarcada sem paralisar o desenvolvedor.
- Acoplamento explícito nas zonas de tensão: Onde dois domínios críticos se esbarram, o contrato (a API, o evento) deve ter propriedade explícita e revisões compartilhadas.
- Auditoria contínua: A empresa pivota, as pessoas saem, a arquitetura envelhece. A Lei de Conway atua 24 horas por dia. O alinhamento sociotécnico é uma prática semanal, não um projeto anual de refatoração.
Conclusão: a arquitetura que você tem é a que a sua empresa merece
Melvin Conway não estava sendo irônico em 1968. Ele estava delineando uma verdade absoluta da engenharia de software contemporânea.
A sua arquitetura corporativa não é o arquivo salvo na nuvem pelo Arquiteto Chefe. É o conjunto vivo de gargalos, concessões e integrações que a sua organização transpira diariamente. Se a comunicação entre as gerências é política e opaca, o tráfego de rede será cheio de intermediários, middlewares e lógicas defensivas. Se a comunicação for descentralizada e confiável, a arquitetura conseguirá respirar através de contratos resilientes.
Não existe abstração de nuvem, malha de serviço ou agente de IA capaz de anular essa mecânica. Resta à liderança técnica uma única decisão consciente: moldar as conversas organizacionais para pavimentar a arquitetura desejada, ou fingir que o organograma não importa e assistir o código traduzir o caos humano em latência, custo e falhas em produção.
A arquitetura segue a organização. Sempre seguiu. A única pergunta é se você vai observar a lei para trabalhar com ela, ou se vai ignorá-la e pagar o preço do atrito no caminho crítico.
Este artigo faz parte da série "Leis Mentais e Princípios Aplicados à Arquitetura de Software e IA".
Episódio anterior: A Lei de Gall — por que todo sistema complexo que funciona evoluiu de um sistema simples que funcionava
Texto complementar: Seis Graus até o Colapso — por que contar microsserviços não diz nada sobre risco
No próximo episódio: a Lei de Goodhart — quando a métrica vira meta e para de medir.
Top comments (0)