Durante anos, a indústria repetiu que squads autônomas seriam o caminho definitivo para a velocidade. E, de fato, muita agilidade nasceu daí. As equipes ganharam foco, ownership e a liberdade de tomar decisões no ritmo do seu contexto.
Mas essa mesma autonomia trouxe um efeito colateral: a Arquitetura ficou periférica. Não porque alguém decidiu “excluir” Arquitetos, mas porque o processo mudou, e poucos perceberam as consequências.
A arquitetura perdeu o timing
No modelo antigo, a Arquitetura vinha antes da construção. Havia tempo e espaço para discutir padrões, características e riscos. No modelo de squads, a história é outra:
- A cada sprint surgem novos contextos.
- As decisões são locais e rápidas.
- O time de Arquitetura não consegue se antecipar a tudo.
- E quando tenta, vira gargalo.
A distância entre Arquitetura e squads aumenta exatamente no momento em que o software se torna mais complexo e mais distribuído.
É nesse intervalo que surgem os sintomas que todo mundo conhece:
- Escolhas de tecnologia inconsistentes;
- Riscos que só aparecem em produção;
- “Salas de guerra” frequentes;
- Retrabalhos caros causados por decisões mal informadas;
- Discussões de Arquitetura acontecendo tarde demais, em cenários de emergência.
A ironia é que nada disso nasce de má intenção. Nasce da falta de um método para conectar as duas pontas.
O AARM reconecta o que foi separado
A força do AARM está em devolver a Arquitetura ao dia a dia e ao contexto real das squads, não como polícia técnica, mas como clareza estratégica.
O AARM faz isso de três formas:
1. Começando pela estratégia do negócio
Quando a squad entende os objetivos estratégicos, ela não toma decisões isoladas. E a Arquitetura deixa de ser abstrata, ela vira instrumento direto para habilitar esses objetivos.
2. Priorizando características de Arquitetura com foco
Escolher 5 a 7 características e destacar 3 como prioridade cria alinhamento imediato. A squad sabe onde não pode errar. E a Arquitetura sabe onde deve apoiar.
3. Trazendo colaboração visual para identificar riscos
O risk-storming coloca todos diante do mesmo diagrama, debatendo o mesmo sistema. É a devolução do diálogo técnico, com contexto, com nuance, com priorização. Quando esse ciclo acontece, uma coisa muda rapidamente: as conversas de Arquitetura deixam de acontecer na crise
e passam a acontecer no planejamento.
O papel redesenhado do Tech Lead
O AARM devolve protagonismo técnico para a própria squad. O Tech Lead vira o “elo vivo” da Arquitetura dentro da equipe:
- Entende os objetivos estratégicos;
- Interpreta as características priorizadas;
- Identifica riscos antes que virem problemas;
- Conduz (junto com o time) as Histórias de Arquitetura.
Isso não elimina Arquitetos. Pelo contrário: fortalece a Arquitetura como guardiã de clareza.
Arquitetura e squad voltam a compartilhar o mesmo mapa
Quando a equipe passa a compreender com clareza o que o produto precisa alcançar, quais características de Arquitetura são realmente essenciais, quais riscos precisam ser mitigados ao longo do caminho e como tudo isso se traduz em histórias concretas dentro do sprint, ela deixa de tomar decisões isoladas e passa a atuar de forma integrada, novamente como parte de um fluxo contínuo de construção.
A autonomia ganha direção
Autonomia sem direção tende à desorganização, assim como direção sem autonomia rapidamente se transforma em burocracia. O AARM surge justamente para ocupar esse espaço intermediário, criando um ambiente seguro onde Arquitetura e squads voltam a se encontrar a partir de um propósito técnico compartilhado. Não se trata de reorganizar estruturas ou impor controle, mas de oferecer clareza para que decisões relevantes sejam tomadas no momento certo, com informação suficiente e impacto real.
Quando Arquitetura e times deixam de operar em extremos e passam a atuar de forma conectada, algo fundamental acontece: o software evolui com mais qualidade e coerência, os times ganham fôlego para trabalhar com menos fricção, e o negócio passa a confiar novamente no sistema que está sendo construído.