Desmistificando a Lei de Conway

Muitos anos atrás, Melvin Conway observou que a forma como as organizações eram estruturadas tinha um forte impacto sobre os sistemas que elas criavam. Em seu “How Do Committees Invent", ele escreveu:

"Qualquer empresa que projeta um sistema (definição mais ampla aqui do que apenas sistemas de informação), inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização."

Na época, o Harvard Business Review rejeitou seu artigo original, com base no fato de que ele não tinha provado a sua hipótese. No entanto, essa observação tornou-se conhecida como Lei de Conway, e as experiências coletivas de ambos os meus colegas e de mim mesmo repetidamente reforçaram a verdade dessa declaração. Mas você não tem que confiar na nossa palavra!

Em "Explorando a dualidade entre o produto e Arquiteturas Organizacionais", um estudo realizado pela Harvard Business School fez uma análise de diferentes bases de código para ver se eles poderiam provar a hipótese original de Conway quando aplicada a sistemas de software. No artigo, trouxeram vários exemplos de software criado para resolver o mesmo propósito (por exemplo, processamento de textos, gestão financeira e software de banco de dados), e compararam os códigos-base criados por equipes de código aberto fracamente acopladas, e aqueles criados por equipes fortemente acopladas. O estudo descobriu que frequentemente as equipes de produto co-localizadas e focadas criavam softwares que tendiam mais ao acoplamento, a códigos-base monolíticos. Enquanto que os projetos de código aberto resultaram em códigos-base mais modulares e decompostos.

Há alguns anos as organizações têm entendido esta ligação entre a estrutura organizacional e o software que criam, e têm abraçado novas estruturas a fim de alcançar os resultados desejados. A Netflix e a Amazon, por exemplo, estruturam-se em torno de várias pequenas equipes, cada uma com a responsabilidade de uma pequena parte de todo o sistema. Essas equipes independentes podem ter autoridade sobre todo o ciclo de vida dos serviços que criam, o que lhes dá um maior grau de autonomia do que é possível para as equipes maiores, com códigos-base monolíticos. Esses serviços com as suas preocupações independentes podem mudar e evoluir separadamente uns dos outros, resultando na capacidade de lançar mudanças para produção mais rápido. Se essas organizações tivessem adotado equipes de tamanhos maiores, os sistemas monolíticos maiores que surgiriam não teriam permitido a eles a mesma capacidade de experimentar, se adaptar, e, finalmente, manter seus clientes satisfeitos.

Você talvez veja tensões em sua própria organização, onde a estrutura e software não estão em alinhamento. Você pode ter visto, por exemplo, os desafios envolvidos em equipes distribuídas tentarem trabalhar no mesmo código-base monolítico. Aqui, as vias de comunicação a que Conway se refere estão em contraste com o próprio código, onde um único código-base requer comunicação de granulação fina, mas uma equipe distribuída só é capaz de comunicação de granulação grossa. Quando essas tensões emergem à procura de oportunidades para dividir sistemas monolíticos em torno das fronteiras organizacionais, muitas vezes vai render vantagens significativas.

Em edições anteriores do Technology Radar destacamos a crescente popularidade dos microsserviços, que estão cada vez mais sendo adotados por organizações que buscam melhorar a autonomia de suas equipes e aumentar a velocidade de mudança. O artigo de Martin Fowler e James Lewis entra em mais profundidade no assunto, destacando o fato de que essas arquiteturas permitem às organizações muito mais flexibilidade no alinhamento da arquitetura de seus sistemas para a estrutura de suas equipes, a fim de garantir que a lei de Conway funcione para você. Na última edição do Tech Radar, discutimos o reflexo da crescente influência dos microsserviços, desde tecnologias de infraestrutura como Packer ou Docker à ferramenta de descoberta de serviço Consul, ou micro-containers como o popular DropWizard ou o relativamente novo SpringBoot. Discutiremos também o inverso - as organizações mudando sua estrutura de equipe para ajustarem-se a seus sistemas de TI.

Esperamos ver mais técnicas e tecnologias de suporte emergirem para permitir arquiteturas de microsserviços, e estaremos mantendo o controle destas ao longo dos próximos. Entretanto, se você quiser saber mais, inscreva-se para receber as últimas Tech Radar, confira os artigos sobre microsserviços de Martin e James , ou o meu livro da O'Reilly, Building Microservices.