Quem faz o quê
O AARM não cria uma nova hierarquia; ele distribui responsabilidades claras entre papéis que já existem. Quatro deles importam em toda sessão.
- Sponsor executivo
- Confirma os objetivos estratégicos na etapa 1 e recebe o resultado no fechamento. Sem ele, o ciclo produz um bom exercício, não uma decisão com autoridade.
- Facilitador
- Conduz as sessões, protege o timebox e garante que a pessoa mais sênior fale por último. Nas primeiras rodadas, alguém treinado no framework.
- Liderança de produto
- Traz a visão do negócio para a etapa 1 e negocia a priorização das histórias de arquitetura no backlog real, na etapa 4.
- Tech leads e time
- São o coração do risk-storming: quanto mais diversa a sala (engenharia, QA, segurança, operações), mais riscos capturados.
Com que frequência rodar cada etapa
O AARM é um ciclo, não um evento. A pergunta certa não é "quando terminamos", e sim "com que frequência revisitamos cada etapa". Um ponto de partida saudável:
| Etapa | Cadência sugerida | Gatilhos extraordinários |
|---|---|---|
| Estratégia do produto | Anual | Mudança de direção do negócio, novo funding, M&A. |
| Características de arquitetura | Trimestral | Novo objetivo estratégico, incidente crítico |
| Risk-storming | A cada 2 semanas | Mudança arquitetural relevante, novo domínio, pós-incidente |
| Histórias de arquitetura | Quando novos riscos são identificados |
Os primeiros 90 dias
A forma mais segura de adotar o AARM é rodar um ciclo piloto pequeno e visível antes de escalar para outros times.
- 1
Semanas 1–2 · Escolha um produto e rode a etapa 1
Um único produto ou fluxo de valor, de preferência o que mais dói hoje. Confirme de 3 a 5 objetivos estratégicos com o sponsor na sala.
- 2
Semanas 3–5 · Priorize ilities e faça o primeiro risk-storming
Traduza os objetivos em características, escolha as top 3 e reúna o time diante dos diagramas C4 para identificar riscos.
- 3
Semanas 6–8 · Leve as histórias ao backlog
Converta os riscos de nota alta em histórias de arquitetura e negocie a priorização com produto, no backlog real.
- 4
Semanas 9–12 · Meça e comunique
Acompanhe um antes/depois das histórias entregues e comunique o avanço ao negócio. É esse resultado que justifica levar o AARM aos próximos times.
Anti-padrões a evitar
- O arquiteto fala primeiro. Quando a pessoa mais sênior apresenta seus riscos antes da rodada individual, ancora o grupo e a sessão vira validação, não descoberta.
- O backlog paralelo. Manter histórias de arquitetura num quadro separado "para não atrapalhar o produto" garante que elas nunca sejam feitas.
- Priorizar tudo. Uma arquitetura que promete todas as ilities não protege nenhuma. A disciplina das top 3 é o que torna os trade-offs decidíveis.
- Tecnologia antes da característica. Decidir a stack antes de priorizar as ilities inverte o método: a tecnologia vira dogma em vez de consequência.
- Entregar sem comunicar. Arquitetura invisível perde a próxima rodada de priorização. Todo avanço precisa chegar ao negócio na linguagem do objetivo que serve.