What are the three view types in the SEI "Views and Beyond" approach, and what does "beyond views" refer to?
answer
- Module / C&C / Allocation
- Style → view → view packet
- Modules ≠ components, not 1:1
- Beyond = roadmap, mappings, rationale, glossary
- Choose views by stakeholder need, then combine
basics
~20 sViews and Beyond groups architecture views into three types: module (units of implementation), component-and-connector (runtime elements and their interactions), and allocation (mapping software to environments — deployment, install, work assignment). "Beyond views" is the cross-view information: how views relate, rationale, and a documentation roadmap.
solid answer
~60 s"Documenting Software Architectures: Views and Beyond" (Clements et al., SEI) says an architecture is documented as a set of views plus information that applies across them. Views fall into three **view types**: **module** views (units of implementation — decomposition, uses, layered, class/generalisation styles; answers "how is the code organised, who depends on whom"), **component-and-connector (C&C)** views (runtime elements with runtime behaviour and their pathways — client-server, pipe-and-filter, publish-subscribe, shared-data styles; answers "what runs, what talks to what, where are the bottlenecks"), and **allocation** views (mapping software to non-software structures — deployment onto hardware, implementation onto the file system, work assignment onto teams). Within a type you pick a **style**; applying a style to your system yields a view; a **view packet** is the smallest usefully consumable chunk of a view. "Beyond views" is everything cross-cutting: how views map to each other, system-wide rationale, constraints, glossary, and the **documentation roadmap** telling readers which parts to read for which purpose. The choice of views is driven by stakeholder needs, not completeness.
go deeper
Name the three view types and give one example each: module = code packages and dependencies, C&C = running services talking to each other, allocation = what runs on which machine.
Add that a style applied to your system gives a view, that modules and runtime components do not map one-to-one, and that "beyond" covers rationale, mappings and the glossary.
Discuss style choices per view type, view packets, the stakeholder-driven select/combine/prioritise procedure, and the documentation roadmap as the highest-leverage cross-view artefact.
Judge when the full rigour pays (contractual, safety-critical, multi-vendor, decade-long systems) versus a generated three-view minimum, and map the vocabulary onto arc42/C4/42010 so an organisation has one consistent language.
## Where the approach comes from **Views and Beyond (V&B)** is the documentation approach from the Carnegie Mellon Software Engineering Institute, published as *Documenting Software Architectures: Views and Beyond* (Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford). Its founding premise: **no single diagram can show a software architecture**, because the structures that matter — code organisation, runtime interaction, and physical/organisational allocation — are genuinely different structures with different elements and different relations. So an architecture description is a *set of views*, chosen deliberately, plus the information that ties them together. ## Vocabulary, defined - **Structure**: a set of elements plus the relations among them, existing in the system. - **View**: a representation of one (or a coherent group) of those structures, written for readers. - **Style** (also called an *architectural style* or, in later work, a *pattern*): a named, reusable specialisation of a view type — e.g. layered, pipe-and-filter, publish-subscribe. In ISO/IEC/IEEE 42010 vocabulary a style plays the role of a **viewpoint**. - **View packet**: the smallest bundle of a view that is useful to a stakeholder on its own — for example the decomposition of *one* subsystem with its context, element catalogue, and rationale. V&B's answer to "this view is 40 pages" is: deliver it in packets. - **Element catalogue**: for each view, the list of elements with their responsibilities, interfaces, and behaviour — the text that stops a diagram from being decorative. ## The three view types ### 1. Module views — units of *implementation* Elements are modules (code units: packages, layers, classes, modules). Relations are things like *is-part-of*, *depends-on*, *is-a*. Styles: **decomposition** (module containment), **uses** (which module needs which to be correct — the basis of incremental build subsets), **layered** (allowed-to-use restricted by layer), **class/generalisation** (inheritance). Answers: What are the units of code? Who is allowed to depend on whom? What is the impact of changing X? How do we assign code ownership? Module views are the primary tool for reasoning about **modifiability**. ### 2. Component-and-connector (C&C) views — units of *runtime* Elements are **components** (runtime entities: processes, services, objects, threads, data stores) and **connectors** (runtime pathways: procedure calls, queues, event buses, HTTP channels, shared-data access). Relations are attachments of ports to roles. Styles: **client–server**, **pipe-and-filter**, **publish–subscribe**, **shared-data (repository)**, **peer-to-peer**, **concurrency/communicating-processes**. Answers: What is running at runtime? What talks to what and over what? Where do requests queue? Where are the concurrency hazards, the single points of failure, the latency hot spots? C&C views are the primary tool for reasoning about **performance, availability, and security at runtime**. **Critical point often missed:** modules and components do **not** map one-to-one. One module can be instantiated as many runtime components; one component can be built from many modules. That mismatch is precisely why both view types exist. ### 3. Allocation views — software mapped to *non-software* structures Elements are software elements plus **environmental elements** (hardware nodes, file systems, teams). Relations are *allocated-to*. Styles: **deployment** (software → hardware/nodes/networks), **implementation** (modules → files and directories in the development environment), **work assignment** (modules → teams or organisational units — the documentation form of Conway's Law). Answers: Where does it run? What does the repo layout look like? Who owns what? ## "Beyond views": the cross-view documentation V&B's second half is everything that is *not* inside a single view. Typically: - **Documentation roadmap** — what documentation exists, how it's organised, and **which parts a given reader should read for a given task**. This is the single highest-leverage artefact for a large description, and the one teams most often omit. - **How a view is documented** — the conventions/notation legend, so readers can interpret the diagrams. - **System overview** — a short prose narrative of what the system does. - **Mapping between views** — the correspondences: which modules realise which runtime components, which components deploy to which nodes. Prevents the views from being three unrelated stories. - **Rationale** — why the architecture is the way it is, alternatives rejected. (ADRs are the modern lightweight vehicle.) - **Directory / index / glossary / acronym list**. - **Cross-view constraints and known inconsistencies.** ## The selection principle V&B is explicit that you do **not** produce every view of every type. The method is: 1. Enumerate stakeholders and what each needs to *do* with the documentation. 2. Build a candidate view list; note which stakeholders each serves and at what detail. 3. **Combine** views that serve overlapping audiences (e.g. fold implementation allocation into the module decomposition view). 4. **Prioritise** — produce the highest-value views first, in view packets, and stop when the remaining views serve nobody concrete. The stated rule of thumb: documentation is a product with users; if you cannot name the reader and the decision they will make with a view, do not write it. ## Trade-offs - **Strength**: rigorous, complete vocabulary; the module/C&C distinction alone prevents a huge class of confused diagrams ("is this box a class or a process?"). Excellent for large, long-lived, multi-team or contractual systems. - **Weakness**: the full templates are heavy; the book is ~500 pages and a fully documented system can run to hundreds of pages. Small agile teams typically borrow the *concepts* (three view types, element catalogues, view packets, mapping between views) and deliver them through arc42 or C4 with docs-as-code. - **Comparison**: arc42's sections 5/6/7 correspond closely to module / C&C / allocation, delivered as a much lighter template. C4 mostly occupies the module and container space with a fixed zoom convention. 42010 supplies the meta-vocabulary that all three instantiate.
- Why do module views and component-and-connector views need to be separate — isn't one derivable from the other?Because the mapping is genuinely many-to-many and carries information neither view holds alone. A single module (say an order-processing library) may be instantiated as dozens of runtime worker components; a single runtime service may be assembled from modules owned by three different teams. Module views answer modifiability and ownership questions; C&C views answer performance, concurrency and availability questions. Collapsing them produces diagrams where nobody can tell whether a box is a code unit or a running process — and where you cannot reason about either quality attribute properly. The mapping between them is documented in the "beyond views" cross-view section.
- What is a view packet and why does it matter for large systems?A view packet is the smallest chunk of a view that is useful on its own to some stakeholder — for example the decomposition of one subsystem, with its context diagram, element catalogue, interface descriptions, variability and rationale. Large views are unreadable as monoliths; packaging them means a reader consumes only their subsystem, review can proceed packet by packet, and different packets can sit at different maturity levels. It is the documentation equivalent of pagination driven by consumption boundaries rather than page count.
- How would you apply Views and Beyond thinking without producing hundreds of pages?Keep the concepts, drop the templates. Pick a deliberately small view set driven by named stakeholders and decisions: one module view (generated from the build graph), one C&C view for the critical runtime path, one deployment allocation view (generated from infrastructure-as-code). Keep short element catalogues so diagrams have responsibilities attached. Write the two highest-value "beyond" pieces — a documentation roadmap and the mapping between views — and use an ADR log for rationale. Deliver it as arc42 sections in Markdown in the repo so it is reviewed with the code.
Documenting a building: the module view is the floor plan (rooms and walls, who is next to whom), the component-and-connector view is the plumbing and electrical flow diagram (what actually moves at runtime), the allocation view is the site plan placing the building on a plot and assigning contractors. "Beyond" is the cover sheet telling the inspector which drawings to read for which inspection.
saying these in an interview costs you the question
- Assuming modules map one-to-one to runtime components; the mismatch is the reason both view types exist.
- Calling a deployment diagram a component-and-connector view — deployment is an allocation view.
- Thinking Views and Beyond requires documenting every style of every view type; it explicitly says to select, combine and prioritise by stakeholder need.
- Omitting the documentation roadmap and view-to-view mappings, leaving readers with disconnected diagrams and no entry point.
- Producing diagrams without element catalogues, so no element's responsibility or interface is written down anywhere.
- Treating Views and Beyond as a competitor to arc42 or C4 rather than the fuller vocabulary those lighter approaches instantiate.