methodatlas
Method guideArchitecture

Views and Beyond

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityMedium
Time1-3 Tage
Participants1-4
FormatWorkshop + async
MaturityCanonical
Plan the work
01

Prerequisite

What needs to be finished first

Complete firstClear working frame

List stakeholder questions and intended documentation use before choosing views.

Without a bounded question or checkable evidence, the result will be unclear.
02

Preparation

What needs to be ready before start

Materials

Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

People / roles

Architect · implementers · operations · testers/security analysts as relevant; view consumers review usability.

Pre-read

Choose materials, data access and participants to fit the research or decision question.

Time needed

An initiative across several days as views and evidence are assembled.

Setup

Open the method-specific structure. Fictional examples are for orientation only; keep the blank worksheet separate from actual findings.

03

Core question

The one question this method answers

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

04

Flow

Phases with goal, actions, output and pitfall

Views and Beyond documents software architecture through stakeholder-relevant views and adds cross-view information and rationale.

Views and Beyond working record

Fictional example

Method-specific prompts and a fictional worked example; template prompts remain empty.

Identify stakeholder use

Create a stakeholder-led documentation roadmap.

**Uses:** Operators need deployment and recovery information; developers need module responsibility and dependencies.

Select relevant views

Keep view elements and relations explicit.

**Views:** An allocation view for runtime placement and a module view for implementation responsibilities, if confirmed by those needs.

Document each view

Explain the diagram so readers can build, analyze, operate or maintain.

**View content:** Identifiers, relations, constraints and relevant interface detail accompany each diagram.

Add cross-view rationale

Review shared facts for consistency.

**Beyond views:** Rationale for a payment adapter plus assumptions and cross-view references.

SEI recommends selecting relevant views for stakeholder use, then documenting cross-view information and rationale.

Views and Beyond Collection | CMU Software Engineering Institute

  1. 1

    Use

    Identify stakeholder use

    Goal

    Create a stakeholder-led documentation roadmap.

    Inputs for this step

    • List stakeholder questions and intended documentation use before choosing views.
    • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

    Actions

    • Name stakeholders and intended documentation use; choose views to answer their questions.
    • Record Documentation roadmap with its evidence status, source or open verification need.

    Output

    Documentation roadmap

    Documentation roadmap

    Quality check

    Does each view serve a named use?

    Pitfall

    Views are selected by habit. Remove views without an audience need.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  2. 2

    Views

    Select relevant views

    Goal

    Keep view elements and relations explicit.

    Inputs for this step

    • Documentation roadmap
    • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

    Actions

    • Choose viewtypes appropriate to concerns; record scope, notation and rationale.
    • Record A small relevant view set with its evidence status, source or open verification need.

    Output

    A small relevant view set

    A small relevant view set

    Quality check

    Are views distinct and justified?

    Pitfall

    Diagrams mix conventions without definition. Name types, elements, relations and notation.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  3. 3

    Detail

    Document each view

    Goal

    Explain the diagram so readers can build, analyze, operate or maintain.

    Inputs for this step

    • A small relevant view set
    • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

    Actions

    • Record elements, relations and the properties, interfaces or behavior needed by its audience.
    • Record Usable architecture views with its evidence status, source or open verification need.

    Output

    Usable architecture views

    Usable architecture views

    Quality check

    Is more than a picture documented?

    Pitfall

    A box-and-line sketch lacks semantics. Add legend, constraints and supporting detail.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

  4. 4

    Cross-view

    Add cross-view rationale

    Goal

    Review shared facts for consistency.

    Inputs for this step

    • Usable architecture views
    • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

    Actions

    • Record information applying across views, rationale, assumptions and relationships; maintain cross references.
    • Record Coherent documentation package with its evidence status, source or open verification need.

    Output

    Coherent documentation package

    Coherent documentation package

    Quality check

    Can readers trace relationships?

    Pitfall

    Copied facts drift between views. Use identifiers, links and an owner.

    Timing: About 10–20 minutes; schedule data or clarification work separately.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Views & Beyond · ArchitekturdokumentationArchitektur über Module, Laufzeit, Zuordnung und Beyond-Artefakte gezielt für Leser dokumentieren
Views and BeyondDas Visual zeigt drei Architekturviews und die Beyond-Artefakte Quality Scenarios, Rationale und Documentation Map.Architektur für unterschiedliche Leser strukturierenViews zeigen unterschiedliche Sichten; Beyond erklärt Qualität, Begründung und Lesepfade.ergänztordnet zuBeyondBegründungNavigationModule ViewCode-StrukturComponent & ConnectorLaufzeit und DatenflüsseAllocation ViewDeployment, Teams, HardwareQuality Scenarioswichtige -ilitiesRationalewarum entschiedenDocumentation MapLesepfade
Form

Versioned record of question, evidence, result, uncertainty, owners and next review date.

Versioning / ownership

Track date, scope, sources, assumptions and changes; assign an owner and review for ongoing practice or initiatives.

Tool alternatives
  • Paper and pens
  • Whiteboard or simple table

views-and-beyond-working-template.md

Plan a session or initiative to match the actual scope of work.

Views and Beyond: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Prepare the full method Time: An initiative across several days as views and evidence are assembled.

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.
  • Roles: Architect · implementers · operations · testers/security analysts as relevant; view consumers review usability.
  • Advance information: Choose materials, data access and participants to fit the research or decision question.
  • Overall time needed: An initiative across several days as views and evidence are assembled.
  • 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

Use: Identify stakeholder use

  • List stakeholder questions and intended documentation use before choosing views.
  • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

Views: Select relevant views

  • Documentation roadmap
  • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

Detail: Document each view

  • A small relevant view set
  • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

Cross-view: Add cross-view rationale

  • Usable architecture views
  • Current system evidence, stakeholder concerns, interface and behavior records, notations and an owner.

Views and Beyond working record

Identify stakeholder use

Create a stakeholder-led documentation roadmap.

...

Select relevant views

Keep view elements and relations explicit.

...

Document each view

Explain the diagram so readers can build, analyze, operate or maintain.

...

Add cross-view rationale

Review shared facts for consistency.

...

Blank worksheet contains prompts only, with no example data.

Views and Beyond Collection | CMU Software Engineering Institute

Use: Identify stakeholder use

Expected artifact: Documentation roadmap

Documentation roadmap

Entry:

...

  • Does each view serve a named use?

Views: Select relevant views

Expected artifact: A small relevant view set

A small relevant view set

Entry:

...

  • Are views distinct and justified?

Detail: Document each view

Expected artifact: Usable architecture views

Usable architecture views

Entry:

...

  • Is more than a picture documented?

Cross-view: Add cross-view rationale

Expected artifact: Coherent documentation package

Coherent documentation package

Entry:

...

  • Can readers trace relationships?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/views-and-beyond/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

views-and-beyond-beispiel.md

Concrete filled scenario, fictional example

Fictional example: reservation service

Uses: Operators need deployment and recovery information; developers need module responsibility and dependencies.

Views: An allocation view for runtime placement and a module view for implementation responsibilities, if confirmed by those needs.

View content: Identifiers, relations, constraints and relevant interface detail accompany each diagram.

Beyond views: Rationale for a payment adapter plus assumptions and cross-view references.

Review: Operators and developers check that the documentation supports their work.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Identify stakeholder useViews are selected by habit.View in phase
  2. Select relevant viewsDiagrams mix conventions without definition.View in phase
  3. Document each viewA box-and-line sketch lacks semantics.View in phase
  4. Add cross-view rationaleCopied facts drift between views.View in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

Omit views without a stakeholder need. If views contradict one another, reconcile source facts and ownership before dependent decisions.

Where to go next?

Paper illustration of two considered options leading to a decision record with a marked status and visible consequences.
Architecture
Architecture Decision Record

Records the design rationale behind a view as its own decision.

A paper-based illustration representing C4 Model with its core stages and visible working result.
Architecture
C4 Model

Uses C4 as the concrete notation for one of the chosen views.

View in playbookBuild Architecture DocumentationMove from scattered architecture knowledge to views, decisions, and communicable documentation.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods