Architecture work is only useful if each stakeholder can see that their interests have been dealt with. Views are how the architect shows this, presenting information in a form each stakeholder understands.
The ISO/IEC/IEEE 42010 concepts
The TOGAF Standard bases its treatment of views on ISO/IEC/IEEE 42010:2022, with supporting terms from ISO/IEC/IEEE 15288:2015.
| Concept | Meaning |
|---|---|
| System | A combination of interacting elements organised to achieve one or more stated purposes |
| Environment | The context of every influence on a system: developmental, technological, business, operational, organisational, political, economic, legal, regulatory, ecological and social |
| Architecture (of a system) | The fundamental concepts or properties of a system in its environment, embodied in its elements, relationships and the principles governing its design and evolution |
| Architecture Description | A work product that expresses an architecture; in practice, a collection of views and models |
| Stakeholder | An individual, team or organisation, or a class of them, that has an interest in the system |
| Concern | An interest in the system that matters to one or more stakeholders, such as performance, reliability, security, distribution or evolvability; concerns may decide whether the system is acceptable |
| Model | A representation of a subject of interest, usually smaller in scale, simplified or abstract |
| View | A representation of the system from the perspective of a related set of concerns; it consists of one or more models |
| Viewpoint | A specification of the conventions for a particular kind of view: its definition or schema, setting out how to construct, interpret and use the view to address concerns |
| Model kind | The conventions for one type of modelling; a viewpoint references one or more model kinds |
| Viewpoint library | A collection of viewpoint specifications, held in the Reference Library |
How the concepts fit together
The chain runs from people to pictures:
- a stakeholder has concerns;
- a viewpoint frames a set of concerns and sets the conventions for addressing them;
- a view follows the conventions of its viewpoint and shows how those concerns are addressed;
- the view is built from selected parts of one or more models, chosen to demonstrate to the stakeholder that their concerns are covered.
Concerns often lead to requirements. A concern about availability, for example, might give rise to several specific requirements. Identifying concerns makes sure stakeholder interests are addressed and requirements are found, and linking concerns to particular artifact types helps the architect choose which artifacts to produce.
View versus viewpoint
| Viewpoint | View | |
|---|---|---|
| Plain-language idea | Where you are looking from (the vantage point) | What you see |
| Nature | Generic: a template or schema | Specific to the architecture it describes: an instance |
| Re-use | Stored in viewpoint libraries and re-used across architectures | Created for one architecture |
| Relationship to models | References one or more model kinds | Incorporates one or more models |
Every view has an associated viewpoint, even if only implicitly; ISO 42010 encourages making viewpoints explicit. A simple example is a business domains viewpoint, aimed at stakeholders such as the Management Board and the CEO.
The Practitioners’ Approach (G186) adds a practical point: stakeholders approve views, not architecture descriptions. The view is the thing a stakeholder actually reviews and agrees to. How a viewpoint library can drive an enterprise’s metamodel is covered in Chapter 3, The Enterprise Continuum and the Architecture Repository. Figure 14.1 traces the chain from the stakeholder’s concerns to the view they approve.
Common trap: A viewpoint is a picture of the architecture prepared for a stakeholder - that is a view; the viewpoint is the generic specification (the template) that the view conforms to.