What it is
The first three stages produce understanding; the fourth produces code. Architectural stories turn the risks and opportunities identified in risk-storming into backlog items with the same dignity as business stories, written so that anyone, technical or not, understands the value.
This is where AARM differs from a governance process: architecture does not live in parallel documents, it lives in the same product backlog, prioritized by the same criteria, delivered in the same cycles. Coding the architecture, and communicating progress, is what puts it back in the game.
"For a long time we architects thought we were in the business of building software. But we are in the business of building a business." Eben Hewitt, in Technology Strategy Patterns.
How to facilitate
-
Turn risks and opportunities into stories
Every risk prioritized in risk-storming (and every optimization opportunity) becomes an architectural story in the backlog. Scored 6 or 9 on the matrix? It goes to the front.
-
Connect each story to the objective and the characteristic
Every architectural story carries its lineage: which strategic objective it enables, through which characteristic. Without that connection, it is technical debt disguised as strategy.
-
Prioritize in the business backlog, not a parallel one
The negotiation happens with whoever prioritizes the product, using the language of stage 1. Parallel technical backlogs are where architectural stories go to die.
-
Communicate progress
Make the delivered value visible: before-and-after metrics, mitigated risks, strengthened characteristics. Invisible architecture loses the next prioritization round.
From objective to technology
The architectural story is the full bridge between strategy and stack. The framework’s classic example:
AARM Toolkit
The complete kit of fillable templates for the 4 stages: strategy canvas, ilities matrix, risk-storming board, architectural story, ADR and backlog.
Common mistakes
- Technology in search of a justification. "We need to migrate to Kubernetes" is not an architectural story: it is a wish. The sentence starts at the business objective, or it convinces no one to prioritize it.
- The parallel backlog. Keeping architectural stories on a separate board "so they don’t disturb the product" guarantees exactly that: they never disturb anything, because they never get done.
- Delivering without communicating. The team cut deploy time in half and nobody on the business side heard about it. Come the next prioritization, architecture is seen as a cost again.