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

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

The illustration shows an architecture development cycle based on the TOGAF ADM (Architecture Development Method), which is a method for developing and managing an enterprise architecture1.

The ADM consists of nine phases, each with a specific purpose and output. The phases are1:

Preliminary Phase: To prepare and initiate the architecture development cycle, including defining the architecture framework, principles, and governance.

Phase A: Architecture Vision: To define the scope, vision, and stakeholders of the architecture initiative, and to obtain approval to proceed.

Phase B: Business Architecture: To describe the baseline and target business architecture, and to identify the gaps between them.

Phase C: Information Systems Architectures: To describe the baseline and target data and application architectures, and to identify the gaps between them.

Phase D: Technology Architecture: To describe the baseline and target technology architecture, and to identify the gaps between them.

Phase E: Opportunities and Solutions: To identify and evaluate the opportunities and solutions for implementing the target architecture, and to define the work packages and transition architectures.

Phase F: Migration Planning: To finalize the implementation and migration plan, and to ensure alignment with the enterprise portfolio and project management.

Phase G: Implementation Governance: To provide architecture oversight and guidance for the implementation projects, and to manage any architecture change requests.

Phase H: Architecture Change Management: To monitor the changes in the business and technology environment, and to assess the impact and performance of the architecture.

In addition to these phases, there is a central process called Requirements Management, which is labeled as item 1 in the illustration. This process operates throughout the ADM cycle, and its purpose is to manage the architecture requirements throughout the architecture development, ensuring that they are aligned with the business requirements and the stakeholder concerns2.

Therefore, the description that matches the phase of the ADM labeled as item 1 is C. Operates the process of managing architecture requirements.

1: The TOGAF Standard, Version 9.2, Chapter 5: Architecture Development Method (ADM)

2: The TOGAF Standard, Version 9.2, Chapter 17: Requirements Management

The statement illustrates iteration and the ADM. Iteration is the technique of repeating a process or a phase with the aim of improving or refining the outcome. Iteration allows for feedback loops and adaptations at any point in the architecture development and transition process. Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects, to address different aspects or levels of the architecture in an iterative manner. Reference: The TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.

The chart shown is a Gantt chart, which is commonly used for project management to illustrate a project schedule. In the context of TOGAF (The Open Group Architecture Framework), which is a framework for enterprise architecture, this Gantt chart is demonstrating the sequenced approach to the Architecture Development Method (ADM). The ADM is the core process of TOGAF which provides a tested and repeatable process for developing architectures. The ADM is described as being iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken about each of the parameters (scope, granularity, time period, and architecture assets).

The ADM consists of a number of phases that have to be followed in sequence:

Preliminary Phase: Framework and principles

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures, including Data and Application Architectures

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

Each phase is dependent on the outputs of the previous phase and the Requirements Management phase runs throughout. The Gantt chart clearly shows the dependency and sequence in which these phases occur, implying that a structured approach is followed to produce the enterprise architecture.

The TOGAF Standard, Version 9.2, a standard of The Open Group

The TOGAF documentation available at https://publications.opengroup.org/standards/architecture and https://publications.opengroup.org/guides/architecture

“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

The statement "Projects may cycle between ADM phases, in planned cycles covering multiple phases" illustrates the concept of iteration, which is the process of repeating the ADM phases or steps within a phase to refine the architecture outputs and address the changing requirements and stakeholder concerns. Iteration can occur at different levels of granularity and scope, such as within a single phase, across multiple phases, or across the entire ADM cycle. Iteration can also be applied to different architecture domains, such as business, data, application, and technology. Iteration is a key feature of the ADM that enables the development of architectures that are fit for purpose, adaptable, and responsive to change. References: : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 24: Applying Iteration to the ADM

“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

The Preliminary Phase is the preparatory phase of the Architecture Development Method (ADM) cycle, which sets the context and direction for the architecture work. One of the objectives of this phase is to select and implement tools to support the Architecture Capability, which is the ability of an organization to perform enterprise architecture effectively and efficiently. Tools can include software applications, methods, techniques, standards, and frameworks that assist the architecture development and governance processes. The selection and implementation of tools should be based on the requirements and constraints of the organization, and the alignment with the Architecture Principles and the Architecture Vision3 References: 3: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 6: Preliminary Phase : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 45: Establishing and Maintaining an Enterprise Architecture Capability : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 46: Tools for Architecture Development

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.

TOGAF’s governance guidance distinguishes benefits such as transparency, accountability, and discipline in operating governance processes. Formal TOGAF conformance topics include “The benefits of Architecture Governance,” which include establishing and enforcing processes and controls (discipline) for architecture decision-making and compliance. togaf-cert.opengroup.org

Strategy Portfolio Project Solution Delivery are the four purposes that typically frame the planning horizon, depth and breadth of an Architecture Project, and the contents of the EA Repository. They correspond to different levels of abstraction and granularity in the architecture development process. Reference: The TOGAF® Standard, Version 9.2 - The Open Group, Section 2.4 Architecture Repository.

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 Enterprise Continuum provides a classification mechanism for artifacts, showing how they evolve from generic Foundation Architectures and Reference Models to organization-specific architectures.

Option A is about tools, not the Continuum.

Option B describes the Architecture Principles.

Option C describes the Architecture Repository.

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. 

According to the TOGAF Standard, 10th Edition, a stakeholder is “an individual with an interest in a system” 1. A stakeholder can be anyone who is affected by the system, or who can influence or be influenced by the system. Stakeholders can have different roles, perspectives, and concerns regarding the system, and they can be internal or external to the organization. Stakeholder management is a technique that helps to identify, analyze, and engage the stakeholders of an architecture project, and to address their needs and expectations 2. The other options are not correct, as they are not the term used by the TOGAF Standard to describe an individual with an interest in a system. A consumer is “an individual or group that uses a product or service” 1. A lead architect is “an individual who is responsible for leading the development of an architecture” 1. A sponsor is “an individual who provides funding and support for an architecture project” 1. References: 1: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 2: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 24: Stakeholder Management.

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 G: Implementation Governance provides architectural oversight of the implementation. It ensures that the implementation conforms to the Target Architecture using Architecture Contracts and governance frameworks.

Phase H: Architecture Change Management is about maintaining the architecture lifecycle and handling new requirements, not direct implementation oversight.

Preliminary Phase is about setting up the architecture capability.

Phase A is about developing the Architecture Vision.

The TOGAF ADM uses Gap Analysis during Phases B, C, and D (Business, Information Systems, and Technology Architectures) to identify building block gaps—the differences between the Baseline Architecture and the Target Architecture. However, simply identifying gaps does not complete the process.

The association of gaps with work packages happens later in the cycle:

Phase E: Opportunities and Solutions is where the identified gaps are analyzed and translated into work packages, projects, or initiatives that will deliver the required changes.

In Phase E, architects also determine whether Transition Architectures are needed, and they generate the initial Architecture Roadmap.

This is the phase where gaps become actionable, linked with specific work packages that can be executed to close them.

Phase F (Migration Planning) takes this further by finalizing the roadmap and building the detailed Implementation and Migration Plan, but the initial association of gaps with work packages occurs in Phase E.

Business Transformation Readiness Assessment is a joint effort between corporate staff lines of business and IT planners to evaluate the readiness of the organization to undergo change. It involves assessing factors such as vision, commitment, capacity, capability, culture, and motivation that may influence the success of a business transformation initiative. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.2 Business Transformation Readiness Assessment.

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

Business scenarios are a technique for capturing, clarifying, and communicating the functional and non-functional requirements of a system. Business scenarios describe the business environment, the actors involved, the desired outcomes, and the processes or rules that govern the behavior of the system. Business scenarios are useful for ensuring that the architecture addresses the real needs and concerns of the stakeholders, and for validating and testing the architecture against expected situations. Business scenarios are developed in Phase A: Architecture Vision of the ADM cycle, and refined and updated throughout the other phases3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 26: Business Scenarios : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision

Ensuring compliance with internal and external standards and regulatory obligations is one of the activities included as part of Architecture Governance. Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It involves establishing processes, roles, responsibilities, policies, and standards to ensure that architectures are aligned with the enterprise’s strategy and objectives, and meet the quality and performance requirements. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.6 Architecture Governance.

A content metamodel is a formal structure that defines the types of entities and relationships that are used to capture, store, filter, query, and represent architectural information in a way that supports consistency, completeness, and traceability12.

A stakeholder map is a tool that identifies and analyzes the key stakeholders and their interests, influence, and expectations in relation to the architecture3. It is not used to structure architectural information, but rather to understand the stakeholder needs and concerns.

An architecture framework is a set of principles, guidelines, standards, and tools that provide a common structure and methodology for developing architectures4. It is not used to structure architectural information, but rather to guide the architecture development process and ensure alignment with the business strategy and objectives.

An EA library is a repository that stores and manages the architecture artifacts, deliverables, and other relevant information produced and consumed during the architecture development and governance. It is not used to structure architectural information, but rather to provide access, security, and version control for the architecture content.

 1: The TOGAF Standard, Version 9.2 - Content Metamodel 2: TOGAF 9.2 Content Metamodel Framework - A Quick Guide - KnowledgeHut 3: The TOGAF Standard, Version 9.2 - Stakeholder Management 4: The TOGAF Standard, Version 9.2 - Architecture Framework : The TOGAF Standard, Version 9.2 - Architecture Repository

Business principles business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. They define what the enterprise wants to achieve, how it wants to operate, and what factors influence its decisions and actions. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2 Preliminary Phase.

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

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.

“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

“A business scenario is essentially a complete description of a business problem, both in business and in architectural terms.” www.opengroup.org

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 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 Implementation Governance Model is a framework that defines the roles, responsibilities, processes, and standards for governing the implementation of the target architecture. It ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance, which is the practice of ensuring compliance with the enterprise architecture and its principles, standards, and goals. The Implementation Governance Model is part of the Implementation and Migration Plan, which is the output of Phase F: Migration Planning of the Architecture Development Method (ADM)12 References: 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning 2: The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance

(Authoritative Open Group guidance distinguishes conceptual, logical, and physical concerns; at the logical level, component types are identified independently of implementation.) For example, the Open Group’s metamodel guidance emphasizes technology-agnostic structure to ensure consistency within an architecture description, which is precisely what the logical level captures before physical realization.

“The Content Metamodel defines a formal structure… to ensure consistency within the architecture description and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.” Open Group Publications

Comprehensive and Detailed Explanation

TOGAF defines an Architecture Principle as a qualitative statement of intent that should be met by the architecture. To ensure clarity and consistent application, TOGAF provides a standard template for documenting each principle. The template includes four parts:

Name – A clear, precise, and easy-to-remember name for the principle.

Answers the question: What is this principle called?

Statement – A short, unambiguous sentence that communicates the essence of the principle.

Answers the question: What does this principle mean?

Rationale – Explains why the principle is important, the benefits of adopting it, and how it supports the enterprise’s goals.

Answers the question: Why should we adopt this principle?

Implications – Highlights the consequences of adopting the principle, including the impact on business processes, technology, governance, and resources.

Answers the question: How does this affect me?

Therefore, the correct section where the reader would find the answer to “How does this affect me?” is Implications.

Why the other options are incorrect

A. Statement: Defines the essence of the principle but does not address consequences.

B. Rationale: Explains the reasoning and justification for the principle but not its practical effects.

C. Name: Only provides the identifier or title of the principle.

References

The Open Group, TOGAF® Standard, Version 9.2, Part III: ADM Guidelines & Techniques — Architecture Principles.

The Open Group, TOGAF® 9 Certified Study Guide — description of the Architecture Principles template and the purpose of each section.

An Architecture Board is an executive-level group responsible for the review and maintenance of the strategic architecture and all of its sub-architectures1. It is a key element in a successful Architecture Governance strategy2.

An Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals2:

Providing the basis for all decision-making with regard to the architectures

Consistency between sub-architectures

Establishing targets for re-use of components

Flexibility of the Enterprise Architecture: To meet changing business needs To leverage new technologies

Enforcement of Architecture Compliance

Improving the maturity level of architecture discipline within the organization

Ensuring that the discipline of architecture-based development is adopted

Supporting a visible escalation capability for out-of-bounds decisions

Therefore, the correct answer is option D, which captures one of the goals of an Architecture Board as stated in the TOGAF Standard, Version 9.22.

Option A is incorrect, because conducting assessments of the maturity level of architecture discipline within the organization is not a direct responsibility of an Architecture Board, but rather a part of the Architecture Capability Framework3.

Option B is incorrect, because allocating resources for architecture projects is not a direct responsibility of an Architecture Board, but rather a part of the Architecture Governance Framework4.

Option C is incorrect, because creating the Statement of Architecture Work is not a direct responsibility of an Architecture Board, but rather a part of the Architecture Development Method5. References:

1: Architecture Board - The Open Group3

2: TOGAF Standard, Version 9.2 - Part VI: Architecture Governance Framework - Architecture Board

3: TOGAF Standard, Version 9.2 - Part VI: Architecture Governance Framework - Architecture Capability Framework

4: TOGAF Standard, Version 9.2 - Part VI: Architecture Governance Framework - Architecture Governance Framework

5: TOGAF Standard, Version 9.2 - Part II: Architecture Development Method - Phase A: Architecture Vision

(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

EA applies architecture principles and practices to analyze, design, plan, and implement enterprise analysis that supports digital transformation, IT growth, and the modernization of IT2. EA also helps organizations improve the efficiency, timeliness, and reliability of business information, as well as the alignment, agility, and adaptability of the architecture to the changing needs and requirements3. Therefore, the best summary of the purpose of EA is to guide effective change.