What needs to be finished first
Stakeholders and their architecture requirements are identified so views can be tailored to concrete consumers.
Top quality attributes with scenarios exist so views prioritize the right aspects (module, component, allocation, behavior).
What needs to be ready before start
Whiteboard or modeling tool; view templates per view type (Module, Component and Connector, Allocation); Cross-View Beyond template; glossary; ADR repository.
One architect with Views-and-Beyond experience; engineering leads per subsystem; one reviewer from operations; stakeholder representative for validation; scribe.
Stakeholder requirements per group; existing architecture artifacts; quality-attribute scenarios; component list from canvas; language conventions (glossary).
2-3 days initial, then maintained living document
Select viewpoint library, for example SEI Software Architecture in Practice. Create template per viewpoint. Define naming convention for views.
The one question this method answers
Which views address which stakeholders with which quality concern, and which cross-view information binds them into a consistent picture?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 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. | Not all viewpoints are mandatory. At least Module, Component-and-Connector, Deployment. Add others when needed. |
2Section 2: Module View | 2-3 h | Structural code organization: modules, layers, subsystems. Dependencies between modules. Module responsibility. | Module View shows static structure, not runtime. If discussion turns to runtime behavior, it belongs in C-and-C View. |
3Section 3: Component-and-Connector View | 3-4 h | Runtime components and their connectors (REST, Kafka, filesystem). Data flows, protocols, QoS properties. | Most important view for performance and availability scenarios. Bottlenecks become visible here. |
4Section 4: Allocation Views | 2-3 h | Deployment (mapping to infrastructure, cloud regions, containers), work assignment (mapping to teams), implementation (mapping to repos). | Deployment view is critical for operations and SRE. Work assignment helps in Team Topology discussions. |
5Section 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. | Cross-View Beyond is the connector. Without it, views remain isolated and contradictory. |
6Section 6: Review and maintenance | ongoing | Reviews with stakeholder per view. Versioning. Change pipeline: ADR trigger -> update affected views -> re-review. | Architecture documentation without maintenance ages quickly. Define quarterly or release-triggered review cadence. |
What comes out at the end
Architecture documentation with multiple views (Module, Component-and-Connector, Allocation, optionally Behavior), Cross-View Beyond section with glossary, drivers, quality-attribute scenarios, ADR references, and view mappings. Diagram plus supporting text per view.
Architecture documentation versioned in Git or wiki. Change date and author per view. Beyond section links ADRs. Quarterly review entry with reviewers and outcome.
Compact working template for Views and Beyond with stakeholder views, cross-view notes, and rationale.
Capture the relevant architecture views, the viewpoints behind them, and the rationale that connects them.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Selected viewpoints
Module View (excerpt)
Layer Domain Model -> Layer Application Service -> Layer Adapters. Subsystem booking-core contains modules Booking, Inventory, Pricing. Dependencies point from Adapters to Domain.
C-and-C View (excerpt)
booking-api (Spring Boot) with REST connectors (HTTPS, JSON) to partner clients and gRPC to internal-graphql.notification-worker consumes Kafka topic bookings.events.availability-cache (Redis) with TTL 60 s.Beyond section
booking-api from C-and-C View corresponds to module booking-core from Module View and service booking-api-task from Deployment View.Recognize symptoms and steer against them
Documentation contains only component diagrams; deployment and module views are missing.
At least three view types are required. Address stakeholder-specific needs. Without deployment view for operations, documentation is incomplete.
Module View shows different subsystems than C-and-C View and nobody notices.
Cross-view mapping in Beyond section. Reference all views in which each element appears.
Diagrams no longer match reality, new components are missing.
Review cadence is mandatory. Re-review at every major release. Diagrams as code ease updates.
Views exist in isolation, rationale and reference are missing.
Beyond section is mandatory: glossary, drivers, ADR links, view mappings.
Views contain every method and table; nobody reads them.
Architecture documentation is big picture, not code mirror. Keep strategic level in views.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.