Manual do CTO

Um exemplo prático da importância da lei de Conway

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.

Em Resumo
  • O fato

    A lei de Conway é implacável: arquiteturas promissoras sucumbem frente a estruturas de times descuidadas.
  • O insight

    Cabe ao CTO a responsabilidade de garantir que a estrutura dos times seja compatível com a arquitetura de software que se deseja implementar. Boas estruturas potencializam resultados. Estruturas ruins ou ingênuas destroem valor.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Mais posts da série Manual do CTO

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *