Developing Architecture Views in the ADM Knowledge-Based Study

Study notes

1. Understanding Views and Viewpoints

   In the TOGAF Standard, communicating architectural information requires a clear separation between the concerns of stakeholders and the representations developed to address them.

   • 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 or architecture relevant to one or more stakeholders (e.g., performance, security, cost, manageability).
   • Architecture Viewpoint: A specification of the conventions for constructing and using an architecture view to address a specific concern or set of concerns. A viewpoint acts as the template, model, or pattern from which a view is generated.
   • Architecture View: A representation of a system from the perspective of a related set of concerns. It is what a stakeholder actually examines.

   An essential conceptual distinction is that architects develop architecture views by applying specific architecture viewpoints tailored to stakeholder concerns.

   General Guidelines

   When developing architecture views across the Architecture Development Method (ADM) phases, architects should observe several fundamental guidelines to ensure clarity and utility:

   • Stakeholder-Centric Framing: Views must be created specifically to address verified stakeholder concerns rather than presenting raw, untailored architectural data.
   • Comprehensibility: A view should be readily understandable by its target audience. Technical jargon and notation must align with the stakeholder's domain and technical fluency.
   • Completeness vs. Clarity: A view should encompass enough detail to address the intended concern without becoming overloaded. Complex architectures should be decomposed across multiple complementary views.
   • Traceability and Consistency: Elements depicted in one view must remain consistent with corresponding representations across other views. The underlying architecture repository ensures synchronization among differing perspectives.

   Steps in Creating Architecture Views

   The process of creating architecture views within the ADM follows a systematic workflow:

   1. Identify Stakeholders and Concerns: Determine who the key decision-makers and impacted parties are, cataloging their specific requirements and critical concerns.
   2. Select Relevant Viewpoints: Identify existing viewpoints from reference models, standards, or the Architecture Repository that adequately frame the recorded concerns. If none exist, define and tailor a new viewpoint.
   3. Instantiate the View: Apply the chosen viewpoint to the architecture data to generate the specific view. This involves selecting relevant artifacts (such as catalogs, matrices, or diagrams) that represent the target state or transition state.
   4. Review and Verify: Validate the completed view with the respective stakeholders to confirm that their concerns are accurately addressed, and refine the view based on feedback.

   Knowledge Check

   Consider the following scenario and question to test your understanding of architecture view creation:

   Question: An enterprise architect needs to present infrastructure consolidation options to non-technical business executives who are concerned primarily with capital expenditure and operational downtime. Which action strictly aligns with the TOGAF guidelines for developing architecture views?

   • A. Present comprehensive deployment network topology diagrams to ensure total technical accuracy.
   • B. Select or create an executive viewpoint focused on financial impact and business continuity, filtering out operational networking syntax.
   • C. Substitute standard viewpoints with raw data spreadsheets to avoid abstract modeling conventions.
   • D. Develop a single comprehensive view intended to satisfy both network engineers and financial officers simultaneously.

   Correct Answer: B

   Explanation: Viewpoints and their resulting views must be selected and tailored to specific stakeholder concerns and communication needs. Non-technical executives require views that clearly address capital expenditure and business continuity rather than dense technical or network models. Combining unrelated audiences into a single view (Option D) or presenting overly technical schemas (Option A) violates the guideline of audience-specific comprehensibility.