The TOGAF Enterprise Architecture Bridge Exam (English) (OGEA-10B)

According to the TOGAF Standard, Version 9.2, an  architecture view  is a representation of a system from the perspective of a related set of concerns 1 .  It consists of one or more architecture models that demonstrate how the system addresses the stakeholder concerns 1 .

An  architecture viewpoint  is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns 1 .  It defines the perspective, scope, notation, and techniques for creating an architecture view of a system 1 .

Architects can present architecture views and viewpoints to stakeholders to extract hidden agendas, principles, and requirements that could impact the final Target Architecture, because 2 3 :

Architecture views and viewpoints help to communicate and visualize the architecture in a way that is meaningful and relevant to different stakeholders, addressing their specific interests and needs.

Architecture views and viewpoints help to elicit and validate the stakeholder concerns and requirements, ensuring that they are aligned with the business goals and objectives, and that they are consistent and feasible within the architecture context.

Architecture views and viewpoints help to identify and resolve any conflicts, gaps, or trade-offs among the stakeholder concerns and requirements, ensuring that they are balanced and prioritized in the architecture design and decision-making.

Architecture views and viewpoints help to demonstrate and verify the value and benefits of the architecture to the stakeholders, ensuring that they are satisfied and committed to the architecture outcome and governance.

References :

1 : The TOGAF Standard, Version 9.2, Chapter 22: Architecture Views, Viewpoints, and Stakeholders

2 : The TOGAF Standard, Version 9.2, Chapter 4: Introduction to Part II, Section 4.2: What is an Architecture Framework?

3 : The TOGAF Standard, Version 9.2, Chapter 31: Architectural Artifacts, Section 31.1: Basic Concepts

According to the TOGAF Standard, 10th Edition, the rationale section of the architecture principles template should highlight the business benefits of adhering to the principle, as well as the business risks of not adhering to it 1. The rationale section should explain the reasoning behind the principle, and provide evidence or arguments to support it. The rationale section should also link the principle to the business drivers, goals, and objectives of the enterprise, and show how the principle contributes to the value and success of the enterprise. The other options are not correct, as they have different purposes in the architecture principles template. The name section should provide a short and memorable name for the principle, such as “Information is an Asset” or “Business Continuity” 1. The statement section should provide a concise and formal statement of the principle, such as “The enterprise’s information is recognized as a core asset, and is managed accordingly” or “The enterprise’s ability to provide critical services and products must be maintained in the event of a disaster” 1. The implications section should identify the impact of the principle on the enterprise, such as the changes, costs, benefits, and risks that may result from applying or violating the principle 1. References: 1: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles, Section 23.3 Developing Architecture Principles.

 In Phase E of the ADM cycle, building block gaps become associated with work packages that will address the gaps. This phase involves creating an Implementation and Migration Plan that defines a set of work packages and Transition Architectures that will deliver the Target Architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.5 Phase E: Opportunities & Solutions.

The TOGAF standard divides Enterprise Architecture into four primary architecture domains: business, data, application, and technology. These domains represent different aspects of an enterprise and how they relate to each other. The business domain defines the business strategy, governance, organization, and key business processes. The data domain describes the structure of the logical and physical data assets and data management resources. The application domain provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes. The technology domain describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. Other domains, such as motivation, security, or governance, may span across these four primary domains.  References :

The TOGAF Standard, Version 9.2 - Core Concepts

Domains - The Open Group

TOGAF® Standard — Introduction - Definitions - The Open Group

The TOGAF Standard, Version 9.2 - Definitions - The Open Group

TOGAF and the history of enterprise architecture | Enable Architect

In the context of TOGAF, a stakeholder is any individual, team, or organization who has interests in, or concerns relative to, the outcome of the architecture. Concerns are those interests which pertain to any aspect of the system’s functioning, development or operation, including considerations such as performance, reliability, and security1. References:

• The TOGAF Standard, Version 9.2 - Definitions - The Open Group

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-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).

References : TOGAF Version 9.1, Chapter 34:  1

According to the TOGAF Standard, 10th Edition, the Preliminary Phase of the Architecture Development Method (ADM) has the purpose to develop an Enterprise Architecture Capability 1. An Enterprise Architecture Capability is the ability of the organization to perform the activities and tasks related to Enterprise Architecture, such as defining the scope, principles, vision, governance, and stakeholders of the architecture. The Preliminary Phase also establishes the architecture framework, the architecture repository, the architecture tools, and the architecture team 1. The other options are not correct, as they have different purposes in the ADM. Phase G: Implementation Governance has the purpose to ensure that the implementation projects conform to the target architecture 2. Phase A: Architecture Vision has the purpose to define the scope, stakeholders, business drivers, and objectives of the architecture project 3. Phase B: Business Architecture has the purpose to describe the baseline and target business architecture, and to identify the gaps between them . References: 1: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 6: Preliminary Phase. 2: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 18: Phase G: Implementation Governance. 3: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 12: Phase A: Architecture Vision. : TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 13: Phase B: Business Architecture.

The objectives listed in the question correspond to the objectives of different phases of the TOGAF ADM (Architecture Development Method), which is a method for developing and managing an enterprise architecture 1 .

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

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.

Based on the above definitions, we can match each objective with the corresponding phase as follows:

Objective 1: Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision.  This objective is achieved in  Phase C: Information Systems Architectures , where the data architecture is defined as a subset of the information systems architecture 2 .

Objective 2: Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals.  This objective is achieved in  Phase B: Business Architecture , where the business architecture is defined as a subset of the enterprise architecture 3 .

Objective 3: Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture.  This objective is achieved in  Phase A: Architecture Vision , where the architecture vision is defined as a high-level description of the target architecture and its benefits 4 .

Objective 4: Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns.  This objective is achieved in  Phase C: Information Systems Architectures , where the application architecture is defined as a subset of the information systems architecture 2 .

References :

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

2 : The TOGAF Standard, Version 9.2, Chapter 9: Phase C: Information Systems Architectures

3 : The TOGAF Standard, Version 9.2, Chapter 8: Phase B: Business Architecture

4 : The TOGAF Standard, Version 9.2, Chapter 7: Phase A: Architecture Vision