Stakeholders, Concerns, and Perspectives

## Why this vocabulary exists Before ISO/IEC 42010 (which grew out of IEEE 1471-2000), teams argued endlessly about "how many diagrams should an architecture document have?" The standard reframes the question: you do not produce diagrams because a template demands them, you produce them because an **identified person** has an **identified worry** that the diagram answers. It is a *meta-model* — it does not tell you which views to draw; it tells you how the pieces of any architecture description relate. ## The terms, defined from zero - **System-of-interest** — the thing whose architecture you are describing (a service, a product, an enterprise, even a business process). "Architecture" in the standard is the *fundamental concepts or properties* of that system in its environment, embodied in its elements, relationships, and design principles. - **Architecture description (AD)** — the concrete work product: the documents, diagrams, models, and prose. The architecture is abstract; the AD is the artifact you can review and put in version control. - **Stakeholder** — an individual, team, organization, or class thereof holding an interest in the system. Crucially it is *not* only the paying customer. Typical classes: users, acquirers/sponsors, developers, maintainers, testers, system administrators/operators, support staff, suppliers, assessors (auditors, regulators, security reviewers), and communicators (those who explain the system, e.g. trainers, technical writers). - **Concern** — any interest of a stakeholder pertaining to the system: functional need, quality property (performance, availability, security, modifiability), cost, schedule, staffing, regulatory constraint, technology risk, lifecycle/decommissioning. A concern is a *worry that could be answered or violated*, not merely a topic. - **Architecture viewpoint** — a *reusable specification* for how to build one kind of view. A well-formed viewpoint definition states: the concerns it frames, the typical stakeholders it serves, the **model kinds** it uses (notation/metamodel/conventions, e.g. "a UML component diagram", "an ER diagram", "a deployment table"), the operations and analysis techniques you can perform on those models, and known pitfalls. Viewpoints are library items: you can reuse the "Deployment viewpoint" across many systems and even import viewpoints defined by others. - **Architecture view** — the result of applying exactly one viewpoint to one system-of-interest. It is *system-specific*. A view is composed of one or more **architecture models** (the individual diagrams/tables), and a single model may in fact be shared by more than one view. - **Correspondence / correspondence rule** — a recorded relationship between elements across models/views (e.g. "every component in the functional view maps to at least one node in the deployment view") and the rule that constrains it. This is how multi-view descriptions stay consistent. - **Architecture decision and rationale** — the standard also lets you record decisions, the alternatives considered, and why one was chosen, and to trace decisions back to the concerns that motivated them. ## The governing rules (what "conformance" means) An AD conforming to ISO/IEC 42010 must: 1. Identify the system-of-interest and the AD's own identifying information. 2. Identify the **stakeholders** it addresses. 3. Identify their **concerns** (the standard calls out a minimum set that must at least be considered: system purpose, suitability for purpose, feasibility of construction/deployment, potential risks and impacts to stakeholders, and maintainability/evolvability). 4. Identify the **viewpoints** used, and for each, which concerns it frames and which stakeholders it addresses. 5. Contain exactly **one view per viewpoint** used. 6. Record correspondences and any known inconsistencies. 7. Record rationale for the architecture decisions made. The closure rule is the useful part in practice: **every concern must be framed by at least one viewpoint, and every viewpoint must frame at least one concern.** That gives you a two-way test. A concern nobody's view addresses is an *undocumented risk*. A view that frames no live concern is *waste* — delete it. ## Viewpoint vs view: the distinction people get wrong The viewpoint exists **before** and **independently of** your system; the view exists **only for** your system. "The Deployment viewpoint" is a genre; "the deployment view of the payments platform" is one instance of that genre. Saying "we need a deployment viewpoint for our system" is a category error — you need a deployment *view*, produced by applying the deployment *viewpoint*. ## How this relates to other well-known view sets - **Kruchten's 4+1** (logical, process, development, physical, + scenarios) is one *fixed set of viewpoints*, predating the standard, and can be expressed as a viewpoint library. - **SEI Views and Beyond** groups view types into module, component-and-connector, and allocation "viewtypes", with styles inside each — again a viewpoint library plus documentation rules. - **Rozanski & Woods** define seven viewpoints (Context, Functional, Information, Concurrency, Development, Deployment, Operational) plus cross-cutting *perspectives* for quality properties. All three are compatible with 42010; the standard is deliberately view-set agnostic. ## Trade-offs and edge cases - **Cost of documentation.** Each view costs effort to write and — worse — to keep current. The stakeholder→concern→viewpoint chain is precisely the tool for justifying *minimum yet sufficient* documentation. - **Stakeholders who cannot attend.** Regulators, future maintainers, and end users often are not in the room. Someone must proxy them, and the AD should say who. - **Quality properties cut across views.** Security or performance are not one view; they surface in several. That is exactly why Rozanski & Woods add *perspectives*, and why the 2022 revision of the standard introduces the analogous notion of *architecture aspects*. - **Consistency debt.** Multiple views drift. Correspondence rules plus recording *known* inconsistencies (rather than pretending there are none) is the standard's honest answer. - **Concerns change.** Concerns are elicited at a point in time; re-elicit at major milestones or the AD ossifies into a view set nobody reads.