Study Guide Notes

TOGAF® 9 Foundation
4th Edition
1. Basic Concepts........................................................................................................................6
1. Describe what an enterprise is (KLP 1.3-1)......................................................................... 6
2. Explain the purpose of an Enterprise Architecture (KLP 1.3-2)........................................... 6
3. List the business benefits of having an Enterprise Architecture (KLP 1.3-3).......................6
4. Define what an Architecture Framework is (KLP 1.3-4).......................................................6
5. Explain why the TOGAF standard is suitable as a framework for Enterprise Architecture
(KLP 1.3-5).............................................................................................................................. 6
6. Describe the structure of the TOGAF standard, and briefly explain the contents of each of
the parts (KLP 1.1-1, 1.1-2)..................................................................................................... 7
7. Briefly explain what the TOGAF standard is (KLP 2.1-1).................................................... 7
8. Explain what architecture is in the context of the TOGAF standard (KLP 2.2-1)................. 7
9. List the different types of architecture that the TOGAF standard deals with (KLP 2.3-1).... 7
10. Briefly explain the TOGAF Library (KLP 1.2-1)..................................................................7
2. Core Concepts......................................................................................................................... 8
1. The ADM: phase names and the purpose of each phase (high-level) (KLP 2.4-1)............. 8
2. The Architecture Content Framework: deliverables, artifacts, and building blocks (KLP
2.5-1, 29.1-1)........................................................................................................................... 8
3. The Enterprise Continuum (KLP 2.6-1)............................................................................... 9
4. The Architecture Repository (KLP 2.7-1)...........................................................................10
5. Establishing and maintaining an Enterprise Architecture Capability (KLP 2.8-1).............. 10
6. Establishing the Architecture Capability as an operational entity (KLP 2.9-1)...................10
7. How to use the TOGAF standard with other frameworks (KLP 2.10-1)............................. 11
3. General Definitions................................................................................................................12
4. Introduction to the ADM........................................................................................................15
1. Briefly describe the ADM cycle, and its phases (KLP 2.4-1, 4.2.2-1, -2, -3)......................15
2. Describe a typical set of steps, such as those for Phases B, C, and D (KLP 4.2.2-2).......15
3. Describe the versioning convention for deliverables used in Phases A to D (KLP 4.2.2-3)..
16
4. Briefly describe the relationship between the ADM and the Enterprise Continuum,
Architecture Repository, Foundation Architecture, and Supporting Guidelines and
Techniques (KLP 4.1-1)......................................................................................................... 17
5. Explain the purpose of the supporting guidelines and techniques, and the difference
between guidelines and techniques (KLP 4.1-2)................................................................... 17
6. Briefly describe the key points of the ADM cycle (KLP 4.2.1-1)........................................ 17
7. List the main reasons why you would need to adapt the ADM (KLP 4.3-1).......................17
8. Explain the need for the ADM process to be governed (KLP 4.4-1)..................................18
9. Describe the major information areas managed by a governance repository (KLP 4.4-2) 18
10. Briefly explain the reasons for scoping an architecture activity (KLP 4.5-1)....................18
11. List the possible dimensions for limiting the scope (KLP 4.5-2).......................................19
12. Briefly explain the need for an integration framework that sits above individual
 architectures (KLP 4.6-1).......................................................................................................19
5. Enterprise Continuum and Tools......................................................................................... 20
1. Briefly explain what the Enterprise Continuum is (KLP 35.1-1)......................................... 20
2. Explain how it is used in organizing and developing an architecture (KLP 35.2-1)........... 20
3. Explain how the Enterprise Continuum promotes re-use of architecture artifacts (KLP
35.2-2)................................................................................................................................... 20
4. Describe the constituents of the Enterprise Continuum (KLP 35.3-1)............................... 21
5. Explain the purpose of the Enterprise Continuum (KLP 35.3-2)........................................21
6. Explain the purpose of the Architecture Continuum (KLP 35.4-3)..................................... 21
7. List the stages of architecture evolution defined in the Architecture Continuum (KLP
35.4-4)................................................................................................................................... 22
8. Explain the purpose of the Solutions Continuum (KLP 35.4-6)......................................... 22
9. List the stages of architecture evolution defined in the Solutions Continuum (KLP 35.4-7)..
22
10. Explain the relationship between the Enterprise Continuum and the ADM (KLP 35.5-1)23
11. Describe the Architecture Repository (KLP 37-1)............................................................ 23
12. Explain the relationship between the Enterprise Continuum and the Architecture
Repository (KLP 35.1-2, 37.1-2)............................................................................................ 24
13. Describe the classes of information held in the Architecture Repository (KLP 37.1-2)... 24
14. List the three levels of the Architecture Landscape (KLP 37.2-1)....................................25
15. Explain the purpose of the Standards Information Base within the Architecture
Repository (KLP 37.4-1)........................................................................................................ 25
6. ADM Phases (Level 1)........................................................................................................... 26
Preliminary Phase..................................................................................................................26
1. Describe the main objectives of the phase (KLP 5.1-1).....................................................26
2. Briefly explain the seven aspects of the approach undertaken in this phase (KLP 5.5-1).26
Phase A: Architecture Vision................................................................................................. 27
Phase B: Business Architecture............................................................................................ 27
Phase C: Information Systems Architecture.......................................................................... 28
Phase D: Technology Architecture.........................................................................................29
Phase E................................................................................................................................. 29
Phase F: Migration Planning.................................................................................................30
Phase G.................................................................................................................................30
Phase H................................................................................................................................. 30
ADM Architecture Requirements Management..................................................................... 32
7. ADM Guidelines and Techniques......................................................................................... 33
1. Briefly explain the contents of Part III, ADM Guidelines and Techniques (KLP 17.1-1).....33
2. Briefly explain the need for Architecture Principles and where they are used within the
TOGAF ADM (KLP 20.1-1).................................................................................................... 33
3. Describe the recommended template for Architecture Principles (KLP 20.3-1)................ 33
4. Explain what makes a good Architecture Principle (KLP 20.4-2)...................................... 33
5. Understand what a Business Scenario is and its purpose (KLP BS.1-1).......................... 34
 6. Explain where Business Scenarios are used within the ADM cycle (KLP BS.1-2)............ 34
7. Explain the purpose of Gap Analysis (KLP 23.2-1)........................................................... 34
8. Describe the Gap Analysis technique (KLP 23.2-1).......................................................... 35
9. Explain the term interoperability (KLP 25.2-1)................................................................... 35
10. Understand the use of Interoperability Requirements within the TOGAF ADM (KLP
25.1-1)................................................................................................................................... 35
11. Understand Business Transformation Readiness Assessment (KLP 26.1-2)..................36
12. Understand where Business Transformation Readiness Assessment is used within the
ADM (KLP 26.1-1)................................................................................................................. 36
13. Understand the characteristics of Risk Management (KLP 27.1-2).................................36
14. Understand where Risk Management is used within the TOGAF ADM (KLP 27.1-1)..... 36
15. Understand Capability-Based Planning (KLP 28.1-1)......................................................37
16. Briefly explain the use of the TOGAF ADM in the context of a specific architectural style
(KLP 17.3-1).......................................................................................................................... 37
8. Architecture Governance (Level 1)...................................................................................... 38
1. Briefly explain the concept of Architecture Governance (KLP 44.1-1)...............................38
2. Describe the main concepts that make up an Architecture Governance framework (KLP
44.2-1)................................................................................................................................... 38
3. Explain why Architecture Governance is beneficial (KLP 44.3-1)......................................38
4. Briefly explain the need for establishment of an Architecture Board (KLP 41.1-1)............38
5. List the responsibilities of an Architecture Board (KLP 41.2-1)......................................... 39
6. Briefly explain the role of Architecture Contracts (KLP 43.1-1)......................................... 39
7. Briefly explain the meaning of Architecture Compliance (KLP 42.2-1).............................. 40
8. Briefly explain the need for Architecture Compliance (KLP 42.1-1)...................................40
9. Briefly explain the purpose of Architecture Compliance Reviews (KLP 42.3-1)................ 41
10. Briefly describe the Architecture Compliance Review process (KLP 42.4-1).................. 41
11. Briefly explain how the ADM can be used to establish an Architecture Capability (KLP
40.1-1)................................................................................................................................... 42
9. Architecture Views, Architecture Viewpoints, and Stakeholders..................................... 43
1. Define and explain the following key concepts (KLP 31.1-1):............................................43
o Stakeholders.......................................................................................................................43
o Concerns............................................................................................................................ 43
o Architecture Views.............................................................................................................. 43
o Architecture Viewpoints...................................................................................................... 43
2. Describe a simple example of an architecture viewpoint and view (KLP 31.1-2).............. 43
3. Discuss the relationship between stakeholders, concerns, views, and viewpoints (KLP
31.1-3)................................................................................................................................... 44
4. Describe the architecture view creation process (KLP 31.2-1)..........................................44
10. Building Blocks....................................................................................................................45
1. Define what a building block is, and explain what makes a good building block (KLP
33.2-1)................................................................................................................................... 45
2. Explain the distinction between Architecture Building Blocks and Solution Building Blocks
 (KLP 33.2-2).......................................................................................................................... 45
3. Briefly explain the use of building blocks in the ADM cycle (KLP 33.3-1)..........................46
4. Describe the characteristics of an Architecture Pattern (KLP 22.1-1)............................... 47
11. ADM Deliverables.................................................................................................................49
1. Briefly explain the role of architecture deliverables across the ADM cycle (KLP 32.1-1).. 49
2. Briefly explain the purpose of the following deliverables (KLP 32.2-1):.............................50
o Architecture Building Blocks............................................................................................... 50
o Architecture Contract.......................................................................................................... 50
o Architecture Definition Document....................................................................................... 50
o Architecture Principles........................................................................................................ 50
o Architecture Repository...................................................................................................... 50
o Architecture Requirements Specification............................................................................50
o Architecture Roadmap........................................................................................................ 50
o Architecture Vision.............................................................................................................. 50
o Business Principles, Business Goals, and Business Drivers..............................................50
o Capability Assessment....................................................................................................... 50
o Change Request.................................................................................................................50
o Communications Plan.........................................................................................................50
o Compliance Assessment.................................................................................................... 50
o Implementation and Migration Plan.................................................................................... 50
o Implementation Governance Model....................................................................................51
o Organizational Model for Enterprise Architecture............................................................... 51
o Request for Architecture Work............................................................................................51
o Requirements Impact Assessment..................................................................................... 51
o Solution Building Blocks..................................................................................................... 51
o Statement of Architecture Work.......................................................................................... 51
o Tailored Architecture Framework........................................................................................ 51
12. TOGAF Reference Models (Level 1)...................................................................................54
1. Explain the role of the TRM as a Foundation Architecture (KLP TRM.2-1)....................... 54
2. Describe at a high level the main components of the TOGAF TRM (KLP TRM.4-1).........54
3. Briefly explain the basic concepts of the III-RM (KLP IIIRM.1-1).......................................55
4. Briefly explain the relationship of the III-RM to the concept of Boundaryless Information
Flow (KLP IIIRM.1-2)............................................................................................................. 55
1. Basic Concepts

1. Describe what an enterprise is (KLP 1.3-1)

Any collection of organizations that have common goals. A part of organization, a part of org
and its vendors or supply chain or customers.

2. Explain the purpose of an Enterprise Architecture (KLP 1.3-2)

Enterprise Architecture aims to integrate and optimize fragmented processes (manual and
automated) across an organization to support business strategy and adapt to change. Effective
management of information and digital transformation is crucial for business success and
gaining a competitive advantage. Enterprise Architecture provides a strategic context for
achieving these goals.

3. List the business benefits of having an Enterprise Architecture

(KLP 1.3-3)
A. More effective and efficient business operations
B. More effective and efficient Digital Transformation and IT operations
C. Better return on existing investment, reduced risk for future investment
D. Faster, simpler, and cheaper procurement

4. Define what an Architecture Framework is (KLP 1.3-4)

An architecture framework is a structure that helps create different architectures. It should
provide a method for designing the enterprise's target state using building blocks and show how
they fit together. The framework should also have tools and a common vocabulary and
recommend standards and products to use.

5. Explain why the TOGAF standard is suitable as a framework

for Enterprise Architecture (KLP 1.3-5)
TOGAF is a standard that helps architects create consistent and effective enterprise
architecture that meets the needs of stakeholders. It is a framework that reduces risk in the
architecture development process, and helps organizations build practical and cost-effective
solutions to their business problems.
+ Current and target architecture plus future needs
+ Considering stakeholders
+ Cost-effective solution
6. Describe the structure of the TOGAF standard, and briefly
explain the contents of each of the parts (KLP 1.1-1, 1.1-2)
1- Architecture Capability Framework
2- Architecture Development Method
a. ADM Guidelines and Techniques (TOGAF Library)
3- Architecture Content Framework
4- Enterprise Continuum and Tools
a. TOGAF Reference Materials (TOGAF Library)

7. Briefly explain what the TOGAF standard is (KLP 2.1-1)

TOGAF is an architecture framework developed by The Open Group Architecture Forum that
provides methods and tools for creating and maintaining Enterprise Architectures. It is based on
an iterative process model and can be used in conjunction with other frameworks. The TOGAF
Architecture Development Method (ADM) is a key component for developing an Enterprise
Architecture that addresses business needs.

8. Explain what architecture is in the context of the TOGAF

standard (KLP 2.2-1)
ISO: The fundamental concepts or properties of a system in its environment embodied in its
elements, relationships, and in the principles of its design and evolution

TOGAF: The structure of components, their inter-relationships, and the principles and guidelines
governing their design and evolution over time.

9. List the different types of architecture that the TOGAF standard

deals with (KLP 2.3-1)
BDAT: Business, Data, Application, and Technology Architecture

10. Briefly explain the TOGAF Library (KLP 1.2-1)

A reference library containing guidelines, templates, patterns, and other forms of reference
material to accelerate the creation of new architectures for the enterprise.
 2. Core Concepts

1. The ADM: phase names and the purpose of each phase

(high-level) (KLP 2.4-1)

TOGAF PHASE DESCRIPTION

Describes the preparation and initiation activities required to create an Architecture
Capability, including the customization of the TOGAF framework, and the definition of
Preliminary Phase Architecture Principles.
Describes the initial phase of an Architecture Development Cycle. It includes
Phase A: Architecture information about defining the scope, identifying the stakeholders, creating the
Vision Architecture Vision, and obtaining approvals.
Phase B: Business Describes the development of a Business Architecture to support an agreed
Architecture Architecture Vision.
Phase C: Information Describes the development of Information Systems Architectures for an architecture
Systems Architectures project, including the development of Data and Application Architectures.
Phase D: Technology
Architecture Describes the development of the Technology Architecture for an architecture project.
Phase E: Opportunities and Describes the process of identifying major implementation projects and grouping them
Solutions into work packages that deliver the Target Architecture defined in the previous phases.
Describes the development of a detailed Implementation and Migration Plan that
Phase F: Migration Planning addresses how to move from the Baseline to the Target Architecture.
Phase G: Implementation
Governance Provides an architectural oversight of the implementation.
Phase H: Architecture
Change Management Establishes procedures for managing change to the new architecture.
Requirements
Management Examines the process of managing architecture requirements throughout the ADM.

2. The Architecture Content Framework: deliverables, artifacts,

and building blocks (KLP 2.5-1, 29.1-1)

CONCEPT DEFINITION
Work products that are specified in contracts and reviewed, agreed upon, and signed off by
stakeholders. They represent the output of projects and may be archived or transitioned to an
Deliverables Architecture Repository as a reference model, standard, or snapshot of the Architecture
 Landscape at a point in time.
Work products that describe an aspect of the architecture. They are generally classified as
catalogs, matrices, or diagrams and may include a requirements catalog, business interaction
matrix, or use-case diagram. Artifacts form the content of the Architecture Repository and may
Artifacts be included in architectural deliverables.
(Potentially re-usable) components of business, IT, or architectural capability that can be
combined with other building blocks to deliver architectures and solutions. They can be
defined at various levels of detail and can relate to both architectures and solutions.
Architecture Building Blocks (ABBs) typically describe the required capability to shape Solution
Building Blocks (SBBs), which represent the components used to implement the required
Building capability. Building blocks may accelerate the development of new solutions by providing
Blocks modular and interoperable components.

3. The Enterprise Continuum (KLP 2.6-1)

The Enterprise Continuum in the TOGAF standard provides a context for architects to leverage
generic solutions and specialize them to support individual organizational requirements. It
includes the Architecture Continuum and the Solutions Continuum, which classify architecture
and solution artifacts as they evolve from generic Foundation Architectures to
 Organization-Specific Architectures. The Enterprise Continuum is a view of the Architecture
Repository.

4. The Architecture Repository (KLP 2.7-1)

The TOGAF standard includes the concept of an Architecture Repository that stores different
levels of abstraction of architectural output created by the ADM. This supports the Enterprise
Continuum and facilitates communication and collaboration between stakeholders and
practitioners at different levels.

5. Establishing and maintaining an Enterprise Architecture

Capability (KLP 2.8-1)

CHAPTER DESCRIPTION
Establishing an Architecture Guidelines for establishing an Architecture Capability within an
Capability organization.
Guidelines for establishing and operating an enterprise Architecture
Architecture Board Board.
Architecture Compliance Guidelines for ensuring project compliance to architecture.
Architecture Contracts Guidelines for defining and using Architecture Contracts.
Architecture Governance Framework and guidelines for Architecture Governance.
Architecture Maturity Techniques for evaluating and quantifying an organization's maturity in
Models Enterprise Architecture.
Architecture Skills A set of role, skill, and experience norms for staff undertaking Enterprise
Framework Architecture work.

6. Establishing the Architecture Capability as an operational entity

(KLP 2.9-1)
An enterprise architecture practice should be treated like a business and establish capabilities in
financial, performance, service, risk, resource, communications, quality, supplier, configuration,
and environment management. Architecture Governance is essential for controlling and aligning
architecturally significant activity within a single framework. Its benefits include increased
transparency, controlled risk management, protection of existing assets, process and
component re-use, value creation, increased visibility, greater shareholder value, and integration
with existing processes and methodologies.
Overall, an enterprise architecture practice should operate with well-defined and effective
governance to ensure its success and contribute to the organization's overall success. The
practice's capabilities and governance provide benefits such as increased transparency, value
creation, and integration with existing processes and methodologies.

7. How to use the TOGAF standard with other frameworks (KLP

2.10-1)
The TOGAF standard provides a flexible and extensible content framework for architecture
deliverables that can be adapted and built upon by architects to define a tailored method that
integrates with enterprise processes and structures. It can be used in conjunction with other
frameworks and reference materials.
 3. General Definitions

# TERM DEFINITION
A description of the structure and behavior of applications used in an
1 Application Architecture organization.
A set of principles or guidelines for designing and building software or IT
2 Architectural Style systems.
The fundamental organization of a system, including its components,
3 Architecture relationships, and principles.
Architecture Building A reusable component of an architecture that can be combined with other
4 Block (ABB) building blocks to create a complete system.
A framework for categorizing and organizing architecture artifacts based on
5 Architecture Continuum their level of abstraction and scope.
Architecture Development A step-by-step process for developing and implementing an enterprise
6 Method (ADM) architecture.
A specific area or aspect of an enterprise architecture, such as business, data,
7 Architecture Domain application, or technology.
A set of principles, standards, and practices for creating and using enterprise
8 Architecture Framework architectures.
The process of managing and overseeing the development, implementation, and
9 Architecture Governance maintenance of an enterprise architecture.
A fundamental guideline or rule that influences the design and development of
10 Architecture Principle an enterprise architecture.
A representation of an architecture that focuses on a specific aspect or
11 Architecture View stakeholder perspective.
12 Architecture Viewpoint A set of guidelines for creating and using architecture views.
13 Architecture Vision A high-level description of the desired future state of an enterprise architecture.
A tangible or intangible object produced or used in the development of an
14 Artifact enterprise architecture.
A snapshot of the current state of an enterprise architecture used as a basis for
15 Baseline comparison and analysis.
A modular component of an enterprise architecture that can be combined with
16 Building Block other building blocks to create a complete system.
A description of the structure and behavior of a business, including its processes,
17 Business Architecture capabilities, and organizational structure.
 A specific ability or capacity that a business possesses to achieve its goals and
18 Business Capability objectives.
The process of managing and overseeing the business operations and
19 Business Governance decision-making processes of an organization.
A specific ability or capacity that an enterprise possesses to achieve its goals and
20 Capability objectives.
A specific area of interest or focus in an enterprise architecture, such as
21 Concern performance, security, or usability.
22 Course of Action A specific plan or strategy for achieving a particular goal or objective.
A description of the structure and behavior of an organization's data assets and
23 Data Architecture how they are used.
A tangible or intangible object produced or used in the development of an
24 Deliverable enterprise architecture, such as a report or diagram.
A complex system or organization made up of multiple components and
25 Enterprise stakeholders.
A core set of building blocks and principles that form the basis of an enterprise
26 Foundation Architecture architecture.
A difference or deficiency between the current state and desired future state of
27 Gap an enterprise architecture.
The process of managing and overseeing the operations and decision-making
28 Governance processes of an organization.
29 Information Data that has been processed or interpreted in a meaningful way.
Information Technology
30 (IT) The use of technology to process, store, and transmit information.
Referring to the structure and behavior of a system at a conceptual or abstract
31 Logical level.
32 Metadata Data that describes other data, such as the structure or format of a file.
33 Metamodel A model that defines the structure and behavior of other models.
34 Method A specific process or approach used to achieve a particular goal or objective.
35 Modeling The process of creating a representation of a system or concept using a model.
36 Objective A specific goal or target that an enterprise is working to achieve.
Referring to the actual hardware and software components of a system or
37 Physical application.
38 Reference Model (RM) A standardized model or framework used as a basis for comparison or analysis.
39 Repository A centralized location for storing and managing enterprise architecture artifacts
 and information.
A specific need or objective that must be met by an enterprise architecture or
40 Requirement system.
41 Service A specific function or capability provided by an IT system or application.
42 Solution Architecture A description of the structure and behavior of a specific IT solution or system.
Solution Building Block A reusable component of a solution architecture that can be combined with
43 (SBB) other building blocks to create a complete solution.
A person or group with a vested interest or concern in the development and
44 Stakeholder implementation of an enterprise architecture.
A description of the long-term goals and objectives of an enterprise, including its
45 Strategic Architecture vision and mission.
46 Target Architecture A description of the desired future state of an enterprise architecture.
A description of the structure and behavior of an organization's technology
47 Technology Architecture assets and how they are used.
A description of the intermediate steps or phases involved in transitioning from
48 Transition Architecture the current state to the desired future state of an enterprise architecture.
49 Value Stream A sequence of activities or steps that add value to a product or service.
A collection of architecture viewpoints and guidelines used in the development
50 Viewpoint Library and implementation of an enterprise architecture.
4. Introduction to the ADM

1. Briefly describe the ADM cycle, and its phases (KLP 2.4-1,
4.2.2-1, -2, -3)
The ADM (Architecture Development Method) cycle is the core of the TOGAF framework. It is a
step-by-step approach to developing and implementing an enterprise architecture. The ADM
cycle consists of nine phases, which are as follows:

1. Preliminary Phase: Prepare the organization for successful TOGAF architecture

projects. Undertake the preparation and initiation activities required to create an
Architecture Capability, including the customization of the TOGAF framework, selection
of tools, and the definition of Architecture Principles.
2. Architecture Vision: In this phase, the organization's business drivers, goals, and
objectives are defined, and an architecture vision is created.
3. Business Architecture: In this phase, the organization's business processes,
organization structure, and capabilities are defined.
4. Information Systems Architecture: In this phase, the organization's information
systems are defined and aligned with the business architecture.
5. Technology Architecture: In this phase, the organization's technology infrastructure is
defined and aligned with the business and information systems architectures.
6. Opportunities and Solutions: In this phase, potential projects or initiatives are
identified to address gaps in the current architecture.
7. Migration Planning: In this phase, the roadmap for implementing the architecture is
created, including prioritizing projects and defining timelines.
8. Implementation Governance: In this phase, the implementation of the architecture is
managed and monitored to ensure that it remains aligned with the vision.
9. Architecture Change Management: In this phase, changes to the architecture are
managed and tracked to ensure that they are properly implemented and documented.
10. Architecture Requirements Management: In this phase, the ongoing requirements for
the architecture are managed and updated to ensure that it remains relevant and
effective.

2. Describe a typical set of steps, such as those for Phases B, C,

and D (KLP 4.2.2-2)
In Phase B, the architecture vision is developed, while in Phase C, the architecture is designed
and refined. Phase D involves developing a roadmap for implementation. A typical set of steps
for these phases includes defining requirements, creating architecture models, and evaluating
alternatives.
Phases B, C, and D of the ADM cycle are part of the core of the architecture development
process. Here are the typical steps involved in each of these phases:
Phase B: Business Architecture
● Define the business architecture scope and objectives.
● Identify the key stakeholders and their needs.
● Define the business functions and processes.
● Define the organization structure and roles.
● Define the business information requirements.
● Develop a gap analysis to identify the current state and future state of the business
architecture.
Phase C: Information Systems Architecture
● Develop a high-level architecture vision and roadmap.
● Define the information systems architecture scope and objectives.
● Develop an inventory of the existing information systems.
● Define the information systems architecture components.
● Define the data architecture, including data entities, data attributes, and data
relationships.
● Develop a gap analysis to identify the current state and future state of the information
systems architecture.
Phase D: Technology Architecture
● Define the technology architecture scope and objectives.
● Develop a high-level architecture vision and roadmap.
● Identify the key technology components.
● Define the technology standards and principles.
● Develop a technology architecture model, including the hardware, software, and network
infrastructure.
● Develop a gap analysis to identify the current state and future state of the technology
architecture.
Overall, these phases involve defining and aligning the organization's business, information
systems, and technology architectures, and developing a roadmap for implementing the
architecture to achieve the organization's goals and objectives.

3. Describe the versioning convention for deliverables used in

Phases A to D (KLP 4.2.2-3)
TOGAF recommends using a versioning convention for deliverables in Phases A to D. The
convention consists of a version number and a date to indicate the maturity of the deliverable
and the date on which it was last updated.
For example, a deliverable in Phase B, the Business Architecture phase, may be named
"Business Architecture - Version 1.0 - January 2022". This indicates that the deliverable is the
first version of the Business Architecture document and was last updated in January 2022.
4. Briefly describe the relationship between the ADM and the
Enterprise Continuum, Architecture Repository, Foundation
Architecture, and Supporting Guidelines and Techniques (KLP
4.1-1)
The ADM is closely related to the Enterprise Continuum, which provides a framework for
organizing architecture artifacts. The Architecture Repository is a central location for storing and
managing architecture artifacts, while the Foundation Architecture provides a starting point for
creating an enterprise architecture. Supporting Guidelines and Techniques provide detailed
guidance for specific aspects of the ADM process.

5. Explain the purpose of the supporting guidelines and

techniques, and the difference between guidelines and
techniques (KLP 4.1-2)
Supporting Guidelines and Techniques provide detailed guidance on how to perform specific
tasks within the ADM. Guidelines provide recommendations, while Techniques provide
step-by-step instructions.

6. Briefly describe the key points of the ADM cycle (KLP 4.2.1-1)
The TOGAF ADM is an iterative process that requires making decisions regarding enterprise
coverage, level of detail, time period, and architecture asset re-use. The scope of activity is
determined by the organization and should focus on creating value for the enterprise. Future
iterations build on the current effort, adding greater width and depth. The ADM can be tailored to
meet the needs of the organization, including omitting or modifying phases or adding additional
procedures. Competence and resource availability should guide decision-making.

7. List the main reasons why you would need to adapt the ADM
(KLP 4.3-1)
The main reasons for adapting the ADM include the need to customize the process to fit an
organization's specific needs, to address changes in technology or business needs, or to
improve the efficiency and effectiveness of the process.

The ADM is a versatile method for architecture development that can be applied to most system
and organizational requirements. However, it may be necessary to modify or extend the ADM to
suit specific needs. This can be done by reviewing the process and its outputs for applicability
and tailoring them to the circumstances of the individual enterprise. There are several reasons
for wanting to tailor the ADM, such as the maturity of the architecture discipline within the
enterprise, the enterprise's business and architecture principles, the use of other enterprise
architecture frameworks, corporate governance requirements, outsourcing situations, resource
constraints, and complex, federated enterprises. The ADM process can also be adapted to deal
with different use scenarios, such as iteration and specialist architectures like security.

1. The order of ADM phases depends on architecture maturity

2. Business and Architecture Principles can define ADM phase order
3. ADM can be tailored to work with other architecture frameworks
4. ADM is part of corporate governance and must reflect other management processes
5. ADM may need to be tailored for outsourcing situations
6. Small-to-medium enterprises may use a simplified version of ADM
7. Large, complex enterprises require a more federated approach to ADM.

8. Explain the need for the ADM process to be governed (KLP

4.4-1)
● ADM is a key process that must be managed and governed
● ADM can be adapted or used as documented in TOGAF
● Architecture Board must ensure correct application of ADM across all phases
● Compliance with ADM is fundamental to architecture governance
● ADM ensures all considerations are made and all required deliverables are produced.

9. Describe the major information areas managed by a

governance repository (KLP 4.4-2)
A governance repository manages information related to the ADM process, including
architecture artifacts, governance policies, and procedures, and performance metrics. It
provides a centralized location for managing and tracking the ADM process.
● A controlled environment should support the management of all architectural artifacts,
governance, and related processes
● Repositories should support versioned object and process control and status
● Reference Data should be included in the repositories for guidance and instruction
during project implementation
● Process Status should be recorded to track the state of governance processes, such as
compliance requests and assessments
● Audit Information should be recorded to support key decisions and serve as a reference
for future architectural and process developments.

10. Briefly explain the reasons for scoping an architecture activity

(KLP 4.5-1)
● The scope of architectural activity can be constrained or restricted for various reasons
 ● These reasons include limits in organizational authority, objectives, and stakeholder
concerns
● Availability of people, finance, and other resources can also limit scope
● The chosen scope is directly dependent on available resources
● Feasibility is usually the final determining factor in selecting the scope.

11. List the possible dimensions for limiting the scope (KLP 4.5-2)
There are several dimensions that can be used to limit the scope of an architecture activity,
including business units, geographic locations, applications, data, and infrastructure. The scope
can also be limited based on time, budget, or specific business goals. The dimensions for
limiting the scope should be chosen based on the organization's specific needs and objectives.

DIMENSION CONSIDERATIONS
- Enterprise extent
- Fuzzy boundaries
Breadth - Federation of organizational units
- Appropriate level of detail
Depth - Demarcation between architecture and other activities
- Articulation of time period
- Practicality and resource considerations
Time period - Number of Transition Architectures
- All four architecture domains (Business, Data, Application, Technology)
Architecture domains - Resource and time constraints may limit top-down approach

12. Briefly explain the need for an integration framework that sits
above individual architectures (KLP 4.6-1)
Architectures created to address a subset of issues within an enterprise need a consistent
frame of reference to be considered as a group and as individual deliverables. The dimensions
used to define the scope of a single architecture, such as level of detail and architecture
domain, are the same dimensions that must be addressed when integrating multiple
architectures.

An integration framework that sits above individual architectures is necessary to ensure that the
different architecture domains are aligned and integrated. The framework provides a common
language, methodology, and set of standards for integrating architectures across the enterprise.
It enables the organization to manage complexity, reduce duplication, and ensure consistency.
The integration framework should be designed to support the organization's business goals and
objectives, and should be flexible enough to accommodate changes in technology and business
needs.
5. Enterprise Continuum and Tools

1. Briefly explain what the Enterprise Continuum is (KLP 35.1-1)

The Enterprise Continuum is a system that helps organize different plans and ideas for a
company's structure. It starts with general ideas and gets more specific to fit the company's
needs.

2. Explain how it is used in organizing and developing an

architecture (KLP 35.2-1)
it can be used to:

● The Enterprise Continuum enables architects to articulate the broad perspective of

enterprise architecture.
● The Enterprise Continuum is an important aid to communication and understanding, both
within and between organizations.
● Without an understanding of the Enterprise Continuum, people discussing architecture
can often talk at cross-purposes.
● It helps to understand where in the continuum you are

3. Explain how the Enterprise Continuum promotes re-use of

architecture artifacts (KLP 35.2-2)
The Enterprise Continuum promotes the re-use of architecture artifacts by providing a common
language and framework for describing and categorizing them. This makes it easier for
architects to find and re-use existing artifacts that are relevant to their current project.

For example, an architect working on a new project can refer to the Architecture Content
Framework to identify relevant building blocks that have already been developed and used in
previous projects. This can save time and effort in developing new artifacts from scratch.

Similarly, an architect can refer to the Architecture Reference Models to identify pre-defined
architectures that can be used as a starting point for their project. This can help ensure
consistency and alignment with the organization's overall architecture vision and strategy.

Overall, the Enterprise Continuum provides a structured approach to organizing and

categorizing architecture artifacts, which promotes re-use and reduces redundancy.
4. Describe the constituents of the Enterprise Continuum (KLP
35.3-1)
● The Enterprise Continuum
● The Architecture Continuum
● The Solutions Continuum

5. Explain the purpose of the Enterprise Continuum (KLP 35.3-2)

The purpose of the Enterprise Continuum is to provide a structured approach to organizing and
classifying architecture artifacts within an organization. It helps to ensure that all necessary
architecture artifacts are developed in a consistent and aligned manner, and that the
architecture is developed in accordance with the organization's overall business strategy and
goals.

The Enterprise Continuum is designed to help enterprise architects manage the complexity of
developing and implementing an enterprise architecture. It provides a framework for organizing
architecture artifacts into four levels: the Architecture Development Method (ADM), the
Architecture Content Framework, the Architecture Reference Models (ARMs), and the Solutions
Continuum.

The Enterprise Continuum helps to promote the re-use of architecture artifacts by providing a
common language and framework for describing and categorizing them. This makes it easier for
architects to find and re-use existing artifacts that are relevant to their current project, which can
save time and effort in developing new artifacts from scratch.

Overall, the Enterprise Continuum is an essential tool for enterprise architects who are
responsible for developing and implementing an enterprise architecture. It provides a structured
approach that helps ensure consistency and alignment with the organization's overall
architecture vision and strategy.

6. Explain the purpose of the Architecture Continuum (KLP

35.4-3)
● The Architecture Continuum defines and understands generic rules, representations,
and relationships in an architecture
● It includes traceability and derivation relationships
● The Architecture Continuum structures Architecture Building Blocks (ABBs), which are
re-usable architecture assets
● ABBs evolve through their development lifecycle from abstract and generic entities to
fully expressed Organization-Specific Architecture assets
 ● The Architecture Continuum assets guide and select the elements in the Solutions
Continuum
● The Architecture Continuum shows relationships among foundational frameworks,
Common Systems Architectures, Industry Architectures, and Enterprise Architectures
● It helps to discover commonality and eliminate unnecessary redundancy

7. List the stages of architecture evolution defined in the

Architecture Continuum (KLP 35.4-4)

8. Explain the purpose of the Solutions Continuum (KLP 35.4-6)

The Solutions Continuum is a framework that provides a structured approach to organizing and
classifying architecture solutions within an organization. It helps to ensure that all necessary
architecture solutions are developed in a consistent and aligned manner, and that the solutions
are developed in accordance with the organization's overall business strategy and goals.

9. List the stages of architecture evolution defined in the Solutions

Continuum (KLP 35.4-7)
The Solutions Continuum has four levels:

10. Explain the relationship between the Enterprise Continuum

and the ADM (KLP 35.5-1)
The TOGAF ADM describes the process of developing an enterprise-specific architecture and
solution while adopting and adapting generic architectures and solutions. Specific architectures
and solutions that prove to be credible and effective will be generalized for re-use. The
Enterprise Continuum provides a framework for organizing and classifying architecture artifacts,
and the TOGAF ADM points to useful architecture assets at the relevant level of generality in
the continuum classification. The TOGAF Library provides reference models for consideration
for use in developing an Organization-Specific Architecture.
 11. Describe the Architecture Repository (KLP 37-1)
Operating a mature Architecture Capability within a large enterprise generates a lot of
architectural output. To effectively manage and leverage these outputs, a formal taxonomy for
different types of architectural asset is required, along with dedicated processes and tools for
storing architectural content. The TOGAF standard provides a structural framework for an
Architecture Repository that allows enterprises to distinguish between different types of
architectural assets at different levels of abstraction. The Architecture Repository is part of the
wider Enterprise Repository, which links architectural assets to components of the Detailed
Design, Deployment, and Service Management Repositories.

12. Explain the relationship between the Enterprise Continuum

and the Architecture Repository (KLP 35.1-2, 37.1-2)
The Architecture Repository is a conceptual model that describes the structure and content of
the repository used to store and manage architecture artifacts within an organization. It provides
a framework for organizing and categorizing architecture artifacts according to the Enterprise
Continuum.

In other words, the Architecture Repository is a physical instance of the Enterprise Continuum,
where actual architecture artifacts are stored and managed in a structured manner. The
Enterprise Continuum provides the conceptual framework for organizing these artifacts, while
the Architecture Repository provides the physical infrastructure to store and manage them.

13. Describe the classes of information held in the Architecture

Repository (KLP 37.1-2)

ITEM DESCRIPTION
This item describes how to tailor an architecture framework to a specific
Architecture organization's needs. It includes a method for developing the architecture and a
Metamodel metamodel for the architecture content.
Architecture This item outlines the rules, structures, and processes that govern the
Capability Architecture Repository.
Architecture This item provides a visual representation of the assets being used or planned by
Landscape the organization at specific points in time.
Standards This item captures the standards that new architectures must comply with. These
Information may include industry standards, products and services from suppliers, or existing
Base shared services within the organization.
 Reference This item provides guidelines, templates, patterns, and other reference materials
Library that can help accelerate the creation of new architectures for the organization.
Governance
Log This item keeps a record of governance activity across the organization.
Architecture
Requirements This item shows all authorized architecture requirements that the Architecture
Repository Board has agreed upon.
This item provides a visual representation of the Solution Building Blocks (SBBs)
Solutions that support the Architecture Landscape and have been planned or deployed by
Landscape the organization.

14. List the three levels of the Architecture Landscape (KLP

37.2-1)

GRANULARITY DESCRIPTION
gives a general, big-picture view of the entire enterprise over a long period of time.
Strategic This level helps executives and decision-makers set the direction for the enterprise
Architectures and organize activities for change.
Segment provides more detailed models of specific areas within the enterprise. This level helps
Architectures align and organize more detailed change activity at the program or portfolio level.
Show in detail how the enterprise can support a particular unit of capability. They
provide an overview of current capability, target capability, and capability increments,
Capability and allow for individual work packages and projects to be grouped within managed
Architectures portfolios and programs.

15. Explain the purpose of the Standards Information Base within

the Architecture Repository (KLP 37.4-1)
The Standards Information Base is a place where the standards and specifications that
architectures must follow are stored. This helps provide clear guidelines for architectural
governance. It allows projects to easily access the standards and plan for their obligations, and
the standards are stated in a clear and unambiguous way so that compliance can be objectively
assessed.
 6. ADM Phases (Level 1)

Preliminary Phase

1. Describe the main objectives of the phase (KLP 5.1-1)

● Determine the Architecture Capability desired by the organization: Why conduct E,
Scope, frameworks, how much resources are needed.
● Establish the Architecture Capability: detailed processes, resources,governance tools
etc.

2. Briefly explain the seven aspects of the approach undertaken in

this phase (KLP 5.5-1)
● Defining the enterprise
● Identifying key drivers and elements in the organizational context
● Defining the requirements for architecture work
● Defining the Architecture Principles that will inform any architecture
● work
● Defining the framework to be used
● Defining the relationships between management frameworks
● Evaluating the Enterprise Architecture maturity

ASPECT DESCRIPTION
defining the organization's scope, structure, and operating model, as
Defining the enterprise well as identifying its stakeholders and their concerns.
Identifying key drivers and analyzing the organization's internal and external environment to
elements in the identify key factors that will influence the architecture work, such as
organizational context business strategies, technology trends, and regulatory requirements.
Defining the requirements identifying the specific needs and expectations for the architecture
for architecture work work, such as the scope, timing, and outcomes of the work.
Defining the Architecture
Principles that will inform establishing a set of guiding principles that will inform the design and
any architecture work development of the enterprise architecture.
Defining the framework to selecting and tailoring an architecture framework that is appropriate for
be used the organization's needs and context, such as TOGAF or Zachman.
Defining the relationships aligning the enterprise architecture with other management
between management frameworks, such as ITIL, COBIT, or ISO 27001, to ensure consistency
frameworks and integration across the organization.
assessing the organization's current level of enterprise architecture
maturity and identifying areas for improvement to ensure that the
Evaluating the Enterprise architecture work is aligned with the organization's goals and
Architecture maturity objectives.

Phase A: Architecture Vision

1. Describe the main objectives of the phase (KLP 6.1-1)
● Develop an aspirational vision of the capabilities and business value to be
delivered
● Obtain approval for a Statement of Architecture Work that outlines the program of
works to develop and deploy the architecture.
2. Briefly explain the main aspect to the approach in this phase (KLP 6.5-1):
o Creating the Architecture Vision
The Architecture Vision is a key tool to sell the benefits of the proposed capability
to stakeholders and decision-makers within the enterprise. It describes how the
new capability will meet the business goals and strategic objectives and address
stakeholder concerns. This phase verifies and understands the documented
business strategy and goals, or researches and gains buy-in to the key business
objectives and processes that the architecture is to support. The Architecture
Vision should explore other domains appropriate for the Enterprise Architecture
and provide a first-cut high-level description of the Baseline and Target
Architectures. Building consensus around the Architecture Vision is critical to
ensure acceptance of the final architecture by the organization as a whole.

Phase B: Business Architecture

1. Describe the main objectives of the phase (KLP 7.1-1)
● Target Business Architecture: How to achieve goals, respond to strategic drivers,
address stakeholder concerns and the Statement of Architecture Work
● The Architecture Roadmap components are identified based on the gaps
between the Baseline and Target Business Architectures.

2. Briefly explain the main aspects of the approach in this phase (KLP 7.5-1):
General: understanding the enterprise context, identifying stakeholders, and
defining the scope and objectives of the Business Architecture work.
 Developing the Baseline Description: documenting the current state of the
enterprise in terms of its business processes, information flows, organizational
structure, and IT systems.

Applying Business Capabilities: identifying the key business capabilities

required to achieve the enterprise's strategic goals and objectives, and defining
how they should be delivered.

Applying Value Streams: identifying the key value streams that provide value to
customers and stakeholders, and defining how they should be optimized and
improved.

Applying the Organization Map: defining the organizational structure of the

enterprise, including the roles, responsibilities, and relationships of different
business units and functions.

Applying Modeling Techniques: using various modeling techniques, such as

process modeling, data modeling, and capability modeling, to represent the
Business Architecture in a visual and structured way.

Using the Architecture Repository: leveraging the Architecture Repository to

store and manage the artifacts and deliverables of the Business Architecture
work, and to provide a central reference point for architecture information and
knowledge.

Phase C: Information Systems Architecture

1. Describe the main objectives of the phase (KLP 8.1-1, 9.1-1, 10.1-1)
● Develop the Target Information Systems Architecture to enable the Business
Architecture and Architecture Vision, addressing the Statement of Architecture
Work and stakeholder concerns.
● Identify Architecture Roadmap components based on gaps between Baseline
and Target Information Systems Architectures.
2. Briefly explain the approach recommended by the TOGAF framework,including:
Key considerations for the Data Architecture (KLP 9.5-1)
● The TOGAF framework recommends an approach to Data Architecture
that involves identifying the key considerations for the data architecture,
such as data governance, data quality, and data integration. The data
architecture should support the business goals and objectives outlined in
the Architecture Vision and the requirements defined in the Statement of
Architecture Work.
 ● Identify candidate Architecture Roadmap components based upon gaps
between the Baseline and Target Information Systems (Data and
Application) Architectures
Using the Architecture Repository (KLP 9.5-1, 10.5-1)

Phase D: Technology Architecture

1. Describe the main objectives of the phase (KLP 11.1-1)
● Develop the Target Technology Architecture to enable the Business Architecture
and Architecture Vision, addressing the Statement of Architecture Work and
stakeholder concerns.
● Identify Architecture Roadmap components based on gaps between Baseline
and Target Technology Architectures.

2. Briefly explain the approach to the phase (KLP 11.5-1), including:

Emerging technologies – a driver for change
New technologies are a key driver for change in businesses looking to
innovate. Enterprise Architecture must capture transformation
opportunities enabled by technology. TOGAF ADM allows technology to
drive change and be a strategic resource, rather than just responding to
requests. This enables Technology Architecture to drive business
capabilities and respond to information system requirements
simultaneously.
Using the Architecture Repository

Phase E
1. Describe the main objectives of the phase (KLP 12.1-1)
● Generate the initial complete version of the Architecture Roadmap, based upon
the gap analysis and candidate Architecture Roadmap components from Phases
B, C, and D
● Determine whether an incremental approach is required, and if so identify
Transition Architectures that will deliver continuous business value
● Define the overall Solution Building Blocks (SBBs) to finalize the Target
Architecture based on the Architecture Building Blocks (ABBs)
2. Briefly explain the approach to the phase (KLP 12.5-1)
Phase E focuses on delivering the architecture, identifying gaps and grouping
changes into work packages. A roadmap is created based on stakeholder requirements,
transformation readiness, opportunities, and implementation constraints. Four key
concepts are important for transitioning from development to delivery: Architecture
Roadmap, Work Packages, Transition Architectures, and Implementation and Migration
 Plan. Work packages group necessary changes, Transition Architectures provide interim
targets, and the Implementation and Migration Plan schedules projects.

Phase F: Migration Planning

1. Describe the main objectives of the phase (KLP 13.1-1)
● Finalize the Architecture Roadmap and the supporting Implementation and
Migration Plan
● Ensure that the Implementation and Migration Plan is coordinated with the
enterprise’s approach to managing and implementing change in the enterprise’s
overall change portfolio
● Ensure that the business value and cost of work packages and Transition
Architectures is understood by key stakeholders

2. Briefly explain the approach to the phase (KLP 13.5-1)

During Phase F, an Implementation and Migration Plan is created in collaboration
with portfolio and project managers. The Architecture Roadmap and Implementation
and Migration Plan from Phase E are integrated with the enterprise's other change
activities, assessing dependencies, costs, and benefits. The detailed Implementation
and Migration Plan includes portfolio and project-level detail. Once completed, the
Architecture Development Cycle ends, and lessons learned are documented for
continuous process improvement.

Phase G
1. Describe the main objectives of the phase (KLP 14.1-1)
● Ensure conformance with the Target Architecture by implementation projects
● Perform appropriate Architecture Governance functions for the solution and any
implementation-driven architecture Change Requests
2. Briefly explain the approach to the phase (KLP 14.5-1)
Phase G involves bringing together all the information needed for successful
management of the implementation projects. It runs in parallel with the actual
development. The approach is to establish an implementation program, adopt a phased
deployment schedule, follow the organization's governance standards, use established
portfolio/program management approaches, and define an operations framework.
Compliance with the defined architecture is a key aspect of Phase G, not only for
implementation projects but also for ongoing projects.

Phase H
1. Describe the main objectives of the phase (KLP 15.1-1)
● Ensure that the architecture lifecycle is maintained
● Ensure that the Architecture Governance Framework is executed
● Ensure that the enterprise’s Architecture Capability meets current requirements
 2. Briefly explain the approach to the phase (KLP 15.5-1), including:
The architecture change management process ensures that the architecture achieves its
target business value. Business growth and decline monitoring is critical in this phase.
The value and change management process determines the circumstances under which
the architecture or parts of it can be changed after deployment, and the process for
doing so. It also determines when the Architecture Development Cycle will be initiated to
develop a new architecture.

Drivers for change

Driver DESCRIPTION
Strategic, top-down directed change Enhancing or creating new capability through capital investment.
Correcting or enhancing existing capability for operations and
Bottom-up changes maintenance to improve efficiency or effectiveness.
Experiences from previously Incorporating lessons learned from prior project increments still
delivered projects being delivered by ongoing projects.

Enterprise Architecture management process

CHANGE
CATEGORY DESCRIPTION DRIVEN BY
Simplification Can be handled via change management Requirement to reduce
Change techniques investment
Incremental May require partial re-architecting depending Requirement to derive additional
Change on the nature of the change value from existing investment
Requires putting the whole architecture Requirement to increase
Re-architecting through the Architecture Development Cycle investment to create new value
Change again for exploitation

Guidelines for maintenance versus architecture redesign

Guidelines for determining the appropriate change management approach for a
given change include considering the number of stakeholders impacted and
whether the change can be allowed under a dispensation. Additionally, a
refreshment cycle may be required for significant changes to the Foundation
Architecture, components and guidelines for use, or standards used in the
product architecture.
CRITERIA CHANGE MANAGEMENT APPROACH
Impacts multiple stakeholders Re-architecting
Impacts only one stakeholder Change management
Can be allowed under a dispensation Change management
Significant change to Foundation Architecture Refreshment cycle (iteration)
Significant change to components or guidelines Refreshment cycle
Significant change to standards Refreshment cycle

ADM Architecture Requirements Management

1. Briefly explain how Requirements Management fits into the ADM cycle
(KLP 16.1-1)
● The management of architecture requirements is a continuous process that
applies to all phases of the ADM cycle. It involves identifying, storing, and
utilizing requirements for the enterprise throughout the cycle.
2. Describe the nature of the Requirements Management process (KLP 16.1-2)
● Ensure that the Requirements Management process is sustained and operates
for all relevant ADM phases
● Manage architecture requirements identified during any execution of the ADM
cycle or a phase
● Ensure that the relevant architecture requirements are available for use by each
phase as the phase is executed

3. Describe the approach to Requirements Management (KLP 16.5-1)

● The Requirements Management process drives the ADM and is crucial in dealing
with changes and uncertainties in architecture. An Architecture Requirements
Repository should be used to manage all architecture requirements. The TOGAF
standard does not specify any particular tool or process for requirements
management but outlines what an effective process should achieve.
7. ADM Guidelines and Techniques

1. Briefly explain the contents of Part III, ADM Guidelines and

Techniques (KLP 17.1-1)
Part III of TOGAF 9.2, called ADM Guidelines and Techniques, provides a set of guidelines and
techniques for adapting and applying the ADM. The guidelines are used to adapt the ADM
process, while the techniques are used when applying the ADM process. Some of the
guidelines include applying iteration to the ADM, using the ADM at different enterprise levels,
and using the TOGAF framework with different architectural styles.

2. Briefly explain the need for Architecture Principles and where

they are used within the TOGAF ADM (KLP 20.1-1)
Architecture Principles provide general rules and guidelines for the development of enduring
architecture. Principles are an initial output of the Preliminary Phase, they guide
decision-making throughout the ADM, and are seldom amended. There are two key domains:
Enterprise Principles, which harmonize decision-making throughout the organization, and
Architecture Principles, which govern the architecture process and reflect consensus across the
enterprise.

3. Describe the recommended template for Architecture Principles

(KLP 20.3-1)

Simplicity
Using a standard framework to develop an enterprise architecture, such as TOGAF, can
Statement help simplify the architecture and make it easier to understand and maintain.
Complex architectures are harder to understand, maintain, and modify. Simplicity leads
Rationale to better usability, lower costs, and higher efficiency.
The architecture should avoid unnecessary complexity, use common standards and
Implications patterns, and minimize the number of components.

4. Explain what makes a good Architecture Principle (KLP 20.4-2)

CRITERIA DESCRIPTION
The principle should be clear and unambiguous for easy understanding throughout the organization,
Understandability minimizing the possibility of violations.
The principle should support quality decisions, enforceable policies, and precise decision-making in
Robustness complex situations.
Every potential principle governing information and technology management should be defined and
Completeness cover all perceived situations.
Principles should not contradict each other and should be expressed in a way that allows a balance
of interpretations. The wording should be carefully chosen to allow consistent yet flexible
Consistency interpretation.
Principles should be enduring but able to accommodate changes. An amendment process should be
Stability established for adding, removing, or altering principles after initial ratification.

5. Understand what a Business Scenario is and its purpose (KLP

BS.1-1)
Business scenarios are a technique used to help identify and understand the
business requirements that an architecture must address. A good business scenario represents
a significant business need or problem, and enables vendors to understand the value of a
solution to the customer.

6. Explain where Business Scenarios are used within the ADM

cycle (KLP BS.1-2)
Business scenarios figure most prominently in the initial phase of an ADM cycle, Architecture
Vision, when they are used to define relevant business requirements, and to build consensus
with
business management and other stakeholders.
They may also be used in other phases, particularly during Business Architecture, to derive the
characteristics of the architecture directly from the high-level requirements of the business

7. Explain the purpose of Gap Analysis (KLP 23.2-1)

Gap analysis is a technique used in the ADM of TOGAF 9.2 to validate an architecture being
developed. It highlights the shortfall between the Baseline Architecture and Target Architecture
by identifying gaps that have been deliberately omitted, accidentally left out or not yet defined.
Sources of gaps include business domain gaps, data domain gaps, applications impacted,
 eliminated or created, and technologies impacted, eliminated or created. The architecture must
support all essential information processing needs of the organization, and stakeholder
concerns that have not been addressed in prior architectural work should be considered.

8. Describe the Gap Analysis technique (KLP 23.2-1)

To perform a gap analysis, follow these steps:
1. Create a matrix with all ABBs of Baseline Architecture on the vertical axis and Target
Architecture on the horizontal axis
2. Add a "New ABBs" row to the Baseline Architecture and an "Eliminated ABBs" column to
the Target Architecture
3. Record where ABBs are included in both architectures
4. Review missing ABBs from the Baseline Architecture in the Target Architecture
a. If correctly eliminated, mark as such in the "Eliminated" cell
b. If not, mark as needing reinstatement in the "Eliminated" cell
5. Mark missing ABBs from the Target Architecture as a gap in the "New" row, to be
developed or procured.
ABBs = Architecture Building Blocks
The gap analysis technique should be used in Phases B, C, D, and E of the ADM

9. Explain the term interoperability (KLP 25.2-1)

Interoperability, defined as the ability to share information and services, can be categorized as
operational/business, information, and technical. It is useful to consider interoperability from an
IT perspective in terms of presentation, information, application, and technical integration. The
degree of interoperability is important for complex organizations or extended enterprises, and it
is based on the degree of rationalization of the corporate IT infrastructure, using common
platforms and standards for communication, storage, processing, and access to data.

10. Understand the use of Interoperability Requirements within

the TOGAF ADM (KLP 25.1-1)

ADM PHASE DESCRIPTION OF INTEROPERABILITY DETERMINATION

Identify nature and security considerations of information and
A: Architecture Vision service exchanges using business scenarios
B: Business Architecture Define information and service exchanges in business terms
Detail the content of information exchanges using the corporate
C: Data Architecture data and/or information exchange model
Specify the ways that applications are to share information and
C: Application Architecture services
 Specify appropriate technical mechanisms to permit information
D: Technology Architecture and service exchanges
E: Opportunities & Solutions Select actual solutions that support interoperability
F: Migration Planning Implement interoperability logically during migration planning

11. Understand Business Transformation Readiness Assessment

(KLP 26.1-2)
Enterprise Architecture involves significant change, and the Business Transformation Readiness
Assessment is a technique used to evaluate an organization's readiness for change, identify any
issues, and address them in the Implementation and Migration Plan.

12. Understand where Business Transformation Readiness

Assessment is used within the ADM (KLP 26.1-1)
To have a successful architecture transformation in Phases E and F, it's important to use a
technique called Business Transformation Readiness Assessment. This assessment should be
done jointly by corporate staff, lines of business, and IT planners. The assessment involves
determining readiness factors, presenting them using maturity models, assessing them,
determining ratings, assessing risks, and identifying improvement actions to mitigate risks. The
findings are then documented in the Capability Assessment. This assessment should be done
initially in Phase A.

13. Understand the characteristics of Risk Management (KLP

27.1-2)
Risk management is important to minimize risks during an architecture project. There are two
levels of risks to consider: initial level of risk and residual level of risk. Initial level of risk refers to
the categorization of risk before taking any action to mitigate it, while residual level of risk refers
to the categorization of risk after taking action to mitigate it.

14. Understand where Risk Management is used within the

TOGAF ADM (KLP 27.1-1)
Risk is always present in Enterprise Architecture and is addressed in all phases of the ADM. It's
important to identify and mitigate risks early on in Phase A and include them in the Statement of
Architecture Work. Risk assessment worksheets are updated in Phase G during implementation
governance. If critical risks are identified, another ADM cycle may be necessary.
15. Understand Capability-Based Planning (KLP 28.1-1)
Capability-Based Planning is a business planning technique that focuses on achieving desired
outcomes by combining the efforts of different business units. It's useful in organizations where
multiple capabilities are required and the same resources are involved. It accommodates
different business models and is often used with business scenarios to identify and refine
capability needs.

16. Briefly explain the use of the TOGAF ADM in the context of a
specific architectural style (KLP 17.3-1)
● The TOGAF framework is flexible and can be adapted to different architectural styles.
● Practitioners must identify the distinctive features of a style, such as those found in SOA.
● Practitioners adjust models, viewpoints, and tools to address distinctive features.
● Different styles may require new elements, adjust notation, or focus on certain
stakeholders.
● Phase B, C, and D involve selecting relevant architecture resources to address
stakeholder concerns.
● Extensions to the Architecture Content Metamodel and identification of viewpoints may
be necessary.
● Dominant styles may require changes to the Architecture Capability in the Preliminary
Phase.
8. Architecture Governance (Level 1)

1. Briefly explain the concept of Architecture Governance (KLP

44.1-1)
● Architecture Governance is the management and control of enterprise-wide
architectures.
● It involves implementing controls for creating and monitoring architectural components.
● It ensures compliance with standards and regulations.
● Establishing processes to support effective management within agreed parameters.
● Practices are developed to ensure accountability to stakeholders.
● It operates within a hierarchy of governance structures, including corporate governance,
technology governance, IT governance, and architecture governance.
● These governance domains may exist at multiple geographic levels within the
organization.
● Corporate governance is not within the scope of TOGAF.

2. Describe the main concepts that make up an Architecture

Governance framework (KLP 44.2-1)
An Architecture Governance Framework includes policies, decision-making structures,
compliance, risk management, performance measurement, communication, lifecycle
management, and continuous improvement. These concepts ensure effective management,
control, and alignment of architectures with organizational goals, while mitigating risks, ensuring
compliance, and driving successful outcomes.

3. Explain why Architecture Governance is beneficial (KLP 44.3-1)

● Links IT to organizational strategies
● Integrates IT best practices
● Aligns with COBIT framework
● Maximizes information and infrastructure assets
● Protects digital assets
● Supports regulatory requirements
● Promotes risk management

4. Briefly explain the need for establishment of an Architecture

Board (KLP 41.1-1)
An Enterprise Architecture imposed without appropriate political backing is bound to fail.
The establishment of an Architecture Board is necessary to provide oversight, guidance, and
decision-making authority to ensure alignment between business goals and technology
solutions within an organization's architectural framework.

5. List the responsibilities of an Architecture Board (KLP 41.2-1)

● Providing the basis for all decision-making with regard to changes to the architectures
● Consistency between sub-architectures
● Establishing targets for re-use of components
● Flexibility of Enterprise Architecture; to meet business needs and utilize 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

6. Briefly explain the role of Architecture Contracts (KLP 43.1-1)

● Architecture Contracts are agreements on deliverables, quality, and fitness-for-purpose.
● Effective Architecture Governance ensures successful implementation.
● Governed contract management ensures monitoring, integrity, adherence, and audit.
● Architecture team involvement in procurement minimizes misinterpretation.
7. Briefly explain the meaning of Architecture Compliance (KLP
42.2-1)

8. Briefly explain the need for Architecture Compliance (KLP

42.1-1)
● Architecture Compliance ensures that individual projects align with the Enterprise
Architecture and is crucial for Architecture Governance.
● Adopting an Architecture Compliance strategy is recommended.
 ● The TOGAF standard suggests two complementary processes:
○ The Architecture function prepares project-specific views of the Enterprise
Architecture.
○ The IT Governance function defines a formal Architecture Compliance Review
process.
● Architecture Governance may involve the architecture function in technology selection
and commercial relationships to minimize misinterpretation and maximize value.

9. Briefly explain the purpose of Architecture Compliance Reviews

(KLP 42.3-1)
● Catch errors early, reducing costs and risks of later changes, and accelerating project
timelines.
● Ensure best practices in architecture work.
● Assess compliance with enterprise standards and identify potential modifications.
● Identify opportunities for enterprise infrastructure and collaboration among architecture
teams.
● Incorporate technological advancements and communicate technical readiness to
management.
● Define procurement criteria and address architectural gaps.
● Guide decisions based on business benefits rather than technical preferences.

10. Briefly describe the Architecture Compliance Review process

(KLP 42.4-1)
11. Briefly explain how the ADM can be used to establish an
Architecture Capability (KLP 40.1-1)
● Use the ADM to establish a sustainable Architecture Capability within an organization.
● Apply the ADM with a specific Architecture Vision to establish an architecture practice.
● Design the Business, Data, Application, and Technology Architectures for the
architecture practice.
● Implement the architecture practice as an ongoing practice, providing governance and
resources for architecture delivery.
● Changes to the architecture practice can trigger another cycle of the ADM to extend the
practice.
9. Architecture Views, Architecture Viewpoints, and
Stakeholders

1. Define and explain the following key concepts (KLP 31.1-1):

o Stakeholders
Stakeholders are individuals or groups with an interest or concern in a system, such as
users or developers. They play key roles and have specific interests in relation to the
system.

o Concerns
Concerns are the interests stakeholders have in a system. They cover various aspects
like performance, reliability, security, distribution, and evolvability, and determine the
system's acceptability. For instance, a Security Architect's concerns may include
authentication, authorization, audit, assurance, availability, asset protection,
administration, and risk management.

o Architecture Views
An architecture view is a representation of a system based on specific concerns. It
shows stakeholders that their concerns are addressed. Like a building architect uses
different diagrams to communicate with stakeholders, an Enterprise Architect creates
various views for business, information system, and technical aspects.

o Architecture Viewpoints
An architecture viewpoint establishes guidelines for a specific kind of architecture view,
addressing particular concerns. It defines the construction, interpretation, and utilization
of the view, including required information, modeling techniques, and intended audience.
Viewpoints serve as templates to create architecture views within an enterprise.

2. Describe a simple example of an architecture viewpoint and

view (KLP 31.1-2)

Examples of architecture views and viewpoints can include:

Viewpoint: Security
View: Security Architecture View
Concern: Ensuring the system's security by addressing aspects like authentication,
authorization, audit, and risk management.

Viewpoint: Performance
View: Performance Architecture View
Concern: Assessing and optimizing the system's performance, including response times,
throughput, and scalability.

Viewpoint: Data
View: Data Architecture View
Concern: Defining the system's data structure, data flows, and data management strategies.

Viewpoint: Deployment
View: Deployment Architecture View
Concern: Planning and visualizing the system's physical deployment, including hardware,
network topology, and distribution across locations.

Viewpoint: User Interface

View: User Interface Architecture View
Concern: Designing the system's user interface elements, interactions, and usability guidelines.

An architecture view is what you see, while an architecture viewpoint is your perspective or
vantage point. Viewpoints can be stored in libraries for reuse and are always specific to the
architecture they describe.

3. Discuss the relationship between stakeholders, concerns,

views, and viewpoints (KLP 31.1-3)
Stakeholders have concerns about a system. Views capture different aspects of the system.
Viewpoints determine what is seen in a view, serving as the perspective or vantage point.
Stakeholders' concerns influence the selection and creation of viewpoints, which in turn shape
the content and presentation of views. Together, stakeholders, concerns, views, and viewpoints
form a cohesive framework for understanding and representing a system's architecture.

4. Describe the architecture view creation process (KLP 31.2-1)

● Identify stakeholders' concerns and requirements.

● Select or define suitable architecture viewpoints.
● Identify relevant architectural elements and relationships.
● Create the architecture view based on the selected viewpoint.
● Review and validate the view with stakeholders.
● Document and store the view for future reference and reuse.
10. Building Blocks

1. Define what a building block is, and explain what makes a good
building block (KLP 33.2-1)
● It considers implementation and usage, and evolves to exploit technology and standards
● It may be assembled from other building blocks
● It may be a subassembly of other building blocks
● Ideally, a building block is re-usable and replaceable, and well specified with stable
● interfaces
● Its specification should be loosely coupled to its implementation, so that it can be
realized
● in several ways without impacting the building block specification

2. Explain the distinction between Architecture Building Blocks

and Solution Building Blocks (KLP 33.2-2)
● Architecture Building Blocks (ABBs) represent reusable components that define the
fundamental structure and behavior of a system or solution.
● Solution Building Blocks (SBBs) are specific implementations or configurations of ABBs
that are tailored to address a particular problem or meet specific requirements within a
given context. They represent the practical realization of the architectural concepts.
3. Briefly explain the use of building blocks in the ADM cycle (KLP
33.3-1)
 4. Describe the characteristics of an Architecture Pattern (KLP
22.1-1)
Patterns in TOGAF provide context to building blocks, offering reusable solutions and guidance
on their use, trade-offs, and effectiveness. They help architects identify proven combinations of
building blocks for effective solutions.

Pattern Name Description

Layered Organizes the system into multiple layers, each with a specific set of responsibilities and abstraction
Architecture levels.
Service-Oriente Utilizes services as the fundamental building blocks, enabling loose coupling, reusability, and
d Architecture interoperability between components and systems.
Event-Driven Focuses on the communication and handling of events, allowing components to react to events
Architecture asynchronously, facilitating real-time processing and decoupling.
Microservices Decomposes the system into a collection of small, independent services that can be developed,
Architecture deployed, and scaled independently.
Cloud
Computing Leverages cloud services and infrastructure to deliver scalable, on-demand computing resources,
Architecture enabling flexibility and cost optimization.
Data-Centric Puts data at the center of the architecture, emphasizing the management, integration, and access to
Architecture data, promoting consistency and efficiency.
Security Addresses the design and implementation of security measures and controls throughout the system to
Architecture protect assets and mitigate risks.
Integration Defines how different systems, components, and data sources are connected and interact with each
Architecture other, enabling seamless information flow and interoperability.
Model-View-Co Separates the application into three interconnected components: the model, the view, and the controller,
ntroller (MVC) facilitating modular and scalable development.
Repository Provides a standardized way to access data by encapsulating data access logic, promoting separation of
Pattern concerns and maintainability.
Publish-Subscri Enables the distribution of messages to multiple consumers through a publish-subscribe model, allowing
be Pattern loose coupling and event-based communication.
Client-Server Divides the system into two major components: clients that request services, and servers that provide
Architecture services, enabling scalable and distributed systems.
Peer-to-Peer Distributes the workload across all participating nodes, allowing each node to act as both a client and a
Architecture server, promoting fault tolerance and scalability.
Component-Ba
sed Focuses on building software systems by combining and reusing independent components, enabling
Architecture modularity and reusability.
Batch
Processing Processes a large volume of data in batches, typically scheduled at specific intervals, allowing efficient
Architecture handling of bulk data and optimized resource utilization.
Real-Time
Processing Handles data processing and analysis in real-time, providing immediate insights and actions based on
Architecture current information.
Big Data Deals with the challenges of processing and analyzing large and complex data sets, often using
Architecture distributed computing and storage technologies.
Cache Utilizes a cache to store frequently accessed data, reducing latency and improving performance by
Architecture avoiding expensive data retrieval operations.
ETL (Extract,
Transform,
Load) Extracts data from multiple sources, transforms it to a consistent format, and loads it into a target system,
Architecture enabling data integration and consolidation.
Virtualization Abstracts physical infrastructure to create virtual resources, allowing efficient utilization, scalability, and
Architecture flexibility in deploying and managing systems.
11. ADM Deliverables

1. Briefly explain the role of architecture deliverables across the

ADM cycle (KLP 32.1-1)
Architecture deliverables play a critical role in the TOGAF ADM cycle by providing a common
language for stakeholders to communicate and collaborate, defining the scope and objectives of
the architecture project, documenting architectural decisions and recommendations, and
facilitating the implementation and monitoring of the architecture. The deliverables also serve as
a basis for measuring the success and value of the architecture effort and supporting ongoing
improvement and evolution of the architecture.
2. Briefly explain the purpose of the following deliverables (KLP
32.2-1):

o Architecture Building Blocks

o Architecture Contract

o Architecture Definition Document

o Architecture Principles

o Architecture Repository

o Architecture Requirements Specification

o Architecture Roadmap

o Architecture Vision

o Business Principles, Business Goals, and Business

Drivers

o Capability Assessment

o Change Request

o Communications Plan

o Compliance Assessment

o Implementation and Migration Plan

 o Implementation Governance Model

o Organizational Model for Enterprise Architecture

o Request for Architecture Work

o Requirements Impact Assessment

o Solution Building Blocks

o Statement of Architecture Work

o Tailored Architecture Framework

Deliverable Name Phase Description

Describes the key components and their relationships to provide a foundation for
Architecture Building Blocks B,C,D developing and implementing the enterprise architecture.
Establishes a formal agreement between the enterprise and architecture stakeholders,
documenting their mutual commitment to the deliverables, quality, and
Architecture Contract H fitness-for-purpose of an architecture
Describes the architecture in detail, including the scope, viewpoints, and various
Architecture Definition Document B architectural artifacts.
Defines the fundamental guidelines and constraints that shape the architecture's design
Architecture Principles A and implementation.
Stores and manages architectural artifacts, including models, patterns, and templates,
Architecture Repository A for easy access and reuse.

Architecture Requirements Defines the requirements that the architecture must satisfy, including business, data,
Specification B application, and technology requirements.
Outlines the planned evolution of the architecture, identifying the projects and initiatives
Architecture Roadmap E required to reach the target architecture.
Describes the desired future state of the enterprise and the strategic goals that the
Architecture Vision A architecture will support.
Business Principles, Goals, and Identifies the fundamental values, objectives, and motivations that guide the enterprise's
Drivers A business and influence the architecture.
Evaluates the enterprise's existing capabilities and identifies gaps and areas for
Capability Assessment A improvement.
 Documents a request to modify the architecture and outlines the proposed changes,
Change Request E their impact, and the rationale for the request.
Defines the strategy and approach for communicating the architecture to stakeholders
Communications Plan A and ensuring effective information exchange.
Evaluates whether the implemented architecture complies with the defined architecture,
Compliance Assessment G standards, and best practices.
Implementation and Migration Provides a detailed plan for implementing and migrating the architecture, including
Plan E sequencing, dependencies, and resource allocation.
Implementation Governance Defines the organizational structure, roles, and responsibilities for overseeing the
Model E implementation and governance of the architecture.
Organizational Model for Defines the structure and roles within the organization that are responsible for enterprise
Enterprise Architecture A architecture activities.
Initiates the process of developing or modifying the enterprise architecture by requesting
Request for Architecture Work A the necessary resources and support.
Requirements Impact Assessment D Assesses the potential impact of changing requirements on the architecture

Deliverable Name Sample Template Outline for the Document

1. Introduction 2. Purpose 3. Scope 4. Architecture Building Block Descriptions 5. Architecture
Architecture Building Blocks Building Block Relationships 6. Architecture Building Block Catalog
1. Introduction 2. Parties Involved 3. Objectives 4. Scope 5. Roles and Responsibilities 6.
Architecture Contract Deliverables and Timelines 7. Signatures

1. Introduction 2. Executive Summary 3. Architecture Vision 4. Business Architecture 5. Data

Architecture Definition Document Architecture 6. Application Architecture 7. Technology Architecture

Architecture Principles 1. Introduction 2. Purpose 3. Scope 4. Principles List 5. Principles Descriptions and Rationales
1. Introduction 2. Purpose 3. Architecture Repository Components 4. Architecture Repository
Architecture Repository Content 5. Architecture Repository Management

Architecture Requirements 1. Introduction 2. Purpose 3. Stakeholders 4. Requirements Categories 5. Detailed Requirements

Specification 6. Traceability Matrix
1. Introduction 2. Vision and Strategy 3. Current State Assessment 4. Target State Definition 5.
Architecture Roadmap Transition Planning and Roadmap
1. Introduction 2. Purpose 3. Scope 4. Business Goals and Objectives 5. Architecture Vision
Architecture Vision Statement 6. Target State Description
Business Principles, Business 1. Introduction 2. Business Principles 3. Business Goals and Objectives 4. Business Drivers and
Goals, and Drivers Influencers 5. Alignment with Architecture Vision and Strategy

Capability Assessment 1. Introduction 2. Purpose 3. Scope 4. Capability Assessment Methodology 5. Assessment

 Results and Findings
1. Introduction 2. Change Request Details 3. Impact Assessment 4. Proposed Solution 5.
Change Request Approval Process and Sign-offs
1. Introduction 2. Stakeholder Analysis 3. Communication Objectives 4. Communication
Communications Plan Channels and Tools 5. Communication Schedule
1. Introduction 2. Compliance Assessment Criteria 3. Compliance Assessment Results 4. Action
Compliance Assessment Plan for Non-Compliant Areas

Implementation and Migration 1. Introduction 2. Objectives 3. Scope and Approach 4. Implementation and Migration Phases 5.
Plan Resource Requirements

Implementation Governance 1. Introduction 2. Objectives 3. Roles and Responsibilities 4. Decision-Making Framework 5.

Model Compliance and Reporting Mechanisms
Organizational Model for 1. Introduction 2. Purpose 3. Scope 4. Organizational Structure 5. Roles and Responsibilities 6.
Enterprise Architecture Relationship to Other Governance Frameworks
1. Introduction 2. Request Details 3. Business Context and Drivers 4. Architecture Scope and
Request for Architecture Work Objectives 5. Expected Deliverables and Timeline
Requirements Impact 1. Introduction 2. Purpose 3. Scope 4. Requirements Impact Assessment Methodology 5. Impact
Assessment Analysis Results and Recommendations
1. Introduction 2. Purpose 3. Scope 4. Solution Building Block Descriptions 5. Solution Building
Solution Building Blocks Block Relationships and Dependencies
1. Introduction 2. Objectives 3. Scope and Approach 4. Deliverables and Timelines 5. Resource
Statement of Architecture Work Requirements and Constraints
1. Introduction 2. Purpose 3. Scope 4. Tailored Framework Components 5. Framework Adoption
Tailored Architecture Framework Guidelines and Recommendations
12. TOGAF Reference Models (Level 1)

1. Explain the role of the TRM as a Foundation Architecture (KLP

TRM.2-1)
A Foundation Architecture, positioned in the left-hand side of the Enterprise Continuum,
consists of building blocks and standards that support Common Systems Architectures. The
TOGAF Library includes the Technical Reference Model (TRM) as an example, providing a
fundamental architecture for other specific architectures to be built upon.

2. Describe at a high level the main components of the TOGAF

TRM (KLP TRM.4-1)
The TRM has two main components:
1. A taxonomy that defines terminology, and provides a coherent description of the
components and conceptual structure of an information system
2. A model, with an associated TRM graphic, that provides a visual representation of the
taxonomy, as an aid to understanding
3. Briefly explain the basic concepts of the III-RM (KLP IIIRM.1-1)
The emergence of Internet-based technologies led to a shift in organizations' focus from
platform-centric to application software space. In response, The Open Group developed the
Integrated Information Infrastructure Reference Model (III-RM), a subset of the TOGAF TRM, to
address the challenge of designing an integrated information infrastructure for Boundaryless
Information Flow.

4. Briefly explain the relationship of the III-RM to the concept of

Boundaryless Information Flow (KLP IIIRM.1-2)
The III-RM, developed by The Open Group, helps address the challenge of enabling
Boundaryless Information Flow by designing an integrated information infrastructure. It expands
certain parts of the TRM, particularly business applications and infrastructure applications, to
support seamless information exchange across organizational boundaries.