TOGAF 9 Combined Part 1 and Part 2 Free Sample Questions

The Integrated Information Infrastructure Model (III-RM) was specifically created within TOGAF to enable architects to design architectures that address Boundaryless Information Flow requirements. This reference model provides a common vocabulary and approach for integrating information systems across organizational boundaries. The Architecture Repository is for storing architectural artifacts, the Enterprise Continuum provides a classification system for architectures, and the TOGAF Technical Reference Model focuses on platform services rather than boundaryless information flow.

The TOGAF Technical Reference Model (TRM) is a fundamental architecture that provides a structure and taxonomy for categorizing the generic platform services upon which more specific architectures and architectural building blocks can be based. It serves as a foundation reference model that organizations can use as a starting point for developing their own technical architecture. It is not an example of a Common Systems Architecture, not focused on application components, and not a data model for specific industries.

Part VII of TOGAF 9, the Architecture Capability Framework, describes the processes, skills, roles, and organizational structures needed to establish and operate an enterprise architecture capability within an organization. This section provides guidance on architecture governance, skills framework, and organizational structures. Part III covers Tools and Support (not guidelines), Part I is Introduction (not Enterprise Continuum), Part VI covers Reference Models (not release management), and Part II is the ADM (not definitions and changes).

Phase G (Implementation Governance) of the ADM ensures that implementation projects conform to the defined architecture through ongoing oversight and compliance checking. This phase provides architectural oversight for implementation projects to ensure they align with the Target Architecture and comply with architectural principles and standards. Phase F focuses on migration planning, Requirements Management handles requirements flow, Phase H focuses on change management, and Phase D develops the Technology Architecture.

The Requirements Management Phase stores requirements and manages their flow into relevant ADM phases throughout the architecture development process. This phase acts as a central hub that captures, stores, prioritizes, and manages requirements as they are identified and refined across all ADM phases. It does not dispose of requirements, does not generate new requirements itself, is not just a prioritization process, and does more than just resolve conflicts between phases.

The Preliminary Phase of the ADM is focused on defining the framework and methodologies to be used for the architecture development effort. This includes establishing the Architecture Capability, defining architecture principles, and customizing TOGAF for the specific organizational context. Defining application systems happens in Phase C, work packages are defined in Phase F, baseline architecture is developed in Phase A, and stakeholder identification occurs across multiple phases.

When creating views for a particular architecture, TOGAF recommends first referring to existing libraries of viewpoints to identify one for reuse rather than creating new ones from scratch. This promotes consistency, saves time, and leverages proven approaches. Architecture views should be based on established viewpoints that have been tested and validated. Developing target views first, ensuring completeness, and designing custom viewpoints are later steps in the process.

Foundation Architectures in the Architecture Continuum contain the most reusable architecture elements because they represent generic technology building blocks and architectural patterns that can be applied across multiple organizations and industries. They provide the broadest applicability and highest level of reuse potential. Common Systems Architectures are more specific, Industry Architectures are tailored to particular sectors, and Organization-Specific Architectures are the least reusable as they are customized for specific organizations.

The Architecture Vision document provides a high-level description of both the baseline and target architectures, serving as the key deliverable of Phase A that articulates the value proposition and expected outcomes of the proposed architecture work. It sets the vision and scope for the architecture development effort and communicates the key benefits to stakeholders. It is not a detailed implementation schedule, not individual change increments (that would be a roadmap), not rules and guidelines (that would be principles), and not a development agreement (that would be a Statement of Architecture Work).

The Enterprise Continuum is used to structure reusable architecture and solution assets by providing a classification scheme that organizes architectural artifacts from generic to organization-specific. It helps architects leverage existing assets and promotes reuse by categorizing architectures, models, patterns, and other artifacts in a structured way. It does not identify business requirements (that is done through stakeholder analysis), does not describe stakeholder concerns (that is done through viewpoints), does not provide continuous monitoring, and does not coordinate with other management frameworks.