Mesmo a arquitetura mais cuidadosa de um software sucumbirá frente ao eventual design descuidado dos times de uma organização que a implementará. Afinal, como ensina a lei de Conway, com o tempo, a estrutura de um software tenderá a replicar a estrutura de comunicação da empresa que o desenvolve.

Já indicamos, no passado, a importância da lei de Conway para o planejamento tanto da arquitetura de um software quanto para a estruturação dos times da organização. Dessa vez, recorreremos a um exemplo mais concreto.

Considerando, por exemplo, uma empresa onde:

• há três times organizados por área de negócio (squads), agregando desenvolvedores Back-end e Front-end;
• há um único núcleo de profissionais, compartilhado e corporativo, para manter as estruturas de bancos de dados;
• há um único time para suportar a operação;

É possível prever que, com o tempo, qualquer solução desenvolvida:

• conterá três “contextos” com delimitação forte, onde, o código do Backend será “próprio” para atender o Frontend desenvolvido para ele, mas não será fácil de acessar externamente;
• tenderá a ter uma única base, compartilhada, acoplada e monolítica, que atenderá as demandas de todo o software da organização e será gargalo para evolução;
• terá deploy combinado, do tipo tudo ou nada, envolvendo as entregas de todos os times de organização.

Aliás, seguindo a teoria das restrições, podemos inferir, também, que o ritmo das entregas será determinado pelo time menos eficiente.

Também não se pode ignorar que se, além da estrutura de comunicação essencial, os times também tiverem conversas incentivadas em ferramentas de comunicação ou em ritos da organização, então crescem as chances de que se formem, também, pontos de acoplamento entre os componentes que esses times desenvolvem.

Todas essas dificuldades são previsíveis, à luz da lei de Conway, e poderiam ser evitadas com o design cuidadoso da estrutura organizacional. Se a intenção é não ter uma base de dados monolítica, então é essencial diluir o “núcleo DBA” nas squads. Se a intenção é permitir deploy independente, então o “núcleo de operações” também precisa ser diluído. Finalmente, se for importante oferecer uma experiência consistente e consolidada no que é produzido na organização, externamente, então, é indispensável considerar uma equipe responsável por esse intento.

Importante, porém, destacar que qualquer “consolidação” também representa, em algum nível, acoplamento. Por isso, é importante ter claro o que se pretende oferecer “dentro e fora de casa”.

Antes de implementar uma arquitetura promissora, cabe ao CTO garantir que a estrutura dos times seja compatível.