TL;DR
In TOGAF practice, architecture work starts from stakeholders and their concerns. Concerns drive requirements. Viewpoints define how to represent architecture for a concern, and views are the actual representations used to communicate with stakeholders.
Why this matters
If you miss this chain, architecture outputs become hard to approve and easy to ignore.
These concepts help you answer:
- who cares
- what they care about
- how to represent architecture so it is understandable and useful
Core concepts (simple)
Stakeholder
An individual, team, organization, or class thereof, having an interest in a system.
| Concept | Simple meaning | Example |
|---|---|---|
| Stakeholder | Person/group with an interest in the system (enterprise or scoped part) | CIO, security lead, product owner, regulator |
| Concern | What a stakeholder cares about | performance, security, reliability, evolvability |
| Viewpoint | Reusable definition/template for constructing a kind of view | ”Security viewpoint”, “Deployment viewpoint” |
| View | The actual architecture representation created for the system using a viewpoint | security diagram, capability matrix, deployment view |
Concern is the key link
Concern
An interest in a system relevant to one or more of its stakeholders.
A concern can be a broad requirement category (for example, availability), or it can lead to specific architecture requirements.
So in practice:
- stakeholder concerns are captured
- concerns become requirements and evaluation criteria
- requirements are traced across ADM outputs
Viewpoint vs view (the most tested distinction)
The distinction is simple but important:
Architecture View
A representation of a system from the perspective of a related set of concerns.
Architecture Viewpoint
A specification of the conventions for a particular kind of architecture view. An architecture viewpoint can also be seen as the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern or set of concerns about a system-of-interest.
- Viewpoint = generic schema/rules for making a view (reusable)
- View = specific representation for one architecture effort (instance)
Every architecture view has an associated viewpoint, at least implicitly.
Relationship map
flowchart LR S["Stakeholders"] --> C["Concerns"] C --> R["Requirements"] C --> VP["Viewpoints<br/>(reusable definitions)"] VP --> V["Views<br/>(project-specific representations)"] V --> U["Stakeholder understanding<br/>and decision-making"]
Typical forms of views
Views are usually expressed through artifacts such as:
- diagrams
- matrices
- catalogs
These are then packaged into deliverables for formal review and approval.
See:
Practical example
Stakeholder: CISO
Concern: unauthorized access to customer data
Viewpoint: security controls viewpoint
View: security architecture diagram + control-responsibility matrix
Result: clear requirements and governance checks for implementation
Exam note
- Stakeholders have concerns; concerns drive requirements.
- Viewpoints define how to construct views.
- Views are architecture representations for specific stakeholder concerns.
- A view conforms to a viewpoint.
- Good architecture communication depends on selecting the right viewpoints/views for the right stakeholders.