OGEA-101 TOGAF Enterprise Architecture Part 1 Exam (English) Questions and Answers

Gap Analysis is a technique that compares the Baseline Architecture and the Target Architecture to identify the differences and gaps between them. The purpose of this technique is to determine the changes and additions that are required to achieve the desired future state of the architecture. One of the main aspects of Gap Analysis is to identify the functions that are missing or overlapping in the current and future architectures, and to plan how to address them. This helps to ensure that the architecture is complete, consistent, and aligned with the business objectives and requirements3

Deliverable 1 refers to Architecture Principles. In TOGAF, Architecture Principles are established as part of the Preliminary Phase, where the enterprise prepares the architecture capability, defines the framework and governance approach, and sets the foundational rules that will guide architecture work. These principles are intended to be enduring and stable, which matches the wording in the question exactly.

Deliverable 2 refers to Architecture Contracts. In TOGAF, Architecture Contracts are formal agreements between development partners and sponsors concerning the deliverables, quality expectations, and fitness-for-purpose of the architecture. These contracts are not limited to a single phase only. They may be initiated and refined at various stages of the ADM, especially wherever there is a need to formalize agreement between architecture and implementation organizations. Although they are strongly associated with implementation governance, the concept is broader and can appear across the ADM lifecycle depending on governance needs.

The other answer options are incorrect because Architecture Principles are not outputs of Phase A, and Architecture Contracts are not restricted only to Phase E or Requirements Management. Therefore, the correct completion is that deliverable 1 is from the Preliminary Phase, and deliverable 2 can occur at various stages of the ADM.

===========

A-Architecture Repository: This is a part of the Architecture Metamodel that contains artifacts structured according to the metamodel. It includes the Architecture Landscape which is adopted by the enterprise and governed by certain standards and practices.

B-Governing Board: The Governing Board ensures visibility and escalation, meaning it oversees and manages the capability of the architecture landscape. It plays a crucial role in governance.

C-Enterprise Capability: This refers to how well an enterprise can execute its mission, meet business objectives or satisfy its stakeholders’ needs and expectations. It’s influenced by both internal factors (like resources, processes) and external ones (like market trends).

TOGAF Version 9.1, Chapter 34: 1

Comprehensive and Detailed Explanation From documents:

In TOGAF, a Business Scenario is an ADM technique used to capture and structure business requirements in a way that directly informs the development and validation of architectures. It frames a specific business problem (or opportunity) and articulates the desired outcomes/objectives, along with the business and technical context, the involved actors and roles (human and system), and the measures of success. This makes option A correct because it concisely captures the essence of a Business Scenario: a well-defined business problem coupled with the outcomes the business seeks to achieve.

A good Business Scenario typically includes:

The business problem/opportunity and drivers.

The business and technical environment/context in which the problem exists.

The desired outcomes/objectives and measures of success (how success will be recognized).

Actors and roles (both human and system) and their interactions.

Capabilities and high-level requirements implied by the scenario.

Business Scenarios are especially valuable in Phase A: Architecture Vision to validate scope, objectives, and business value, and they continue to be used throughout Phases B–D to test and validate the target architectures and to maintain requirements traceability via Requirements Management. They promote shared understanding among stakeholders and provide a concrete basis for evaluating solution options and assessing architecture fitness-for-purpose.

Why the other options are incorrect:

B. A use-case for developing a business model. While Business Scenarios and use-cases are related, a Business Scenario is broader. It provides context, problem, objectives, and measures of success; use-cases are often derived from or complement Business Scenarios to specify interactions, but a Business Scenario is not merely a use-case.

C. A method to quantify readiness for change. This describes Business Transformation Readiness Assessment, a separate TOGAF technique used to gauge an organization’s readiness to execute change. It is not what TOGAF defines as a Business Scenario.

D. A technique to identify differences between a baseline and a target architecture. That is Gap Analysis, another distinct ADM technique used to determine what needs to change to move from the current state to the desired future state.

References (official TOGAF materials; no links):

The Open Group, TOGAF® Standard, Version 9.2, Part III: ADM Guidelines & Techniques — Business Scenarios; also Requirements Management, and Phase A: Architecture Vision (Part II) for where Business Scenarios are applied.

The Open Group, TOGAF® Series Guide: Business Scenarios — definition, structure, and usage of Business Scenarios across the ADM.

The Open Group, TOGAF® 9 Foundation Study Guide (latest edition) — coverage of Business Scenarios as an ADM technique and their relationship to use-cases.

The Open Group, TOGAF® 9 Certified Study Guide (latest edition) — contrasts with related techniques (Gap Analysis; Business Transformation Readiness Assessment) and explains use within Phase A and Requirements Management. ===========

Phase E: Opportunities & Solutions – Steps/Outputs emphasize grouping work packages, dependencies, and planning the roadmap/plan that reflect value/effort:

“Identify and group major work packages… Refine and validate dependencies… Create the Architecture Roadmap & Implementation and Migration Plan.” www.opengroup.org

The purpose of the Gap Analysis technique is similar to the previous question, but with a focus on the Target Architecture. The technique helps to identify the items that are not included or specified in the Target Architecture, such as capabilities, services, components, standards, or technologies. These items may be essential for achieving the vision and goals of the enterprise, or for addressing the stakeholder concerns and requirements. By identifying the items omitted from the Target Architecture, the technique helps to ensure that the architecture is comprehensive, feasible, and realistic.

Within the TOGAF framework, assessments are used to ensure that architecture work is conformant with governance parameters. A compliance assessment (sometimes called architecture compliance or compliance review) is the evaluation of a project’s architectural artifacts—its design, architecture decisions, progress status—against the established architecture standards, principles, and constraints. The content of a compliance assessment typically includes reviewing the project status, the architectural design alignment, and identifying noncompliance issues or deviations. Because it focuses on how well the project matches the architecture, rather than on capabilities, organizational structure, or risk per se, the described contents correspond to a compliance assessment. The compliance assessment helps governance bodies enforce architectural consistency and correct deviations during implementation.

The image shows a diagram that illustrates the basic concepts of architecture description as defined by the ISO/IEC/IEEE 42010:2011 standard1, which is also adopted by the TOGAF standard2.

According to the ISO/IEC/IEEE 42010:2011 standard, an architecture description is a work product used to express an architecture, and it consists of one or more architecture views1.

An architecture view is a representation of a system from the perspective of a related set of concerns, and it conforms to an architecture viewpoint1.

An architecture viewpoint is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns1.

Therefore, the correct answer is option A, which identifies the items labeled as “A” and “B” in the image as an architecture viewpoint and an architecture view, respectively. References:

1: ISO/IEC/IEEE 42010:2011 - Systems and software engineering — Architecture description1

2: TOGAF Standard, Version 9.2 - Part IV: Architecture Content Framework - 31. Architectural Artifacts2

“The Content Metamodel defines a formal structure for these terms to ensure consistency within the architecture description…” A metamodel used across the enterprise enables consistency and completeness checking of the architecture description against the defined structure. Open Group Publications

Architecture governance is the practice of ensuring compliance with the enterprise architecture and its principles, standards, and goals. Architecture governance provides the means to establish, monitor, and control the architecture development and implementation processes, and to resolve any issues or conflicts that may arise. Architecture governance also ensures that all stakeholders are represented and involved in the decision-making process, and that their interests and concerns are balanced and aligned. Statements 1 and 2 highlight the value and necessity for architecture governance to be adopted within organizations, as they emphasize the importance of responsibility, accountability, fairness, and transparency in the architectural activities. Statements 3 and 4 are more related to the benefits and outcomes of having a good enterprise architecture, rather than the governance aspect.

The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 29: Architecture Governance

In TOGAF, an Architecture View is defined as the representation of a system from the perspective of a related set of concerns. This means a view is created to address the interests of specific stakeholders by focusing on those aspects of the architecture that matter to them. For example, business stakeholders may need a view centered on processes and capabilities, while technical stakeholders may need a view showing applications, interfaces, or technology infrastructure.

The other options are not correct because they refer to specific forms of architectural content rather than the broader concept of stakeholder-oriented representation. A Catalog is a list of architectural elements. A Matrix shows relationships between items. A Diagram presents information graphically. All of these may be used to help construct or express an architecture view, but they are not themselves the formal TOGAF concept being asked about in the question.

The key phrase in the question is “from the perspective of a related set of concerns.” That wording matches the TOGAF definition of an Architecture View. It is specifically intended to communicate architecture in a way that is meaningful to stakeholders and their concerns. Therefore, the correct answer is Architecture View.

According to the TOGAF Standard, 10th Edition, architecture governance is “the practice by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level” 1. Architecture governance ensures that the architecture development and implementation are aligned with the strategic objectives, principles, standards, and requirements of the enterprise, and that they deliver the expected value and outcomes. Architecture governance also involves establishing and maintaining the architecture framework, repository, board, contracts, and compliance reviews 1. The other options are not correct, as they are not the term used by the TOGAF Standard to describe the practice by which the enterprise architecture is managed and controlled at an enterprise-wide level. Corporate governance is “the system by which an organization is directed and controlled” 2, and it covers aspects such as leadership, strategy, performance, accountability, and ethics. IT governance is “the system by which the current and future use of IT is directed and controlled” 2, and it covers aspects such as IT strategy, policies, standards, and services. Technology governance is “the system by which the technology decisions and investments are directed and controlled” 3, and it covers aspects such as technology selection, acquisition, deployment, and maintenance. References: 1: TOGAF Standard, 10th Edition, Part VI: Architecture Governance, Chapter 44: Introduction. 2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 3: TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Part II: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Chapter 5: Technology Governance.

Statements 1 and 3 about architecture partitioning are correct. Architecture partitioning is the technique of dividing an architecture into smaller and more manageable parts that can be developed, maintained, and governed independently. Partitions are used to simplify the management of the Enterprise Architecture and to enable different teams to work on different elements of the architecture at the same time. Partitions are not equivalent to architecture levels, which are different degrees of abstraction or detail in an architecture. Partitions do not necessarily reflect the organization’s structure, which may change over time or differ from the architecture’s scope and boundaries. Reference: The TOGAF® Standard | The Open Group Website, Section 2.5 Architecture Partitioning.

 In the ADM documents which are under development and have not undergone any formal review and approval process are called “draft”. This indicates that they are subject to change and refinement as the architecture development progresses. Reference: The TOGAF® Standard | The Open Group Website, Section 4.2.5 Architecture Deliverables.

In TOGAF, Phase E (Opportunities & Solutions) is the first phase that transitions from architecture models into actionable implementation. Within Phase E, architects identify candidate implementation projects or work packages, assess dependencies, cost/benefit, constraints, and derive a highlevel implementation and migration strategy and initial plans. That means the first planning around how to carry out the architecture begins in Phase E. Later phases refine and govern the implementation (e.g. in Phase F and G), but the initial planning belongs in Phase E. Thus Phase E includes the initial implementation planning.

Comprehensive and Detailed Explanation

In the TOGAF ADM, deliverables go through a lifecycle of development, review, approval, and usage. TOGAF distinguishes between draft deliverables (work-in-progress) and final deliverables (those that have been formally reviewed and signed off).

Draft deliverables are produced as working versions of the required outputs in each ADM phase. These may carry version labels such as 0.1, 0.5, 0.9, etc., and are subject to stakeholder review and refinement.

Once the document has been reviewed and approved by the relevant stakeholders (e.g., Architecture Board, governance bodies), it becomes a final deliverable.

Final deliverables are baseline-controlled items and are formally stored in the Architecture Repository as an approved architecture artifact.

Thus, the correct term for a deliverable that has completed review and is approved is “final”.

Why the other options are incorrect

B. Approved: While true in general language, TOGAF uses the formal term “final deliverable”, not “approved deliverable.”

C. Ratified: This term is not used in TOGAF to describe the state of a deliverable.

D. Version 0.9: This is a draft numbering convention, not the status of an approved deliverable.

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — description of deliverables, artifacts, and building blocks.

The Open Group, TOGAF® 9 Certified Study Guide — explanation of draft vs. final deliverables in the ADM lifecycle.

According to the TOGAF Standard, 10th Edition, documents which are under development and have not undergone any formal review and approval process are called draft documents, while documents which have been reviewed and approved are called approved documents 1. Draft documents are typically marked with a version number of 0.x, indicating that they are incomplete or provisional. Approved documents are typically marked with a version number of 1.0 or higher, indicating that they have been finalized and authorized. The other options are not correct, as they are not the terms used by the TOGAF Standard to distinguish between documents under development and documents that have been reviewed and approved. The terms “finalized”, “concept”, “deliverable”, and “Version 0.1” and “Version 1.0” are not specific to the TOGAF Standard, and they may have different meanings or interpretations in different contexts. References: 1: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 7: Applying Iteration to the ADM, Section 7.2.3 Document Categorization.

A set of architecture principles that cover every situation perceived meets the recommended criteria of completeness. Completeness is one of the six criteria that should be applied when developing or assessing architecture principles. Completeness means that there are no gaps or overlaps in the coverage of principles across all relevant aspects of the enterprise’s architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.7 Architecture Principles.

“Modeling these items would help the clarification process, and in particular would highlight any ambiguities or conflicts that involved trade-offs and/or prioritization… the architecture principles… likewise help clarify ambiguities or conflicts that involve trade-offs.” Open Group Publications

According to the TOGAF Standard, 10th Edition, a transformation readiness assessment is a technique that evaluates the preparedness of the organization to undergo a change, and identifies the actions needed to increase the likelihood of a successful outcome. A transformation readiness assessment can be conducted in Phase E: Opportunities and Solutions, and the actions resulting from it can be dealt with in Phase F: Migration Planning 1. In Phase E, the transformation readiness assessment can help to identify the major implementation challenges and risks, and to define the critical success factors and key performance indicators for the architecture project. In Phase F, the actions resulting from the transformation readiness assessment can help to develop a detailed and realistic migration plan, and to address the gaps, issues, and dependencies that may affect the transition to the target architecture 1. References: 1: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 29: Business Transformation Readiness Assessment.

In TOGAF, deliverable 2 is correctly identified as Architecture Contracts. These are the formal joint agreements between development partners, sponsors, and in some cases implementation organizations, covering the expected deliverables, quality measures, and fitness-for-purpose of the architecture. Their role is to ensure that architecture intent is translated into governed and measurable commitments. Architecture Contracts are especially important in implementation governance because they define expectations, conformance requirements, and accountability between parties involved in the architecture and delivery process.

Deliverable 3 is the Request for Architecture Work. This is the formal initiating document sent from the sponsoring organization to the architecture function to trigger the start of a new architecture development cycle. It provides the initial authorization to begin the architecture effort and acts as a formal signal that architecture work is needed. It is one of the recognized inputs used to begin structured ADM activity.

The other options do not match the definitions given. The Architecture Definition Document describes the architecture itself, not joint agreements. A Change Request is used later to propose modifications. Architecture Vision and Architecture Requirements Specification are different ADM outputs with different purposes.

Therefore, the correct mapping for labels 2 and 3 is Architecture Contracts and Request for Architecture Work, which is Option B.

Architecture Requirements Specification: “provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.” Open Group Publications

Statement of Architecture Work (Phase A output): “The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture project.” (Produced in Phase A per the Phase A outputs list.) Open Group Publications

“There are two levels of risk that should be considered namely: Initial Level of Risk [and] Residual Level of Risk.” archive.opengroup.org

Gap Analysis in TOGAF is a technique used to compare the baseline architecture (current state) with the target architecture (future desired state). The output is a set of gaps, representing what is missing or what must change to move from baseline to target. These gaps help validate that the target architecture is adequate: by identifying what is not addressed, architects can ensure that all required functionality, constraints, and transformation paths are captured. In effect, Gap Analysis validates the architecture by exposing omissions, inconsistencies, or unmet requirements between what is and what should be. It is not primarily about defining service levels, nonfunctional requirements, or quality metrics (though it helps inform those). Rather, its main role is in validating and guiding closure of architectural gaps.

(ADM Inputs/Outputs for early phases include Business Scenario/Architecture Vision content, with “Risks and issues” explicitly listed.) — “Business Scenario / Architecture Vision… Risks and issues …” www.opengroup.org

The table describes the output, outcome, and essential knowledge of an ADM phase that oversees the implementation of changes necessary to reach the adjusted target state. This corresponds to Phase G, also known as Implementation Governance, which ensures that the architecture defined in earlier phases is realized, and it oversees the development and implementation of projects to align with this architecture. The essential knowledge required during this phase includes understanding constraints on the implementation team and adjusting stakeholder priority and preference in response to success, value, effort, and risk of change. References: TOGAF Version 9.1 - 1

Gap analysis is a technique that is used to validate an architecture by highlighting the shortfall between the Baseline Architecture and the Target Architecture. One of the purposes of gap analysis is to identify missing functions that are either deliberately omitted, accidentally left out, or not yet defined in the Target Architecture. Missing functions are marked as gaps that need to be filled by developing or procuring the building blocks. 

The objective of the ADM Implementation Governance Phase is to provide an architectural oversight of the implementation and to ensure conformance for the target architecture. This phase involves establishing procedures and processes to monitor and control the implementation projects and to verify that they comply with the defined architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.7 Phase G: Implementation Governance.

“In addition to the method itself being iterative, there is also iteration within the ADM cycle, both among the individual phases and among the steps within a phase.” www.opengroup.org

Comprehensive and Detailed Explanation

When defining the scope of an architecture, TOGAF identifies four dimensions that need to be considered:

Breadth – This dimension addresses the extent of the enterprise that will be impacted by the architecture. It answers the question: How much of the enterprise is covered? For example, does the scope include the entire enterprise, a business unit, a division, or just a single organizational function?

Depth – This refers to the level of detail to be covered. For instance, will the architecture describe high-level capabilities, or will it go into detailed system design?

Time Period – This defines the planning horizon of the architecture. It could be short-term (tactical), medium-term, or long-term (strategic).

Architecture Domains – This refers to which domains are covered: Business, Data, Application, and Technology. The scope may include all or just a subset of these domains.

Project Scope (sometimes discussed separately) – Focuses on which specific programs, portfolios, or projects will be impacted.

Among these, the dimension that specifically relates to the extent of the enterprise is Breadth.

Why the other options are incorrect

A. Architecture Domains: Refers to the domains covered (Business, Data, Application, Technology), not the extent of the enterprise.

B. Depth: Refers to the level of detail, not the enterprise extent.

C. Project: Refers to the program or initiative focus, not enterprise coverage.

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — Preliminary Phase (scope considerations).

The Open Group, TOGAF® 9 Certified Study Guide — discussion of the dimensions of architecture scope (Breadth, Depth, Time Period, Architecture Domains).

A business scenario describes business and technology environment in which those problems occur. It provides a realistic context for identifying and addressing business problems and opportunities, as well as their impact on the enterprise’s architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.1 Business Scenarios.

business and technology environment in which those problems occur https://pubs.opengroup.org/togaf-standard/business-architecture/business-scenarios.html#_Toc68617078 "

A Business Scenario is a uniform description of: - Real business problems - The business and technology environment in which those problems occur - Value streams enabled by capabilities - The desired outcome(s) of proper execution - The human and computing components (the “actors”) who provide the capabilities "

The Architecture Repository is the structural framework defined by TOGAF to store, manage, and leverage architecture artifacts, including reference models, standards, governance logs, and deliverables.

The Architecture Capability refers to governance and processes.

The Architecture Landscape shows Strategic, Segment, and Capability architectures, not storage.

The Enterprise Architecture Capability Model is not a defined TOGAF concept.

The graphic illustrates the Architecture Trade-off method. In TOGAF, this method is used to evaluate multiple architectural alternatives against defined criteria derived from the Architecture Vision, Architecture Principles, and Requirements. The purpose is to compare possible target architecture options in a structured way and select the one that best satisfies stakeholder concerns, business goals, and architectural constraints.

The diagram clearly shows that alternative options are not accepted automatically. Instead, they are examined against criteria and then passed through a selection step. That is the defining pattern of trade-off analysis. It supports decision-making where several valid options exist, but each has different strengths, weaknesses, costs, risks, or compliance characteristics. By applying this method, architects can justify why one option is preferable over others.

The other choices do not match the structure shown. Architecture Partitioning is concerned with dividing architecture work into manageable sections. The Business Scenario method is used to derive and validate business requirements. Iteration refers to repeated cycles within the ADM. None of those are represented by a criteria-based comparison and selection of alternatives.

Therefore, according to the TOGAF Standard, the correct answer is A. The Architecture Trade-off method.

Comprehensive and Detailed Explanation

Let’s examine each statement against the TOGAF ADM principles:

All ADM activities are carried out within an iterative cycle of continuous architecture definition and realization

Correct. The ADM is iterative in three dimensions: across the cycle, between levels (enterprise, segment, capability), and within phases. This means architecture development is never linear but part of a continuous cycle of definition and realization.

The Requirements Management phase is a continuous phase

Correct. Requirements Management is central to the ADM cycle. It operates continuously, ensuring requirements are identified, stored, and addressed throughout all phases, not only in a single step.

Output from an early phase may be modified in a later phase

Correct. The ADM is iterative and allows feedback between phases. For example, new requirements identified in later phases may lead to modifications of deliverables from earlier phases.

When a phase starts, the previous phase closes

Incorrect. The ADM is not strictly sequential. Phases can overlap, iterate, and provide feedback loops. One phase starting does not imply that the previous phase is closed; instead, phases interact dynamically.

Correct Mapping

Statements 1, 2, and 3 are correct.

Statement 4 is incorrect.

Correct answer is B (1, 2 & 3).

Why the other options are incorrect

A (2, 3 & 4): Includes statement 4, which is incorrect.

C (1, 2 & 4): Includes statement 4, which is incorrect.

D (1, 3 & 4): Includes statement 4, which is incorrect.

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — overview of ADM iterations, Requirements Management, and feedback between phases.

The Open Group, TOGAF® 9 Certified Study Guide — emphasizes ADM as iterative and requirements-driven.

The purpose of the Preliminary Phase is to architect an Enterprise Architecture Capability that meets the needs and expectations of the enterprise’s stakeholders and supports and enables subsequent phases of architecture development and transition. This phase involves defining the scope, principles, framework, and governance for the Enterprise Architecture Capability. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2 Preliminary Phase.

The class of information known as the Reference Library within the Architecture Repository contains guidelines and templates used to create new architectures. The Reference Library provides a set of resources that can be leveraged or customized for specific architecture development purposes. It includes generic building blocks, patterns, models, standards, frameworks, methods, techniques, best practices, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4 Architecture Repository.

The correct answer is Risk Management because risk assessment and risk analysis are core parts of the risk management process. In TOGAF, risk management is used to support architectural and implementation decision-making by identifying risks, evaluating their likelihood and impact, and determining appropriate responses. This allows stakeholders and architects to make informed choices about architecture options, transition paths, implementation timing, and governance actions.

Risk assessment focuses on understanding the nature of identified risks and estimating their significance. Risk analysis examines those risks in more detail to determine consequences, priorities, and possible treatments. These activities are not stand-alone disciplines in TOGAF; they are applied as part of Risk Management, which provides the structured method for using risk information in decisions.

The other options are related but not as precise. Information Security Management focuses on managing security controls and policies. Security Governance is concerned with oversight and accountability. Security Architecture defines structural security capabilities and controls. While all may use risk-related information, the direct application of risk assessment and risk analysis in decision-making belongs to Risk Management. Therefore, according to TOGAF terminology and governance practice, the best answer is C.

===========

In TOGAF, architecture work must be grounded in a clear understanding of the enterprise context. That context is provided by business principles, business goals, and business drivers, because these explain why the enterprise exists, what it is trying to achieve, and what forces are shaping its direction. They also reflect the ways of working, operational intentions, and guiding rules that influence architecture development.

Architecture Contracts are governance mechanisms used later to formalize implementation relationships and obligations, so they do not provide the initial business context for architecture work. Stakeholder needs are important inputs, but by themselves they do not fully describe the enterprise’s broader ways of working or strategic operating context. Strategy and vision are also important, but the TOGAF framing of enterprise context is more completely expressed through principles, goals, and drivers, which collectively establish both direction and operational grounding.

This is why option D is the best answer. It captures the combination of enduring guidance, intended outcomes, and motivating forces that shape architecture decisions. In TOGAF, these elements help architects understand the enterprise environment before defining architecture scope, constraints, and solutions. Therefore, the correct completion is Business principles, business goals, and business drivers.

===========

The Architecture Landscape is divided into levels known as Segment Strategic and Capability Architectures. These levels correspond to different scopes and purposes of architectures within an enterprise. Segment Architectures are architectures that address specific business units, functions, or processes within an enterprise. Strategic Architectures are architectures that provide a high-level view of the enterprise’s vision, goals, and direction. Capability Architectures are architectures that address specific business capabilities or services that span multiple segments or domains. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4 Architecture Repository.

The TOGAF Architecture Development Method (ADM) is best described as a repeatable process for developing architectures. It provides the step-by-step method used to create, evolve, govern, and manage enterprise architectures in a consistent and structured way. The ADM is the core of TOGAF and defines how architecture work progresses from preparation and vision through business, data, application, and technology architecture, then into opportunities, migration planning, implementation governance, and change management.

Option A is incorrect because a classification mechanism is not the purpose of the ADM. Option B is too narrow, since requirements management is only one supporting aspect of the ADM, not its full definition. Option C is also incorrect because readiness assessment may be used as a technique within architecture practice, but it is not what the ADM itself is.

The strength of the ADM is that it is iterative, adaptable, and repeatable. It can be tailored for different enterprises and change scenarios while still preserving a consistent method. This makes it suitable for both large transformation efforts and more focused architecture initiatives. Therefore, the best description is option D, a repeatable process for developing architectures.

The Preliminary Phase establishes the Organization Model for Enterprise Architecture, defines principles, and sets up the Architecture Capability.

The Architecture Vision is developed in Phase A.

The Architecture Roadmap comes from Phase E and Phase F.

The Implementation Governance Model is part of Phase G.