Architecture Views vs. Viewpoints

Hello! Last time, you distinguished the TOGAF Standard’s Fundamental Content from its Series Guides. We now move from the structure of the standard to something an architect produces and uses: descriptions that help people understand an architecture.

Different people need different answers from the same architecture. A service manager may want to know how work passes between teams; a technology operator may need to know which systems a service depends on. In this lesson, you will learn why the architecture viewpoint sets up a way to address such concerns, while the architecture view is the resulting representation of a particular architecture. This distinction is useful for Foundation terminology now and for choosing suitable views in later Practitioner scenarios.

Start with the stakeholder’s concern

A stakeholder is a person, group, or organization with an interest in the system being described. A concern is an area that matters to them, such as service reliability, the handling of customer requests, or the cost of a proposed change. A concern is not necessarily a precise requirement. “Will this service remain available?” is a concern; a specified availability target would be a more precise requirement arising from it.

An architecture can have many components and relationships, but showing all of them at once rarely helps someone make a decision. Instead, an architect selects and represents information relevant to a set of concerns. That representation is an architecture view. The conventions for selecting, constructing, and interpreting such a representation form an architecture viewpoint.

The Open Group’s archived Developing Architecture Views explains this distinction directly. It comes from an earlier TOGAF edition, so use it here for the underlying concepts of views and viewpoints—not as a guide to the structure of the 10th Edition.

Notice that the worked example does not define a viewpoint merely by naming its audience. It specifies what question the view should address and how information should be expressed. Those choices make the resulting representation interpretable.

Viewpoint: the specification for looking

A viewpoint defines a perspective from which to describe an architecture. More concretely, it specifies matters such as the intended stakeholders and concerns, the information to include, and the conventions or modeling techniques for presenting and interpreting it. Think of it as a reusable specification for a kind of view, rather than a picture of one organization’s systems.

Suppose an architect defines a service-request workflow viewpoint. Its purpose is to help service managers understand where requests wait and which roles handle them. It calls for a representation of request stages, responsible roles, and handoffs, using the same conventions for each workflow shown. At this point, no particular organization’s request stages or roles have been filled in. The architect has defined how to construct and read a workflow view.

The phrase “where you look from” is a useful memory aid, but it can be too vague on its own. A viewpoint is not simply a stakeholder’s personal opinion, nor is it identical to a job title. Two service managers can use a view built from the same viewpoint; one manager might also need views built from several viewpoints. What makes the viewpoint valuable is that it connects concerns to a disciplined way of representing architecture information.

The image’s template comparison captures a practical difference: a viewpoint can be kept for reuse, while a view contains information about the particular architecture under discussion.

View: the representation made for this architecture

Now imagine applying the workflow viewpoint to a proposed cross-branch borrowing service. The resulting view might show that a request is recorded, checked for an available item, assigned to a branch, and passed to a delivery team. It would identify the actual roles and handoffs in that proposed service. A manager could examine it to find a possible delay or an unclear responsibility.

This is a view, not a viewpoint, because the specification has been populated with architecture-specific information. If the architect later describes a different service using the same workflow conventions, that second service will have a different view made from the same viewpoint.

A view need not be a single diagram. It may draw on selected parts of one or more models and present them in a form that addresses stakeholder concerns. “What you see” means what the architecture description shows you, not necessarily something you see in a picture. Equally, a view need not show every detail of the system. Its value lies in making the relevant relationships understandable for its intended purpose.

Consider another concern about the same borrowing service: an operator wants to know what depends on the request-recording application so that a failure can be assessed. A workflow view may mention that application but say little about its technical dependencies. The architect could use a different viewpoint—one specifying how to show applications and their dependencies—to create a second view of the same architecture. The two views need not contain identical information; each makes different concerns examinable.

For a brief spoken reinforcement, watch the definitions and reuse comparison in Pass TOGAF 10 in 4 weeks - Architecture View and Viewpoints by EdTechSociety-AllLearners. Use The Open Group’s reading above for the more precise account of what a viewpoint specifies.

A reliable way to tell them apart

When the terms appear in a description, ask whether you are looking at instructions for a type of representation or a representation of an actual architecture.

The relationship is not that a viewpoint is “the business side” and a view is “the technology side.” A viewpoint can be defined for business, data, application, or technology concerns; a view can be created using it in any of those areas. Nor does a viewpoint become a view merely because it has been written down. It becomes useful when an architect uses it to create and interpret architecture-specific views.

For Foundation study, retain the compact distinction: a viewpoint governs how a view is made; a view shows an architecture in relation to stakeholder concerns. The practical test is reuse. You can apply suitable viewpoint conventions to another architecture, but you cannot simply carry over a view containing this service’s roles and dependencies as though it described that other architecture.

Key takeaways

An architecture viewpoint specifies a perspective, relevant concerns, and conventions for constructing and interpreting views. An architecture view is a representation of a particular architecture made using a viewpoint to address stakeholder concerns. Viewpoints can be reused; views are specific to the architecture they describe.

This completes the module’s introduction to enterprise architecture and the TOGAF landscape. Next, you will examine how architecture work is organized into deliverables, artifacts, and building blocks—including where representations such as views fit into the content an architect produces.