Free OGEA-103 Practice Test Questions and Answers (2026)

Risk management is a generic technique that can be applied across all phases of the Architecture

Development Method (ADM), as well as in the Preliminary Phase and the Requirements

Management Phase2. Risk management involves the following steps1:

•Risk identification: This step involves identifying the potential risks that may affect the architecture

project, such as technical, business, organizational, environmental, or legal risks. The risks can be

identified through various sources, such as stakeholder interviews, workshops, surveys, checklists,

historical data, or expert judgment.

•Risk classification: This step involves categorizing the risks based on their nature, source, impact,

and priority. The risks can be classified according to different criteria, such as time, cost, scope,

quality, security, or compliance. The classification helps in prioritizing the risks and allocating

resources and efforts to address them effectively.

•Initial risk assessment: This step involves assessing the likelihood and impact of each risk, and

determining the initial level of risk. The likelihood is the probability of the risk occurring, and the

impact is the severity of the consequences if the risk occurs. The initial level of risk is the product of

the likelihood and impact, and it indicates the urgency and importance of the risk. The initial risk

assessment helps in identifying the most critical risks that need immediate attention and mitigation.

Reference: 1: The TOGAF Standard, Version 9.2 - Risk Management 2: TOGAF ADM: Top 10

techniques – Part 9: Risk Management

According to the TOGAF Standard, 10th Edition, an architecture contract is “a formal agreement

between a service provider and a service consumer that defines the mutual commitments and

expectations for the delivery of an architecture” 1. An architecture contract is a governed approach

of a particular deliverable that will ensure adherence to the principles, standards, and requirements

of the existing or developing architectures, as it specifies the roles, responsibilities, deliverables,

quality criteria, and acceptance criteria for the architecture work 1. The other options are not

correct, as they are not governed approaches of a particular deliverable, but rather different types of

deliverables within the architecture development process. An architecture vision is “a high-level,

aspirational view of the target architecture” 1. A statement of architecture work is “a document that

defines the scope and approach that will be used to complete an architecture project” 1. An

architecture definition document is “a document that describes the baseline and target architectures

for one or more domains” 1. Reference: 1: TOGAF Standard, 10th Edition, Part I: Introduction,

Chapter 3: Definitions.

In the context of the TOGAF standard, stakeholder management and addressing stakeholder

concerns are critical components, especially for high-impact initiatives like adopting an AI-first

approach. Here’s why the selected answer aligns best with TOGAF principles and the scenario:

Stakeholder Analysis and Engagement:Conducting a stakeholder analysis is essential as it helps

identify and document the concerns, issues, and cultural factors influencing each stakeholder group.

This aligns with TOGAF’s emphasis on understanding and managing stakeholder concerns,

particularly in the Preliminary and Architecture Vision phases of the ADM (Architecture Development

Method). Since the scenario highlights diverse concerns about AI, understanding each group's unique

perspective will help the EA team tailor the architecture to address these effectively.

Architecture Vision Document:By documenting these concerns in the Architecture Vision document,

the EA team can provide a clear, high-level representation of how AI will be adopted, its benefits,

and how it addresses specific stakeholder concerns. This is critical for communicating the intent and

value of the AI-first approach in a way that aligns with the agency's strategic goals, including

addressing apprehensions about job security, skill development, and cyber resilience.

Risk Management and Architecture Requirements Specification:TOGAF highlights the importance of

identifying and managing risks early in the process. By documenting the requirements related to risk

in the Architecture Requirements Specification, the EA team ensures that these concerns are

formally integrated into the architecture and addressed throughout the ADM phases. Regular

assessments and feedback loops will provide a mechanism for continual risk monitoring and

adjustment as the AI-first initiative progresses.

Alignment with TOGAF’s ADM Phases:The approach specified aligns with TOGAF’s guidance on

managing risk and stakeholder concerns during the early ADM phases, specifically Architecture

Vision and Requirements Management. In these phases, the framework emphasizes identifying and

addressing risks associated with stakeholders' concerns to build a resilient and widely accepted

architecture.

Reference to TOGAF Stakeholder Management Techniques:TOGAF’s stakeholder management

techniques underscore the importance of understanding and addressing stakeholder needs as a

foundational step. This involves assessing the influence and interest of various stakeholders and

integrating their views into architectural development, ensuring that the architecture aligns with

both business goals and operational realities.

In conclusion, by conducting a thorough stakeholder analysis and documenting concerns in both the

Architecture Vision and Architecture Requirements Specification, the EA team can ensure that

stakeholder concerns are addressed, that the architecture supports AI adoption effectively, and that

potential risks are managed proactively. This approach will foster acceptance among stakeholders

and ensure that the architecture aligns with the agency’s strategic goals and risk management

requirements as recommended by TOGAF.

When considering agile development, Architecture to Support Portfolio will identify the necessary

products for the enterprise, define their boundaries, and outline the constraints for a product owner.

This process directly relates to defining the enterprise's backlog, which in agile methodologies, is a

prioritized list of work for the development team that is derived from the roadmap and its

requirements.

:

Business scenarios are a technique recommended by the TOGAF ADM for use in developing an

Architecture Vision document12. Business scenarios are a means of capturing the business

requirements and drivers, the processes and actors involved, and the desired outcomes and

measures of success34. Business scenarios help to create a common vision and understanding

among the stakeholders, and to identify and validate the architecture requirements . Business

scenarios also provide a basis for analyzing the impact and value of the proposed architecture.

Reference:

•The TOGAF Standard, Version 9.2 - Phase A: Architecture Vision - The Open Group

•TOGAF® Standard — Introduction - Phase A: Architecture Vision

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

•Business Scenarios - The Open Group

•[The TOGAF Standard, Version 9.2 - Architecture Requirements Specification - The Open Group]

•[The TOGAF Standard, Version 9.2 - Architecture Vision - The Open Group]

•[The TOGAF Standard, Version 9.2 - Business Transformation Readiness Assessment - The Open

Group]

Enterprises are examples of the scope of an architecture according to the TOGAF Standard. An

enterprise is defined as any collection of organizations that has a common set of goals and/or asingle

bottom line. Enterprises can be whole corporations or divisions of a corporation, government

agencies or single government departments, partnerships and alliances of businesses working

together, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.1 Core

Concepts.

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

Based on the illustration, the phase of the ADM labeled as item 2 is the Implementation Governance

phase. This phase provides architectural oversight for the implementation. It ensures that the

implementation project conforms to the architecture. It also provides a framework for monitoring

and managing the implementation.

The Implementation Governance phase involves the following activities:

Finalizing the Architecture Roadmap and the supporting Implementation and Migration Plan

Assigning an Architecture Board to oversee the implementation

Establishing Architecture Contracts with the implementation partners

Reviewing and approving the implementation project plans and deliverables

Performing Architecture Compliance reviews to ensure alignment with the architecture

Performing Architecture Audit reviews to ensure quality and performance of the architecture

Resolving any architecture issues or change requests that arise during the implementation

Maintaining the architecture lifecycle and ensuring its continuity

The Implementation Governance phase is essential for ensuring that the architecture is realized as

intended and that it delivers the expected business value and outcomes.

Implementation Governance

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

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

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

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

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

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

Based on the web search results, architecture partitioning is a technique that divides the Enterprise

Architecture into smaller and manageable segments or groups, based on various classification

criteria, such as subject matter, time, maturity, volatility, etc.12 Architecture partitioning is used to

simplify the development and management of the Enterprise Architecture, by reducing complexity,

improving governance, enhancing reusability, and increasing alignment and agility12. Therefore, the

statement that partitions are used to simplify the management of the Enterprise Architecture is

correct.

The other statements are incorrect because:

•Partitions are not equivalent to architecture levels. Architecture levels are different layers of

abstraction that describe the Enterprise Architecture from different perspectives, such as strategic,

segment, and capability3. Partitions are subsets of architectures that are defined within or across the

levels, based on specific criteria1.

•Partitions do not necessarily reflect the organization’s structure. The organization’s structure is one

possible criterion for partitioning the architecture, but it is not the only one. Other criteria, such as

business function, product, service, geography, etc., can also be used to partition the architecture12.

•Partitions are not defined and assigned to agile Enterprise Architecture teams. Agile Enterprise

Architecture is an approach that applies agile principles and practices to the architecture work, such

as iterative development, frequent feedback, adaptive planning, and continuous delivery4. Partitions

are not a specific feature of agile Enterprise Architecture, but a general technique that can be applied

to any architecture method or framework, including TOGAF12.

Reference: 1: The TOGAF Standard, Version 9.2 - Architecture Partitioning 2: TOGAF® Standard —

Introduction - Architecture Partitioning 3: [The TOGAF Standard, Version 9.2 - Applying the ADM

Across the Architecture Landscape] 4: TOGAF® Standard — Introduction - Definitions - The Open

Group

Key aspects of the scenario:

Business Objective:

A merger is happening to combine offerings, reduce costs, and achieve operational efficiency.

The goal includes fully integrating retail operations and systems, replacing duplicated systems, and

reducing the number of applications used.

Technological Improvements:

A central AI-based inventory system is in place.

Hand-held devices for stores have improved customer and staff satisfaction and increased efficiency.

Scope of Architecture Work:

Integrating the merged systems.

Managing retail architecture to optimize operations.

TOGAF Alignment:

TOGAF principles aim to ensure the architecture supports business transformation effectively while

aligning with governance and best practices.

Best answer analysis:

Option 1:

Maximize Benefit to the Enterprise: Aligns with the merger goals of cost reduction and efficiency.

Common Use Applications: Matches the goal to reduce duplicated systems.

Data is an Asset: Central AI system depends on accurate and reliable data.

Responsive Change Management: Necessary to support the transition and manage organizational

impacts.

Technology Independence: Encourages selecting flexible, scalable solutions post-merger.

This option comprehensively aligns with the scenario.

Option 2:

Control Technical Diversity: Important but less emphasized than cost reduction and application

unification.

Interoperability: Relevant, but less critical compared to principles addressing business value.

Data is an Asset: Relevant.

Data is Shared: Implied in centralized inventory but not directly stated.

Business Continuity: Important but not the main focus here.

This option partially fits but lacks emphasis on business outcomes.

Option 3:

Common Vocabulary and Data Definitions: Indirectly helpful but not central to the transformation.

Compliance with the Law: Always critical, but no explicit legal issues are mentioned.

Requirements-Based Change: General principle but not transformation-specific.

Responsive Change Management: Relevant.

Data Security: Important but not a central concern in the scenario.

This option focuses more on governance and less on merger goals.

Option 4:

Common Use Applications: Relevant to reducing duplicate systems.

Data is an Asset: Relevant.

Data is Accessible: Fits with AI system and handheld devices but is a subset of "Data is an Asset."

Ease of Use: Relevant to handheld devices but not a core transformation principle.

Business Continuity: Important but secondary to cost and efficiency.

This option focuses more on usability and accessibility rather than transformation objectives.

This statement about Requirements Management is most correct because it reflects the central role

of Requirements Management and stakeholder engagement in the ADM cycle. Requirements

Management is not a step of all ADM Phases, but rather an ongoing process that ensures that all

relevant requirements are elicited, analyzed, prioritized, and addressed throughout the architecture

development and transition. Stakeholder engagement is also a continuous activity that involves

identifying, communicating, and managing stakeholder expectations and concerns. Reference: The

TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.

Building blocks are reusable components of business, IT, or architectural capability that can be

combined to deliver architectures and solutions. Building blocks can be defined at various levels of

detail, depending on the stage of architecture development. In the earlier phases of the ADM cycle

(A to D), building blocks are defined in generic terms, such as logical or physical, to provide a high-

level view of the architecture. In Phase E: Opportunities and Solutions, building blocks become

implementation-specific, meaning that they are linked to specific products,standards, technologies,

and vendors that are available in the market. This phase also identifies the delivery vehicles, such as

projects, programs, or portfolios, that will realize the building blocks12 Reference: 1: The TOGAF

Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 23: Phase E:

Opportunities and Solutions 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content

Framework, Chapter 36: Building Blocks

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.

Reference: 1: Enterprise architecture - Wikipedia 2: What is enterprise architecture? A framework for

transformation 3: 3 The Purpose of Enterprise Architecture - The Open Group

Comprehensive and Detailed Step-by-Step Explanation

Context of the Scenario

The company is in the process of delivering requested architectures to support the introduction of

digital products and services. The Business Architecture is sufficiently defined, and the focus is on

developing the Information Systems and Technology Architectures.

TOGAF emphasizes breaking down large, complex transformation programs into manageable

projects, focusing on dependencies, risks, trade-offs, and sequencing of efforts. Based on the

scenario, the company must deal with:

Data privacy and residency compliance across different regions.

Re-use of existing architecture for efficiency.

Alignment of digital services with a global roadmap.

The activity described aligns with ADM Phases B (Business Architecture), C (Information Systems

Architecture), and D (Technology Architecture), with a focus on delivering architectures for

implementation.

Option Analysis

Option A:

Strengths:

Refers to developing high-level architecture descriptions and identifying reference architectures and

candidate building blocks, which align with ADM Phases B, C, and D.

Addresses feasibility analysis, trade-offs, and stakeholder engagement, which are part of architecture

development and decision-making in TOGAF.

Ensures that the architecture descriptions are resource-conscious, including cost and value analysis,

dependencies, risks, and synergies between projects.

Conclusion: Correct, as it provides a complete approach to organizing the work to deliver

architectures while adhering to TOGAF principles.

Option B:

Strengths:

Suggests creating architecture descriptions for the Application, Data, and Technology Architectures,

which are necessary for delivering requested architectures.

Addresses readiness assessments and the fitness of solutions.

Weaknesses:

Emphasizes looking outside the company and studying other companies’ models, which is not

necessarily aligned with TOGAF unless justified by specific gaps.

Skips essential TOGAF steps like feasibility analysis and detailed stakeholder engagement.

Conclusion: Incorrect, as it places undue emphasis on external research instead of leveraging

TOGAF’s structured ADM.

Option C:

Strengths:

Suggests reviewing the Architecture Vision and determining scope, which aligns with TOGAF

principles.

Proposes preparing an Architecture Roadmap and involving the Architecture Board for review.

Weaknesses:

Does not cover important elements such as candidate building blocks, feasibility analysis, or

stakeholder engagement.

Suggests starting the project prematurely without proper sequencing or risk trade-offs.

Conclusion: Incorrect, as it skips key steps and lacks a structured approach to dependencies and

resource management.

Option D:

Strengths:

Suggests revising the Architecture Vision and conducting a Stakeholder Analysis, which aligns with

Phase A of the ADM.

Weaknesses:

Returning to Phase A is not required here, as the Architecture Vision has already been defined.

Revising the vision at this stage indicates a step backward.

Lacks focus on feasibility analysis, dependencies, and sequencing, which are the immediate needs in

this phase.

Conclusion: Incorrect, as it unnecessarily revisits earlier ADM phases instead of progressing.

TOGAF Reference

ADM Phases B, C, D: Emphasizes developing detailed architectures, identifying candidate building

blocks, and addressing dependencies, risks, and resource needs (TOGAF 9.2, Chapters 8-10).

Architecture Roadmap and Feasibility Analysis: Guides sequencing and trade-offs for implementation

(TOGAF 9.2, Section 12.4).

Stakeholder Engagement: Critical for ensuring alignment and feasibility (TOGAF 9.2, Section 24.2).

Decision-Making and Trade-offs: TOGAF emphasizes documenting risks and trade-offs as part of

feasibility analysis (TOGAF 9.2, Section 6.4.1).

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

According to the TOGAF Standard, Version 9.2, an Architecture Contract is a joint agreement

between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of

an architecture1. It defines the scope, responsibilities, and governance of the architecturework, and

ensures the alignment and compliance of the architecture with the business goals and objectives1.

In the scenario, the Lead Enterprise Architect has asked you to review the draft Architecture

Contracts and recommend the best approach to address the Chief Engineer’s concern about the

consistency and quality of the deployment of the new processes for the battery pack production at

each location.

The best answer is C, because it follows the guidelines and best practices for defining and using

Architecture Contracts as described in the TOGAF Standard, Version 9.22. It ensures that the

contracts cover the essential aspects of the project objectives, effectiveness metrics, acceptance

criteria, and risk management, and that they are legally enforceable for third-party contractors. It

also recommends a schedule of compliance reviews at key points in the implementation process, and

a mechanism for handling any deviations from the Architecture Contract, involving the Architecture

Board and the possibility of granting a dispensation to allow the process to be customized for local

needs.

The other options are not correct because they either23:

A . For changes requested by an internal team, you recommend a memorandum of understanding

between the Architecture Board and the implementation organization. For contracts issued to third-

party contractors, you recommend that it is a fully enforceable legal contract. You recommend that

the Architecture Board reviews all deviations from the Architecture Contract and considers whether

to grant a dispensation to allow the implementation organization to customize the process to meet

their local needs.: This option does not address the need to review the contracts to ensure that they

address the project objectives, effectiveness metrics, acceptance criteria, and risk management. It

also does not recommend a schedule of compliance reviews at key points in the implementation

process. Moreover, it suggests that a memorandum of understanding is sufficient for internal teams,

which may not be legally binding or enforceable.

B . For changes undertaken by internal teams, you recommend a memorandum of understanding

between the Architecture Board and the implementation organization. If a contract is issued to a

contractor, you recommend that it is a fully enforceable legal contract. If a deviation from the

Architecture Contract is found, you recommend that the Architecture Board grant a dispensation to

allow the implementation organization to customize the process to meet their local needs.: This

option has the same problems as option A, and also implies that the Architecture Board should

always grant a dispensation for any deviation, which may not be appropriate or desirable in some

cases.

D . You recommend that the Architecture Contracts be used to manage the architecture governance

processes across the locations. You recommend deployment of monitoring tools to assess the

performance of each completed battery pack at each location and develop change requirements if

necessary. If a deviation from the contract is detected, the Architecture Board should allow the

Architecture Contract to be modified meet the local needs. In such cases they should issue a new

Request for Architecture Work.: This option does not address the need to review the contracts to

ensure that they address the project objectives, effectiveness metrics,acceptance criteria, and risk

management. It also does not recommend a schedule of compliance reviews at key points in the

implementation process. Moreover, it suggests that the Architecture Board should always allow the

Architecture Contract to be modified for any deviation, which may not be appropriate or desirable in

some cases. It also implies that a new Request for Architecture Work should be issued for each

deviation, which may not be necessary or feasible.

1: The TOGAF Standard, Version 9.2, Chapter 3: Definitions and Terminology, Section 3.1: Terms and

Definitions

2: The TOGAF Standard, Version 9.2, Chapter 43: Architecture Contracts

3: The TOGAF Standard, Version 9.2, Chapter 44: Architecture Governance

The TOGAF standard covers the development of four architecture domains: Business, Data,

Technology and Application. These domains represent different aspects of an enterprise’s

architecture and provide a consistent way of describing, analyzing, and designing them. Reference:

The TOGAF® Standard | The Open Group Website, Section 2.2 Architecture Development Method

(ADM).

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.