Palladio - Enterprise Architecture Foundation With TOGAF

Enterprise Architecture (Foundation)
with the TOGAF Standard, 10th Edition

Biggest and best course for TOGAF and Enterprise Architecture | All-in-
one carefree package to pass the part 1 exam | Learn from 2 EA experts
Copyright and Trademarks – All rights reserved
Reproduction and redistribution only with written permission
▪ Palladio Consulting GmbH & Co. KG is a member of The Open Group Architecture Forum and has a
commercial license for the TOGAF® Standard, 10th Edition & Earlier.
▪ TOGAF® is a registered trademark of The Open Group.
▪ Digital Practitioner Body of Knowledge is a trademark of The Open Group.
▪ DPBoK is a trademark of The Open Group.
▪ Boundaryless Information Flow is a trademark of The Open Group.
▪ The Open Group TOGAF 9 templates and examples, Copyright (c) 2010 The Open Group, The
Open Group gratefully acknowledges Capgemini for contributing these templates and examples.
TOGAF® is a registered trademark of The Open Group.

Document outline (1/3)
Enterprise Architecture Foundation with the TOGAF Standard, 10th Edition
1 Welcome
2 Introduction to Enterprise Architecture
3 Architecture Development Method (ADM)
4 Preliminary Phase
5 Phase A: Architecture Vision
6 Phase B: Business Architecture
7 Phase C: Information Systems Architectures
8 Phase D: Technology Architecture

9 Phase E: Opportunities and Solutions
10 Phase F: Migration Planning
11 Phase G: Implementation Governance
12 Phase H: Architecture Change Management
13 Requirements Management Phase
14 Applying the ADM
15 Architecture Content & Core Concepts
16 Architecture Governance & Architecture Capability

17 Exam Preparation & Definitions
18 Practice Test
19 Wrap-up

Course outline (1/5)
Enterprise Architecture Foundation with the TOGAF® Standard, 10th Edition
▪ Course outline
1. Welcome ▪ Course instructors
▪ TOGAF Certification Program
2. Introduction ▪ Enterprise Architecture Definition, Purpose & Benefit

to Enterprise ▪ Domains, Levels, Partitions & Abstractions
Architecture ▪ The TOGAF Standard, 10th Edition
3. Architecture ▪ Overview of the ADM Phases

Development ▪ Artifacts & Deliverables, Building Blocks
Method (ADM) ▪ Stakeholders, concerns, viewpoints and views
4. Preliminary ▪ Purpose, Objectives, Steps & Approach

Phase ▪ Architecture Principles

5. Phase A: ▪ Statement of Architecture Work

Architecture ▪ Business Transformation Readiness Assessment
Vision ▪ Architecture Vision & Definition Document
6. Phase B:
▪ Purpose, Objectives, Steps & Approach
Business
▪ Gap Analysis
Architecture
7. Phase C: Interface 1
App 1 Interface 2
Information
▪ Application & Data Architecture Artifacts
App 2
Interface 3
Systems Arch. App 3
8. Phase D:
Technology
▪ Technology Architecture Artifacts
Architecture

9. Phase E: ▪ Interoperability & Risk Management

Opportunities ▪ Architecture Roadmap
and Solutions ▪ Implementation and Migration Plan
10. Phase F:
Migration
▪ Implementation Governance Model
Planning
11. Phase G:
▪ Portfolio
▪ Identify the products
needed by the enterprise
▪ Identify the boundaries

▪ Project
▪ Identify the products
needed by the enterprise
▪ Identify the boundaries

▪ Solution Delivery
▪ Architecture Contracts
▪ Compliance Assessment
of the products of the products
Implementation ▪ Set constraints for the

product owner
▪ Define the enterprise’s

▪ Set constraints for the
product owner
▪ Set constraints for the ▪ Set constraints for the
▪ Support of Agile Software Development

backlog agile teams agile teams
Governance ➢ The Enterprise Architect serves the stakeholders guarding the mission, vision, goals
and investment roadmap, hence guarding enterprise value
12. Phase H:
Arch. Change
▪ Change Request
Management

13. Require-
ments Mgmt. Requirements
Management
▪ Requirements Impact Assessment

Phase
▪ ADM Techniques & Iterations

14. Applying
▪ Information Flow
the ADM
▪ Architecture Alternatives & Trade-off Method
▪ Content Framework & Enterprise Metamodel

15. Content &
▪ Enterprise Continuum
Core Concepts
▪ Architecture Repository
16. Architecture
▪ Corporate & EA Governance
Governance &
▪ Architecture Board & Capability
EA Capability

17. Exam ▪ Key Definitions

Preparation & ▪ Exam Preparation & Time Management
Definitions ▪ Question Analysis & Answer selection
18. Practice ▪ TOGAF EA Part 1 Sample Exam

Test ▪ 40 Questions, Answers & Explanations
▪ Next Steps & Good Luck

19. Wrap-up
Enterprise Architecture (Foundation)
with the TOGAF Standard, 10th Edition
Everything you need to master the TOGAF Enterprise Architecture
▪ Course Materials Download
Part 1 Exam [OGEA-101]

About your Instructors
Tobias Smuda
Professional
▪ Expert in Enterprise Architecture Management
▪ Master degree in mechanical engineering
▪ Managing partner at palladio Consulting
▪ Certified in TOGAF, Business Analysis & SCRUM Master
▪ Consulting experience in Enterprise Architecture
Management since 2016 (> 20 business/IT projects)
Personal
▪ Father of two daughters
▪ Board game geek
▪ Hiking in the mountains

About your Instructors
Dr. Christopher Schulz
Professional
▪ PhD in Computer Science focusing on Enterprise Architecture
▪ Managing partner at palladio Consulting
▪ Certified in TOGAF, ArchiMate, COBIT and ISO/IEC 20000
▪ 15 years consulting experience in Enterprise Architecture
Management (> 50 business/IT projects)
▪ Professional trainer since 2008 (TOGAF and IREB)
Personal
▪ Two young kids
▪ Sports & outdoors
▪ Blogging & writing (15 books, > 500 posts)

TOGAF Certification Program – Certification Portfolio
This course focuses on the Enterprise Architecture Foundation certification
This
Course
TOGAF® TOGAF® TOGAF®

TOGAF®9 TOGAF®9
Enterprise Enterprise Business
Architecture Architecture Architecture
Foundation Certified
Foundation Practitioner Foundation
TOGAF® is a registered trademark of The Open Group. Explain the TOGAF Certification Program and distinguish between the levels for certification
TOGAF Certification Program – Exam (1/2)
Reach your TOGAF® Enterprise Architecture Foundation Certification
▪ Validates that the candidate has gained knowledge of the terminology and basic
concepts of The TOGAF® Standard, 10th Edition and understands the core
principles of Enterprise Architecture and the TOGAF® framework
▪ 40 basic single choice questions

Setup
▪ 60 minutes + 30 minutes for non-native speakers (English)
▪ Closed book
▪ Pass mark: 60% (24 out of 40 questions)

Info
➢ TOGAF® Enterprise Architecture Part 1 Exam (OGEA-101, English)
TOGAF Certification Program – Exam (2/2)
Book & take your Enterprise Architecture Part 1 Exam with Pearson Vue
▪ Conditions
▪ Booked at & conducted by Pearson Vue on behalf of The Open Group
▪ Test Center or remote under controlled conditions (video surveillance)
▪ Extra time, if English is 2nd language https://certification.opengroup.org/ESL
▪ Translation dictionary may be used and must be presented for inspection
Document outline
1 Welcome
4 Preliminary Phase

Enterprise – Definition
An enterprise is any collection of organizations that have common goals
Exam
▪ Entire Enterprise or one or more specific
areas of interest
▪ May comprise multiple enterprises
▪ May include partners, suppliers, customers and internal business units
▪ Considered as a system Image source: Pixabay.com / Pixabay
▪ May develop and maintain several independent Enterprise Architectures
▪ Examples: Corporation vs. division of a corporation, government agency vs. single

government department, partnerships and alliances of businesses
TOGAF® is a registered trademark of The Open Group. Describe what an enterprise is
Architecture – Definition
The TOGAF Standard enhances the ISO/IEC/IEEE 42010:2011 terminology
1. The fundamental concepts or properties of a

system in its environment embodied in its elements,
relationships and in the principles of its design &
evolution.
(Source: ISO/IEC/IEEE 42010: 2011)
2. The structure of components, their

interrelationships & the principles and guidelines
governing their design & evolution over time.
(Source: The Open Group TOGAF® Standard —
Introduction and Core Concepts)
Image source: Pexels.com / Pexels

Architecture Domains – Introduction (1/2)
The BDAT Architecture Domains divide an Enterprise Architecture into 4 subsets
Exam
Business Architecture
Specific domains as combination (e.g., digital

architecture, risk & security architectures)
Defines the business strategy, governance, organization and key business processes
Data Architecture
Describes the Structure of an organization’s conceptual, logical & physical data assets,
data management resources
IT Architecture
Application Architecture
Provides a blueprint for the individual applications to be deployed, their interactions and their
relationships to the core business processes of the organization
Technology Architecture
Describes the digital architecture and the logical software and hardware infrastructure capabilities and
standards that are required to support the deployment of business, data and applications services
➢ Single or holistic consideration of architecture domains

List the four architecture domains that are commonly accepted as subsets of an overall
Enterprise Architecture and which the TOGAF Standard supports
Architecture Domains – Introduction (2/2)
Each Architecture Domain describes different “things”
▪ Business Capabilities ▪ Value Streams ▪ Organization Units
▪ Business Processes ▪ Information Concepts ▪ …
Data Architecture
▪ Information Objects ▪ Data management ▪ …
▪ Data Objects resources
▪ Applications ▪ Application Domains ▪ Application Services
▪ Interfaces ▪ Application Functions ▪ …
▪ IT infrastructure ▪ Network elements ▪ Cloud services
▪ Middleware ▪ Technology platforms ▪ Runtime environments

Architecture Domains – Visualization (1/2)
Each Architecture Domain can be described & visualized by several artifacts
Business Capability Value Stream Organization

Map Map Map
Data Architecture
Business Function Application
Sales HR Sales-System HR-System
Product Margin Data x Product Margin Data x
Customer Data x Customer Data x
Data Entity
Data Entity
Employee Data x Employee Data x …
Payroll Data x Payroll Data x
Insurance Data x Insurance Data x
Revenue Data x Revenue Data x
Data Dissemination Data Entity/Business Application / Data

Diagram Function Matrix Matrix

The Open Group TOGAF 9 templates and examples, Copyright (c) 2010 The Open Group
Architecture Domains – Visualization (2/2)
Each Architecture Domain can be described & visualized by several artifacts
ID Name Category Organization
Enterprise Resource Sales HR
L_APP_01 Plattform
Planning CRM x
Application
Customer Relationship ERP x
L_APP_02 Plattform
Management DWH x x …
Data Videocall x x
L_APP_03 Plattform
Warehouse DMS x x
Application Portfolio Application Communication Application / Organization

Catalog Diagram Matrix
ID Name Category
L_TEC_01 Workflow Automation
L_TEC_02 Event trigger Automation …
L_TEC_03 App Connector Automation
L_TEC_04 ETL BI
Technology Portfolio Platform Decomposition Environments & Location
Catalog Diagram Diagram

Architecture Domains – Example
Simplified Enterprise Architecture for the Order to Cash process
Business
Order to Cash
Order Fulfillment Delivery Invoice Cash
Purchase Order Transport

Data
Invoice Transaction
order confirmation order
App
Enterprise Resource Planning

Tech
Cloud Platform

Architecture States – Overview
Enterprise Architects manage multiple architecture states
Resting Architecture Candidate Architecture

State where the enterprise receives Future state that stakeholders
value if all change activity is suspended have not approved yet
Baseline Architecture
Current state acting as
reference for all change
Transition Architecture Target Architecture
Fully functional future state that partially Future state that
realizes targets with a specific time and stakeholders have approved
target conformance
Today Future
Scoping Architectures – Scope, Detail, Domains & Time
Four dimensions define and limit the scope of an architecture
Exam
Enterprise Scope Level of Detail Architecture Time Period

(breadth) (depth) Domains (planning horizon)
What is the full extent of the To what level of detail Which domains should be What is the time period that
enterprise and what part of should the architecting effort looked at? needs to be articulated for
that extent will this go? the Architecture Vision?
architecting effort deal with?
▪ Organizations How much architecture is ▪ Business Does it make sense

▪ Business unit "enough“ (effort between ▪ Data (practicality, resources) to
▪ Departments architecture and system ▪ Application be covered in a detailed
▪ Processes design & development)? ▪ Technology Architecture Description?
Scope of the architectural activity is mostly limited by people, finance, objectives, stakeholder concerns and the
organisational authority of the EA team
TOGAF® is a registered trademark of The Open Group. Briefly explain how to scope an architecture
Architecture Levels – Strategic, Segment & Capability Architecture
The concept divides the Architecture Landscape into three levels of granularity
Exam
Provide an organizing framework for change &
operations describing & classifying the landscape
1. Strategic Architecture supports direction

setting at an executive level
2. Segment Architecture supports direction

setting and the development of architecture
roadmaps at a program or portfolio level
3. Capability Architecture supports the

development of effective architecture
roadmaps realizing capability increments
TOGAF® is a registered trademark of The Open Group. List the three levels of the Architecture Landscape
Architecture Partitioning – Approach
A divided subset of an architecture facilitates its development & management
1. Establish several architecture

partitions, providing defined
boundaries, governance and
ownership
2. Apply partitioning to architecture

until each architecture has one
owning team
3. Each team carrying out architecture

activity within the enterprise owns one or more architecture
partitions and will execute the ADM to define, govern and realize their architectures
➢ Adopt a partitioning model that reflects the enterprise’ operating model

TOGAF® is a registered trademark of The Open Group. Briefly explain how partitioning helps simplify the development of an Enterprise Architecture
Architecture Partitioning – Benefits
Partitioning helps to simplify the development & management of Architectures
Conflict Management Parallelization

Organizational unit architectures conflict with Partitions allow for specific groups of
one another architects to own and develop specific
elements of the architecture at the same time
Re-use Manageable Complexity & Governance

Effective architecture re-use requires modular Partitioning divides an Architecture into
architecture segments that can be taken and subsets to reduce complexity, ensure
incorporated into broader architectures and effective governance and simplify the
solutions development & management
TOGAF® is a registered trademark of The Open Group. Briefly explain how partitioning helps simplify the development of an Enterprise Architecture
Architecture Abstraction Levels – Introduction
The concept motivates to ask structured questions about an architecture
Why (Contextual) How (Logical)

Why is the architecture How do we structure
needed? the functionality?
What (Conceptual)
With what (Physical)
What functionality and
With what assets shall
other requirements
we implement this
need to be met by the
structure?
architecture?
➢ Dividing a problem area into smaller problem areas easier to model & to solve
Note: Why, what and how have no connection to Zachman® Enterprise Architecture Framework
TOGAF® is a registered trademark of The Open Group. Briefly describe how architecture abstraction can be used in Enterprise Architecture
Architecture Abstraction Levels – Definition
The concept divides an architecture effort into four distinct levels Exam
▪ Understand the Environment of an enterprise and the
Contextual
context of architecture work
Abstraction
▪ E.g., scope, motivation, drivers, scope, goals, objectives
Layering
▪ Understand the problem Moving
Conceptual
▪ Requirements and service models from
Abstraction
▪ E.g., business service, application service, technology service high-level
▪ Identify implementation-independent components to models to
Logical more
achieve the services of the conceptual abstraction
Abstraction detailed
▪ E.g., business, data, application and technology components
models
Physical ▪ Find alternatives for allocation and implementation of
Abstraction physical components to meet the logical components
➢ Abstraction levels cross the Architecture Domains
TOGAF® is a registered trademark of The Open Group. Briefly describe how architecture abstraction can be used in Enterprise Architecture
Abstraction Levels vs. Levels of the Architecture Landscape
One or more Abstraction Levels describe the Levels of the Architecture Landscape
Levels of the Architecture Landscape Architecture Abstraction Levels
Contextual
Abstraction
Conceptual
Abstraction
Logical
Abstraction
Physical
Abstraction

Building Block – Definition
The potentially re-usable component delivers architectures and solutions
Exam
▪ Is a package of functionality defined to meet the business needs across an
organization (generally recognizable as "a thing" by domain experts)
▪ Has normally a type that corresponds to the Enterprise Metamodel (e.g., actor,
business service, application, data entity)
▪ Can be defined at various levels of detail, depending on the objectives of the

Enterprise Architecture and the architecture development stage
▪ Can lead to improvements in legacy system integration, interoperability and

flexibility in the creation of new systems and applications
➢ An organization must decide what arrangement of Building Blocks works best
TOGAF® is a registered trademark of The Open Group. Details: Object Management Group® Reusable Asset Specification Explain what building blocks are and their use in the ADM
Building Block – Characteristics
A good Building Block meets several criteria
Exam
Considers implementation Is re-usable and replaceable May be assembled from and

& usage and evolves to and well specified subassembly of other
exploit technology & Building Blocks
standards
May interoperate with other, inter- Should have defined boundaries

dependent Building Blocks based and specification which are loosely
on a published and stable interface coupled to its implementation (i.e.,
possible to realize a Building Block in
several ways)
TOGAF® is a registered trademark of The Open Group. Explain what building blocks are and their use in the ADM
Building Block – Architecture & Solution Building Blocks
ABBs and SBBs are special types of Building Blocks
Building Blocks (BBs)

Potentially re-usable component
Meet the business needs
Defined at various levels of detail
Architecture Building Blocks Solution Building Blocks

(ABBs) (SBBs)
Implement the
capability
Architectural components Solution components
Describe the required capability Realize the required capability
Logical or supplier- Shape the Physical or implementation-
independent specification specific

The TOGAF Standard – Introduction
TOGAF is a best practice framework for Enterprise Architecture
Exam
▪ Enterprise Architecture Framework to develop any kind of
architecture in any context
▪ Developed through the collaborative efforts of the community
▪ Can be applied for a range of use-cases

(e.g., agile enterprise, digital transformation)
▪ Describes a standard cycle of change, used to plan, develop,

implement, govern, change and sustain an architecture
▪ Describes the Building Blocks in an enterprise used to deliver

business services & information systems
TOGAF® is a registered trademark of The Open Group. Explain why the TOGAF Standard is suitable for use as a framework for Enterprise Architecture
The TOGAF Standard – Suitability
TOGAF is a suitable framework for Enterprise Architecture
Exam
▪ Enables organizations to operate in an efficient & effective way
using a proven and recognized set of best practices to address
business & technology trends
▪ Enables the organization to build workable & economic solutions
▪ Adds value, standardizes & de-risks architecture development
▪ Results in an Enterprise Architecture that is…

▪ consistent
▪ reflects the needs of stakeholders
▪ employs best practice
▪ considers current and future needs of the business
TOGAF® is a registered trademark of The Open Group. Explain why the TOGAF Standard is suitable for use as a framework for Enterprise Architecture
The TOGAF Standard – Tailoring & Integration
The generic framework can be tailored & integrated with other frameworks
Exam
▪ May adopt elements from other frameworks
▪ Allows the replacement or extension of its deliver-

ables by a more specific set (e.g., defined by other
frameworks)
▪ Allows the integration of TOGAF methods to

other standard frameworks or best practices
(e.g. ITIL®, COBIT®, PRINCE®)
▪ Should be tailored and integrated into the processes and organization structures
▪ May be used as a standalone framework

The TOGAF Standard – Structure & Documents
The Fundamental Content is covered by six documents
Exam
Introduction to the Guidelines for

Standard and its adapting the
Core Concepts TOGAF ADM
Iterative approach
to developing an
Enterprise Typical
Architecture. Architecture
deliverables
and how to
Collection of techniques to Organization, processes, classify, store
apply the TOGAF approach roles and responsibilities and re-use
and the Architecture to establish and operate them
Development Method (ADM) Enterprise Architecture
TOGAF® is a registered trademark of The Open Group. Describe where guidance on how to apply the TOGAF Standard is provided
The TOGAF Standard – ADM, Supporting Guidelines & Techniques
The TOGAF ADM is supported by an extended set of resources
TOGAF Fundamental TOGAF Series Guides White Papers & Guides

Content Documents Guidance on how to use and Classified and referenced in
▪ ADM adapt the ADM for specific the TOGAF Library
▪ ADM Techniques needs
▪ Applying the ADM
➢ Individual guidelines & techniques are described separately so that they can be
referenced from the relevant points in the Architecture Development Method (ADM)
TOGAF® is a registered trademark of The Open Group. Briefly describe how the ADM and Supporting Guidelines and Techniques relate to each other
The TOGAF Library – Overview
The portfolio of additional guidance material supports the practical application
Exam
▪ Accompanies the TOGAF Standard
▪ Offers guidance material to support the

practical application of TOGAF
▪ Contains guidelines, templates, patterns

and reference material
▪ Accelerates the creation of new

architectures for the enterprise
https://Publications.OpenGroup.org/ ▪ Maintained under the governance of The

TOGAF-Library Open Group Architecture Forum
TOGAF® is a registered trademark of The Open Group. Describe where guidance on how to apply the TOGAF Standard is provided
Enterprise Architecture – Purpose (1/2)
A framework for continuous change links strategic direction & business value
Exam
▪ Manages complexity & risks and supports Change
▪ Optimizes processes into an integrated environment that is responsive to change and

supportive of the delivery of the business strategy & mission
▪ Provides enterprises a strategic context for the evolution and reach of digital
capability in response to the changing needs of the business environment
▪ Achieves a balance between business transformation and operational efficiency
▪ Allows business units to innovate for business goals and competitive advantage
▪ Enables an integrated strategy with synergies across the enterprise and beyond
TOGAF® is a registered trademark of The Open Group. Explain the purpose of Enterprise Architecture
Enterprise Architecture – Purpose (2/2)
The business capability guides effective change to improve an enterprise
Exam
▪ Governs (directs and controls) the change activity
to realize the expected value
▪ Describes current and future state of an enterprise

as well as the gap
▪ Documents processes around personal data that

can be easily understood
▪ Addresses the end state, performs preference trade-

off and value realization for big and little questions
TOGAF® is a registered trademark of The Open Group. Explain the purpose of Enterprise Architecture
Enterprise Architecture – Benefits
Enterprise Architecture has several key benefits for an organization
Exam
Better return on existing More effective and efficient More effective strategic
investment & reduced risk digital transformation and decision-making by C-Level
for future investment operations executives & business
leaders
More effective and efficient Faster, simpler and cheaper Right balance across
business operations procurement conflicting demands
TOGAF® is a registered trademark of The Open Group. List the business benefits of having an Enterprise Architecture
Document outline
1 Welcome
4 Preliminary Phase

Architecture Development Method (ADM) – Overview (1/9)
The method develops & manages the lifecycle of an Enterprise Architecture
Exam
▪ Core of the TOGAF Standard
▪ Tested & repeatable process for developing architectures
▪ Establishes an architecture framework
▪ Develops architectures and architecture content
▪ Governs the realization & transition of architectures
▪ Iterative cycle of continuous architecture definition and

realization
▪ Transforms enterprises in a controlled manner in response

to business goals and opportunities
TOGAF® is a registered trademark of The Open Group. Briefly describe the ADM and its phases
The method develops & manages the lifecycle of an Enterprise Architecture
Exam
▪ Step-by-step approach with 10 phases (8 arranged in a cycle)
▪ Each phase is divided into steps
▪ Recommendations to define and deploy an EA
▪ Should be adapted to the needs of the enterprise and to

support different architecture styles
▪ Is not a „waterfall“ method and does not mandate a specific

sequence (Phases & Steps)
▪ Reference model:
▪ Deliver solutions in an architected way
▪ Identify interacting components and relationships
Preliminary Phase creates the architecture capability of an organization
Exam
Preliminary
Preliminary Phase
▪ Preparation and initiation activities that are required to

create an Architecture Capability
▪ Customize the TOGAF framework
▪ Define Architecture Principles
Phase A initializes an architecture development cycle
Exam
Phase A: Architecture Vision
▪ Initial phase of an architecture development cycle

A.
Architecture
Vision
▪ Define the scope of the architecture development
initiative
▪ Identify the stakeholders
▪ Create the Architecture Vision
▪ Obtain approval to proceed with the architecture

development
Phases B,C & D develop architectures to support the agreed Architecture Vision
Exam
Phase B: Business Architecture

&
Phase C: Information Systems Architectures
&
B. Phase D: Technology Architecture
Business
Architecture
▪ Develop Baseline & Target…

C. Data
Information Architecture
Systems
Architectures Application
▪ Business Architecture (Phase B),
Architecture
▪ Data & Application Architectures (Phase C) &
D.
▪ Technology Architecture(Phase D)
Technology
Architecture
to support the agreed Architecture Vision
Phases E & F plan the implementation and migration of the Target Architecture
Exam
Phase E: Opportunities and Solutions
▪ Conduct the initial implementation planning
▪ Identify delivery vehicles for the architecture defined in

the previous phases
Phase F: Migration Planning
▪ Describe how to move from the Baseline to the Target

F.
Migration Architectures
Planning E.
Opportunities
and
Solutions
▪ Finalize a detailed Implementation and Migration Plan
Phase G governs the implementation & Phase H supports the architecture change
Exam
Phase G: Implementation Governance
H. ▪ Provide an architectural oversight of the

Architecture
Change implementation
Management
G.
Implemen-
tation
Phase H: Architecture Change Management
Governance
▪ Establish procedures for managing change to the new

architecture
Briefly explain the ADM phases and their purpose

TOGAF® is a registered trademark of The Open Group. Briefly describe the ADM and its phases.
Requirements Management manages the requirements during an ADM cycle
Exam
Requirements Management
▪ Operates the process of managing architecture

requirements throughout the ADM
▪ Continuous phase for requirements management

Requirements
Management
▪ Ensures that any changes to requirements are
handled through appropriate governance processes
and are reflected in all other phases
Briefly explain the ADM phases and their purpose

TOGAF® is a registered trademark of The Open Group. Briefly describe the ADM and its phases.
The method develops and manages the lifecycle of an Enterprise Architecture
Exam
▪ Each phase generates an output
▪ Status of outputs at each stage is defined
▪ Output from an early phase may be modified in a later

phase
ADM – Artifact
The architectural work product describes aspects of the Enterprise Architecture
➢ Artifacts can be classified as catalogs, matrices or diagrams

ID Business Capability Category
BC_01 Customer Relationship Management Sales and Services
BC_02 Customer Portfolio Management Sales and Services
BC_03 Business Partner Management Sales and Services
BC_04 Human Resources Management Support
BC_05 Facility Management Support
BC_06 Risk Management Support
BC_07 Accouting Support
Catalogs: List of things Diagrams: Picture of things

(e.g., Business Capability Catalog) (e.g., Organization Map)
Matrices: Relationships between things (e.g., Capability / Organization Matrix)

ADM – Deliverable
The architectural work products is contractually specified and approved
▪ Is formally reviewed, approved and signed off by the

stakeholders
▪ Is usually a document (e.g., Architecture Definition

Document)
▪ Represents the output of projects and is archived at

completion
▪ May be transitioned into an Architecture Repository

(e.g. Reference Model, Standard)

ADM – Relationship between Artifacts & Deliverables
Deliverables contain Artifacts & are managed through a version numbering policy
Exam
Deliverable Definition Draft

Architecture Definition Document Documents that are under development
and have not undergone any formal
Artifact review and approval process.
Business Capability Map
Definition Approved
Artifact Documents that have been reviewed
Process Flow Diagram and approved.
Artifact
Approved ≠ finalized: Approved
Use-Case Diagram
Documents…
Artifact ▪ may evolve during subsequent ADM phases
… ▪ may only be changed through a change
control & governance process
TOGAF® is a registered trademark of The Open Group. Describe the difference between "draft" and 'approved" deliverables
Key concepts – Stakeholder
Stakeholder have interest in a system
Exam
▪ Represents an individual, team, organization, or
class thereof, having an interest in a system
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: stakeholders
Source: Adapted from ISO/IEC/IEEE 42010: 2011 and ISO/IEC/IEEE 15288: 2015
Key concepts – Concern
Concern is an interest in a system to stakeholders
Exam
▪ Represents an interest in a system relevant to one
or more of its stakeholders and their goals
▪ May pertain to any aspect of the system’s

functioning, development or operation, including
considerations such as performance, reliability,
security, distribution and evolvability
▪ May determine the acceptability of the system
▪ Can be a general requirement type (e.g., availability)
▪ May lead to the definition of several requirements
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: concerns
Key concepts – Relationship between stakeholder and concern
Stakeholders‘ concerns lead to requirements
Exam
▪ Identifying concerns helps ensure stakeholders’
interests are addressed and requirements are
identified
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: stakeholders, concerns
Key concepts – Architecture Viewpoint
(Architecture) Viewpoint represents where you are looking from on a system
Exam
▪ Represents the vantage point or perspective that
determines what can be see of a system
▪ Defines conventions for constructing, interpreting

and using an architecture view to address specific
concern(s) about a system-of interest
▪ Can also be called the definition or schema for that

kind of architecture view
▪ Is generic and can be stored in viewpoint libraries

for re-use
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: architecture viewpoints
Key concepts – Architecture View
(Architecture) View represents what you see of a system
Exam
▪ Is a representation of a system from the
perspective of a related set of concerns
▪ Consists of one or more architecture models of

the system
▪ Is always specific to the architecture for which it is

created and meaningful to stakeholders
▪ Enables the architecture to be communicated to

and understood by the stakeholders
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: architecture views
Key concepts – Relationship between Viewpoint and View
An (Architecture) View is rooted in an (Architecture) Viewpoint
Exam
▪ Every architecture view has an associated
architecture viewpoint that describes it, at least
implicitly
TOGAF® is a registered trademark of The Open Group. Define and explain the following key concepts: architecture views, architecture viewpoints,
Document outline
1 Welcome
4 Preliminary Phase

ADM – Preliminary Phase – Purpose
The phase creates the Architecture Capability of an enterprise
Exam
Preliminary
▪ Preparation and initiation activities to create an

Architecture Capability
▪ Customizing the TOGAF framework
▪ Definition of Architecture Principles
Briefly explain the purpose of the Preliminary Phase

in developing an Enterprise Architecture Capability
ADM – Preliminary Phase – Objectives
The phase determines the target maturity & establishes the Architecture Capability
Exam
1. Determine the Architecture Capability desired by the
Preliminary
organization
▪ Review the organizational context for conducting EA
▪ Identify and scope the elements of the enterprise
organizations affected by the Architecture Capability
▪ Identify the established frameworks, methods and
processes that intersect with the Architecture Capability
▪ Establish a Capability Maturity target
2. Establish the Architecture Capability
▪ Define and establish the Organizational Model for
Enterprise Architecture
▪ Define and establish the detailed process and resources
for Architecture Governance
▪ Select and implement tools that support the Architecture
Capability
▪ Define the Architecture Principles
TOGAF® is a registered trademark of The Open Group. Describe the objectives of the Preliminary Phase
ADM – Preliminary Phase – Steps
The phase defines "where, what, why, who and how you do architecture"
Preliminary 1 Scope the enterprise organizations impacted
2 Confirm governance and support frameworks
Define and establish Enterprise Architecture

3
team and organization
4 Identify and establish Architecture Principles
Tailor the TOGAF framework and, if any, other

5
selected architecture frameworks
Develop a strategy and implementation plan for
6
tools and techniques

ADM – Preliminary Phase – Architecture Principles
Architecture Principles are developed in the Preliminary Phase
Preliminary 1 Scope the enterprise organizations impacted
2 Confirm governance and support frameworks
Define and establish Enterprise Architecture

3
team and organization
4 Identify and establish Architecture Principles
Tailor the TOGAF framework and, if any, other

5
selected architecture frameworks
Develop a strategy and implementation plan for
6
tools and techniques

Architecture Principles – Definition (1/2)
Architecture Principles guide the development & maintenance of the EA
Exam
▪ Guide architecture development as part of the
Architecture Principles
Principles Catalog
Business Principles
▪ Define the underlying general rules & guidelines for
the use of resources and assets Data Principles
Application Principles
▪ Form the basis for making architecture decisions
Technology Principles
▪ Are intended to be enduring and seldom amended
▪ Reflect a level of consensus among the various elements of the enterprise
▪ Relate back to the business objectives and key architecture drivers

Briefly describe the TOGAF Standard deliverables created and consumed in different TOGAF
ADM phases: Architecture Principles
Architecture Principles – Definition (2/2)
The ADM technique aligns target architecture & implementation with the business
Exam
▪ Influenced by emerging industry trends, enterprise mission & plans, enterprise
strategic initiatives, current systems & technology and external constraints
▪ Provide a foundation for making architecture & planning decisions, framing policies,
procedures & standards and supporting resolution of conflicting situations
▪ Typically developed by the Enterprise Architects in conjunction with key

stakeholders, being approved by the Architecture Board afterwards
▪ Altered and removed through an amendment process after initial ratification
▪ Few in number, future-oriented and endorsed & championed by senior management
TOGAF® is a registered trademark of The Open Group. Explain what makes a good Architecture Principle
Architecture Principles – Principle hierarchy
Enterprise Principles set bounds for principles on lower levels
▪ The hierarchy of principles starts

with the overarching Enterprise
Enterprise Principles
Principles
▪ At each hierarchical level, the
principles will be elaborate on the
Segment Segment principles inherited from the
Principles Principles level above
▪ A lower-level principle cannot

Architecture Other Other overstep the boundaries of a
Principles Principles Principles higher-level principle

Architecture Principles – Principle key domains
Principles may be established within different domains and at different levels
Enterprise Principles Architecture Principles
▪ Provide a basis for decision-making ▪ Relate to Architecture Work

throughout an enterprise
▪ Govern the architecture process (i.e.,
▪ Inform & support how an organization development, maintenance and use of
sets about fulfilling its mission the Enterprise Architecture)
▪ Are a key element in a successful ▪ Embody the spirit and thinking of

Architecture Governance strategy existing Enterprise Principles
▪ Can have subsidiary principles within

a business or organizational unit

Architecture Principles – Structure
A template helps to define and use principles in a standard way
Exam
▪ Represents the essence of the principle
Name
▪ Is easy to remember
State-
▪ Communicates succinctly and unambiguously the fundamental rule
ment
Rationale Implications
▪ Highlights the business benefits of ad- ▪ Highlight the requirements for carrying
hering to the principle in business terms out the principle in terms of resources,
costs and activities
▪ Describes relationship to other principles,
esp. where tradeoffs will be required ▪ State the impact to business and
consequences of adopting the principle
▪ Gives guidance toward a balanced and
consistent interpretation ▪ Answer the “How does this affect me?”
question of the reader
TOGAF® is a registered trademark of The Open Group. Explain the recommended template for Architecture Principles
Architecture Principles – Example
Business Principle: Compliance
Name Compliance with Law
State- Enterprise information management processes comply with all

ment relevant laws, policies and regulations.
Rationale Implications
▪ Enterprise policy is to abide by laws, ▪ Comply with laws, regulations and
policies and regulations. external policies regarding the collection,
retention and management of data
▪ This will not preclude business process
improvements that lead to changes in ▪ Education and access to the rules
policies and regulations.
▪ Changes in the law and changes in
regulations may drive changes in the
business processes or applications

Architecture Principles – Characteristics
Five criteria distinguish a good set of principles
Exam
Complete Consistent Stable

Each principle is defined and Expressed in a way that allows a Principles should be
every situation perceived is balance of flexible interpretations enduring, yet able to
covered without contradictions accommodate changes
Understandable Robust
Intentions of the principles are clear, Enable good quality and consistent decisions
understandable & unambiguous so that about architectures, plans enforceable
(unintended) violations are minimized policies as well as standards to be created in
complex situations
TOGAF® is a registered trademark of The Open Group. Explain what makes a good Architecture Principle
Architecture Principles – Purpose
The enduring guidelines address different purposes
Enable decision-making Align the enterprise

Set precedence during trade-off discussions Take subjectivity & bias out and drive critical
and authority of tie-breaking conversations aligned with the enterprise’s value
Support governance Reflect value & culture

Ensure that the right decisions are made at Provide understanding about the enterprise’s
the right time with the right decision-makers culture and values as well as an insight into
and that these decisions are monitored how well the enterprise reacts to change
TOGAF® is a registered trademark of The Open Group. Explain the purpose of Architecture Principles
Architecture Principles – Usage within the TOGAF ADM
Principles are created in the Preliminary Phase and used in Phases A, B, C & D
Exam
Identify, define & establish (based on enterprise
principles and organizational context)
Review, clarify (esp. definition & areas of ambiguity),

elaborate & confirm existing Principles (or generate new, if
necessary)
Review & validate (or generate, if necessary) Principles

and ensure alignment between the Target
Architectures and Architecture Principles
Briefly describe the TOGAF Standard deliverables created and consumed in different TOGAF ADM phases:
Architecture Principles
ADM – Preliminary Phase – Approach
The phase defines "where, what, why, who and how we do architecture"
Preliminary
▪ Define the enterprise

▪ Identify key drivers and the organizational context
▪ Define the requirements for architecture work
▪ Define the Architecture Principles
▪ Define the framework to be used
▪ Define the relationships between management
frameworks
▪ Evaluate the Enterprise Architecture maturity
▪ Determine the Architecture Capability desired by
the organization

Document outline
1 Welcome
4 Preliminary Phase

ADM – Phase A: Architecture Vision – Purpose
The phase creates the Architecture Vision & establishes the Architecture Project
Exam
▪ Initial phase of the Architecture Development Cycle

A.
Architecture
Vision ▪ Defining the scope (problem & project)
▪ Identify stakeholders & concerns
▪ Create an Architecture Vision (summary answer to

the problem & value)
▪ Obtain approval to proceed
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase A
ADM – Phase A: Architecture Vision – Objectives
The phase develops the Architecture Vision & Statement of Architecture Work
Exam
1.Develop a high-level aspirational vision of the

A. capabilities and business value to be delivered as a
Architecture
Vision result of the proposed Enterprise Architecture
2.Obtain approval for a Statement of Architecture Work

that defines a program of works to develop and
deploy the architecture outlined in the Architecture
Vision
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase A
ADM – Phase A: Architecture Vision – Steps (1/2)
The phase creates the Vision, Statement of Architecture Work & secures approval
1 Establish the architecture project
Identify stakeholders, concerns and business

2
A. requirements
Architecture
Vision
Confirm and elaborate business goals,
3
business drivers and constraints
4 Evaluate capabilities
5 Assess readiness for business transformation
6 Define scope

ADM – Phase A: Architecture Vision – Steps (2/2)
The phase creates the Vision, Statement of Architecture Work & secures approval
Confirm and elaborate Architecture Principles,

7
including business principles
8 Develop Architecture Vision

A.
Architecture
Vision
Define the Target Architecture value
9
propositions and KPIs
Identify the business transformation risks and
10
mitigation activities
Develop Statement of Architecture Work;
11
secure approval

ADM – Phase A: Architecture Vision – Request for Architecture Work
The phase begins with the receipt of a Request for Architecture Work

Request for
Architecture
Work
2
A. requirements
Architecture
Vision
3
6 Define scope

Request for Architecture Work – Definition
The official document triggers the start of an architecture development cycle
Exam
▪ High-level document that is sent from the sponsoring to the architecture
organization triggering the start of an architecture development cycle
Purpose
▪ Created as output of the Preliminary Phase, results of an approved architecture

Change Requests or is generated as terms of reference for architecture work
originating from migration planning
▪ Organization sponsors, mission statements, budget information, constraints

Content
▪ Business goals, strategic plans, changes in environment, time limits, constraints
▪ Business system, IT system and architecture description
▪ Developing organization including resources

Request for Architecture Work
Request for Architecture Work – Structure
All the information in the document should be at a high level

Request for Architecture Work – Usage within the TOGAF ADM
The deliverable is created in the Preliminary Phase, Phase F and H
Exam
Create as the sponsoring
organization as optional output
Use or generate as result of
approved architecture Receive as the architecture
Change Requests organization & use as input
Use as input
Use as input
Use as input
Generate as terms of reference

for architecture work
Use as input
Use as input
ADM – Phase A: Architecture Vision – Communications Plan
The communications plan is derived from a stakeholder map

2
A. requirements
Architecture
Vision
3
6 Define scope

Communications Plan – Definition
The deliverable defines how architecture information reaches the stakeholders
Exam
▪ Allows communication for to be carried out within a planned and managed
process
Purpose
▪ Ensures effective communication of targeted information to the right

stakeholders at the right time as critical success factor for Enterprise Architecture
▪ Stakeholders (e.g., grouping by communication requirements)

Content
▪ Information (e.g., needs, key messages for the vision, risks, success factors)
▪ Mechanisms (e.g., meetings, newsletters, repositories)
▪ Timetable (e.g., stakeholder <> time <> location)

Explain the outputs necessary to proceed with the architecture development work:
Communications Plan
Communications Plan – Structure
The document defines the “who, what, how and when” of communication

Communications Plan – Usage within the TOGAF ADM
The deliverable is created in Phase A and used throughout Phase B till F
Exam
Create & show where, how

and when the Enterprise Architects will
communicate with the stakeholders
Use as input
Use as input
Use as input
Use as input
Use as input
Communications Plan
ADM – Phase A: Architecture Vision – Business Scenarios
Business Scenarios are a source for business requirements

2
A. requirements
Architecture
Vision
3
6 Define scope

Business Scenarios – Definition
The technique identifies, documents & understands the business needs
Exam
▪ Derive the characteristics of the architecture from the
high-level requirements of the business to achieve
desired business outcomes
▪ Consider business value, outcomes & Value Streams and

the required resources to understand the requirements in
any industry (e.g., healthcare, transportation, oil)
▪ Can be applied to very large general problems areas

(e.g., standards for national lotteries) and very small
focused problem areas (e.g., retail point of sale upgrades)
TOGAF® is a registered trademark of The Open Group. Briefly explain business scenarios
Business Scenarios – Key elements (1/2)
The technique uses a uniform description for business requirements
Exam
Real business problem Business and technology Desired outcome(s) of

environment in which the proper execution
problem occurs
Human actor(s) Computer actor(s)

who provide the capabilities who support the capabilities
➢ Not examining all elements of a Business Scenario

carries a risk of producing an incomplete solution
Business Scenarios – Key elements (2/2)
A good Business Scenario contains SMART outcomes
Exam
S M A R T
Specific Measurable Actionable Realistic Time-bound
by defining through clear by segmenting if the problem with a clear

what needs to metrics for the problem can be solved statement of
be done in the success and providing within the when the
business the basis for bounds of solution
determining physical opportunity
elements & reality, time expires
plans for the and cost
solution constraints
Business Scenarios – Development phases & steps
Each key element is iteratively refined through phases, steps & activities
Exam
▪ Three successive phases capture, examine and improve
the key elements of the Business Scenario
▪ Each phase requires the steps planning, information

gathering, analysis, documentation and review consisting
of several activities
▪ All phases are repeated through iterations until the under-

standing is fit-for-purpose for deciding to move forward
▪ The resulting Business Scenario is valid at a specific

point in time and should be updated to reflect changes
TOGAF® is a registered trademark of The Open Group. Describe what a TOGAF business scenario is and its purpose
Business Scenarios – Differentiation
The technique differs from other business concepts
▪ Use-cases (e.g., OMG, Rational Software): Detailed descriptions of human to

computer interaction being typically used in software development
▪ Business Models/cases/scenario plans: A Business Scenario can be informed by a

company’s Business Model and a SMART Business Scenario can inform a Business
Model/case/scenario plan
▪ SPIN (Situation, Problem, Implication, Need-Payoff): Sales technique that can be

used to gather information for a Business Scenario and the Business Scenario can
provide relevant “context” for a SPIN engagement
▪ Engineering specifications (e.g., IEEE): Detailed, material-specific and tied to science
Business Scenarios – Benefits
The technique creates value at an early stage in the Architecture Project
Provide a common language Enable all requirements to Gain the buy-in of

with which the commercial be viewed in relation to one stakeholders (esp.: business
(software) vendor another in the context of the line management) to the
community can link overall problem, its solution Architecture Project and the
customer problems to their and the business value resulting Enterprise
solutions while drawing on Architecture
open standards & skills

Business Scenarios – Usage within the TOGAF ADM
The technique is used in ADM Phases A & B and Requirements Management
Discover & document business
requirements for establishing an Discover & document business
Enterprise Architecture capability requirements and deriving an
Architecture Vision
Discover & document

Discover & document
business requirements and
business requirements
iteratively decomposing the
and provide them for all
Business Architecture at
phases of an ADM
different levels of detail
lifecycle
ADM – Phase A – Architecture Requirements Specification
The phase documents the requirements that are in scope of the project

2
A. requirements
Architecture
Vision
3
6 Define scope

Architecture Requirements Specification – Definition
The quantitative view of the solution states the criteria that must be met
Exam
▪ Defines a set of quantitative statements that outline what an implementation
project must do to comply with the architecture
Purpose
▪ Is a major part of an implementation contract or contract for Architecture

Definition
▪ Acts as companion to the Architecture Definition Document (= qualitative view)
▪ Architecture, Interoperability & IT Service Management requirements

Content
▪ Business & Application service contracts
▪ Implementation guidelines, specifications & standards
▪ Success measures, Constraints, Assumptions

Architecture Requirements Specification
Architecture Requirements Specification – Structure
The deliverable complements the Architecture Definition Document

Architecture Requirements Spec. – Usage within the TOGAF ADM (1/2)
The deliverable is created in Phase A and complemented during Phase B till D
Exam
Draft & Document new requirements generated for future
architecture work
Draft including Business Architecture requirements
Draft including Data Architecture requirements
Draft including Application Architecture requirements
Draft including Technology Architecture requirements
Architecture Requirements Spec. – Usage within the TOGAF ADM (2/2)
The deliverable is used in Phase G & H and populated in Requirements Mgmt.
Exam
Populate & update with architecture requirements
Use as input
Use as input
Finalize
Update with any additional relevant outcomes
ADM – Phase A: Architecture Vision – Principles, Goals & Drivers
The phase explores the contextual surroundings of the Architecture Project

2
A. requirements
Architecture
Vision
3
6 Define scope

Business Principles, Goals & Drivers – Definition
The concepts provide the business context for the architecture work
Exam
▪ Describe the needs and ways of working within the enterprise
Purpose
▪ May have significant implications for the way that architecture is developed,
although being outside the consideration of the architecture discipline
▪ Business principles, business goals and business drivers

Content
▪ Vary considerably from one organization to the next
Business Principles, Business Goals and Business Drivers
Business Principles, Goals & Drivers – Structure
The content & structure of business context for architecture is likely to vary

Business Principles, Goals & Drivers – Usage within the TOGAF ADM
The concepts are clarified in Phase A and used throughout Phase B till D
Exam
Confirm as intentions and culture of the organization
Confirm, clarify & refine any areas of ambiguity
Use as input for selecting relevant Business Architecture

resources & Validate
Use as input for selecting relevant Data Architecture
Use as input for selection of relevant Application
Architecture resources & Validate
Use as input for selecting relevant Technology Architecture

Business Principles, Business Goals and Business Drivers
ADM – Phase A: Architecture Vision – Capability Assessment
The phase performs a Capability Assessment to evaluate capabilities

2
A. requirements
Architecture
Vision
3
6 Define scope

Capability Assessment – Definition (1/2)
The deliverable captures the baseline & target capability level of the enterprise
Exam
Can be examined on several capability levels:
▪ Enterprise, e.g., architectural focus areas
▪ IT function, e.g., design governance, operational governance, skills and

organization structure or style, formality and detail for the architecture project
Purpose
▪ Architecture function, e.g., architectural assets, standards and reference models,

re-usable assets
▪ Capability gaps, e.g., business readiness, risks to transformation, cultural barriers
Capability Assessment
Capability Assessment – Definition (2/2)
The deliverable is a prerequisite for a detailed architecture definition
Exam
▪ Business Capability Assessment, including baseline state assessment & future
state aspiration regarding performance and realization; impacts to the organization
▪ IT Capability Assessment, including baseline & target maturity level of change and
operational processes; baseline capacity & capability; impacts to the organization
Content
▪ Architecture maturity assessment, including Architecture Governance; re-use

potential; Architecture skills; landscape, standards and reference model definition
▪ Business Transformation Readiness Assessment, including readiness factors

and particular vision; current and target readiness ratings; readiness risks
Capability Assessment – Structure
A template supports the capturing & documentation of the capabilities

Capability Assessment – Usage within the TOGAF ADM
The deliverable is created in Phase A and used throughout Phase B till G
Exam
Document the baseline & target

capability level of the enterprise
Use as input to understand the Use as input to capability level

maturity of the architecture of the enterprise as a whole
function Use as input to understand the
maturity level of the IT function
Use as input to understand to

what extent is the business is
ready to transform
Use as input to understand Use as input
where capability gaps exist
ADM – Phase A – Business Transformation Readiness Assessment
The technique evaluates the organization's readiness to undergo change

2
A. requirements
Architecture
Vision
3
6 Define scope

Business Transformation Readiness Assessment – Motivation
The technique assesses an organization’s readiness for business transformation
Exam
▪ Enterprise Architecture will entail considerable
change
▪ Innovative and sound architecture plans could lead

to nowhere, if there is a change-averse culture
and a narrowly skilled workforce
▪ Need for understanding the readiness of the

Image source: Pexels.com / Tom Fisk
organization to accept change, identifying the
issues and then dealing with them
▪ Business Transformation Readiness Assessment as a joint effort between

corporate staff (especially human resources), lines of business and IT planners
TOGAF® is a registered trademark of The Open Group. Explain Business Transformation Readiness Assessment and where it can be used in the ADM
Business Transformation Readiness Assessment – Approach
The ADM technique assesses an organization’s readiness through five activities
Exam
1. Determine the readiness factors that will impact the organization
2. Present the readiness factors using maturity models
3. Assess the readiness factors, including determination of readiness factor ratings
4. Assess the risks for each readiness factor and identify mitigation actions
5. Work these actions into Phase E and F Implementation and Migration Plan
> There are many dimensions to change,

but by far the most important is the human element
Business Transformation Readiness Assessment – Example
The TOGAF Standard provides templates & tools for the ADM technique
Maturity Model for the Data Architecture
Summary table as management overview

Business Transformation Readiness Assessment – BTEP Method
The complementary method helps identifying business transformation issues
Exam
▪ Canadian Government Business Transformation
Enablement Program (BTEP) method provides
guidance on how to identify business
transformation-related issues
▪ All projects conduct a transformation readiness

assessment based on defined readiness factors
to uncover the business transformation issues
Image source: Government of Canada Publications
▪ Outcome is a deep understanding of the

challenges and opportunities with many of them
translating into risks
Business Tr. Readiness Assessment – Usage within the TOGAF ADM
The deliverable is created in Phase A and used in Phase E, F and G
Create, when conducting a

business assessment
Monitor the readiness factors
and take corrective actions
Review & determine impact

on the Architecture Roadmap
and Implementation &
Migration Plan
Review & determine impact on
the Architecture Roadmap and
Implementation & Migration
Plan
ADM – Phase A: Architecture Vision – Architecture Vision
The deliverable contains a high-level aspirational vision of the capabilities & value

7

A.
Architecture
Vision
9
10
11
secure approval

ADM Phase A: Architecture Vision – Definition
The early summary version of the full Architecture Definition eases communication
Exam
▪ Contains a summary of the changes to the enterprise after the successful
deployment of the Target Architecture
Purpose
▪ Provides stakeholders with a formally agreed outcome and communication

basis early in the ADM cycle
▪ Serves as a basis to develop the Domain Architectures (BDAT)
▪ Problem description (stakeholder and concerns, list of issues/scenarios)

Content
▪ Objective of the Statement of Architecture Work
▪ Summary views (e.g., value chain diagram, solution concept diagram)
▪ Mapped requirements and reference to draft Architecture Definition Document

Explain the outputs necessary to proceed with the architecture development work:
Architecture Vision
Architecture Vision – Structure
The document provides key stakeholders with a formally agreed outcome

Architecture Vision – Usage within the TOGAF ADM (1/2)
The deliverable is created in Phase A and used throughout Phase B till D
Exam
Create with relevant concerns and viewpoints
Use for Target Business Architecture development
Use for Target Data Architecture development
Use for Target Application Architecture development
Use for Target Technology Architecture development
Architecture Vision
Architecture Vision – Usage within the TOGAF ADM (2/2)
The deliverable is refined in Phase E and used in Phase G
Manage requirements
Use & update (post-implementation)
Refine & update with any additional relevant

outcomes
Architecture Vision
ADM – Phase A: Architecture Vision – Architecture Definition Document
The deliverable acts as container for the core architectural artifacts

2
A. requirements
Architecture
Vision
3
6 Define scope

Architecture Definition Document – Definition (1/2)
The deliverable is a qualitative view of the solution communicating the intent
Exam
▪ Works as deliverable container for the core architectural artifacts created during
a project and important related information
▪ Qualitative view of the solution
▪ Spans all architecture domains (Business, Data, Application and Technology)

Purpose
▪ Examines all relevant states of the architecture (Baseline, Transition and Target)
▪ Aims to communicate the intent of the architects
▪ Acts a companion to the Architecture Requirements Specification (=

quantitative view)
Architecture Definition Document
Architecture Definition Document – Definition (2/2)
The deliverable is a qualitative view of the solution communicating the intent
Exam
▪ Scope, Goals, Objectives & Constraints,
Architecture Principles, Baseline & Target
Architecture, Gap analysis, Impact assessment
▪ Architecture Models for all domains
▪ Rationale and justification for architectural

Content
approach
▪ Mapping to Architecture Repository (Architecture

Landscape, reference models, standards, re-use
assessment)
▪ Transition architectures (definition, business, data,

application, technology)
Architecture Definition Document – Structure
The container keeps architectural artifacts created during the project
▪ The document contains complementary artifacts representing Architecture Views on

the Building Blocks

Architecture Definition Document – Usage within the TOGAF ADM (1/2)
The deliverable is created in Phase A and enriched through Phase B, C and D
Exam
Draft (may include Baseline and/or Target
Architectures of any architecture domain)
Create, update & review (esp. rationale for Building Block

decisions, business architecture sections with key views)

decisions, data architecture sections with key views)

decisions, application architecture sections with key views)

decisions, technology architecture sections with key views)
Architecture Definition Document – Usage within the TOGAF ADM (2/2)
The deliverable is finalized in Phase F and used throughout Phase G
Exam
Use & update (post-implementation)
Finalize (may include assigning project

objectives and aligning projects and their deliverables
with the Transition Architectures)
Update with any additional relevant outcomes
ADM – Phase A: Architecture Vision – Statement of Architecture Work
The deliverable documents all findings & results and serves as a contract

7

A.
Architecture
Vision
9
10
11
secure approval

Statement of Architecture Work – Definition
The deliverable measures the execution success of the Architecture Project
Exam
▪ Defines scope & approach being used for an architecture development cycle
Purpose
▪ May form the basis for a contractual agreement between the supplier and
consumer of architecture services
▪ Title, approvals, change of scope procedures

Content
▪ Architecture project request, background, description, scope, plan & schedule
▪ Acceptance criteria and procedures, roles, responsibilities and deliverables
▪ Overview of Architecture Vision

Statement of Architecture Work
Statement of Architecture Work – Structure
The deliverable answers the Request for Architecture Work

Statement of Architecture Work – Usage within the TOGAF ADM
The deliverable is created in Phase A and used throughout Phase B till H
Exam
Use Create, review & approve as

scope and approach for an
architecture development cycle
Use & update, if necessary Use & update, if necessary
Use & update, if necessary

Use
Use
Statement of Architecture Work
ADM – Phase A: Architecture Vision – Approach (1/2)
The phase builds consensus about the Architecture Vision with the sponsors
▪ Receive a Request for Architecture Work
▪ Define what is in and what is outside the scope of the

A. architecture effort and constraints
Architecture
Vision
▪ Obtain, verify and understand the documented

business principles, business goals, strategic drivers
and architecture principles (preliminary phase) and
ensure that existing definitions are current
▪ Describe Baseline and Target Architectures for all

domains (Business, Data, Application, Technology) on
a High-level

ADM – Phase A: Architecture Vision – Approach (2/2)
The phase builds consensus about the Architecture Vision with the sponsors
▪ Define and document an overview of the Architecture

Vision in the Statement of Architecture Work (incl. how
new business capabilities will meet business goals &
A. strategic objectives and address stakeholder’s
Architecture
Vision concerns)
▪ Use Architecture Vision to communicate the benefits of

the proposed business capability to stakeholders and
decision-makers
▪ Get the Statement of Architecture Work signed by the

sponsoring organization

Document outline
1 Welcome
4 Preliminary Phase
7 Phase C: Information Systems Architecture

ADM – Phase B: Business Architecture – Purpose (1/2)
The phase is a prerequisite for architecture work in any other domain
Exam
▪ Develop a Business Architecture to support an

agreed Architecture Vision
▪ Show how the current Enterprise fails to meet the

B.
Stakeholders preferences
Business
Architecture
▪ Identify necessary changes to meet Stakeholder
preferences (Gaps)
▪ Definition of the required work to realize the changes

and the added value of the changes (Work Packages)
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phases B, C and D
ADM – Phase B: Business Architecture – Purpose (2/2)
The phase is a prerequisite for architecture work in any other domain
Exam
▪ Manage stakeholder priority and preference adjusted to

value, effort and risk (Stakeholder Requirements)
▪ Make sure, that Gaps, Work, Added Value and Risks

B.
are understood by the stakeholders
Business
Architecture
▪ Output & Outcome: Business Architecture approved
by the stakeholders for the problem being addressed,
with a set of gaps and work to clear the gaps
understood by the stakeholders
Phase B, C and D have the “same” purpose
ADM – Phase B: Business Architecture – Objectives
The phase develops the Target Architecture & identifies Roadmap components
Exam
1.Develop the Target Business Architecture that

describes how the enterprise needs to operate to
B.
achieve the business goals and respond to the
Business
Architecture
strategic drivers set out in the Architecture Vision,
in a way that addresses the Statement of
Architecture Work and stakeholder concerns
2.Identify candidate Architecture Roadmap

components based upon gaps between the Baseline
and Target Business Architectures
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase B
ADM – Phase B: Business Architecture – Steps (1/2)
The phase performs a gap analysis between the Baseline & Target Architecture
1 Select reference models, viewpoints and tools
Develop Baseline Business Architecture

2
Description
B. Develop Target Business Architecture
Business 3
Architecture Description
4 Perform gap analysis
5 Define candidate roadmap components
Resolve impacts across the Architecture

6
Landscape

ADM – Phase B: Business Architecture – Steps (2/2)
The phase performs a gap analysis between the Baseline & Target Architecture
7 Conduct formal stakeholder review
8 Finalize the Business Architecture
B. Create/Update the Architecture Definition

Business 9
Architecture Document
In phase B, C and D, follow the same steps

ADM – Phase B: Business Architecture – Gap Analysis
The technique identifies gaps between the Baseline & Target Business Architecture
Develop Baseline Business Architecture

2
Description
B. Develop Target Business Architecture
Business 3

6
Landscape

Gap Analysis – Technique
A Gap defines what must be changed within the enterprise
Exam
Baseline Architecture Gap Target Architecture

Current state acting as Future state that
reference for all change stakeholders have approved
Shortfall between Baseline Architecture and Target Architecture

with items that have been deliberately
omitted, accidentally left out or not yet defined
TOGAF® is a registered trademark of The Open Group. Explain the purpose of gap analysis
Gap Analysis – Gap sources
Architecture gaps can be found in every Architecture Domain
Business
People, process, tools, information, measurement, financial, facility
Data
Currency, location, availability, creation, consumption, relations, need
Application
Creation, elimination, impact
Technology
Creation, elimination, impact
➢ Ignored stakeholder concerns are the most critical source of gaps
TOGAF® is a registered trademark of The Open Group. Explain the purpose of gap analysis
Gap Analysis – Example 1 (1/2)
The technique visually compares the Baseline with the Target Architecture
1. Create Matrix (ABBs of Target Architecture on

horizontal axis, ABBs Baseline Architecture on
vertical axis)
2. Add row “New” & column “Eliminated”
3. For each Architecture Building Block (ABB)

of the Baseline Architecture, check whether it
is included in the Target Architecture
▪ Yes? Record “Included” at the intersection
▪ No? Record “Intentionally eliminated” or
“Unintentionally eliminated” at the column
“Eliminated”

Gap Analysis – Example 1 (2/2)
The technique visually compares the Baseline with the Target Architecture
4. For each Architecture Building Block (ABB)

of the Target Architecture, check whether it is
included in the Baseline Architecture
4. Yes? You should have already recorded
"Included" in the intersection
5. No? Record the gap at the row “New”
➢ Anything in the row “New” or column

“Eliminated” is a gap between Baseline and
Target Architecture

Gap Analysis – Example 2
The technique supports long-term compliance reporting
Reporting against constraints, expected value and known gaps
Considering
Assessment
of Baseline,
results with
Project and
color coding
Planning
TOGAF® is a registered trademark of The Open Group. Briefly explain gap analysis
Gap Analysis – Usage within the TOGAF ADM (1/2)
The technique is widely used throughout all cyclic ADM phases
Perform Gap Analysis between Baseline and Target


Information Systems Architectures


Gap Analysis – Usage within the TOGAF ADM (2/2)
The technique is widely used throughout all cyclic ADM phases
Use as input & Perform Gap Analysis of the

performance of the Enterprise Architecture
Use as input & Perform Gap Analysis on Enterprise

Architecture and solutions framework as well as
Solution Architecture and operations
Use as input
Review & Consolidate Gap Analysis results

ADM – Phase B: Business Architecture – Approach (1/2)
Business Architecture is the first architecture activity that needs to be done
▪ Prerequisite for architecture work of BDAT-Architecture
▪ Means of demonstrating the business value and return

on investment of subsequent architecture work to key
stakeholders
B.
Business
Architecture
▪ Case 1: Parts of the Business Architecture are already
done >> Verify and update the documented material
and bridge between high-level and specific
requirements
▪ Case 2: Little or no Business Architecture is done >>

Research, verify and gain buy-in to key business
objectives and processes

ADM – Phase B: Business Architecture – Approach (2/2)
The re-use of internal and external material saves time
▪ Re-use existing material and descriptions (e.g.,

Architecture Definition Document)
▪ Use and update existing architecture descriptions
(Phase A) and/or gather information to develop the
Business Architecture models
B. ▪ Determine if fundamental view of the business is
Business
Architecture changing
▪ Develop Business Architecture models (e.g. Business
Capability Map, Value Stream Model, Organization
Map, Business Process Models) and applying (industry
specific) Modeling Techniques (e.g., UML®)
▪ Use resources from the Architecture Repository
(industry reference models, applicable standards,
enterprise-specific business architecture views and
Building Blocks)

Document outline
1 Welcome
4 Preliminary Phase

ADM – Phase C: Information Systems Architectures – Purpose
The Data & Application Architectures enable the Business Architecture & Vision
Exam
Phase C consists of two parts (in either order):

1. Development of the Application Architecture
2. Development of the Data Architecture
▪ Develop the Target Information Systems

Architectures (Application & Data Architectures) to
C.
support an agreed Architecture Vision
Information
Systems
Architectures
▪ …
▪ See Purpose of Phase B: Business Architecture

(they are the same)
ADM – Phase C: Information Systems Architectures – Objectives
The phase develops the Target Architectures & identifies Roadmap components
Exam
1.Develop the Target Information Systems

Architectures (Data & Application Architecture),
describing how the enterprise’s Information Systems
Architectures will enable the Business Architecture
and the Architecture Vision, in a way that addresses
the Statement of Architecture Work and stakeholder
C. concerns
Information
Systems
Architectures
2.Identify candidate Architecture Roadmap
components based upon gaps between the Baseline
and Target Information Systems Architectures (Data &
Application Architecture).
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase C for Data Architecture and Application Architecture
ADM – Phase C: Information Systems Architectures – Steps
The phase identifies gaps between Baseline & Target Data & Application Arch.
Develop Baseline Application & Data

2
Develop Target Application & Data
3
C.
Information 4 Perform gap analysis
Systems
Architectures
6 …

ADM – Phase C – Application Architecture Artifacts
The phase describes the Baseline and Target Application Architecture

2
3
C.
Systems
Architectures

6
Landscape

ADM – Phase C: Application Architecture – Artifacts (1/4)
Catalogs, matrices and diagrams visualize the Application Architecture
▪ Application Portfolio Catalog ▪ Application and User Location Diagram

▪ Interface Catalog ▪ Application Use-Case Diagram
▪ Application/Organization Matrix ▪ Enterprise Manageability Diagram
▪ Role/Application Matrix ▪ Process/Application Realization Diagram
▪ Application/Function Matrix ▪ Software Engineering Diagram
▪ Application Interaction Matrix ▪ Application Migration Diagram
▪ Application Communication Diagram ▪ Software Distribution Diagram

The Application Portfolio Catalog lists all logical application components
Logical Application Components (CORE)
ID Name Description Category Source

ISA_LAC_01 Enterprise Resource Planning An Enterprise Resource Planning (ERP) system is Plaform Interview
Platform a comprehensive software solution used by
organizations to manage and streamline various
aspects of their business operations. It integrates
core functions such as finance, human resources,
inventory management, and supply chain
management into a single unified platform, enabling
data sharing and real-time collaboration across
different departments.
ISA_LAC_02 Customer Relationship A Customer Relationship Management (CRM) Plaform Interview
Management Platform platform is a software tool that helps businesses
effectively manage their interactions and
relationships with customers. It centralizes
customer data and communication history, allowing
organizations to track and analyze customer
interactions, preferences, and feedback.
▪ Provides a foundation for other matrices and diagrams

▪ Contains logical application components and physical application components
▪ Often the starting point of the Application Architecture phase

The Application Communication Diagram shows App components & interfaces
Interface 1
App 1 Interface 2
App 2
Interface 3
App 3
▪ Interfaces may be associated with data entities

▪ Applications may be associated with business services
▪ Communication should be logical and only show technology where it is relevant

The Application / Organization Matrix shows usage of applications
Logical Application Components Map to Organization's Units
Sales HR Production Development

Enterprise Ressource
x x x x
Planning Platform
Customer Relationship
x
Management Platform
Human Resource Platform x
Product Lifecycle
x x
Management System
▪ Defines the application set used by a particular organization unit

▪ Shows which organizational units are supported by which applications
▪ Helps to understand the application support requirements
▪ Supports the gap analysis by determining missing or inappropriate applications

ADM – Phase C – Data Architecture Artifacts
The phase describes the Baseline and Target Data Architecture

2
3
C.
Systems
Architectures

6
Landscape

ADM – Phase C: Data Architecture – Artifacts
Catalogs, matrices and diagrams visualize the Data Architecture
Logical Data Components Map to Business Functions
Sales HR
Product Margin Data x
Customer Data x
Employee Data x
Payroll Data x
Insurance Data x
Revenue Data x
Data Entity/Business Function Matrix Logical Data Diagram
▪ Data Entity/Data Component Catalog ▪ Data Security Diagram

▪ Application/Data Matrix ▪ Data Migration Diagram
▪ Conceptual Data Diagram ▪ Data Lifecycle Diagram
▪ Data Dissemination Diagram

ADM – Phase C: Application Architecture – Approach
The phase considers the relevant & available Application Architecture resources
▪ Use Application models relevant to common high-

level business functions (e.g., e-commerce)
▪ Use generic business models and related

application models relevant to the organization’s
industry sector provided by
▪ The Open Group Forum

C.
Information
▪ Object Management Group (https://www.omg.org/)
Systems
Architectures
▪ TM Forum (https://www.tmforum.org/)
▪ The Open Group has a Reference Model for Integrated

Information Infrastructure (III-RM) focuses on the
application-level components and services necessary
to provide an integrated information infrastructure

ADM – Phase C: Data Architecture – Approach (1/2)
Effective use of data can be a competitive advantage
Three key considerations for developing a Data Architecture:
1. Data Management:
▪ Define which application components serve as enterprise master data
▪ Understand how data entities are utilized by business capabilities,
business functions, processes and business and application services
▪ Understand how and where enterprise data entities are created,
stored, transported and reported
2. Data Migration:
C. ▪ Identify data migration requirements
Information
Systems ▪ Provide indicators for data transformation, weeding and cleansing
Architectures ▪ Ensure an enterprise-wide common data definition to support the
transformation & migration
3. Data Governance:
▪ Ensure that the enterprise has the necessary structures, management
systems and people in place to enable the transformation

ADM – Phase C: Data Architecture – Approach (2/2)
Conceptual, logical and physical data models provide a structural view
Data Architecture is created by using three metamodel entities:
▪ Data entity: used to create conceptual data models to help the IT

developers understand the concepts they will be dealing with
▪ Logical data entity: used to create logical data models as a requirement

on the data stored in applications (at rest), data moved between
applications (in motion), or data at the user interface of applications (data
in use)
C. ▪ Physical data entity: used to create data models that have been
Information
Systems
implemented
Architectures
Data Architecture should be able to handle:
▪ Data at rest - data in stores
▪ Data in motion - data in transactions or services/APIs
▪ Data in use - data at the border of the application (e.g. GUI)
▪ Open data - data that the organization provides for public usage

Document outline
1 Welcome
4 Preliminary Phase

ADM – Phase D: Technology Architecture – Purpose
The Technology Architecture supports Business, Data & Application Architecture Exam
▪ Develop the Target Technology Architecture to

support an agreed Architecture Vision
▪ …
▪ See Purpose of Phase B: Business Architecture

(they are the same)
D.
Technology
Architecture
ADM – Phase D: Technology Architecture – Objectives
The phase develops the Target Architecture & identifies Roadmap components Exam
▪ Develop the Target Technology Architecture that

enables the Architecture Vision, target business,
data and application Building Blocks to be
delivered through technology components and
technology services, in a way that addresses the
Statement of Architecture Work and stakeholder
concerns
▪ Identify candidate Architecture Roadmap

D. components based upon gaps between the Baseline
Technology
Architecture and Target Technology Architectures
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase D
ADM – Phase D: Technology Architecture – Steps
The phase identifies gaps between Baseline & Target Technology Architecture
Develop Baseline Technology Architecture

2
Description
Develop Target Technology Architecture
3
Description

D.
Technology
Architecture
6 …

ADM – Phase D: Technology Architecture – Artifacts
The phase identifies gaps between Baseline & Target Technology Architecture
Develop Baseline Technology Architecture

2
Description
Develop Target Technology Architecture
3
Description

D.
Technology
Architecture
6
Landscape

ADM – Phase D: Technology Architecture – Artifacts (1/3)
Logical Technology Components
The Technology Portfolio Catalog lists all the logical technology in use
ID Name Description Date Category

TA_LTC_01 Workflow automation Automate repetitive tasks and processes, improving 10/15/2023 Business Process Automation
efficiency and reducing human intervention.
TA_LTC_02 Event trigger Mechanism that initiates an action or process in 10/15/2023 Business Process Automation
response to a specific occurrence or predefined
condition within a system or software.
TA_LTC_03 Application Connector Software component or interface that facilitates 10/15/2023 Business Process Automation
seamless communication and integration between
different applications or systems, enabling data
exchange and interoperability.
TA_LTC_04 Data Warehouse Centralized repository that stores large volumes of 10/16/2023 Business Intelligence
structured, unstructured, and semi-structured data
from various sources, designed for analysis,
reporting, and business intelligence purposes
TA_LTC_05 ETL Extract, Transform, Load, is a process in data 10/16/2023 Business Intelligence
integration where data is gathered from various
sources, transformed into a consistent format, and
loaded into a target data repository for analysis and
reporting
▪ Includes hardware, infrastructure software and application software

▪ Is a typical starting point for ADM Phase D Technology Architecture
▪ Provides a basis for other matrices and diagrams
The Platform Decomposition Diagram depicts the used technology platforms
Business Process Automation Business Intelligence

Application Data
Event Triggers ETL
Connectors Warehouse
Subscription Workflow Historic Operational

services automation Reporting Reporting
▪ Shows the enterprise applications and the decomposed technology components

▪ Provides an overview of the enterprise's technology platforms
▪ May map technology platforms to application components within a specific functional or
process area
▪ May show further specification details (e.g., product versions, number of CPUs)

The Environments & Location Diagram shows technology of the different sites
▪ Depicts what
technologies are
used at which
locations

ADM – Phase D: Technology Architecture – Approach (1/2)
Emerging Technologies are a major driver for change in enterprises
Emerging Technologies:
▪ Anticipate and be open to technology-driven change
▪ Look for new innovative ways of operating and
improve the business
▪ Technology Architecture needs to capture the
transformation opportunities available through
adoption of new technology
▪ The TOGAF ADM enables technology change to
become a driver and strategic resource rather than
a recipient of Change Requests
▪ Technology Architecture may both drive business
capabilities and respond to information system
D.
Technology requirements at the same time
Architecture
▪ Rapid adoption of changing technologies can cause
discontinuities across the enterprise.

ADM – Phase D: Technology Architecture – Approach (2/2)
The re-use of internal and external material saves time
Use resources from the Architecture Repository:
▪ Existing IT services documented in the IT repository

or IT service catalog
▪ Generic technology models relevant to the

organization’s industry sector
▪ Reference Models from The Open Group Technology

D.
Technology (e.g. III-RM, Technical Reference Model TRM)
Architecture

Document outline
14 Applying the ADM

ADM – Phase E: Opportunities and Solutions – Purpose (1/2)
The phase is directly concerned with solutions & implementation
Exam
▪ Find Solution Building Blocks (SBBs)
▪ Conduct initial implementation planning
▪ Validate dependencies (Work Package & Gap

dependency)
▪ Identify delivery vehicles (projects, programs, or

portfolios) that effectively deliver the Target
Architecture
E.
Opportunities
and
Solutions
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase E
ADM – Phase E: Opportunities and Solutions – Purpose (2/2)
The phase is directly concerned with solutions & implementation
Exam
▪ Assess value, effort and risk associated with each

change and work package
▪ Manage stakeholder priority and preference adjusted

to value, effort and risk (Stakeholder Requirements)
▪ Output & Outcome:

▪ Work packages
▪ Addressed gaps
▪ Added value
▪ Required effort
E.
Opportunities ▪ Dependencies
and
Solutions
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase E
ADM – Phase E: Opportunities and Solutions – Objectives
The phase concentrates on how to deliver the architecture
Exam
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
2.Determine whether an incremental approach is

required, and if so, identify Transition Architectures that
will deliver continuous business value
3.Define the overall Solution Building Blocks (SBBs) to

finalize the Target Architecture based on the
Architecture Building Blocks (ABBs)
E.
Opportunities
and
Solutions
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase E
ADM – Phase E: Opportunities and Solutions – Steps (1/2)
The phase consolidates the gaps and creates an initial implementation plan
Determine/confirm the key corporate change

1
attributes
Determine the business constraints for
2
implementation
Review and consolidate the gap analysis
3
results from Phases B to D
Review the consolidated requirements across
4
related business functions
Consolidate and reconcile interoperability
5
requirements
E.
Opportunities
and 6 Refine and validate dependencies
Solutions

ADM – Phase E: Opportunities and Solutions – Steps (2/2)
The phase consolidates the gaps and creates an initial implementation plan
Confirm readiness and risk for business

7
transformation
Formulate Implementation and Migration
8
Strategy
9 Identify and group major work packages
10 Identify Transition Architectures
Create the Architecture Roadmap &

11
Implementation and Migration Plan
Phase E is the bridge between the Target

E.
Opportunities
Architecture and the Solution. It concentrates on
and
Solutions
how to deliver the architecture.

ADM – Phase E: Opportunities and Solutions – Interoperability
The phase minimizes interoperability conflicts between solutions
Determine/confirm the key corporate change

1
attributes
Determine the business constraints for
2
implementation
Review and consolidate the gap analysis results
3
from Phases B to D
Review the consolidated requirements across
4
related business functions
Consolidate and reconcile interoperability
5
requirements
E.
Opportunities
and 6 Refine and validate dependencies
Solutions

Interoperability – Definition
Interoperability is the ability to share information and services
Exam
Operational or Business Information Technical

Interoperability Interoperability Interoperability
How different parts of the How information is to be How technical resources are
enterprise work together shared? to be shared or at least
at the business level? connect to one another?
TOGAF® is a registered trademark of The Open Group. Briefly explain interoperability and how it is used
Interoperability – Application Interoperability
TOGAF recommends Enterprise Application Integration (EAI) for interoperability
Exam
Presentation: Common look-and-feel approach through a common portal-like

solution guides the user through the system functions
Information: Information is seamlessly shared between applications based on a

corporate ontology and shared services (e.g., security, access, structure, quality)
Application: Corporate functionality is integrated & shareable and business &

infrastructure applications are seamlessly linked together
Technical: Common methods and shared services for the communication,

storage, processing and access to data in platforms & infrastructure
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard ADM Techniques Briefly explain interoperability and how it is used
Interoperability – Usage within the TOGAF ADM (1/2)
The technique is applied in Phase A till Phase F
Reveal the nature and security considerations of the

information & service exchanges with Business scenarios
Define information & service exchanges in business

terms
Detail the content of the information exchanges with

corporate data and/or information exchange model
Specify how applications share information and

services
Specify the technical mechanisms to permit

the information and service exchanges
Interoperability – Usage within the TOGAF ADM (2/2)
The technique is applied in Phase A till Phase F
Logically implement the interoperability
Select actual solutions (e.g., Commercial Off-The-

Shelf packages)
ADM – Phase E: Opportunities and Solutions – Risk Management
The technique identifies, classifies & mitigates risks of the transformation effort

7
transformation
8 Formulate Implementation and Migration Strategy

11
E.
Opportunities
and
Solutions

Risk Management – Definitions
There is always risk with any architecture/business transformation effort
Exam
▪ Risk: “Effect of uncertainty on objectives” (ISO 31000:2009) with uncertainty as any
deviation from what is expected (positive and negative)
▪ Risk triggers: May be inside or outside the scope of the transformation
▪ Risk Management: Identifying and assessing the likelihood and magnitude of potential
positive or negative events on strategic, tactical & operational level
▪ Initial Level of Risk: Risk categorization prior to determining & implementing mitigation
▪ Residual Level of Risk: Risk categorization after implementation of mitigation
➢ Main goal: Maximizing business benefit and minimizing business loss

TOGAF® is a registered trademark of The Open Group. Briefly explain risk management
Risk Management – Classification
The TOGAF Standard uses risk concepts from The SABSA Institute
Image source: © The SABSA Institute Image source: © The SABSA Institute
Differentiate Balanced view

Business risk vs. Cyber risk Control effects of threats vs. Leveraging
benefits of opportunities
Risk Management – Assessment
Top-down assessment starts with business value and its optimization
Exam
1. Risk identification
2. Risk classification
3. Initial Risk Assessment
4. Risk mitigation
5. Residual risk assessment
6. Risk monitoring & governance
Initial Risk Assessment – Effect & Frequency
The method classifies risk with respect to effect & frequency by using scales
Effect Frequency
on (parts of) the organization during a transformation cycle
▪ Catastrophic: critical financial loss that ▪ Frequent: likely to occur very often
could result in bankruptcy and/or continuously
▪ Critical: serious financial loss in more ▪ Likely: occurs several times

than one line of business
▪ Occasional: occurs sporadically
▪ Marginal: minor financial loss in one
line of business ▪ Seldom: occur not more than once
▪ Negligible: minimal impact on one line ▪ Unlikely: probably not occur

of business

Initial Risk Assessment – Risk impact
Effect & frequency are combined using a heuristically-based classification
Extremely High Risk High Risk
Transformation will most likely fail with Failure of parts of the transformation
severe consequences resulting in goals not being achieved
Low Risk Moderate Risk

Certain goals of the transformation will Failure of parts of the transformation
not be wholly successful threatening the success of goals
Risk Management – Usage within the TOGAF ADM
The technique is conducted throughout Phase E till H
Exam
Identify risk areas to be addressed &

Manage Enterprise Architecture assess the business risk
risks
Conduct risk monitoring
Validate, assign to projects &

accept residual risks
Identify, classify and mitigate
risks associated with the
business transformation
Briefly explain the characteristics of architecture risk management and where it is used within
the TOGAF ADM
ADM – Phase E: Opportunities and Solutions – Architecture Roadmap
The phase consolidates work packages & transitions architectures into a roadmap

7
transformation

11
E.
Opportunities
and
Solutions

Architecture Roadmap – Definition (1/2)
The deliverable lists all work packages realizing the Target Architecture
Exam
▪ Shows progression from the Baseline Architecture to the Target Architecture
▪ Lists work packages and their business value realizing the Target Architecture
▪ Incrementally developed throughout ADM phases E and F and informed by readily

identifiable roadmap components from Phase B, C and D
Purpose
Architecture Roadmap
Architecture Roadmap – Definition (2/2)
The deliverable lists all work packages realizing the Target Architecture
Exam
▪ Work package portfolio (i.e., description, functional requirements, dependencies,
value, relationship to opportunity/architecture definition document & requirements)
▪ Implementation factor catalog (i.e., risks, issues, assumptions, dependencies,

actions, inputs)
Content
▪ Consolidated Gaps, Solutions and Dependencies matrix (i.e., architecture

domain, gap, potential solutions, dependencies)
▪ Transition Architectures
▪ Implementation recommendations (i.e., criteria measures of effectiveness, risks

and issues, Solution Building Blocks)
Architecture Roadmap – Structure
The deliverable focuses on the work packages realizing the Target Architecture

Architecture Roadmap – Usage within the TOGAF ADM (1/2)
The deliverable is based on input from the Phase B throughout D
Exam
Identify candidate Business Architecture Roadmap

components
Identify candidate Data Architecture Roadmap

components
Identify candidate Application Architecture Roadmap
components
Identify candidate Technology Architecture Roadmap

components
Architecture Roadmap – Usage within the TOGAF ADM (2/2)
The deliverable is finalized in Phase F and used in Phase G
Exam
Use as input
Adjust, finalize & confirm
Generate the initial complete version
ADM – Phase E – Implementation and Migration Plan
The phase aligns Implementation and Migration Plan to Architecture Roadmap

7
transformation

11
E.
Opportunities
and
Solutions

Implementation and Migration Plan – Definition
The deliverable provides a schedule of projects towards the Target Architecture
Exam
▪ Contains a schedule of the projects realizing the Target Architecture
Purpose
▪ Includes executable projects grouped into managed portfolios and programs
▪ Shows the Implementation and Migration Strategy identifying the change

approach
▪ Implementation and Migration Strategy with direction & sequencing approach

Content
▪ Project and portfolio breakdown with work packages, delivered capabilities,

milestones and timing, work breakdown structure and impact analysis
▪ Project charters with work packages business value, risks, issues, assumptions,
dependencies, resources, benefits, costs
Implementation Migration Plan
Implementation and Migration Plan – Structure
The deliverable focuses on the projects realizing the Target Architecture

Implementation and Migration Plan – Usage within the TOGAF ADM
The deliverable is created in Phase E & F and used in Phase G and H
Exam
Use as input
Use as input
Finalize, approve & integrate with the enterprise’s

other change activity
Draft including Implementation and Migration Strategy
Implementation Migration Plan
ADM – Phase E: Opportunities and Solutions – Approach
Implementation & Migration Plan is initialized in Phase E & finalized in Phase F
Four concepts for the transition from developing to

delivering a Target Architecture:
1. Architecture Roadmap: lists work packages in a

timeline that will realize the Target Architecture
2. Work Packages: group changes that are necessary to

realize the Target Architecture
3. Transition Architectures: significant state between

the Baseline and Target Architecture (interim Target
Architectures)
E.
Opportunities 4. Implementation and Migration Plan: schedule of
and
Solutions projects that will realize the Target Architecture

Document outline
14 Applying the ADM

ADM – Phase F: Migration Planning – Purpose
The phase finalizes the Implementation and Migration Plan
Exam
▪ Finalizing a detailed Implementation and Migration
Plan (how to move from the baseline to the target
architectures )
▪ Estimating the resources required to undertake the

change and ensuring availability
▪ Manage stakeholder priority and preference

adjusted to value, effort and risk
▪ Output & Outcome: Approved set of projects incl.

F.
▪ Objectives
Migration
Planning
▪ Constraints
▪ Resources required
▪ Start & finish date
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase F
ADM – Phase F: Migration Planning – Objectives
The phase finalizes the Implementation and Migration Plan
Exam
1.Finalize the Architecture Roadmap and the

supporting Implementation and Migration Plan
2.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
3.Ensure that the business value, cost of work

packages and Transition Architectures is
F.
Migration understood by key stakeholders
Planning
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase F
ADM – Phase F: Migration Planning – Steps
The phase completes the architecture development cycle
Confirm management framework interactions
1
for the Implementation and Migration Plan
2 Assign a business value to each work package
Estimate resource requirements, project

3
timings and availability/delivery vehicle
Prioritize the migration projects through conduct
4
of a cost/benefit assessment and risk validation
Confirm Architecture Roadmap and update
5
F.
Migration 6 Complete the Implementation and Migration Plan
Planning
Complete the architecture development cycle

7
and document lessons learned
ADM – Phase F – Implementation Governance Model
The phase transitions governance from the development to realization
Confirm management framework interactions
1
for the Implementation and Migration Plan
2 Assign a business value to each work package
Estimate resource requirements, project

3
timings and availability/delivery vehicle
Prioritize the migration projects through conduct
4
of a cost/benefit assessment and risk validation
Confirm Architecture Roadmap and update
5
F.
Migration 6 Complete the Implementation and Migration Plan
Planning
Complete the architecture development cycle

7
and document lessons learned
Implementation Governance Model – Definition
The deliverable enables Architecture Governance on a project basis
Exam
▪ Ensures that a project transitioning into implementation also smoothly transitions
into appropriate Architecture Governance
Purpose
▪ Supports also organizations having established architecture functions and a

governance framework on project-by-project basis
▪ Governance process
Content
▪ Governance organization structure
▪ Governance roles and responsibilities
▪ Governance checkpoints and success/failure criteria

Implementation Governance Model
Implementation Governance Model – Structure
The deliverable defines the governance for the implementation projects

Implementation Governance Model – Usage within the TOGAF ADM
The deliverable is created in Phase F and used in Phase G
Exam
Use as input
Created, if the maturity of the Architecture Capability

warrants
Implementation Governance Model
ADM – Phase F: Migration Planning – Approach
The phase closely aligns with the work of project and portfolio managers
▪ Finalize Implementation and Migration Plan

(based on Draft Architecture Roadmap and Draft
Implementation and Migration Plan from Phase E)
▪ Include portfolio and project-level details to the

▪ Integrate the Roadmap, the Implementation and Migration

Plan with the enterprise’s change activities
▪ Assess the dependencies, costs and benefits of the

various migration projects
F.
Migration
Planning
▪ Transition to Implementation Governance & Document
the lessons learned to enable continuous process
improvement

Document outline
14 Applying the ADM

ADM – Phase G: Implementation Governance – Purpose
The phase provides the architectural oversight of the implementation
Exam
▪ Ensure the compliance of the (implementation)

projects with the defined architectures
▪ Guide the implementation teams (Purpose,

Constraints, Gap, Architecture Requirement
Specification, Control)
▪ Manage stakeholder priority and preference

G.
Implemen- adjusted to success, value, effort and risk
tation
Governance
▪ Output & Outcome:

▪ Completed projects
▪ Implemented changes
▪ Adjusted target state
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase G
ADM – Phase G: Implementation Governance – Objectives
The phase ensures conformance and performs Architecture Governance
Exam
1.Ensure conformance of the implementation projects

with the Target Architecture
2.Perform appropriate Architecture Governance

G.
Implemen-
functions for the solution and any implementation-
tation
Governance
driven architecture Change Requests
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase G
ADM – Phase G: Implementation Governance – Steps
The phase runs parallel to the implementation projects
Confirm the scope and the priorities for the

1
deployment with the development management
2 Identify deployment resources and skills
3 Guide development of solutions deployment
G. Perform Enterprise Architecture Compliance

Implemen- 4
tation reviews
Governance
5 Implement business and IT operations
Perform post-implementation review and close

6
the implementation
ADM – Phase G: Implementation Governance – Architecture Contract
Architecture Contracts guide the development of solutions deployment

1

Implemen- 4
tation reviews
Governance

6
the implementation
Architecture Contract – Development Contract
The contract type governs the collaboration of sponsors and implementers
Exam
▪ Reflects a joint agreement between development partners and sponsors on the
deliverables, quality and fitness-for-purpose of an architecture
▪ Delivered through effective Architecture Governance
▪ Enables a dynamic Enterprise Architecture allowing for flexible evolution in

Purpose
response to changing technology and business drivers
▪ Traditional: Agreements between the sponsor and the architecture function or

Information Systems (IS) department
▪ Today: Agreements between all parties involved in the architecture development

and delivery (e.g., systems integrators, applications providers & service providers)
Architecture Contract
Architecture Contract – Content
The contract content depends on the contract type
Exam
Architecture Design & Development Contract
▪ Introduction and background, Nature of the agreement, Scope of the
architecture, Architecture and strategic principles and requirements,
Conformance requirements, Architecture development and management process
and roles, Target Architecture measures, Defined phases of deliverables,
Prioritized joint workplan, Time window(s), Architecture delivery and business
Content
metrics
Business Users’ Architecture Contract

▪ Introduction and background, Nature of the agreement, Scope, Strategic
requirements, Conformance requirements, Architecture adopters, Time window,
Architecture business metrics, Service architecture (including Service-Level
Agreement)
Details: TOGAF Standard Enterprise Architecture Capability and Governance
Development Contract – Usage within the TOGAF ADM
The contract is created mainly in Phase G and used throughout Phase H
Exam
Connect architecture and implementation

organization &
& update, if necessary
Document &
Obtain signature from all developing organizations
and sponsoring organization
Architecture Contract – Statement of Architecture Work
The contract type governs the collaboration between sponsor & architects
▪ Represents an Architecture Contract between the architecting organization and

the sponsor of the Enterprise Architecture, created as a deliverable of Phase A
Purpose
▪ Defines scope & approach being used for an architecture development cycle
▪ May form the basis for a contractual agreement between the supplier and
consumer of architecture services
▪ Title, approvals, change of scope procedures

Content
▪ Architecture project request, background, description, scope, plan & schedule
▪ Acceptance criteria and procedures, roles, responsibilities and deliverables
▪ Overview of Architecture Vision

Architecture Contract – Architecture Design & Development Contract
The contract type governs the architecture and implementation work
▪ Is a statement of intent on designing & implementing (parts of) the Enterprise

Architecture from partners (e.g., system integrators, application providers)
Purpose
▪ Defines the deliverables, quality and fitness-for-purpose of the developed

architecture and the collaboration processes of the partners
▪ Is defined at the appropriate stage of the ADM, depending on the contracted work
▪ Introduction, background and nature of the agreement

Content
▪ Architecture scope, Target Architecture measures and delivery/business metrics
▪ Architecture & strategic Principles and (conformance) requirements
▪ Architecture development & management process and workplan & time window

Architecture Contract – Business Stakeholder’s Architecture Contract
The contract type governs the collaboration between architects & business
▪ Drawn up between the architecting function and the business stakeholders who
will subsequently be building and deploying the architected business solutions
Purpose
▪ Created at the end of Phase F with the agreed Implementation and Migration Plan
▪ Also used to manage changes to the Enterprise Architecture in Phase H
▪ Introduction, background and nature of the agreement

Content
▪ Scope, strategic and conformance requirements and Service Level Agreements
▪ Architecture deliverables & business metrics meeting business requirements
▪ Time window and architecture adopters

Architecture Contract – Structure
The content of the document depends on the contract’s type

Architecture Contract – Benefits
A governed approach to the management of contracts has many advantages
Exam
Accountability, Continuous monitoring of Adherence to the principles,

responsibility and all architecture-related standards & requirements
discipline using architectural activities (e.g., integrity, of architectures
artifacts changes, decision-making,
audit)
Identification of risks of the Understanding of the governance

development (e.g., standards, policies, organization responsible for the
technologies) and operation (e.g., contract, their level of authority and
resilient environment) of architectures scope of the architecture
TOGAF® is a registered trademark of The Open Group. Briefly explain the role of Architecture Contracts
Architecture Contract – Usage within the TOGAF ADM
Contracts may be used during various ADM phases
Contract of architecture Statement of Architecture

function <> implementation Work as contract of architecting
function for implementing organization <> sponsor of
the EA (inhouse, contractor), Enterprise Architecture (or IT
e.g., strategic & enterprise- governance function)
wide technology
infrastructure, applications &
data management Contract of systems
integrators, applications
providers and/or service
Contract of architecture
providers regarding the
function <> business
architecture and work
stakeholders building and
deploying application
systems in the architected
environment
TOGAF® is a registered trademark of The Open Group. Briefly explain the role of Architecture Contracts
ADM – Phase G: Implementation Governance – Compliance Assessment
The phase performs compliance reviews to fulfill Architecture Governance

1

Implemen- 4
tation reviews
Governance

6
the implementation
Architecture Compliance Assessment (Deliverable) – Definition
The deliverable governs the architecture through the implementation
Exam
▪ Ensures that the realized design and implementation is in line with the strategic
and architectural objectives and the Architecture Vision
Purpose
▪ Ensures that implementation learnings are fed back into the architecture
process
▪ Overview of project progress, status and architecture/design

Content
▪ Architecture checklists (e.g., hardware & operating system, software services and
middleware, applications, information management, security, system management,
system engineering, methods and tools)
Compliance Assessment
Architecture Compl. Assessment – Usage within the TOGAF ADM
The deliverable is used in Phase G and H
Exam
Assess realized value using the linkage between

stakeholder requirements & specified constraints
Consider the scope of the Implementation Project

and the work packages filling the gaps & Confirm
whether the Architecture Requirements Specifications
have been followed
Compliance Assessment
Architecture Compliance Review (Process) – Timing
The review is held at project milestones or checkpoints in the project’s lifecycle
▪ Architecture development ▪ Project implementation

▪ Development of the architecture itself ▪ Implementation of the architecture(s)
(ADM compliance) (architecture compliance)
▪ When business requirements and the ▪ Specific checkpoints within the project
Enterprise Architecture are reasonably (e.g., project initiation, initial design,
firm and the project architecture is taking major design changes, ad hoc)
shape
▪ Stage when there is still time to correct
any major errors or shortcomings

Architecture Compliance Review (Process) – Resources (1/2)
The Target Architecture Checklist ensures architecture development compliance
# Checklist questions (excerpt) ▪ The EA Practitioner assesses

1 Were the correct stakeholders identified? the Target Architecture and
stakeholders approve it
Were constraints and guidance from the
2
superior architecture taken into account?
Upon negative response…
Do appropriate SMEs agree with the facts and
3 1. the EA Practitioner reworks
interpretation of the facts in the architecture?
the Target Architecture or
Do any constraints or guidance produced 2. the Architecture Project is
reflect the views produced for stakeholders and canceled
4
any underpinning architecture models and
analysis?
… ….

Architecture Compliance Review (Process) – Resources (2/2)
The Implementation & other Change Checklist ensures implementation compliance
# Checklist questions (excerpt) The EA Practitioner acts as…

Did the organization embarking on a change 1. auditor (compliance
1 reasonably interpret the Target Architecture’s assessment) and
guidance and constraints? 2. architect (recommendations)
Do appropriate SMEs agree with the facts and
2 interpretation of the facts in the impact Recommendation is based on
assessment? impact assessment
Do appropriate SMEs agree with the 1. Enforce compliance
3 recommendation to enforce the target, grant 2. Provide temporary relief or
time-bound relief, or change the architecture? 3. Change Target Architecture
… …

ADM – Apply Architecture to Support agile software development
The TOGAF Standard aligns to agile development in Phase G
Exam
▪ Portfolio ▪ Project ▪ Solution Delivery
▪ Identify the products ▪ Identify the products
needed by the enterprise needed by the enterprise
▪ Identify the boundaries ▪ Identify the boundaries

of the products of the products
▪ Set constraints for the ▪ Set constraints for the

product owner product owner
▪ Define the enterprise’s ▪ Set constraints for the ▪ Set constraints for the
backlog agile teams agile teams
➢ The Enterprise Architect serves the stakeholders guarding the mission, vision, goals
and investment roadmap, hence guarding enterprise value
Explain how developing architecture for different purposes, or levels of detail,
TOGAF® is a registered trademark of The Open Group. can be applied to support Agile software development
ADM – Phase G: Implementation Governance – Approach (1/2)
The phase deploys the Target Architecture as a series of transitions
▪ Incremental steps towards the Target Architecture:
▪ Each step delivers business value
▪ Early realization of business value and benefits
▪ Minimize risks in the transformation and

G. migration program
Implemen-
tation
Governance
▪ Establish an implementation program
▪ Adopt a phased deployment schedule based on

business priorities

ADM – Phase G: Implementation Governance – Approach (2/2)
The phase deploys the Target Architecture as a series of transitions
▪ Follow the organization’s standard for corporate, IT and

Architecture Governance
▪ Use the organization’s established portfolio/program

management approach
▪ Define an operations framework to ensure the effective

long life of the deployed solution
G.
Implemen-
tation
Governance
▪ Develop project details (name, descriptions,
acceptance criteria, measures of effectiveness)
Phase G establishes the connection between

architecture and implementation organization,
through the Architecture Contract.

Document outline
14 Applying the ADM

ADM – Phase H: Architecture Change Management – Purpose
The phase establishes procedures for managing change to the new architecture
Exam
▪ Ensure that the architecture achieves its original target

business value (Value Realization)
▪ Identify Gaps between approved target, or

H.
Architecture
preference and realization from prior work
Change
Management
▪ Manage Changes (preference, priority or stakeholder
requirements)
▪ Output & Outcome: Direction to proceed and start

developing a Target Architecture that addresses
perceived, real, or anticipated shortfalls in the
Enterprise relative to stakeholder preferences.
TOGAF® is a registered trademark of The Open Group. Briefly explain the purpose of Phase H
ADM – Phase H: Architecture Change Management – Objectives
The phase maintains the Architecture Development Cycle
Exam
1. Ensure that the architecture development cycle is

H.
maintained
Architecture
Change
Management 2. Ensure that the Architecture Governance
Framework is executed (regarding changes)
3. Ensure that the Enterprise Architecture Capability

meets current requirements
TOGAF® is a registered trademark of The Open Group. Describe the objectives of Phase H
ADM – Phase H: Architecture Change Management – Steps
The phase waits for changes and manages them
1 Establish value realization process
2 Deploy monitoring tools
H. 3 Manage risks
Architecture
Change
Management
Provide analysis for architecture change
4
management
Develop change requirements to meet
5
performance targets
6 Manage governance process
7 Activate the process to implement change

ADM – Phase H: Architecture Change Mgmt. – Architectural Inputs
Change requests trigger change management
▪ Change Requests (technology)

▪ New technology reports
▪ Asset management cost reduction initiatives
▪ Technology withdrawal reports
H.
Architecture ▪ Standard initiatives
Change
Management
▪ Change Request (business)

▪ Business developments
▪ Business exceptions
▪ Business innovations
▪ Business technology innovations
▪ Strategic change developments

Change Request – Definition
The request extents or refines the architecture during its implementation
Exam
▪ Describes a deviation from the suggested architectural approach (e.g.,
definition, scope, requirements, solution)
Purpose
▪ Created due to gained knowledge or external factors (e.g., market factors,

changes in business strategy, new technology opportunities)
▪ Kick-starts a further cycle of architecture work
▪ Description and rational for the proposed change

Content
▪ Impact assessment (i.e., reference to requirements, stakeholder priority, phases to

be revisited, recommendations)
▪ Repository reference number
Change Request
Change Request – Structure
A change request should be captured in a structured manner

Change Request – ADM Phases
The deliverable is captured & documented in Phase F & G and assessed in H
Exam
Assess regarding architecture update vs. new

ADM cycle
Create during the implementation and

solutions deployment
Create for the Architecture Capability arising

from lessons learned
Use as input for existing business programs

and projects
Change Request
ADM – Phase H: Architecture Change Management – Approach (1/2)
The phase manages changes to the architecture in a cohesive & architected way
▪ The change management process determines

circumstances under which…
▪ … the enterprise architecture, or parts of it, will be

H. permitted to change after implementation and the
Architecture
Change process by which that will happen
Management
▪ …the enterprise architecture development cycle

will be initiated again to develop a new architecture
▪ Establish criteria to judge (based on business value)

whether a Change Request…
▪ …warrants an architecture update
▪ …warrants starting a new cycle of the ADM

ADM – Phase H: Architecture Change Management – Approach (2/2)
The phase is closely related to Architecture Governance & Architecture Contract
▪ Content of a Change Request:

▪ Description of the proposed change
▪ Rationale for the proposed change
▪ Impact assessment of the proposed change
H.
Architecture
Change ▪ Change classification:
Management
▪ Simplification change (handled via change
management techniques)
▪ Incremental change (may require partial re-
architecting)
▪ Re-architecting change (requires a new
architecture development cycle)

Document outline
14 Applying the ADM

ADM – Requirements Management Phase – Purpose
The phase documents, evaluates and distributes architecture requirements
Exam
▪ Manage architecture requirements throughout the

ADM
▪ Operate the requirements management process
▪ Ensure effective requirements management
▪ Provide traceability from the organization’s vision,

Requirements
Management
mission, business model and strategies to the
requirements
▪ Maintain the complete set of requirements

(incl. stakeholder preferences)
TOGAF® is a registered trademark of The Open Group. Describe the purpose of Requirements Management
ADM – Requirements Management Phase – Objectives
The phase stores requirements and feeds them in and out of the ADM phases
Exam
1.Ensure that the Requirements Management process

is sustained and operates for all ADM phases
2.Manage architecture requirements identified during

any execution of the ADM cycle or a phase
Requirements
Management
3.Ensure that relevant architecture requirements are
available for use by each phase as the phase is
executed
TOGAF® is a registered trademark of The Open Group. Describe the objectives of the Requirements Management process
ADM – Requirements Management Phase – Steps (1/4)
Architecture requirements are available for use in all ADM Phases
# Requirements Management steps ADM Phases steps

▪ Identify requirements by analyzing
business goals & scenarios,
management information, value
1 streams & user experience
▪ Document requirements in the Archi-
tecture Requirements Specification
& Requirements Repository
▪ Establish baseline requirements with
2
approved stakeholder priorities
3 ▪ Monitor baseline requirements


Identify new and changed requirements:
4 ▪ Add new requirements and modify or

remove existing requirements
▪ Re-assess requirements’ priorities
▪ Identify changed requirements
▪ Record new requirements’ priorities
incl. decisions
5
▪ Solve conflicts among requirements
▪ Generate Requirements Impact
Statement (version n)


▪ Assess impact of changed require-
ments on previous & current ADM
Phase(s)
6 ▪ Decide to implement changed re-
quirements in current/later ADM cycle
Statement (version n+1)
▪ Implement requirements arising from
7
Phase H: Architecture Change Mgmt.
▪ Update the Architecture Require-
8 ments Repository (incl. changes,
affected stakeholder views)


9 ▪ Implement changes
▪ Conduct Gap Analysis for past phases
▪ Identify gap requirements (i.e., block
being eliminated by accident, causing
10 a change to the Target Architecture)
▪ Record gap requirements in Archi-
tecture Requirement Repository
▪ Revise Target Architecture

ADM – Requirements Management – Requirements Impact Assessment
The impact of changed requirements is assessed in the ADM Phases

▪ Assess impact of changed require-
ments on previous & current ADM
Phase(s)
6 ▪ Decide to implement changed re-
quirements in current/later ADM cycle
Statement (version n+1)
▪ Implement requirements arising from
7
Phase H: Architecture Change Mgmt.
▪ Update the Architecture Require-
8 ments Repository (incl. changes,
affected stakeholder views)

Requirements Impact Assessment – Definition
The approach considers new facts that may invalidate parts of the architecture
Exam
▪ Assesses the current architecture requirements and specification to identify
changes that should be made as well as their implications to the architecture
Purpose
▪ Phases to be revisited and to lead on requirements prioritization including results

Content
▪ Investigation results and recommendations on management of requirements
▪ References to specific requirements and stakeholder priority
▪ Repository reference numbers

Requirements Impact Assessment
ADM – Requirements Management – Approach (1/2)
The ADM is continuously driven by the Requirements Management process
▪ Dynamic process to identify and store requirements

for Enterprise Architecture (and their changes)
▪ The Requirements Management Phase feds

requirements into and out of the relevant ADM
phases and between ADM cycles
Requirements
Management
▪ The relevant ADM-phases disposes of, addresses,
or prioritizes requirements, not the Requirements
Management process

ADM – Requirements Management – Approach (2/2)
The ADM is continuously driven by the Requirements Management process
▪ Use an Architecture Requirements Repository to

record and manage all architecture requirements
(recommendation)
▪ The Architecture Requirements Repository can

Requirements
Management
hold information from multiple ADM cycles (unlike
the Architecture Requirements Specification and the
Requirements Impact Assessment)

Document outline
14 Applying the ADM

ADM Iterations – Iterative approach
The Architecture Development Method can be executed in an iterative way
Exam
The ADM is iterative…
▪ …over the whole process,
▪ …between phases and
▪ …within phases.
Each iteration = new decision:

▪ Breadth of coverage of the enterprise
▪ Level of detail
▪ Aimed time period
▪ Used architectural assets created previously or externally
Decision based on:

▪ Availability of resources and competence
▪ Value to the enterprise from the chosen scope
TOGAF® is a registered trademark of The Open Group. Explain the iterative approach of the ADM
ADM Iterations – Practice (1/2)
Each Architecture Project starts with Phase A and uses an individual ADM path
Exam
▪ Need for iterations in the development of an Architecture:
▪ High complexity (manage complexity)
▪ Inter-dependent nature (consider the entire architecture,
existing gaps and resulting work simultaneously)
▪ Each Architecture Project

▪ has a different purpose
▪ traverses a distinct path
▪ uses a different configuration of the TOGAF ADM
▪ starts with Phase A: Architecture Vision
(to initiate a project)
ADM Iterations – Practice (2/2)
Iterations are driven by the information needs of the Architecture Project
Exam
▪ Architecture Projects do not need to enter all phases
(if information is not needed or already has been produced)
▪ ADM Phases and their steps can be executed

simultaneously and repeated at the necessary level of
detail
▪ Multiple ADM phases may stay open to produce the

information in the required breadth, depth, time and
recency
ADM Iterations – Iteration Cycles
The TOGAF Standard suggests iteration cycles to achieve specific purposes
Exam
1. Iteration through the entire ADM 3
Develops a comprehensive Architecture Landscape
1 2
2. Architecture Development Iteration
Creates architecture content and ensures the
architecture is considered as a whole
3. Architecture Capability Iteration 4

Creates & evolutes the Architecture Capability
(approach, principle, scope, vision, governance)
4. Architecture Governance Iteration

Supports the governance of change activities
5. Transition Planning Iteration 5

Creates change roadmaps for a defined architecture
TOGAF® is a registered trademark of The Open Group. Explain how iteration within the ADM enables concurrent operation of multiple ADM phases
ADM Iterations – Iteration through the entire ADM (1/2)
The iteration type develops a comprehensive Enterprise Architecture Landscape
Exam
▪ Projects go through the entire ADM cycle
(starting with Phase A and a Request for
Architecture Work) 1
▪ Each project / cycle is bound by a

▪ Output of each project / cycle changes or

extends the Architecture Landscape
ADM Iterations – Iteration through the entire ADM (2/2)
The iteration type develops a comprehensive Enterprise Architecture Landscape
Exam
▪ Separate projects may operate their own ADM
cycles concurrently with relationships to each
other (parallel iteration) 1
▪ A project may trigger another project

(sequential iteration), if…
▪ …the project identifies opportunities or

solutions requiring a detailed architecture
or
▪ …the project identifies EA landscape impacts

outside the Request for Architecture Work
ADM Iterations – Architecture Development Iteration (1/2)
The iteration type is an iteration within an ADM cycle
Exam
Projects may…
▪ …operate multiple ADM phases concurrently (to
manage the inter-relationship between BDAT- 2
Architectures)
▪ …cycle between ADM phases

(to cover multiple phases and converge on a detailed
Target Architecture, when higher-level architecture
does not exist)
▪ …return to previous phases

(to update work products, to converge on an
Architecture Roadmap or Implementation & Migration
Plan, when requirements change
ADM Iterations – Architecture Development Iteration (2/2)
The ADM can be visualized with a process-oriented view
Explain the iterative approach of the ADM

ADM Iterations – Architecture Capability Iteration
The iteration type creates & evolves the Architecture Capability
Exam
Projects may require a new iteration of the 3
Preliminary Phase to…
▪ …(re-)establish aspects of the Architecture

Capability identified in Phase A addressing a
▪ …adjust the Architecture Capability based on

new or changed requirements because of a
Change Request in Phase H.
ADM – Information flow between the ADM phases (1/2)
The ADM is not a linear waterfall process
Exam
The TOGAF Architecture Development Method (ADM)…
▪ …is a logical method for developing knowledge
▪ …places key activity steps together for understanding
relatonships of activities and information flows
The TOGAF crop-circle diagram…

▪ is a stylized path that demonstrates the
essential information flow
▪ should not be understood as a linear processes model
▪ is not a representation of activity sequence
TOGAF® is a registered trademark of The Open Group. Explain the information flow between the ADM phases
ADM – Information flow between the ADM phases (2/2)
The ADM is not a linear waterfall process
Exam
The TOGAF Standard…
▪ …provides an ADM phase for each essential output that is necessary to develop an
architecture
▪ …suggests what input is necessary at each phase to develop the required output
Information flow between different ADM phases:

▪ In every phase of the ADM you consume inputs to generate outputs
▪ The output of one phase can be the input of a later phase
▪ The output of one phase can be updated or detailed in a later phases
▪ The work plan of an Enterprise Architecture team varies depending on the problem and
development task, that is defined in the Request for Architecture Work
-> Each request requires a distinct path of the TOGAF ADM and different outputs
TOGAF® is a registered trademark of The Open Group. Explain the information flow between the ADM phases
Building Block Specification Process – ADM Phases
ABBs are defined in the phases A, B, C & D and shaped as SBBs in Phase E
Exam
Evolutionary and iterative
process based on required
functions, imposed constraints
and available products
1. Identify Architecture
Building Blocks (ABBs)
required to meet business
goals and objectives
2. Refine selected ABBs to

Solution Building Blocks
(SBBs) bought from the
shelf or custom developed
TOGAF® is a registered trademark of The Open Group. Explain what building blocks are and their use in the ADM
Architecture Alternatives & Trade-offs – Definition
Multiple Target Architectures could suit the vision, principles and requirements
Exam
Sometimes not a single architecture exists that will
meet all stakeholders’ concerns
▪ Identify alternative Target Architectures
▪ Build an understanding of different possibilities
▪ Identify trade-offs between the alternatives Image source: Pexels.com / Pavel Danilyuk
(competing forces)
▪ Extract hidden agendas, principles and requirements by presenting the alternatives

to the stakeholder
Briefly explain the reasons for considering architecture alternatives,

including understanding concerns and trade-off
Architecture Alternatives & Trade-offs – Technique
The technique investigates Architecture Alternatives
1. Use the vision, principles, requirements

and other information to select sets of
criteria fitting for different alternatives
2. Define alternatives based on the

criteria and build an understanding of
each
3. Select one of the alternatives or

combine features from multiple
alternatives to create the proposed
target architecture
Architecture Trade-Off Method
Briefly explain the reasons for considering architecture alternatives,

including understanding concerns and trade-off
Digital Enterprise – Definition
The enterprise type creates, delivers and obtains products and services digital
Exam
Definition Digital Enterprise*
An enterprise characterized by:
1. The creation of digitalized products or services that are delivered fully digitally
(e.g., digital media or online banking)
2. Where physical products and services are obtained by the customer by digital
means (e.g., online car-sharing services)
*based on Digital Practitioner Body of Knowledge (DPBoK)
TOGAF® is a registered trademark of The Open Group. Briefly explain how the TOGAF Standard can be applied to support the Digital enterprise
Digital Enterprise – Support in agile environments
The TOGAF Standard can be applied to support the Digital Enterprise
Exam
Enterprise Architecture supports agile environments in delivering and enhancing digital
products and services quicker and easier by…
1. … managing technical dept (reactively and proactively)
2. …identifying standards and reusable standard components
3. …providing governance to oversee the reuse of components
4. …simplifying complexity
5. …establishing an Enterprise Capability that drives operational excellence
6. …institutionalizing agile development methods

TOGAF® is a registered trademark of The Open Group. Briefly explain how the TOGAF Standard can be applied to support the Digital enterprise
Document outline
14 Applying the ADM

(Architecture) Content Framework – Introduction (1/2)
The concept is a categorization framework for Architecture Content
Exam
▪ Structures the Architecture
Description, work products,
artifacts & models
▪ Defines artifacts and work

products to be developed and to
describe the Architecture
▪ Top-level structure mirrors the ADM

phases
▪ Provides an underlying structure

and companion for the ADM
TOGAF® is a registered trademark of The Open Group. Briefly explain the TOGAF Content Framework and Enterprise Metamodel
(Architecture) Content Framework – Introduction (2/2)
The concept is a categorization framework for Architecture Content
Exam
▪ Puts each deliverable into the
context of the holistic architecture
view of the enterprise
▪ Multiple Frameworks are available

(e.g., TOGAF Content Framework,
Zachman Framework, DoDAF, NAF)
▪ Framework decision is influenced

by the Architecture Framework
and used EA software tool
▪ Usually adapted to fit organization

needs
(Architecture) Content Framework – Explanation
The framework is part of the Enterprise-Specific Architecture Framework
Models for the Models for

surrounding applications &
context data
Models for
Models for the technology
business and its assets in use
motivation implementing the
information
systems
Models for Models for value

transition realization
roadmaps and management
binding events
statements
(Architecture) Content Framework – Benefits
Describes what the architecture should look like once it is done
▪ Detailed model of architectural work

products
▪ Enhances consistency in the

outputs
▪ Comprehensive checklist of
architecture output
▪ Reduces the risk of gaps
▪ Defines standards (i.e., architecture

concepts, terms and deliverables)
Enterprise Metamodel – Introduction
The model defines entities within the enterprise & the relationships between them
Exam
▪ Starter pack for architects with types of
things to investigate & cover in models
▪ Provides context for the artifacts suggested

in the ADM
▪ Completeness-check for architecture

modeling languages and metamodels
▪ Improves consistency, completeness &

traceability
▪ Structures architectural information to meet Example: Foundation-level Core Enterprise

stakeholder needs Metamodel found in the TOGAF Library
Enterprise Metamodel – Development (1/2)
The Enterprise Metamodel is specific to an individual Enterprise
▪ Its types of entity and their relationships

are specific to the individual enterprise
▪ A high-quality metamodel is important for

establishing the EA Capability
▪ TOGAF does not constrain the selection of

artifacts & modeling notation
▪ Modeled in a variety languages (e.g.,

ArchiMate®, Business Process Modeling
Notation , Unified Modeling Language ,
flowchart, entity relationship diagram) Example: Foundation-level Core Enterprise
Metamodel found in the TOGAF Library
Briefly explain the TOGAF
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard Architecture Content
Content Framework and Enterprise Metamodel
Enterprise Metamodel – Development (2/2)
Two approaches to develop an Enterprise Metamodel
1. Based on viewpoints which address

stakeholder concerns
2. Based on available / established

metamodels
In both cases:
▪ Minimize the information in the Metamodel
according to the purpose of the EA Capability
▪ Each entity, relationship and their attributes

must be maintained and tracked
Example: Foundation-level Core Enterprise
Metamodel found in the TOGAF Library
Briefly explain the TOGAF
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard Architecture Content
Content Framework and Enterprise Metamodel
(Enterprise) Architecture Repository – Introduction
The concept stores different classes of architectural output at different levels
Exam
▪ Part of the Enterprise Repository
▪ Often implemented by modeling

software, analytic tools, file
repository or document
management system
TOGAF® is a registered trademark of The Open Group. Briefly explain the Architecture Repository
(Enterprise) Architecture Repository – Elements (1/2)
The content facilitates understanding & co-operation of stakeholders
Architectural Organizationally
representation of tailored application of
assets deployed within an architecture
the enterprise at a framework including
particular point in time the Content
(current, target, Metamodel
transition, candidate)
often at multiple level of Standards with which
abstractions new architectures and
Parameters, implementations must
structures and comply (e.g., industry
processes that support standards, selected
governance of the products & services
Architecture from suppliers, shared
Repository services)
(Enterprise) Architecture Repository – Elements (2/2)
The repository is enriched by the different ADM outputs
Architectural Guidelines,
representation of the templates, patterns
Solution Building and other forms of
Blocks (SBBs) reference material to
supporting the accelerate the creation
Architecture Landscape of new architectures
which have been
planned or deployed
View of all authorized Record of

architecture governance activity
requirements which across the enterprise
have been agreed with
the Architecture Board
Enterprise Continuum – Introduction & Explanation (1/2)
The concept structures & categorizes assets held in Enterprise Repositories
Exam
▪ Sets a broader context
for re-using artifacts
▪ Explains how generic

solutions can be
leveraged & specialized to
support architecture
requirements of an
individual organization
▪ Comprises the
Architecture & Solution
Continuum
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard Architecture Content Briefly describe the Enterprise Continuum
Enterprise Continuum – Introduction & Explanation (2/2)
The concept is a view of the repository of all internal & external architecture assets
Exam
▪ Provides view on models,
patterns, viewpoints,build-
ing blocks and artifacts
▪ Internal architecture and

solution artifacts:
Deliverables of previous
architecture work, which
are available for re-use
▪ External architecture
and solution artifacts:
Industry reference models
and architecture patterns
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard Architecture Content Briefly describe the Enterprise Continuum
Document outline
14 Applying the ADM

Governance – Definition
A system by which the current and future state are directed and controlled
Exam
▪ Is a committed & hierarchical decision-making process with a defined structure of
relationships to direct and control the enterprise to achieve stated goals
▪ Accounts for the equality of concerns and transparency, protecting the rights and
interests of the business (and not the ones of narrow-minded interests)
▪ Can be used to drive a set of behaviors controlled via measurements and metrics
➢ A customized governance approach should define the Why, What, When and How
TOGAF® is a registered trademark of The Open Group. Briefly explain the concept of Architecture Governance
Source: ISO/IEC 38500:2015 Information technology - Governance of IT for the organization
Corporate Governance – Definition
A system by which business corporations are directed and controlled
▪ Ensures that business is conducted properly through guidance & usage of resources
▪ Focuses on the rights, roles and equitable treatment of shareholders
▪ Enacts a board to review and guide corporate strategy and to set and monitor
achievement of performance objectives
▪ Ensures disclosure and transparency of the responsibilities of the board
▪ Ensures strategic guidance, monitoring of management and board accountability
Source: Basic principles of corporate governance, Organization for Economic Co-operation and Development (OECD) 2001
(Enterprise) Architecture Governance – Definition
A system by which (Enterprise) Architectures are directed and controlled
Exam
▪ Is a practice and orientation by which
Enterprise Architectures and other
architectures are managed and controlled
at an enterprise-wide level
▪ Operates within a hierarchy of governance

structures (= tiers) with their own disciplines
and processes (e.g., corporate governance,
technology governance, IT governance)
▪ May exist at multiple geographic levels

within the enterprise (e.g., global, regional,
local)
Architecture Governance – Need
The development & maintenance of an Enterprise Architecture must be governed
Exam
▪ Why ▪ What ▪ How
▪ Without control, there is ▪ Development of the ▪ Architects & implementer
no need to develop a Target Architecture are directed & controlled
Target Architecture by the stakeholders
▪ All changes within the
▪ Direct & control change scope of the Target ▪ Architecture Project:
Architecture Statement of Architecture
Work, Target Architecture
Checklist
▪ Implementation Project:
Architecture Contracts,
Architecture Require-
ments Specification
TOGAF® is a registered trademark of The Open Group. Explain the need to govern the creation, development and maintenance of Enterprise Architecture
Architecture Governance – Governance Repository
The governance artifacts & processes are part of the Architecture Repository
Exam
▪ Reference Data ▪ Process Status ▪ Audit information
▪ Description of the ▪ State of the governance ▪ Completed governance
governance procedures processes process actions
▪ Guidance & instruction ▪ Examples: outstanding ▪ Key decisions &

in project implementation compliance requests, responsibles for any
dispensation requests, Architecture Project
compliance assessments
investigations ▪ Architecture & supporting
process developments,
guidance & precedence
TOGAF® is a registered trademark of The Open Group. Explain the need to govern the creation, development and maintenance of Enterprise Architecture
(Enterprise) Architecture Governance – Benefits
Architecture Governance adopts its benefits from Corporate Governance Exam
Discipline Responsibility Accountability

Commitment to adhere to Each contracted party is Organization groups are
procedures, processes and required to act responsible authorized & accountable for
authority structures their actions
Fairness Transparency Independency

Decisions, processes and Decisions and supporting Processes, decision-making
implementations will not be actions will be available for and mechanisms will be
allowed to create unfair inspection established as to minimize
advantage to any party potential conflicts of interest
TOGAF® is a registered trademark of The Open Group. Explain why Architecture Governance is beneficial
Source: Adapted from Corporate Governance by Ramani Naidoo, 2002
Architecture Board – Role
The cross-organizational board is represented by key architecture stakeholders
Exam
▪ Comprises a group of executives responsible for the review and maintenance
of the architecture and for oversee the implementation of the strategy within
Phase H of the Architecture Development Method (ADM)
▪ Possesses identifiable and articulated responsibilities, decision-making

capabilities, remit and authority limits
▪ Distinguishes between local (domain experts, line responsibility) and global

(organization-wide responsibility) representatives in larger enterprises
▪ May have global, regional, or business line scope
TOGAF® is a registered trademark of The Open Group. Briefly explain the role of an Architecture Board and its responsibilities
Architecture Board – General responsibilities
The board is made responsible and accountable for achieving different goals
Exam
▪ Improves the maturity level of architecture discipline while ensuring that the
discipline of architecture-based development is adopted
▪ Ensures consistency of sub-architectures and enforces Architecture Compliance
▪ Establishes targets for re-use of components
▪ Ensures flexibility of the Enterprise Architecture regarding business needs &

technologies
▪ Supports a visible escalation capability for out-of-bounds decisions
➢ Basis for all decision-making regarding the architectures

Architecture Board – Operational responsibilities
The board has many different operational responsibilities
▪ Monitors, controls and publishes of Architecture Contracts
▪ Ensures the management & implementation of the architectures
▪ Resolves ambiguities, issues, conflicts & provides advice, guidance, infos
▪ Ensures compliance with the architectures and grants dispensations
▪ Considers policy changes (e.g., schedule, SLAs, new service requirement)
▪ Validates of reported service levels, cost savings, etc.
Architecture Board – Governance responsibilities
The board has many different governance responsibilities
▪ Provides a mechanism for the formal acceptance and approval of the

enterprise architecture
▪ Provides a control mechanism for ensuring the implementation of the

enterprise architecture
▪ Identifies divergence from the architecture and planning activities for

realignment (e.g., dispensations, policy updates)
▪ Links strategic objectives of the business, the architectural strategy and

objectives and the implementation of the architecture
▪ Produces usable governance material and activities
Architecture Board – Decision Rights
The decision rights about the Target Architecture lies with the stakeholders
Exam
▪ The Architecture Board owns the process &
recommendations regarding completeness
and confidence in the architecture work that
led to the Target Architecture
▪ Decision rights about Target Architecture,

relief and enforcement are always vested in
the architecture’s stakeholders,
independent of the architecture domain
▪ TOGAF® provides decision-tree checklists

to require an architect to answer when
assessing a Target Architecture as well as a
non-compliance report (cf. extract on left)
(Enterprise) Architecture Compliance – Types
Architecture compliance of projects is essential to Architecture Governance
Exam
▪ Architecture function ▪ Enterprise & IT Governance function
▪ Prepares project architectures (i.e., ▪ Defines a formal Architecture
project-specific views) illustrating how Compliance Review process for
the Enterprise Architecture impacts reviewing the compliance of projects
on major projects to the Enterprise Architecture
▪ May stipulate the participation in the

technology selection process, in
external service provision and
product purchases in addition to
architecture definition and standards
selection
TOGAF® is a registered trademark of The Open Group. Briefly explain the need for Architecture Compliance
Architecture Capability – Overview
The EA capability is a business capability supporting four different purposes
Exam
▪ Posses organization structures
with roles, responsibilities, skills
and processes for EA work
▪ Treated and run like any other

operational unit within a
business
▪ Establishes management
capabilities (e.g., financial, risk
& opportunity, performance, sup-
plier, service, communications &
stakeholder, resource, quality,
configuration, environment)
TOGAF® is a registered trademark of The Open Group. Briefly explain what an Architecture Capability is
Architecture Capability – Purposes
Main goal is to develop, use and sustain the architecture to govern change
Exam
▪ Change & synergies, governance ▪ Governance framework for change
▪ Multiple programs or portfolios ▪ Single project or significant part
▪ Provide Target Architecture & roadmaps ▪ Support solution deployment
▪ Alignment, synergies and governance ▪ Integration between projects

▪ Single portfolio of projects ▪ Single project (value, compliance)
▪ Support cross-functional & multi-phase ▪ Support the project delivery method
TOGAF® is a registered trademark of The Open Group. Briefly explain what an Architecture Capability is
Architecture Capability – Architecture to support Strategy
The focus lies on an architecture with low depth for the next 3 till 10 years
Purpose of the Architecture

▪ Deliver EA to provide an end-to-end Target Architecture
▪ Develop roadmaps of change over a three to ten-year period
Use of the Architecture

Enterprise Scope No pattern - Broad &
▪ Identify change initiatives (Breadth) narrow impact
▪ Support portfolio and programs
▪ Set terms of reference Level of Detail
▪ Identify synergies Low
(Depth)
▪ Govern the execution of
strategy via portfolio &
Time Period 3-10 years (Target
programs
(Planning horizon) Architecture)
TOGAF® is a registered trademark of The Open Group. List the four purposes that help to frame the planning horizon and breadth and depth of the Architecture Project
Architecture Capability – Architecture to support Portfolio
The focus lies on a single subject architecture with low depth for 2 till 5 years

▪ Deliver EA to support cross-functional, multi-phase and multi-project change
initiatives

Enterprise Scope Single subject (the
▪ Identify projects (Breadth) Portfolio)
▪ Set terms of reference for
projects Level of Detail Typically low but detailed
▪ Align approaches for projects (Depth) for constraints
▪ Identify project synergies
▪ Govern project execution
Time Period
2-5 years
(Planning horizon)
Architecture Capability – Architecture to support Projects
The focus lies on a narrow architecture with detailed depth for less than 2 years

▪ Deliver EA to support the Enterprise’s project delivery method

Enterprise Scope Narrow (projects within the
▪ Clarify the purpose and value of (Breadth) portfolio)
the project
▪ Identify requirements to address Level of Detail Detailed, more constraints
synergy and future dependency (Depth) than guidance
▪ Assure compliance
▪ Support integration and
Time Period
alignment between projects <2 years
(Planning horizon)
Architecture Capability – Architecture to support Solution Delivery
The focus lies on a narrow architecture with detailed depth for less than 2 years

▪ Deliver EA that is used to support the solution deployment.

Enterprise Scope
Very narrow (one project)
▪ Define how the change will be (Breadth)
designed and delivered
▪ Identify constraints Level of Detail
▪ Define control and architecture Most detailed
(Depth)
requirements to the design
▪ Establish a governance
Time Period
framework for change <2 years
(Planning horizon)
Architecture Capability – Development (1/4)
The TOGAF ADM can be used to iteratively develop an EA Capability
Capability topic ADM Level Enterprise deliverables EA Capability deliverables

▪ Goals, objectives, initiatives, competitive ▪ Goals
Enterprise & Phase Partial and tactic analysis
EA Context B Strategic ▪ Operating model (partners, suppliers)
▪ Explore what-if scenarios and scorecards
None ▪ Provide initial goals and objectives
▪ Select a reference EA Capability and
Business Phase maturity model
Capability
Objectives A ▪ Candidate EA Capability
▪ Candidate operating model
▪ EA Capability gap and priority roadmap
▪ Enterprise Risk Management Model ▪ Risk Management Model
▪ Governance Model ▪ Governance Model
Partial
Architecture Phase ▪ Extend candidate operating model to
Segment /
Governance B include EA governance
Capability
▪ Initial Architecture Partition Model
▪ Trace to EA Capability goals


▪ Reference models for key frameworks ▪ Framework touch-points
▪ Capability assessment of key frameworks ▪ Extend candidate operating model to
Phase include other frameworks
B& ▪ Extend EA governance and EA risk
Alignment with Partial Partial management
other Frameworks Phase Capability ▪ Initial EA Content Framework aligned to
C other frameworks and EA governance
(Data) ▪ Candidate architecture partition model
▪ Trace to EA Capability goals
▪ EA Capability
None ▪ EA Content Framework
▪ EA Content Metamodel
Customization of
Phase ▪ Viewpoint Library
Architecture
C Capability ▪ Architecture Repository Model
Contents &
(Data) ▪ Trace to EA Capability goals
Metamodel
▪ Initial EA Content Framework and
architecture repository gap


None ▪ EA organizational model
▪ Select reference EA skills framework
▪ Initial alignment with enterprise job titles
Organization and roles
B Capability
Model ▪ Initial accountability matrix for EA Content
Framework and initial architecture
repository
▪ Organizational gap and priority roadmap
▪ Process model highlighting touch-points ▪ Process model
between EA Capability and enterprise ▪ Architecture repository application model
B, C processes the EA Capability supports27 ▪ Matrix for EA Content Framework and
(Partial)
Process Model (App) ▪ Performance matrix for key processes architecture repository application
Capability
and D and organization architecture
▪ Accountability matrix for EA Content ▪ Process and architecture repository gap
Framework and organization and priority roadmap
Create a roadmap highlighting development ▪ Trace roadmap to EA Capability goals
of the EA Capability by changes in the:
▪ Organizational model
Roadmap E Capability
▪ Process model
▪ EA Content Framework
▪ Architecture repository


▪ Transition the EA Capability Roadmap to ▪ Execute the Implementation & Migration
Establishing & Phase
Capability an Implementation & Migration Plan Plan to build the EA Capability your
Evolving F and G
enterprise desires

Architecture Capability – Benefits
The capability supports the execution of a defined & effective governance
Increased transparency of Increased visibility Internal value and

accountability and informed supporting internal shareholder value creation
delegation of authority processes and external
parties’ requirements
Process, concept and Proactive risk and Protection of the existing

component re-use across opportunity management assets through re-use of
all organizational business through controlling and existing architectural
units monitoring components
TOGAF® is a registered trademark of The Open Group. Details: TOGAF Standard Enterprise Architecture Capability & Governance Briefly explain what an Architecture Capability is
Document outline
18 Practice Test
19 Wrap-up

TOGAF Enterprise Architecture Part 1 Exam (1/4)
Exam preparation
Study the content – Go through the ADM, its phases, techniques and deliverables.
If you know the method, you can get at least 24 correct answers.
Complete exam questions – Test your TOGAF knowhow and familiarize yourself
with the structure & characteristics of the exam by answering as many practice
questions as possible.
Test under real conditions – Simulate a TOGAF exam with 40 questions in 60

minutes. Learn how to deal with challenging questions in times of low concentration.
Check your exam infrastructure – Test your IT for a TOGAF® proctored exam.
Ensure you have a redundant internet connection. Make sure it is quiet in your
room.

Time management
Force a constant pace – As a native English speaker, you only have 90s on
average to answer a question. Skip difficult questions and look for quick wins
instead.
Use the complete time frame – The devil is in the detail, especially with tricky
questions. Use any remaining time for a quality check. Start with the answers where
you have the most doubts.

Question analysis
Read questions carefully – Go through each question and all the answers. Pay
attention to the details. A single word can make all the difference.
Pay attention to key terms – Main TOGAF terms like concern, stakeholder or
governance point to relevant phases, techniques or content of the EA framework.
Identify the ADM phase – Many questions & answers define the phase(s) of the
Architecture Development Method. Use this context to find the right answer.

Answer selection
Stick to the TOGAF spirit – Select the answer that most closely matches the key
concepts of the TOGAF Standard, e.g., ADM phases, deliverables and techniques.
Sort out the distractor – In most cases, one answer has nothing to do with the
TOGAF Standard and is very different from other answers. Exclude this incorrect
option.
Look for similar answers – For some questions, the best and second-best
answers are similar. Choose the one that comes closest to the TOGAF Standard.
Always choose an answer – Only one answer is correct and wrong answers do
not give minus points. Therefore, always put at tick in the box. Always.

Definitions – A (1/6)
Application Architecture, Architecture, Architecture Building Block (ABB)
Definition Application Architecture

A description of the structure and interaction of the applications
that provide key business capabilities and manage the data assets.
Definition Architecture
1. 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.
(Source: ISO/IEC/IEEE 42010:2011)
2. The structure of components, their inter-relationships and the principles and
guidelines governing their design and evolution over time.
Definition Architecture Building Block (ABB)

An architectural component that specifies the required Solution Building Blocks
(SBBs) at a more logical (or supplier-independent) level.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Application Architecture
Architecture Continuum, Architecture Development Method (ADM)
Definition Architecture Continuum

A categorization mechanism, with increasing detail and specialization, for the
components and artifacts stored in the Architecture Landscape or Reference
Library (part of the Architecture Repository).
This Continuum begins with foundational definitions like reference models, core
strategies and basic building blocks. From there it spans to Industry Architectures and
all the way to an Organization-Specific Architecture.
Definition Architecture Development Method (ADM)
The core of the TOGAF framework. A multi-phase, iterative approach to develop and
use an Enterprise Architecture to shape and govern business transformation.

Architecture Domain, Architecture Framework, Architecture Governance
Definition Architecture Domain

The architectural area being considered. The TOGAF framework follows the tradition of
dividing Enterprise Architecture into four primary architecture domains: business,
data, application and technology. Other domains (motivation, security, governance,
etc.) may span those four primary domains.
Definition Architecture Framework

A conceptual structure used to plan, develop, implement, govern and sustain an
architecture.
Definition Architecture Governance

The practice of monitoring and directing architecture-related work. The goal is to
deliver desired outcomes and adhere to relevant principles, standards and
roadmaps.
Architecture Landscape, Level, Model, Partition
Definition Architecture Landscape

The architectural representation of assets in use, or planned, by the enterprise at
particular points in time.
Definition Architecture Level

Levels provide a framework for dividing the Architecture Landscape into levels of
granularity. Note: Architecture levels are distinct from architecture partitions.
Definition Architecture Model

A representation of a subject of interest. An architecture model provides a smaller
scale, simplified and/or abstract representation of the subject matter.
Definition Architecture Partition

A subset of architecture resulting from dividing that architecture to facilitate its
development and management.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Architecture Landscape, Architecture Model
Architecture Principle, Architecture View, Architecture Viewpoint
Definition Architecture Principle

A qualitative statement of intent that should be met by the architecture.
Definition Architecture View

A representation of a system from the perspective of a related set of concerns.
Definition Architecture Viewpoint

A specification of the conventions for a particular kind of architecture view. An
architecture viewpoint can also be seen as the definition or schema for that kind of
architecture view. It establishes the conventions for constructing, interpreting and using
an architecture view to address a specific concern (or set of concerns) about a system-of-
interest.

Architecture Vision, Artifact
Definition Architecture Vision

A succinct description of the Target Architecture that describes its business value
and the changes to the enterprise that will result from its successful deployment. It
serves as an aspirational vision and a boundary for detailed architecture development.
Definition Artifact
An architectural work product
that describes an aspect of the architecture.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Artifact
Definitions – B (1/2)
Baseline, Building Block
Definition Baseline
A specification that has been formally reviewed and agreed upon, that thereafter
serves as the basis for further development or change and that can be changed only
through formal change control procedures or a type of procedure such as configuration
management.
Building Block
A potentially re-usable component that can be combined with other building blocks to
deliver architectures and solutions.

Definitions – B (2/2)
Business Architecture, Business Capability, Business Model
Definition Business Architecture

A representation of holistic, multi-dimensional business views of:
capabilities, end-to-end value delivery, information and organizational structure;
and the relationships among these business views and strategies, products, policies,
processes, initiatives and stakeholders.
Relates business elements to business goals and elements of other domains.

Definition Business Capability
A particular ability that a business may possess or exchange to achieve a specific
purpose.
Definition Business Model
A model describing the
rationale for how an enterprise creates, delivers and captures value.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Business Architecture, Business Model
Definitions – C
Capability, Capability Architecture, Concern, Communications
Definition Capability
An ability that an organization, person or system possesses.
Definition Capability Architecture

An architecture that describes the abilities that an enterprise possesses.
Definition Concern
An interest in a system relevant to one or more of its stakeholders.
Definition Communications & Stakeholder Management

The management of needs of stakeholders of the Enterprise Architecture practice. It
also manages the execution of communication between the practice and the
stakeholders and the practice and the consumers of its services.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Capability, Capability Architecture
Definitions – D (1/2)
Data Architecture, Deliverable
Definition Data Architecture

A description of the structure of the enterprise’s major types and sources of data,
logical data assets, physical data assets and data management resources.
Definition Deliverable
An architectural work product that is contractually specified and in turn formally
reviewed, agreed and signed off by the stakeholders.
Represent the output of projects. If in documentation form it will typically be archived at

completion of a project or transitioned into an Architecture Repository as a reference
model, standard, or snapshot of the Architecture Landscape at a point in time.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Data Architecture, Deliverable
Definitions – D (2/2)
Digital Architecture
Definition Digital Architecture

The inclusive architecture focused on a combination of Enterprise Architecture, data
science, telecommunications and Internet of Things (IoT), security, artificial
intelligence, cognitive science, neuroscience, robotics and social medias to deliver
operational services.

Definitions – E
Enterprise, Enterprise Continuum
Definition Enterprise
The highest level (typically) of description of an organization and typically covers all
missions and functions. An enterprise will often span multiple organizations.
Definition Enterprise Continuum

A categorization mechanism for classifying architecture and Solution Building
Blocks (SBBs) as they evolve from generic to specific applicability (or vice versa).

Definitions – G
Gap, Governance
Definition Gap
A statement of difference between two states. Used in the context of gap analysis,
where the difference between the Baseline and Target Architecture is identified.
Definition Governance
The discipline of monitoring & guiding the management of a business (or Information
Systems/Information Technology landscape) to deliver the business outcomes
required.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Gap
Definitions – I
Interoperability
Definition Interoperability
1. The ability to share information and services.
2. The ability of two or more systems or components to exchange and use information.
3. The ability of systems to provide and receive services from other systems and to
use the services so interchanged to enable them to operate effectively together.

Definitions – L
Logical
Definition Logical
Implementation-independent. A logical architecture is an implementation-independent
definition of the architecture.

Definitions – M
Metamodel, Modeling
Definition Metamodel
A model that describes the entities used in building an Architecture Description,
their characteristics and the key relationships between those entities.
Definition Modeling
A technique through construction of models
which enables a subject to be represented in a form
that enables reasoning, insight and clarity
concerning the essence of the subject matter.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Metamodel, Modeling
Definitions – P
Physical
Definition Physical
Real-world, tangible. A logical architecture is realized through a physical
architecture.

Definitions – R
Requirement, Roadmap, Role
Definition Requirement
A statement of need,
which is unambiguous, testable or measurable and necessary for acceptability.
Definition Roadmap
An abstracted plan for business or technology change, typically operating across multiple
disciplines over multiple years. Normally used in the phrases Technology Roadmap,
Architecture Roadmap, etc.
Definition Role
1. The usual or expected behavior of an actor, or the part somebody or something
plays in a particular process or event. An actor may have a number of roles.
2. The part an individual plays in an organization and the contribution they make
through the application of their skills, knowledge, experience and abilities.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Requirement, Role,
Definitions – S (1/2)
Segment Architecture, Solution Architecture, Solution Building Block (SBB)
Definition Segment Architecture

A detailed, formal description of areas within an enterprise,
used at the program or portfolio level to organize and align change activity.
Definition Solution Architecture

A description of a discrete and focused business operation or activity and how IS/IT
supports that operation.
Definition Solution Building Block (SBB)

A physical or implementation-specific component that realizes part or all of one or
more logical Architecture Building Blocks (ABBs). There are business, application and
technology SBBs.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Segment Architecture)
Definitions – S (2/2)
Solution Continuum, Stakeholder, Standards Library, Strategic Architecture
Definition Solution Continuum

A categorization mechanism, with increasing detail and specialization, for the
components and artifacts stored in the Solutions Landscape or Reference Library
(part of the Architecture Repository).
Definition Stakeholder
An individual, team, organization, or class thereof, having an interest in a system.
Definition Standards Library
A library of standards that can be used to define the particular services and other
components of an Organization-Specific Architecture.
Definition Strategic Architecture
A summary formal description of the enterprise,
providing an organizing framework for operational and change activity,
and an executive-level, long-term view for direction setting.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Stakeholder, Strategic Architecture
Definitions – T
Technology Architecture, Transition Architecture
Definition Target Architecture

The description of a future state of the architecture being developed for an
organization. There may be several future states developed as a roadmap to show the
evolution of the architecture to a target state.
Definition Technology Architecture
A description of the structure and interaction
of the technology services and technology components.
Definition Transition Architecture

A formal description of one state of the architecture
at an architecturally significant point in time.
One or more Transition Architectures may be used to describe the progression in

time from the Baseline to the Target Architecture.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Technology Architecture, Transition Architecture
Definitions – V
Value Stream
Definition Value Stream

A representation of an end-to-end collection of activities that create an overall result
for a customer, stakeholder, or end user.
Definition Viewpoint Library

A collection of the specifications of architecture viewpoints contained in the
Reference Library portion of the Architecture Repository.

Definitions – W
Work Package
Definition Work Package

A set of actions identified to achieve one or more objectives for the business.
A work package can be a part of a project, a complete project, or a program.
TOGAF® is a registered trademark of The Open Group. Define the following concepts: Work Package
Document outline
18 Practice Test
19 Wrap-up

Document outline
18 Practice Test
19 Wrap-up

Congratulations. You’ve made it. Thanks for your participation!
Good luck for your TOGAF® Enterprise Architecture Part 1 Exam (Foundation)
„Architecture should speak of its time and place,

but yearn for timelessness.”
- Frank Gehry, Canadian-American Architect
Dr. Christopher Schulz Tobias Smuda

Enterprise Architect Enterprise Architect
Please give us feedback by writing a review!

Thanks in advance.

Palladio - Enterprise Architecture Foundation With TOGAF

Uploaded by

Copyright:

Available Formats

Palladio - Enterprise Architecture Foundation With TOGAF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Palladio - Enterprise Architecture Foundation With TOGAF

Uploaded by

Copyright:

Available Formats

Enterprise Architecture (Foundation)

with the TOGAF Standard, 10th Edition

▪ TOGAF® is a registered trademark of The Open Group.

▪ Digital Practitioner Body of Knowledge is a trademark of The Open Group.

▪ DPBoK is a trademark of The Open Group.

▪ Boundaryless Information Flow is a trademark of The Open Group.

TOGAF® is a registered trademark of The Open Group.

2 Introduction to Enterprise Architecture

3 Architecture Development Method (ADM)

5 Phase A: Architecture Vision

6 Phase B: Business Architecture

7 Phase C: Information Systems Architectures

8 Phase D: Technology Architecture

TOGAF® is a registered trademark of The Open Group.

9 Phase E: Opportunities and Solutions

10 Phase F: Migration Planning

11 Phase G: Implementation Governance

12 Phase H: Architecture Change Management

13 Requirements Management Phase

14 Applying the ADM

15 Architecture Content & Core Concepts

16 Architecture Governance & Architecture Capability

TOGAF® is a registered trademark of The Open Group.

17 Exam Preparation & Definitions

TOGAF® is a registered trademark of The Open Group.

2. Introduction ▪ Enterprise Architecture Definition, Purpose & Benefit

3. Architecture ▪ Overview of the ADM Phases

4. Preliminary ▪ Purpose, Objectives, Steps & Approach

TOGAF® is a registered trademark of The Open Group.

5. Phase A: ▪ Statement of Architecture Work

Systems Arch. App 3

TOGAF® is a registered trademark of The Open Group.

9. Phase E: ▪ Interoperability & Risk Management

▪ Identify the boundaries

▪ Identify the boundaries

Implementation ▪ Set constraints for the

▪ Define the enterprise’s

▪ Set constraints for the ▪ Set constraints for the

▪ Support of Agile Software Development

TOGAF® is a registered trademark of The Open Group.

▪ Requirements Impact Assessment

▪ ADM Techniques & Iterations

▪ Content Framework & Enterprise Metamodel

TOGAF® is a registered trademark of The Open Group.

17. Exam ▪ Key Definitions

18. Practice ▪ TOGAF EA Part 1 Sample Exam

▪ Next Steps & Good Luck

TOGAF® is a registered trademark of The Open Group.

TOGAF® is a registered trademark of The Open Group.

TOGAF® is a registered trademark of The Open Group.

TOGAF® TOGAF® TOGAF®

▪ 40 basic single choice questions

▪ 60 minutes + 30 minutes for non-native speakers (English)

▪ Pass mark: 60% (24 out of 40 questions)

➢ TOGAF® Enterprise Architecture Part 1 Exam (OGEA-101, English)

▪ Test Center or remote under controlled conditions (video surveillance)

▪ Extra time, if English is 2nd language https://certification.opengroup.org/ESL

▪ Translation dictionary may be used and must be presented for inspection

2 Introduction to Enterprise Architecture