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)
| 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
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:
- 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.