Who does what
AARM doesn’t create a new hierarchy; it assigns clear responsibilities to roles that already exist. Four of them matter in every session.
- Executive sponsor
- Confirms the strategic objectives in stage 1 and receives the outcome at the readout. Without them, the cycle produces a good exercise, not a decision with authority.
- Facilitator
- Runs the sessions, protects the timebox and makes sure the most senior person speaks last. In the first rounds, someone trained in the framework.
- Product leadership
- Brings the business view to stage 1 and negotiates the prioritization of architectural stories in the real backlog, in stage 4.
- Tech leads and team
- They are the heart of risk-storming: the more diverse the room (engineering, QA, security, operations), the more risks captured.
How often to run each stage
AARM is a cycle, not an event. The right question isn’t "when are we done", but "how often do we revisit each stage". A healthy starting point:
| Stage | Suggested cadence | Extraordinary triggers |
|---|---|---|
| Product strategy | Annual | Business direction shift, new funding, M&A |
| Architecture characteristics | Quarterly | New strategic objective, critical incident |
| Risk-storming | Every 2 weeks | Major architectural change, new domain, post-incident |
| Architectural stories | Every new risk identified |
The first 90 days
The safest way to adopt AARM is to run a small, visible pilot cycle before scaling to other teams.
- 1
Weeks 1–2 · Pick a product and run stage 1
A single product or value stream, ideally the one that hurts most today. Confirm 3 to 5 strategic objectives with the sponsor in the room.
- 2
Weeks 3–5 · Prioritize ilities and run the first risk-storming
Translate objectives into characteristics, choose the top 3, and gather the team in front of the C4 diagrams to identify risks.
- 3
Weeks 6–8 · Take the stories to the backlog
Turn the high-scored risks into architectural stories and negotiate prioritization with product, in the real backlog.
- 4
Weeks 9–12 · Measure and communicate
Track a before/after of the delivered stories and communicate progress to the business. That result is what justifies bringing AARM to the next teams.
Anti-patterns to avoid
- The architect speaks first. When the most senior person presents their risks before the individual round, they anchor the group and the session becomes validation, not discovery.
- The parallel backlog. Keeping architectural stories on a separate board "so they don’t disturb the product" guarantees they never get done.
- Prioritizing everything. An architecture that promises every ility protects none. The top-3 discipline is what makes trade-offs decidable.
- Technology before the characteristic. Deciding the stack before prioritizing the ilities inverts the method: technology becomes dogma instead of consequence.
- Delivering without communicating. Invisible architecture loses the next prioritization round. Every advance must reach the business in the language of the objective it serves.