methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method session2-3 days initial, then maintained living documentWorkshop or asyncArchitecture Views

Session: Views and Beyond

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 1-4. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Architecture Views. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Section 1: Viewpoint selection

    60 min

    From the set (Module, Component-and-Connector, Allocation, Deployment, Behavior), select the viewpoints needed for stakeholders and quality attributes. Document audience and purpose per viewpoint. Hint: Not all viewpoints are mandatory. At least Module, Component-and-Connector, Deployment. Add others when needed.

    FacilitatorArchitecture Views
  2. 2

    Section 2: Module View

    2-3 h

    Structural code organization: modules, layers, subsystems. Dependencies between modules. Module responsibility. Hint: Module View shows static structure, not runtime. If discussion turns to runtime behavior, it belongs in C-and-C View.

    FacilitatorCross-view Notes
  3. 3

    Section 3: Component-and-Connector View

    3-4 h

    Runtime components and their connectors (REST, Kafka, filesystem). Data flows, protocols, QoS properties. Hint: Most important view for performance and availability scenarios. Bottlenecks become visible here.

    FacilitatorRationale
  4. 4

    Section 4: Allocation Views

    2-3 h

    Deployment (mapping to infrastructure, cloud regions, containers), work assignment (mapping to teams), implementation (mapping to repos). Hint: Deployment view is critical for operations and SRE. Work assignment helps in Team Topology discussions.

    FacilitatorArchitecture Views
  5. 5

    Section 5: Behavior and Beyond

    2-3 h

    If needed, Behavior Views (sequence, state, activity) for critical workflows. Beyond section: glossary, architecture drivers, quality attribute scenarios, ADR list, variability, mapping between views. Hint: Cross-View Beyond is the connector. Without it, views remain isolated and contradictory.

    FacilitatorCross-view Notes
  6. 6

    Section 6: Review and maintenance

    ongoing

    Reviews with stakeholder per view. Versioning. Change pipeline: ADR trigger -> update affected views -> re-review. Hint: Architecture documentation without maintenance ages quickly. Define quarterly or release-triggered review cadence.

    OwnerRationale
  7. 7

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerArchitecture Views
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Views and Beyond

Goal

Artifact: Architecture Views

Working Question

Which views address which stakeholders with which quality concern, and which cross-view information binds them into a consistent picture?

Context

Stakeholder requirements per group; existing architecture artifacts; quality-attribute scenarios; component list from canvas; language conventions (glossary).

Setup

  • Format: Method session
  • Duration: 2-3 days initial, then maintained living document
  • Mode: Workshop or async
  • Participants: One architect with Views-and-Beyond experience; engineering leads per subsystem; one reviewer from operations; stakeholder representative for validation; scribe.
  • Owner: One architect with Views-and-Beyond experience
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Architecture Views. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Whiteboard or modeling tool; view templates per view type (Module, Component and Connector, Allocation); Cross-View Beyond template; glossary; ADR repository.

Preparation

Select viewpoint library, for example SEI Software Architecture in Practice. Create template per viewpoint. Define naming convention for views.

Agenda

  1. Section 1: Viewpoint selection (60 min) Owner: Facilitator Action: From the set (Module, Component-and-Connector, Allocation, Deployment, Behavior), select the viewpoints needed for stakeholders and quality attributes. Document audience and purpose per viewpoint. Hint: Not all viewpoints are mandatory. At least Module, Component-and-Connector, Deployment. Add others when needed. Output: Architecture Views

  2. Section 2: Module View (2-3 h) Owner: Facilitator Action: Structural code organization: modules, layers, subsystems. Dependencies between modules. Module responsibility. Hint: Module View shows static structure, not runtime. If discussion turns to runtime behavior, it belongs in C-and-C View. Output: Cross-view Notes

  3. Section 3: Component-and-Connector View (3-4 h) Owner: Facilitator Action: Runtime components and their connectors (REST, Kafka, filesystem). Data flows, protocols, QoS properties. Hint: Most important view for performance and availability scenarios. Bottlenecks become visible here. Output: Rationale

  4. Section 4: Allocation Views (2-3 h) Owner: Facilitator Action: Deployment (mapping to infrastructure, cloud regions, containers), work assignment (mapping to teams), implementation (mapping to repos). Hint: Deployment view is critical for operations and SRE. Work assignment helps in Team Topology discussions. Output: Architecture Views

  5. Section 5: Behavior and Beyond (2-3 h) Owner: Facilitator Action: If needed, Behavior Views (sequence, state, activity) for critical workflows. Beyond section: glossary, architecture drivers, quality attribute scenarios, ADR list, variability, mapping between views. Hint: Cross-View Beyond is the connector. Without it, views remain isolated and contradictory. Output: Cross-view Notes

  6. Section 6: Review and maintenance (ongoing) Owner: Owner Action: Reviews with stakeholder per view. Versioning. Change pipeline: ADR trigger -> update affected views -> re-review. Hint: Architecture documentation without maintenance ages quickly. Define quarterly or release-triggered review cadence. Output: Rationale

  7. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Architecture Views

Closeout

  • Update result artifact: Architecture Views
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Architecture Views: Views and Beyond

Working Question

Which views address which stakeholders with which quality concern, and which cross-view information binds them into a consistent picture?

Context

Stakeholder requirements per group; existing architecture artifacts; quality-attribute scenarios; component list from canvas; language conventions (glossary).

Participants

  • Owner: One architect with Views-and-Beyond experience
  • Participants: One architect with Views-and-Beyond experience; engineering leads per subsystem; one reviewer from operations; stakeholder representative for validation; scribe.

Input

Whiteboard or modeling tool; view templates per view type (Module, Component and Connector, Allocation); Cross-View Beyond template; glossary; ADR repository.

Template

Views and Beyond Working Template

Goal

Capture the relevant architecture views, the viewpoints behind them, and the rationale that connects them.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Working area

  • Stakeholder views:
  • Structural views:
  • Behavioral views:
  • Cross-view concerns:
  • Rationale and trade-offs:

Output artifacts

  • View set:
  • Cross-view notes:
  • Documentation rationale:

Open questions

  • ...

Next step

Owner, date, and success signal.

Completion Check

  • Architecture Views is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Views and Beyond Working Template

View templateCompact working template for Views and Beyond with stakeholder views, cross-view notes, and rationale.
markdown

views-and-beyond-working-template.md

Compact working template for Views and Beyond with stakeholder views, cross-view notes, and rationale.

Views and Beyond Working Template

Goal

Capture the relevant architecture views, the viewpoints behind them, and the rationale that connects them.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Working area

  • Stakeholder views:
  • Structural views:
  • Behavioral views:
  • Cross-view concerns:
  • Rationale and trade-offs:

Output artifacts

  • View set:
  • Cross-view notes:
  • Documentation rationale:

Open questions

  • ...

Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Architecture Views.
  • Architecture documentation versioned in Git or wiki. Change date and author per view. Beyond section links ADRs. Quarterly review entry with reviewers and outcome.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet