Basic Concepts Knowledge-Based Study

Study notes

1. In the TOGAF Standard, 10th Edition, enterprise architecture content is captured and structured through architectural artifacts. To communicate complex architectural information effectively to diverse stakeholders, architects rely on the foundational concepts of Architecture Views and Architecture Viewpoints, which align directly with the ISO/IEC/IEEE 42010 standard.

   Key definitions to master include:

   • Architecture View: A representation of a system from the perspective of a related set of concerns. A view is what the stakeholder actually sees; it is the concrete model, document, or representation illustrating the architecture.
   • Architecture Viewpoint: The specification of the conventions for constructing and using a view to address a specific set of concerns. A viewpoint defines the perspective, notation, modeling techniques, and analytical methods used to produce a view.
   • Stakeholder: An individual, team, or organization with an interest in, or concerns relative to, the outcome of the architecture.
   • Concern: An interest in a system relevant to one or more stakeholders (for example, performance, reliability, security, or regulatory compliance).

   A critical conceptual distinction in enterprise architecture is the difference between an architecture viewpoint and an architecture view. An easy way to understand this relationship is using the analogy of a template versus an instance, or a lens versus the resulting picture:

   • The Viewpoint is the 'Template' or 'Specification': It dictates how to construct a view, defining the intended audience, the concerns addressed, and the modeling languages or rules required. An architecture viewpoint exists before the architecture view is drawn.
   • The View is the 'Instance': It is the actual depiction or artifact generated by applying the viewpoint rules to a specific enterprise context.

   In formal TOGAF terminology: An architecture view is what you see; an architecture viewpoint is the perspective from which you see it.

   To clarify the distinction between viewpoint and view, consider a common non-architectural analogy: a passenger flight status screen at an international airport.

   • Stakeholder: Air travelers departing the airport.
   • Concerns: Departure time, boarding gate, flight status (on time, delayed, boarding), and destination.
   • Architecture Viewpoint (The Schema / Specification): The design specification for the Flight Information Display System (FIDS). This defines that information must be laid out in a tabular grid with columns for 'Flight Number', 'Destination', 'Scheduled Time', 'Gate', and 'Status', updated in real-time, using high-contrast text for legibility.
   • Architecture View (The Concrete Representation): The actual screen mounted in Terminal 2 displaying current flights at 14:30 on a specific Monday afternoon.

   Similarly, an architect might use a Security Viewpoint (guidelines, catalog formats, and threat models addressing compliance concerns) to produce an actual Security View for an enterprise online banking system.

   Test your understanding of Architecture Views and Viewpoints with the following practice question.

   Question:
   An enterprise architect develops a specification document that defines the modeling notation, analytical methods, and stakeholder concerns related to network bandwidth and data latency. Which TOGAF 10th Edition concept does this specification represent?

   • A) An Architecture View
   • B) An Architecture Viewpoint
   • C) A Building Block
   • D) A Requirement Statement

   Correct Answer: B) An Architecture Viewpoint

   Explanation:
   According to the TOGAF Standard, 10th Edition, an Architecture Viewpoint is the specification of the conventions for constructing and using a view, including the modeling notations, metamodel components, and analytical techniques applied to address specific stakeholder concerns. An Architecture View (Option A) is the actual resulting representation or model of the system itself, not the specification defining how to build it. A Building Block (Option C) represents a component of enterprise capability or business/IT design, while a Requirement Statement (Option D) is an expression of need.