This chapter will help you understand the concepts of views and viewpoints, and their role in communic ating with stakeholders.
Key Points Explained
This chapter will help you to answer the following questions:
• What are the key concepts for views and viewpoints in the TOGAF standard?
• How can a simple example of a viewpoint and view be described?
• What are the relationships between stakeholders, concerns, views, and viewpoints?
• How are views created?
(Syllabus Reference: Unit 9, Learning Outcome 1: You should be able to define and explain the following concepts: stakeholders, concerns, views and viewpoints.)
In this section we introduce the following concepts and definitions:
• System
• Stakeholders
• Concerns
• Views
• Viewpoints
These have been adapted from more formal definitions in ISO/IEC 42010:2007. Many people use these terms in different ways. Here we need to understand them within the context of TOGAF 9.
A system is a collection of components organized to accomplish a specific function or set of functions.
“The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest.”
[Source: ISO/IEC 42010:2007, previously known as IEEE Std 1471-2000]
Stakeholders are people who have key roles in, or concerns about, the system; for example, users, developers, etc. Stakeholders can be individuals, teams, organizations, etc.
A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to, that system. Figure 22 shows a typical set of stakeholders for an enterprise architecture, with defined categories of stakeholder type.
Figure 22: A Typical Set of Stakeholders for an Enterprise Architecture
Concerns are key interests that are crucially important to stakeholders, and determine the acceptability of the system.
They may include performance, reliability, security, distribution, evolvability, etc. A Security Architect could have the following concerns: authentication, authorization, audit, assurance, availability, asset protection, administration, risk management.
The terms “concern” and “requirement” are not synonymous. A concern is an area of interest.
Concerns are the root of the process of decomposition into requirements.
Concerns are represented in the architecture by these requirements. Requirements should be SMART (i.e., should include specific metrics).
[Source: TOGAF 9 Part VI: Architecture Content Framework, Chapter 35 (Architectural Artifacts)]
A view is a representation of a system from the perspective of a related set of concerns. A view is what you see (or what a stakeholder sees).
An architect creates architecture models. A view consists of parts of these, chosen to show stakeholders that their concerns are being met. For example, just as a building architect will create wiring diagrams, floor plans, and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials), so an Enterprise Architect must create different views of the business, information system, and technical architecture for the stakeholders who have concerns related to these aspects. These might include business process, physical layout, and security views of an IT system.
Figure 23: Typical Views from Building Architecture
A viewpoint defines the perspective from which a view is taken.
It defines how to construct and use a view, the information needed, the modeling techniques for expressing and analyzing it, and a rationale for these choices (e.g., by describing the purpose and intended audience of the view).
The relationship between viewpoint and view is analogous to that of a template and an instance of the completed template. In constructing an enterprise architecture, an architect first selects the viewpoints (templates), then constructs a set of corresponding views (instances).
(Syllabus Reference: Unit 9, Learning Outcome 2: You should be able to describe a simple example of a viewpoint and view.)
The architect uses views and viewpoints in the ADM cycle during Phases A through D for developing architectures for each domain (Business, Data, Application, and Technology).
Views and Viewpoints
A “view” is what you see. A “viewpoint” is where you are looking from; the vantage point or perspective that determines what you see (a viewpoint can also be thought of as a schema).
Viewpoints are generic, and can be stored in libraries for re-use.
A view is always specific to the architecture for which it is created.
Every view has an associated viewpoint that describes it, at least implicitly.
To illustrate the concepts of views and viewpoints, consider Example 3. This is a very simple airport system with two different stakeholders: the pilot and the air traffic controller.
Example 3: Views and Viewpoints for a Simple Airport System
To summarize from Example 3, we can see that a view can subset the system through the perspective of the stakeholder, such as the pilot versus the controller. This subset can be described by an abstract model called a viewpoint, such as an air flight versus an air space model. This description of the view is documented in a partially specialized language, such as “pilot-speak” versus “controller-speak”. Tools are used to assist the stakeholders, and they interface with each other in terms of the language derived from the viewpoint. When stakeholders use common tools, such as the radio contact between pilot and controller, a common language is essential.
For many architectures, a useful viewpoint is that of business domains, which can be illustrated by an example from The Open Group.
The viewpoint can be specified as follows:
The corresponding view of The Open Group (in 2008) is shown in Figure 24.
Figure 24: Example View – The Open Group Business Domains
(Syllabus Reference: Unit 9, Learning Outcome 3: You should be able to discuss the relationship between stakeholders, concerns, views, and viewpoints.)
The relationship between stakeholders, concerns, views, and viewpoints are summarized in Figure 25.12
Figure 25: Relationship between Basic Architectural Concepts
(Syllabus Reference: Unit 9, Learning Outcome 4: You should be able to describe the view creation process.)
Architecture views are representations of the overall architecture in terms meaningful to stakeholders. They enable the architecture to be communicated to and understood by the stakeholders, so they can verify that the system will address their concerns.
[Source: TOGAF 9 Part IV: Architecture Content Framework, Chapter 35 (Architectural Artifacts)]
The architect chooses and develops a set of views in the ADM cycle during Phases A through D that enable the architecture to be communicated to, and understood by, all the stakeholders, and enable them to verify that the system will address their concerns.
The choice of which particular architecture views to develop is one of the key decisions that the architect has to make.
The architect has a responsibility for ensuring:
• The completeness of the architecture:
— Does it address all the concerns of its stakeholders?
• The integrity of the architecture:
— Can the views be connected to each other?
— Can the conflicting concerns be reconciled?
— What trade-offs have been made (e.g., between security and performance)?
Recommended Steps
The following are the recommended steps to create the required views for a particular architecture:
1. Refer to any existing libraries of viewpoints (note that TOGAF 9 includes a set of architecture viewpoints).
2. Select key stakeholders.
3. Analyze their concerns and document them.
4. Select appropriate viewpoints (based on the stakeholders and their concerns).
5. Generate views of the system using the selected viewpoints as templates.
The TOGAF standard embraces the concepts and definitions of ISO/IEC 42010:2007, specifically those that guide the development of a view, and make the view actionable, such as:
• Selecting key stakeholders
• Analyzing their concerns and documenting them
• Understanding how to model and deal with those concerns
The language used to depict the view is the viewpoint. The viewpoints provided should be customized to create a set of architecture views that ensure all stakeholder concerns are met.
Q1: Which of the following terms does the TOGAF standard use to describe people who have key roles in, or concerns about, a system?
A. Architect
B. Consumer
C. Customer
D. Sponsor
E. Stakeholder
Q2: Which of the following statements is not correct?
A. A view can be thought of as a template for a viewpoint.
B. A viewpoint defines the perspective from which a view is taken.
C. A viewpoint defines how to construct and use a view.
D. A view is what a stakeholder sees.
E. A view might describe business process for an IT system.
Q3: Which of the following statements is not correct?
A. A concern might include performance and reliability.
B. A concern is an area of interest.
C. Concerns are key interests of the stakeholders.
D. Concern and requirement are synonymous.
Q4: In Example 3, Views and Viewpoints for a Simple Airport System, which of the following is the common tool used by pilots and controllers?
A. Altitude
B. Fuel
C. Location
D. Radar
E. Radio
Q5: Which of the following statements describing relationships between stakeholders, concerns, views, and viewpoints is correct?
A. A concern is important to only one stakeholder.
B. A stakeholder identifies one or more concerns.
C. A viewpoint covers one concern.
D. A viewpoint consists of one or more views.
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part IV: Architecture Content Framework, Chapter 35 (Architectural Artifacts)
_______________________
12 Reprinted with permission from IEEE Std 1471-2000, Systems and Software Engineering – Recommended Practice for Architectural Description of Software-Intensive Systems, Copyright © 2000, by the IEEE.
