o design organizacional impacta diretamente a arquitetura de software, especialmente em ambientes de microsserviços.
a manobra inversa de conway
a lei de conway afirma que sistemas de software tendem a copiar a estrutura de comunicação das organizações que os constroem. se ignorarmos isso, a lei atua como um anti-pattern, criando arquiteturas acopladas e difíceis de manter.
lei de conway
“organizações que projetam sistemas são constrangidas a produzir designs que são cópias das estruturas de comunicação dessas organizações.” — Melvin Conway
a manobra inversa de conway consiste em evoluir a estrutura do time e da organização para corresponder à arquitetura desejada. em vez de deixar os times definirem a arquitetura organicamente, os times são estruturados para facilitar o modelo de microsserviços. na prática, são criados times multifuncionais e desacoplados, permitindo que a arquitetura do software também seja desacoplada.
two pizza team
conceito popularizado pela amazon para definir o tamanho ideal de uma equipe ágil.
- um time deve ser pequeno o suficiente para ser alimentado com apenas duas pizzas.
- equipes menores se comunicam de forma mais eficiente (menos ruído), reduzindo a sobrecarga cognitiva.
- o tamanho reduzido força a limitação do escopo de responsabilidade. o time deve ser capaz de entender todo o serviço pelo qual é responsável, sem depender excessivamente de outros times para tomar decisões.
produto vs projeto
para que microsserviços funcionem, é necessária uma mudança de mentalidade de “gestão de projetos” (início, meio e fim) para “gestão de produtos” (ciclo de vida contínuo). microsserviços devem ser encarados como produtos contínuos, não como projetos que acabam ao serem entregues.
cultura de projeto (tradicional)
- foco na entrega pontual.
- equipe de desenvolvimento entrega o código e “passa o bastão” para operações/sustentação.
- gera pouco incentivo para qualidade a longo prazo.
cultura de produto (ownership)
“you build it, you run it” — Werner Vogels
- quem desenvolve também opera, mantém e corrige, tendo responsabilidade por todo o ciclo de vida do serviço
- incentiva decisões de código são mais cuidadosas, pois a equipe de desenvolvimento também lida com o impacto de suas decisões no dia a dia.
- integração com especialistas de negócio para entender o que gera valor, evitando desperdício e funcionalidades inúteis.
- garante que o software continue evoluindo com o negócio.
team topologies
baseado no livro de Matthew Skelton e Manuel Pais, define quatro tipos fundamentais de times para reduzir a sobrecarga cognitiva e acelerar o fluxo.
🟡 stream-aligned team
- é o time responsável pela entrega contínua de valor, alinhado a uma capacidade de negócio específica (ex: checkout, catálogo, pagamentos).
- deve ser autônomo e multifuncional.
🔵 platform team
- ajuda a reduzir a sobrecarga cognitiva dos times de fluxo (stream-aligned)
- entrega infraestrutura como serviço, ferramentas padronizadas, pipelines de CI/CD, bibliotecas e frameworks internos.
- a plataforma é tratada como um produto interno. deve oferecer “caminhos pavimentados” para que os outros times trabalhem rápido, equilibrando autonomia com padronização.
🟣 enabling team
- formado por consultores internos e especialistas.
- ajudam os stream-aligned teams a adotar novas tecnologias ou boas práticas.
- têm atuação temporária (timeboxed). o objetivo não é criar dependência, mas sim dar autonomia (capacitar o time e sair).
🔴 complicated subsystem team
- lida com partes do sistema que requerem conhecimento de nicho extremamente específico (ex: um algoritmo de reconhecimento de imagem proprietário, um motor matemático complexo).
- deve existir apenas quando necessário. em muitos casos acaba sendo melhor que os times de valor sejam capazes de gerenciar seus sistemas complexos
- funciona em casos em que complexidade é tão alta que, se ficasse com o time de fluxo, travaria a entrega de valor.