OG0-093 TOGAF 9 Combined Part 1 and Part 2 Practice Questions

A key objective of the Technology Architecture Phase (Phase D) is to define technology components into a set of technology platforms that provide the foundation services required by the applications. This phase focuses on organizing and structuring the technology building blocks into logical technology platforms and services. Selecting specific technology products is done later in solution architecture, defining solution architecture is not the primary goal, transition architectures are defined in Phase E, and migration planning occurs in Phase F.

The ADM should be adapted to suit the specific needs of the enterprise because every organization has unique business drivers, constraints, requirements, and operating environments. TOGAF recognizes that the ADM is a generic method that must be tailored to fit the particular context, culture, and requirements of each organization. Moving through the cycle faster, making it more realistic, or aligning closer to business are potential outcomes but not the primary reason for adaptation.

Phase E (Opportunities & Solutions) is where Gap Analysis results from earlier phases are consolidated to identify transformation opportunities and solution approaches. This phase brings together all the gap analysis work from the Business, Data, Application, and Technology Architecture phases to develop the overall solution approach and identify work packages. Phase G focuses on implementation governance, Phase H on change management, Phase D on technology architecture, and Phase F on migration planning.

A business scenario helps identify and understand the business requirements that an architecture must address by providing a structured technique for capturing business requirements, constraints, and assumptions in a narrative format that stakeholders can understand and validate. Business scenarios drive the architecture development process by ensuring that the resulting architecture addresses real business needs. They are not for technical specifications, architecture design methods, or project plans.

The Requirements Management process is not a phase that is executed in sequence; it is a central, continuous process that interacts with all ADM phases. Each phase can generate new requirements or update existing ones, which are managed by this central process. It then feeds the relevant, prioritized requirements back into the phases as they are executed, ensuring that the architecture remains aligned with business needs.

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.