What is the difference between a view and a viewpoint in an architecture description (as defined by ISO/IEC/IEEE 42010)?
answer
- Viewpoint = template/convention, reusable across systems
- View = the concrete result for one system
- Viewpoint frames concerns; view answers them
- Correspondence rules = cross-view consistency
- Perspectives = cross-cutting qualities, not views
basics
~20 sA viewpoint is the reusable template: which stakeholders and concerns it serves, what notation and rules to use. A view is the actual result of applying that template to one specific system — the concrete diagram plus its supporting text.
solid answer
~50 sISO/IEC/IEEE 42010 separates the *specification* of how to describe something from the *description itself*. A **viewpoint** is a reusable convention: it names the **stakeholders** it serves, the **concerns** it addresses, the **model kinds** and notations to use, and the rules for building and checking such a description. It is system-independent — you can carry a "deployment viewpoint" from one project to the next. A **view** is what you get when you apply a viewpoint to a particular system: the actual deployment diagram of *this* system, made up of one or more architecture **models**, and it governs nothing beyond that system. The relationship is the same as class-to-instance or template-to-document. The practical value is that concerns drive viewpoint selection: you start from "who needs to know what", pick or define viewpoints that answer those concerns, then produce views. 4+1 and C4 are effectively pre-packaged viewpoint sets.
go deeper
State the template-vs-instance distinction plainly and give one concrete pair (deployment viewpoint / this system's deployment view).
Add the surrounding vocabulary — stakeholder, concern, model, architecture description — and note that 4+1 and C4 are pre-packaged viewpoint sets.
Discuss deriving views from stakeholder concerns, correspondence rules for consistency, and perspectives as orthogonal quality lenses.
Talk about curating an organisation-wide viewpoint catalogue with agreed notation and review checklists, coverage checks (every concern framed by some viewpoint), tying decisions/rationale to views, and the governance cost of maintaining it.
## The standard and its purpose ISO/IEC/IEEE 42010 ("Systems and software engineering — Architecture description", the successor to IEEE 1471) does not tell you how to design architecture. It standardises **how you describe** one, by fixing a small conceptual vocabulary. Knowing this vocabulary is what lets you talk precisely about documentation instead of arguing about diagram tools. ## The vocabulary, in dependency order 1. **System** — the thing of interest. 2. **Stakeholder** — an individual, team or organisation with an interest in the system: users, developers, operators, testers, security officers, auditors, funders, regulators. 3. **Concern** — an interest of one or more stakeholders relevant to the system: "how do we recover from a data-centre outage?", "where do I add a new report?", "is personal data encrypted at rest?", "what will this cost to run?". Concerns include both functional questions and quality attributes (performance, security, modifiability, cost). 4. **Architecture description (AD)** — the whole artefact set that documents the architecture. 5. **Architecture viewpoint** — a *convention* for constructing, interpreting and using a certain kind of description. It specifies: the stakeholders addressed, the concerns framed, the **model kinds** used, notations/languages, and any construction, analysis or consistency rules. It is defined once and **reused across systems**. 6. **Architecture view** — the *expression* of the architecture of a **particular** system from the perspective of one viewpoint. A view *governed by* a viewpoint; a view consists of one or more architecture models. 7. **Architecture model** — the individual artefact inside a view: one diagram, one table, one formal model. 8. **Correspondence / correspondence rule** — an explicit relation between elements across views (or between a view and something else), and the rules that must hold. This is the mechanism for consistency: e.g. "every component in the component view must be allocated to exactly one container in the deployment view". 9. **Architecture decision & rationale** — 42010's later editions make the *why* first-class, which is where Architecture Decision Records (ADRs) fit. ## The key distinction, stated three ways - **Template vs document.** A viewpoint is the blank form; a view is the filled-in form. - **Class vs instance.** "Deployment viewpoint" is the class; "the deployment view of the Payments platform, v3" is an instance. - **Rules vs result.** The viewpoint says what must appear and how to check it; the view is the thing that must satisfy those rules. A memorable phrasing from the viewpoints literature: *a viewpoint is where you look from; a view is what you see.* ## Why anyone should care ### 1. It makes documentation demand-driven The standard's flow is: identify stakeholders → elicit their concerns → select viewpoints that frame those concerns → produce views. That inverts the common anti-pattern of "we should draw the standard five diagrams" and then discovering nobody reads three of them. Conversely, 42010 requires every identified concern to be framed by at least one viewpoint — so a concern with no view is a documented gap, not an accident. ### 2. It makes reuse possible Because viewpoints are system-independent, an organisation can maintain a small catalogue ("our security viewpoint", "our data viewpoint", "our deployment viewpoint") with agreed notation and checklists, and every project's views become mutually comparable and reviewable. ### 3. It makes consistency checkable Correspondence rules turn "do these diagrams agree?" from a vibe into a verifiable property, and they are what diagrams-as-code tooling can automate. ## How the popular models map onto this - **Kruchten's 4+1** is, in 42010 terms, a *viewpoint set*: logical, process, development and physical viewpoints, plus scenarios acting as the cross-view consistency mechanism. What a project draws for its own system are views. - **The C4 model** is another viewpoint set (context, container, component, code, plus deployment/dynamic/landscape) with an unusually strict abstraction hierarchy and self-description rules. - **Rozanski & Woods** publish an explicit viewpoint catalogue (functional, information, concurrency, development, deployment, operational) and add a second, orthogonal concept: **perspectives** — cross-cutting quality concerns such as security, performance and scalability, availability, evolution, which you apply *across* several views rather than as a view of their own. - **arc42** is a document template whose sections largely correspond to views plus decisions and quality scenarios. ## Edge cases and confusions - **"Perspective" vs "viewpoint".** In Rozanski & Woods, a perspective is not a viewpoint: security is not usefully drawn as a single diagram, it is a lens applied to the deployment, functional and information views. Calling security a "view" and drawing one box-and-arrow picture is a classic mistake. - **A view is not one diagram.** A view may contain several models — a diagram, a table of node sizing, and explanatory prose — all governed by the same viewpoint. - **Views are not layers or tiers.** "Presentation/business/data" is a structural pattern that appears *inside* a view; it is not a set of views. - **A viewpoint frames concerns; it does not answer them.** Answers live in the view. - **You may define your own viewpoints.** 42010 allows ad-hoc viewpoints as long as you state their stakeholders, concerns, model kinds and rules — that is the escape hatch for domain-specific needs (a safety-case viewpoint, a data-residency viewpoint).
- Give an example of a viewpoint and a corresponding view.Viewpoint: 'deployment viewpoint — for operations and infrastructure stakeholders, addressing runtime topology, capacity, failover; expressed as node diagrams plus a sizing table; rule: every runnable unit must be allocated to at least one node.' View: the actual production deployment diagram and sizing table for the Payments platform as of release 3.2.
- How is a 'perspective' in Rozanski & Woods different from a viewpoint?A perspective is a cross-cutting quality concern — security, performance and scalability, availability and resilience, evolution — applied across multiple existing views, with its own checklist and tactics. A viewpoint produces a view; a perspective inspects and modifies several views.
- How does 42010 handle consistency between views?Through explicit correspondences and correspondence rules: named relations between elements in different views plus the constraints that must hold. Violations are recorded as known inconsistencies rather than silently tolerated.
A viewpoint is the blank tax form plus its instruction booklet — designed once, used by millions. A view is your completed return for this year: the same structure, but specific to one filer and only meaningful for them.
saying these in an interview costs you the question
- Using 'view' and 'viewpoint' interchangeably
- Thinking 42010 prescribes a fixed set of views (it prescribes the meta-model, not the diagrams)
- Assuming a view is exactly one diagram
- Treating security as a view rather than a cross-cutting perspective applied across views
- Selecting diagrams first and looking for stakeholders afterwards, instead of deriving views from concerns
- Believing you cannot define your own viewpoints