Na altura, a Harvard Business Review rejeitou o seu trabalho original com base no facto de ele não ter provado a sua hipótese. No entanto, esta observação ficou conhecida como a Lei de Conway, e as experiências coletivas tanto dos meus colegas como de mim mesmo reforçaram repetidamente a verdade desta afirmação. Mas não é preciso acreditar na nossa palavra!
Em “Exploring the Duality between Product and Organizational Architectures”, um estudo da The Harvard Business School realizou uma análise de diferentes bases de código para ver se elas poderiam provar a hipótese original de Conway como aplicada a sistemas de software. Nele, eles tomaram vários exemplos de software criado para resolver o mesmo propósito (por exemplo, processamento de texto, gestão financeira e software de banco de dados), e compararam as bases de código criadas por equipes de código aberto frouxamente acopladas, e aquelas criadas por equipes fortemente acopladas. O estudo deles descobriu que as equipes de produtos muitas vezes co-localizadas e focadas criaram softwares que tendem mais para bases de código monolíticas e fortemente acopladas. Enquanto os projetos de código aberto resultaram em bases de código mais modulares e decompostas.
Organizações há alguns anos têm entendido esta ligação entre estrutura organizacional e software que criam, e têm abraçado novas estruturas a fim de alcançar o resultado desejado. A Netflix e a Amazon, por exemplo, estruturam-se em torno de várias pequenas equipes, cada uma com responsabilidade por uma pequena parte do sistema como um todo. Estas equipas independentes podem ser donas de todo o ciclo de vida dos serviços que criam, dando-lhes um maior grau de autonomia do que é possível para equipas maiores com bases de código mais monolíticas. Estes serviços com suas preocupações independentes podem mudar e evoluir separadamente uns dos outros, resultando na capacidade de entregar mudanças à produção mais rapidamente. Se essas organizações tivessem adotado equipes maiores, os sistemas monolíticos maiores que teriam surgido não lhes teriam dado a mesma capacidade de experimentar, adaptar-se e, finalmente, manter seus clientes satisfeitos.
Você pode ver tensões em suas próprias organizações onde sua estrutura e software não estão alinhados. Você pode ter visto, por exemplo, os desafios envolvidos onde equipes distribuídas tentam e trabalham na mesma base de código monolítico. Aqui, os caminhos de comunicação a que a Conway se refere estão em contraste com o próprio código, onde uma única base de código requer uma comunicação de granulação fina, mas uma equipe distribuída só é capaz de uma comunicação de granulação grosseira. Onde tais tensões surgem, a busca de oportunidades para dividir os sistemas monolíticos em torno das fronteiras organizacionais muitas vezes trará vantagens significativas.
Nos Radares Tecnológicos anteriores destacamos a crescente popularidade dos Microservices, que estão sendo cada vez mais adotados por organizações que buscam melhorar a autonomia de suas equipes e aumentar a velocidade das mudanças. O artigo de Martin Fowler e James Lewis aprofunda o assunto, destacando que essas arquiteturas permitem às organizações muito mais flexibilidade no alinhamento da arquitetura de seus sistemas com a estrutura de suas equipes, a fim de garantir que a lei da Conway funcione para você. Na próxima edição do Tech Radar, vamos discutir o reflexo da crescente influência da Microservices, desde a tecnologia de infraestrutura como Packer ou Docker até a ferramenta de descoberta de serviços Consul, ou microcontainers como o popular DropWizard ou o bastante novo SpringBoot. Também discutiremos o reverso – organizações mudando sua estrutura de equipe para se adequar a seus sistemas de TI.
Esperamos ver mais técnicas e tecnologia de suporte emergindo para permitir arquiteturas Microservice, e estaremos acompanhando isso ao longo dos próximos meses. Entretanto, se você quiser saber mais, inscreva-se no último Tech Radar, confira o artigo de Martin e James sobre microservices, ou meu livro de O’Reilly, Building Microservices.