Conway’s Law

É responsabilidade do CTO estruturar a empresa de forma ótima para o desenvolvimento de soluções, maximizando resultados. Para ser eficiente, ele deve fazer isso considerando a seguinte observação, proferida por Melvin Conway, em 1967 (há mais de cinquenta anos).

Qualquer empresa que projeta um sistema, inevitavelmente, produz um projeto cuja a estrutura é uma cópia da estrutura de comunicação da organização.

Esta afirmação, conhecida como “Conway’s Law”, vem sendo comprovada empiricamente e demonstrada em estudos rigorosos.

Produtos são “espelhos” das organizações que os produzem. (MacCormack, Rusnak e Baldwin)

A implicação prática da lei de Conway é que, a forma como “pensamos” nossas organizações tem impacto direto nos sistemas que desenvolvemos.  Não é possível projetar microsserviços em uma organização com um time organizado de maneira monolítica.

Se desejamos que os componentes dos sistemas que produzimos operem com baixo acoplamento, coesos, e de forma alinhada, precisamos ter times que operem dessa forma. Equipes com autonomia mas sem alinhamento, produzem sistemas com baixo acoplamento mas que não entregam o resultado esperado.

A melhoria da comunicação entre os componentes de um sistema é consequência direta da melhoria na comunicação entre os times que os desenvolvem. Se dois componentes, em um sistema, estão se sobrepondo, então, há, na organização, dois times se sobrepondo.

Recentemente, começamos a ajudar uma organização, de porte médio, que deseja decompor suas soluções em microsserviços, de forma que, inclusive, os diversos produtos os utilizem de maneira compartilhada.

Observamos, imediatamente, que a organização atual dos times de desenvolvimento, em torno dos produtos,  impossibilitaria o atingimento desse objetivo. Enquanto os times estiverem organizados por produto, terão seus “roadmaps” orientados pelo desenvolvimento destes produtos.

Se o desejo da organização é desenvolver serviços independentes e compor produtos a partir desses serviços, então, devem existir times organizados “por serviço”, “compondo produtos” a partir desses serviços.

É papel do CTO, independente do perfil demandado pela organização, explicitar com o time as características desejadas para os sistemas que se pretende desenvolver. Então, garantir que a  organização esteja estruturada de forma compatível com essas características.

Não sonhe com microsserviços se tudo o que consegue gerenciar é uma equipe monolítica. Não sonhe com serviços coesos e com baixo acoplamento se sua gestão é baseada em comando e controle.