Architecture

Documents an architecture decision with context, alternatives, and consequences so later reviews remain traceable.

Core question: Which architecture decision are we making in this context, why choose it and which consequences does it carry?

• 15-45 min
• 1-3

Structures architecture knowledge across goals, context, runtime, and deployment into living system documentation.

Core question: What system context, constraints, and decisions must the architecture communicate?

• 1-2 Tage
• 1-4

Makes system, container, and building blocks legible in graduated views, easing architecture communication.

Core question: Which diagrams let each audience understand the software architecture?

• 1-4 h
• 1-5

Gathers quality goals, prioritizes risks, and turns them into architecture topics evaluated together.

Core question: Which quality scenarios matter architecturally to business goals and need clarification first?

• 2-4 h
• 5-15

Bundles problem, goals, stakeholders, and risks into a starting picture that sorts early architecture questions.

Core question: Which goals, constraints and testable architecture hypotheses shape the new system?

• 1-2 h
• 3-8

Prepares stakeholders, core messages, and artifacts so architecture communication connects deliberately.

Core question: What system information must these recipients understand, examine or communicate onward?

• 60-120 min
• 2-8

Gathers system goals, constraints, and building blocks into a compact view for early architecture decisions.

Core question: Which business and functional context bounds the solution space, and which architecture hypotheses must be tested?

• 1-2 h
• 3-10

Connects several views of large systems and keeps cross-view information for the overall picture.

Core question: Which views serve these stakeholders, and what must be documented beyond each view?

• 1-3 Tage
• 1-4

Moves architecture context, options, and consequences toward a concrete result through "place the architecture diagram or plan in the center", "set risk categories such as technical, organizational, and external", and "assign an owner and next steps for each top risk".

Core question: Which concrete failure scenarios sit where in the architecture, which matter collectively, and how will we reduce or test them?

• 60-90 min
• 4-12

Uses a structured proposal and review process to make non-trivial technical or product changes discussable and decidable.

Core question: Is the proposal decision-ready with alternatives, consequences, and a migration path?

• 1-3 Wochen vom Draft bis zur Entscheidung
• 3-20 Reviewer

Examines how architecture decisions support important quality goals and makes risks and trade-offs visible.

Core question: How does the architecture support our most important quality goals, and where do risks or trade-offs arise?

• Several meetings plus preparation and analysis; total effort depends on scope
• Evaluation team, architects, and relevant stakeholders

Uses concrete tasks to show how well an architecture supports use and change.

Core question: What changes do our planned tasks require, and how do the architecture alternatives differ?

• Preparation, scenario analysis, and findings review; effort depends on scope
• Architecture experts and stakeholders for scenarios and weighting

Developers try a preliminary technical design through typical tasks, showing what makes it easy or difficult to use.

Core question: Can developers accomplish their important tasks using this preliminary design?

• 2–4 h review as a planning range; preparation and evaluation additional
• Designers, developers as users, and facilitation

Helps a small team assess the main quality risks in its software and choose where to investigate further.

Core question: How well does our software meet its quality goals, and which risks should we investigate further?

• 3–4 h for initial assessment; preparation and deeper analysis additional
• 1 or a small team; particularly suitable for 3–4 people