Por que precisamos mexer em 3 lugares diferentes pra subir uma funcionalidade em produção?
- Erik Aceiro Antonio
- 11 de abr.
- 2 min de leitura

Essa decisão era nossa, ou do outro time ?
Vamos marcar uma reunião com todo mundo …
Você já deve ter passado por situações assim, e eu também, seja no meio de uma sprint, em um Fórum de Arquitetura, ou em simples chat de mensagem do Teams ou Slack.
Estávamos pra entregar uma funcionalidade simples. Uma API de consulta, nada de rocket science da NASA como dizia um antigo líder e mentor.
Mas tínhamos um dilema, ou para aqueles em reunião que gostam de falar como filósofos do Olimpo, um acoplamento acidental.
Para mim era, eu vejo assim.
aquele bloco de macarronada de final de semana, que você vai comer e parece um bloco de cimento, e você joga azeite, molho e não solta.
Enfim, agora para isso funcionar, precisávamos:
Atualizar um serviço mantido por outro time
Mudar a API e atualizar todos os outros times e que nem sabíamos quem eram
Atualizar o payload de umas filas SNS/SQS que notificam... sei lá quem
Tínhamos um problema onde cada parte dessa jornada morava em um time diferente. E cada time com suas próprias prioridades, e Backlogs. Ficamos semanas só para orquestrar o caos, com reuniões e alinhamentos.
Não por causa da complexidade da funcionalidade. Mas pela forma como a organização estava estruturada ao redor da tecnologia.
No fim, entregamos. Mas a partir dessa experiência, levo comigo uma pergunta que sempre ecoa:
Por que as pessoas e times têm que sofrer para implementar uma funcionalidade ?
Perceba que você poderia fazer a pergunta de outra forma e que tem efeito similar, porém com um olhar diferente.
Por que temos que ter esse acoplamento acidental ?
Como um arquiteto cientista, sempre procuro compreender os efeitos e fenômenos. Nesse dia, entendi na prática o que o Nick Tune chama de falta de alinhamento sociotécnico.
O sistema parecia modular. Mas a colaboração era monolítica. Às vezes, o problema não está na engenharia. Está na arquitetura organizacional que vive um descompasso com a arquitetura de software.
Evoluir é equilibrar a arquitetura organizacional que queremos com a arquitetura que vivemos.
Talvez o gargalo não seja técnico.
É sobre equilíbrio entre arquitetura organizacional e arquitura de software.






Comentários