Move from the guardrails of an architecture initiative through prioritized quality scenarios to a solution put up for review.
An architecture solution checked against prioritized quality scenarios and identified risks, broadly aligned through an RFC.
You can decide which risks still need to be addressed before implementation and when the RFC is approved.
After the comment period closes, finalize the RFC decision and kick off implementation.
Which goals, constraints and testable architecture hypotheses shape the new system?
The canvas creates a shared baseline before quality requirements are prioritized in detail.
The guardrails allow the relevant quality attributes to be concretely prioritized.
Which quality scenarios matter architecturally to business goals and need clarification first?
The workshop makes abstract quality goals such as performance or security tangible in concrete, testable scenarios.
Architectural risks are then deliberately sought for the prioritized scenarios.
Which concrete failure scenarios sit where in the architecture, which matter collectively, and how will we reduce or test them?
Risk storming pools distributed knowledge about possible weaknesses before the solution is locked in.
The addressed risks and the proposed solution are put up for broad review.
Is the proposal decision-ready with alternatives, consequences, and a migration path?
The RFC makes the decision broadly visible before implementation and allows for well-founded objections.
Once the comment period closes, the solution is finally approved and implemented.
Artifacts stay collapsed until you actually need them.
Plan a session or initiative to match the actual scope of work.
# Architecture Inception Canvas: Worksheet
## Question
To be confirmed
## Desired outcome
To be confirmed
## Scope
Prepare the full method
Time: 60–120 minutes with prepared participants; missing requirements or technical research are separate.
Complete this worksheet on paper or in your own document during the work.
## Preparation for this scope
### Method setup
- **Materials:** Official canvas, business goals, communication partners, known constraints and key stakeholders.
- **Roles:** Product/business · software architecture · engineering · stakeholders responsible for quality.
- **Advance information:** Choose materials, data access and participants to fit the research or decision question.
- **Overall time needed:** 60–120 minutes with prepared participants; missing requirements or technical research are separate.
- **Setup:** Open the method-specific structure. Fictional examples are for orientation only; keep the blank worksheet separate from actual findings.
### Prepare for the work steps
#### System: Name system and business case
- Use the published Architecture Inception Canvas and record system, team, workshop date and iteration.
- Official canvas, business goals, communication partners, known constraints and key stakeholders.
#### Goals: Capture context and quality goals
- Context for a greenfield inception
- Official canvas, business goals, communication partners, known constraints and key stakeholders.
#### Constraints: Record constraints
- Context diagram and quality goals
- Official canvas, business goals, communication partners, known constraints and key stakeholders.
#### Hypotheses: Record hypotheses and risks
- Traceable constraints
- Official canvas, business goals, communication partners, known constraints and key stakeholders.
## Architecture Inception Canvas fields from the published template
### Business Case
Describe the business or economic driver.
...
### Functional Overview
List the most important functions at high level.
...
### Business Context
Show the system as a black box and its communication partners.
...
### Organisational Constraints
Record organizational limits on design choices.
...
### Quality Goals
Name three top quality goals from key stakeholder view.
...
### Technical Constraints
Record technical limits on design choices.
...
### Architectural Hypotheses
Record consequential architecture hypotheses and reasons.
...
### Technical Challenges & Risks
List known technical challenges and risks.
...
[Architecture Inception Canvas (official PDF)](https://canvas.arc42.org/downloads/architecture-inception-canvas.pdf)
## System: Name system and business case
Expected artifact: Context for a greenfield inception
Context for a greenfield inception
Entry:
...
- [ ] Is purpose separate from technology?
## Goals: Capture context and quality goals
Expected artifact: Context diagram and quality goals
Context diagram and quality goals
Entry:
...
- [ ] Are partners and quality expectations concrete?
## Constraints: Record constraints
Expected artifact: Traceable constraints
Traceable constraints
Entry:
...
- [ ] Is every constraint binding and verifiable?
## Hypotheses: Record hypotheses and risks
Expected artifact: Hypotheses and technical challenges
Hypotheses and technical challenges
Entry:
...
- [ ] Is a concrete check planned?
## Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/architecture-inception-canvas/run-sheet
Prepare Quality Attribute Workshop with a clear question, roles, and sources.
# Quality Attribute Workshop: Worksheet
## Question
To be confirmed
## Desired outcome
To be confirmed
## Scope
Plan the full method
Time: Set according to scope and available evidence
Complete this worksheet on paper or in your own document during the work.
## Preparation for this scope
### Method setup
- **Materials:** Shared workspace, accessible sources, and a decision log.
- **Roles:** Facilitator · stakeholders · architecture · scribe
- **Advance information:** Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
- **Overall time needed:** A full facilitated workshop; additional stakeholder groups may require further workshops.
- **Setup:** Create a shared version. Label facts, assumptions, and decisions separately.
### Prepare for the work steps
#### Drivers: Understand drivers and stakeholders
- Business drivers, users, and system context
#### Scenarios: Elicit quality scenarios
- Stakeholder needs and quality scenarios
#### Prioritization: Consolidate and prioritize
- Scenarios and prioritization rationale
#### Refinement: Refine key scenarios
- Refined stimulus-environment-response measures
## Prioritized quality scenarios, not a finished architecture
### Driver
Record business goals, system context, and represented roles.
...
### Scenario
Write concrete stimulus, context, and response scenarios.
...
### Priority
Record consolidated scenarios and prioritization rationale.
...
### Open question
Add source, quality attribute, and testable response.
...
Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.
[Quality Attribute Workshop Collection · Software Engineering Institute](https://www.sei.cmu.edu/library/quality-attribute-workshop-collection/)
## Drivers: Understand drivers and stakeholders
Expected artifact: Consolidated business and architecture drivers
Consolidated business and architecture drivers
Entry:
...
- [ ] Are important perspectives represented?
## Scenarios: Elicit quality scenarios
Expected artifact: Quality scenarios from stakeholder perspectives
Quality scenarios from stakeholder perspectives
Entry:
...
- [ ] Are scenarios observable and contextual?
## Prioritization: Consolidate and prioritize
Expected artifact: Prioritized scenarios with rationale
Prioritized scenarios with rationale
Entry:
...
- [ ] Are conflicts and trade-offs visible?
## Refinement: Refine key scenarios
Expected artifact: Refined stimulus-environment-response measures
Refined stimulus-environment-response measures
Entry:
...
- [ ] Can results inform architecture, prototypes, or tests?
## Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/quality-attribute-workshop/run-sheet
Set subject, data, roles, flow, and review.
# Risk Storming: Worksheet
## Question
To be confirmed
## Desired outcome
To be confirmed
## Scope
Complete run
Time: 90–150 minutes for one architecture view; action tracking separate.
Complete this worksheet on paper or in your own document during the work.
## Preparation for this scope
### Method setup
- **Materials:** Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log
- **Roles:** Architecture/tech lead · developers · operations/security · domain/product · facilitator · risk owners
- **Advance information:** Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.
- **Overall time needed:** 90–150 minutes for one architecture view; action tracking separate.
- **Setup:** Prepare a workspace with Context · Solo · Share · Assess · Treat · Review; separate example from live data.
### Prepare for the work steps
#### Context: Shared map
- Set architecture boundary, current diagram version, quality goals, and operating condition; invite required perspectives.
- Current C4/architecture diagrams, quality goals and constraints, risk stickies, evidence, action and decision log
#### Solo: Risk stickies
- Shared map
#### Share: Risk clusters
- Risk stickies
#### Assess: Priority view
- Risk clusters
#### Treat: Treatment plan
- Priority view
#### Review: Risk decision
- Treatment plan
## Risk Storming · working structure
| Risk | Location | Scenario | Quality goal | Evidence | Exposure | Treatment | Owner/review |
| --- | --- | --- | --- | --- | --- | --- | --- |
| R1 · Payment latency | | | | | | | |
| R2 · Retry storm | | | | | | | |
- **R1 · Payment latency:** Add evidence and rationale.
- **R2 · Retry storm:** Add evidence and rationale.
The blank worksheet contains prompts only.
[Reference · original teaching example](https://simonbrown.je/workshops/)
## Context: Shared map
Expected artifact: Shared map
Read diagram, scope, quality goals, and assumptions together; resolve comprehension questions.
Entry:
...
- [ ] Does everyone understand elements, relationships, and critical quality goals alike?
## Solo: Risk stickies
Expected artifact: Risk stickies
Each person silently identifies concrete risk scenarios and locates them on an element or relationship.
Entry:
...
- [ ] Does every note contain trigger, event, and impact?
## Share: Risk clusters
Expected artifact: Risk clusters
Explain notes in turn, cluster duplicates, and preserve different perspectives.
Entry:
...
- [ ] Do distinct scenarios stay separate and common causes remain visible?
## Assess: Priority view
Expected artifact: Priority view
Justify qualitative exposure from plausible occurrence and consequence; mark evidence and unknowns.
Entry:
...
- [ ] Is high exposure grounded in scenario and evidence rather than calculated points?
## Treat: Treatment plan
Expected artifact: Treatment plan
For material risks avoid, reduce, transfer, or accept; assign experiment/ADR and owner.
Entry:
...
- [ ] Does every action state expected risk effect and proof?
## Review: Risk decision
Expected artifact: Risk decision
Approve residual risk, update diagram/ADR, and set trigger for another risk storm.
Entry:
...
- [ ] Is acceptance owned by an authorised person with review date?
## Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/risk-storming/run-sheet
Plan Request for Comments (RFC) around its domain steps and the concrete decision question.
# Request for Comments: Worksheet
## Question
To be confirmed
## Desired outcome
To be confirmed
## Scope
Establish and review the practice
Time: 2–10 working days by consequence
Complete this worksheet on paper or in your own document during the work.
## Preparation for this scope
### Method setup
- **Materials:** Problem and constraints, design draft and alternatives, reviewers and decision owner, shared workspace, source links, and decision log.
- **Roles:** Author · reviewers · decision owner · affected implementers
- **Advance information:** Collect Problem and constraints, design draft and alternatives, reviewers and decision owner in advance and mark open assumptions.
- **Overall time needed:** 2–10 working days by consequence
- **Setup:** Prepare versioned proposal with open review window, resolved comments, and explicit status visibly and calibrate assessment terms before starting.
### Prepare for the work steps
#### Draft: Draft
- Problem and constraints
- design draft and alternatives
- reviewers and decision owner
#### Review: Review
- RFC draft
- design draft and alternatives
- reviewers and decision owner
#### Decision: Decision
- review record
- design draft and alternatives
- reviewers and decision owner
#### Lifecycle: Lifecycle
- RFC decision
- design draft and alternatives
- reviewers and decision owner
## RFC record
### Problem/goals
Problem/goals information to record
...
### Proposal/alternatives
Proposal/alternatives information to record
...
### Review/decision
Review/decision information to record
...
### Migration/status
Migration/status information to record
...
Enter only real input, sources, and decisions.
[IETF RFC 2026: The Internet Standards Process](https://www.rfc-editor.org/rfc/rfc2026)
## Draft: Draft
Expected artifact: RFC draft
RFC draft · source · uncertainty · next decision
Entry:
...
- [ ] Are trade-offs included rather than only benefits?
## Review: Review
Expected artifact: review record
review record · source · uncertainty · next decision
Entry:
...
- [ ] Are Security, Operations, and consumers represented?
## Decision: Decision
Expected artifact: RFC decision
RFC decision · source · uncertainty · next decision
Entry:
...
- [ ] Is every material objection addressed?
## Lifecycle: Lifecycle
Expected artifact: RFC lifecycle
RFC lifecycle · source · uncertainty · next decision
Entry:
...
- [ ] Does status reflect reality?
## Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/rfc/run-sheet