Qrs Togaf 8-9 Study Guide
Qrs Togaf 8-9 Study Guide
Qrs Togaf 8-9 Study Guide
Disclaimer: These questions and answers are best of our ability at the time of development. Should you have questions
or comments to answers in this study guide, please share with us.
Table of Content
Introducttion
1. PART I - Introduction
high-level intrroduction to
o the key con
ncepts of enterprise arch
hitecture and
d the
TO
OGAF approa
ach.
co
ontains the definitions
d of terms used
d
co ase notes dettailing the changes betw
ontains relea ween this verrsion and the
prrevious version of TOGA
AF
2. PART II - Architecture
e Developme
ent Method
de
escribes the TOGAF Arch
hitecture Dev
velopment Method
M (ADM
M) - a step-b
by-
ste
ep approach
h to developing an enterrprise archite
ecture
3. PART III - ADM Guidelines and Techniques
a collection of guidelines and techniques available for use in applying TOGAF
and the TOGAF ADM
4. PART IV - Architecture Content Framework
describes the TOGAF content framework, including a structured metamodel
for architectural artifacts, the use of re-usable architecture building blocks,
and an overview of typical architecture deliverables
5. PART V- Enterprise Continuum & Tools
discusses appropriate taxonomies and tools to categorize and store the
outputs of architecture activity within an enterprise
6. PART VI - TOGAF Reference Models
provides a selection of architectural reference models, includes the TOGAF
Foundation Architecture, and the Integrated Information Infrastructure
Reference Model (III-RM)
7. PART VII - Architecture Capability Framework
discusses the organization, processes, skills, roles, and responsibilities
required to establish and operate an architecture function within an
enterprise
• KLP 1.1-3 (2N) The intention of dividing the TOGAF specification into independent parts.
- to optimize across the enterprise the often fragmented legacy of processes (both
manual and automated) into an integrated environment that is responsive to
change and supportive of the delivery of the business strategy
- to enable the enterprise to achieve the right balance between IT efficiency and
business innovation
• KLP 1.2-4 (1) What is an architecture framework?
- should describe a method for designing a target state of the enterprise in terms
of a set of building blocks, and for showing how the building blocks fit together
• KLP 1.2-5 (1) Why do I need TOGAF as a framework for enterprise architecture?
2 Core Concepts
• KLP 2.3-1 (1) What kind of architecture does TOGAF deal with?
• KLP 2.5-1 (1N) Deliverables, Artifacts and Building Blocks (explaining these key concepts
and the relationships between them)
Financial Management
Performance Management
Service Management
Risk Management
Resource Management
Communications and Stakeholder Management
Quality Management
Supplier Management
Configuration Management
Environment Management
• KLP 2.11-1 (1N) TOGAF Document Categorization Model (purpose and overview)
3 Definitions
• KLP 3-1 The existence of the Definitions section and its purpose
- provides common vocabulary
4 Release Notes
• KLP 4-1 (1N) The existence of the Release Notes section and its purpose
- Modular structure
- Content Framework
- Extended Guidance on Adopting TOGAF within an Enterprise
- Explicit Consideration of Architectural Styles, including SOA and Security
Architecture
- Additional ADM Detail
- Greater usability
- More focus on holistic enterprise change
- More consistency of output
• KLP 4.3-1 (-) Mapping from TOGAF 8.1.1 to TOGAF 9 (minimally from the structural
perspective of the document)
- Introduction part of the TOGAF 8.1.1 specification has been used as the basis for
creation of Part I: Introduction in TOGAF 9
- Essence of the TOGAF 8.1.1 ADM has been retained in TOGAF 9. Part II: Architecture
Development Method (ADM)
- Enterprise Continuum concept is retained within Part V: Enterprise Continuum &
Tools.
- TOGAF Technical Reference Model and Integrated Information Infrastructure
Reference Model are extracted and placed within Part VI: TOGAF Reference Models in
TOGAF 9
- TOGAF 9 removes the Standards Information Base from the TOGAF specification
Developing Architecture Views Elements retained within Part IV: Architecture Content Framework
Building Blocks Elements retained within Part IV: Architecture Content Framework
Business Process Domain Views Elements retained within Part IV: Architecture Content Framework
Case Studies Removed. Case Studies will be available on The Open Group web site.
Other Architectures & Frameworks Removed. This material will be available on The Open Group web site
as a White Paper.
Tools for Architecture Development Moved to Part V: Enterprise Continuum & Tools
ADM and the Zachman Framework Removed. This material will be available on The Open Group web site
as a White Paper.
• KLP 4.4-1 (-) Mapping of TOGAF 9 Structure to TOGAF 8.1.1
Part I: Introduction
21 Security Architecture and the ADM New chapter; derived from Security White Paper (W055)
43 Foundation Architecture: Technical Reference Model No material change; maps to Chapters 19 and 20
Module 2: ADM, Guidelines and Techniques
ADM Overview
• KLP 5.1-2 (1N) The existence of supporting guidelines and techniques to use with the
ADM and the difference between the two sections: guidelines vs techniques
- Iterative process over the whole process, between phases and within phases\
- For each iteration, decision must be made with regards to:
Enterprise coverage
Level to detail that needs to be defined
Time period
Architectural assets that need to be leveraged
- Decisions should be based on a practical assessment of resource and
competence availability, and the value that can realistically be expected to accrue
to the enterprise from the chosen scope of the architecture work
• KLP 5.2.2-1 (1)
( The ADM Basic Structture, including the Phase
es
5.3 Adap
pting the ADM
• K 5.3-1 (1)) Why you wo
KLP ould need to
o adapt the ADM
A
- Flexib
bility - orderr of the phas
ses in the AD me extent dependent on the
DM is to som
maturrity of the arrchitecture discipline
d witthin the ente
erprise
- Integrration – can integrate with other fram
mework
- ADM is
i compleme nd supportive of, other standard
entary to, an s pro
ogram
manag
gement proc
cesses
• KLP 5.5-1 (1) The reasons for constraining the scope of the architectural activity.
• KLP 5.5-2 (1) The dimensions to define and limit scope of an architecture
- Four dimensions:
Preliminary Phase
• Objectives
• Approach
Preliminary phase is about defining "where, what, why, who, and how we do
architecture"
• Inputs
TOGAF
Other architecture framework(s), if required
- Non-Architectural Inputs
Board strategies and board business plans, business strategy,
business principles, business goals, and business drivers, when
pre-existing
Major frameworks operating in the business
Governance and legal frameworks, including architecture
governance strategy, when pre-existing
Budget for scoping project
Partnership and contract agreements
IT strategy
• Outputs
• Objectives
• Approach
Phase A defines what is in and what is outside the scope of the architecture
effort and the constraints
- Scoping
- Creating Architecture Vision Document
- Creating Statement of Architecture Work
- Building consensus
- Obtaining approval for Statement of Architecture Work
• Inputs
• Outputs
- Communications Plan
- Additional content populating the Architecture Repository
Phase B – Business Architecture
• Objectives
• Approach
• Inputs
• Steps
• Outputs
• Objectives
- Define major types and sources of data necessary to support the business
• Approach
- Take into account data management, data migration and data governance
- Decide what relevant assets are available from the Architecture
Repository in particular industry specific data models
- Develop the As-Is and Target Data Architecture
• Inputs
• Steps
• Outputs
• Objectives
• Approach
• Inputs
• Steps
• Outputs
• Objectives
• Approach
• Inputs
• Steps
• Outputs
• Objectives
• Inputs
- Reference Materials External to the Enterprise
Architecture reference materials
Product Information
- Non-Architectural Inputs
Request for Architecture Work
Capability Assessment
Communications Plan
Planning Methodology
- Architectural Inputs
Organizational Model for Enterprise Architecture, including:
• Scope of organizations impacted
• Maturity assessment, gaps, and resolution approach
• Roles and responsibilities for architecture team(s)
• Constraints on architecture work
• Budget requirements
• Governance and support strategy
Governance models and frameworks:
• Enterprise Architecture Management Framework
• Capability Management Framework
• Portfolio Management Framework
• Project Management Framework
• Operations Management Framework
Tailored Architecture Framework, including:
• Tailored architecture method
• Tailored architecture content
• Configured and deployed tools
Statement of Architecture Work
Architecture Vision
Architecture Repository, including:
• Re-usable building blocks
• Publicly available reference models
• Organization-specific reference models
• Organization standards
Draft Architecture Definition Document, including:
• Baseline Business Architecture, Version 1.0 (detailed)
• Target Business Architecture Version 1.0 (detailed)
• Baseline Data Architecture, Version 1.0 (detailed)
• Target Data Architecture, Version 1.0 (detailed)
• Baseline Application Architecture, Version 1.0 (detailed)
• Target Application Architecture, Version 1.0 (detailed)
• Baseline Technology Architecture, Version 0.1 (detailed)
• Target Technology Architecture, Version 0.1 (detailed)
Draft Architecture Requirements Specification, including:
• Gap analysis results (from Business, Data Application and
Technology Architectures)
• Architecture Requirements
• IT service management integration requirements
Change requests for existing business projects or programs
• Steps
• Outputs
• Objectives
• Approach
- Focus of Phase F is the creation of a viable Implementation and Migration
Plan in co-operation with the portfolio and project managers
- Assess dependencies, costs, and benefits of the various migration
projects
- Prioritize list of projects
- Create detailed Implementation and Migration Plan that will supplement
the architectures with portfolio and project-level detail assigning tasks to
specific resources.
- Establish architecture evolution cycle to ensure that the architecture stays
relevant
- Document lessons learned to enable continuous process improvement
• Inputs
- Reference Materials External to the Enterprise
Architecture reference materials
- Non-Architectural Inputs
Request for Architecture Work
Capability Assessment
Communications Plan
- Architectural Inputs
Organizational Model for Enterprise Architecture, including:
• Scope of organizations impacted
• Maturity assessment, gaps, and resolution approach
• Roles and responsibilities for architecture team(s)
• Constraints on architecture work
• Budget requirements
• Governance and support strategy
Governance models and frameworks:
• Enterprise Architecture Management Framework
• Capability Management Framework
• Portfolio Management Framework
• Project Management Framework
• Operations Management Framework
Tailored Architecture Framework, including:
• Tailored architecture method
• Tailored architecture content
• Configured and deployed tools
Statement of Architecture Work
Architecture Vision
Architecture Repository, including:
• Re-usable building blocks
• Publicly available reference models
• Organization-specific reference models
• Organization standards
Draft Architecture Definition Document, including:
• Strategic Migration Plan
• Baseline Business Architecture, Version 1.0 (detailed)
• Target Business Architecture Version 1.0 (detailed)
• Baseline Data Architecture, Version 1.0 (detailed)
• Target Data Architecture, Version 1.0 (detailed)
• Baseline Application Architecture, Version 1.0 (detailed)
• Target Application Architecture, Version 1.0 (detailed)
• Baseline Technology Architecture, Version 0.1 (detailed)
• Target Technology Architecture, Version 0.1 (detailed)
• Impact Analysis – Project List and Charters
Draft Architecture Requirements Specification, including:
• Architectural requirements
• Gap analysis results (from Business, Data, Application, and
Technology Architecture)
• IT service management integration requirements
Change Requests for existing business programs and projects
Consolidated and validated Architecture Roadmap
Capability Assessment, including:
• Enterprise Architecture Maturity Profile
• Transformation Readiness Report
Transition Architecture, Version 1.0, including:
• Consolidated Gaps, Solutions, and Dependencies
Assessment
• Risk Register, Version 1.0
• Impact analysis - project list
• Dependency Analysis Report
• Implementation Factor Assessment and Deduction Matrix
Implementation and Migration Plan, Version 0.1, including the
high-level Implementation and Migration Strategy
• Steps
• Outputs
• Objectives
• Approach
- Establish an implementation program that will enable the delivery of the
Transition Architectures agreed for implementation during the Migration
Planning phase
- Adopt a phased deployment schedule that reflects the business priorities
embodied in the Architecture Roadmap
- Follow the organization's standard for corporate, IT, and architecture
governance
- Use the organization's established portfolio/program management
approach, where this exists
- Define an operations framework to ensure the effective long life of the
deployed solution
• Inputs
• Objectives
• Approach
• Steps
• Outputs
• Objectives
• Approach
• Inputs
• Steps
Notes
• Outputs
• K 18.1-1 (1
KLP 1N) Understa
anding the contents
c of Part
P III includ
ding an overrview of the
purpose of ea
ach of the gu
uidelines and techniques provided.
19. Apply
ying Iteration to the ADM
M
- organizational fac
ctors such as
s:
formality and
a nature of
o establishe
ed process checkpoints within
w the
organization (gated ap
pproach)
level of sta
akeholder in
nvolvement expected
e witthin the proc
cess
number off teams invo e relationships between different tea
olved and the ams
maturity of on area and the expected amount off re-work an
o the solutio nd
proof of concept, protottype)
refinement required (p
Attitude to
o risk
- ADM iteration
i cyc
cles are inten
nded to span
n multiple ph
hases of activity and allo
ow
forma
al review upo
on completio
on of each multi-phase
m iteration cyc
cle
- Sugge
ested Iteratio
on cycles
Architecture Context iterations
i alllow initial arrchitecture activities
a
Architecture Definition
n iterations allow
a the cre
eation of arc
chitecture
content by
y cycling through Busine
ess, Informattion Systems
s and
Technolog
gy Architectu
ure phases
Transition Planning ite
erations sup
pport the creation of form
mal change
roadmaps for a define
ed architectu
ure
Architecture Governan
nce iterations support go
overnance of change acttivity
progressin
ng towards a defined Target Architecture
20. Apply
ying the ADM
M at Differen
nt ADM Leve
els
- 3 areas of engagement fo
or architects
s:
Identification of Required
R Cha
ange
architecture can be us
sed as a tech
hnique to pro
ovide visibility of IT
capability in order to support
s stra
ategic decisio
on-making and
a executio
on
Definiition of Chan
nge
Where there is a need for change, architecture
e can be use
ed as a techn
nique
to define the
t nature and extent off change
Implementation of
o Change
Architecture at all leve
els of the enterprise can be used as a technique
e to
provide de
esign govern
nance to cha
ange initiativ ding big-picture
ves by provid
visibility, supplying structural constraints, and defining criteria on which
to evaluate technical decisions
• KLP 20-2 (2N) Define the different approaches used to implement architecture on
different levels on the organisation
• KLP 21-1 (2N) Characteristics of Security Architecture for the Enterprise Architect
• KLP 21-2 (2N) Define the Security Architecture influences on ADM Architecture
Requirements Management
• KLP 21-3 (2N) Define the Security Architecture influences on the Preliminary Phase
- Determine who are the legitimate actors who will interact with the
product/service/process
Authorization needs
- Assess and baseline current security-specific business processes
- Determine whom/how much it is acceptable to inconvenience in utilizing security
measures
- Identify and document interconnecting systems beyond project control
- Determine the assets at risk if something goes wrong - "What are we trying to
protect?"
- Determine the cost (both qualitative and quantitative) of asset loss/impact in
failure cases
- Identify and document the ownership of assets
Trust assumptions
- Determine and document appropriate security forensic processes
- Identify the criticality of the availability and correct operation of the overall
service
- Determine and document how much security (cost) is justified by the threats and
the value of the assets at risk
- Reassess and confirm Architecture Vision decisions
- Assess alignment or conflict of identified security policies with business goals
- Determine "what can go wrong?"
Threat analysis
• KLP 21-6 (2N) Define the Security Architecture influences on Phase C
- Assess the impact of new security measures upon other new components or
existing leveraged systems
- Implement assurance methods by which the efficacy of security measures will be
measured and communicated on an ongoing basis
- Identify correct secure installation parameters, initial conditions, and
configurations
- Implement disaster recovery and business continuity plans or modifications
- Determine "what can go wrong?"
- Establish architecture artifact, design, and code reviews and define acceptance
criteria for the successful implementation of the findings
Mitigate security exposure in code
- Implement methods and procedures to review evidence produced by the system
that reflects operational stability and adherence to security policies
Review system configurations with security impact which can be modified
to ensure configuration changes have not compromised security design
Audit the design, deployment, and operations against security policies
Audit the design, deployment, and operations against business objectives
Run test cases against systems to ensure the security systems have been
implemented as designed
Run disaster recovery tests
Run business continuity tests
- Implement necessary training to ensure correct deployment, configuration, and
operations of security-relevant subsystems and components; ensure awareness
training of all users and non-privileged operators of the system and/or its
components
- Determine "what has gone wrong?"
- autonomous
- loosely coupled: minimized dependencies
- re-usable
- contractual: adhere to agreement on service description
- composable: facilitate the assembly of composite services
- EA provides in SOA context a set of tools and techniques to link top down
business-led SOA with bottom up developer-led SOA that addresses many of the
non technical challenges with SOA adoption
• KLP 22-4 (-) Using the TOGAF meta-model to capture SOA concepts
- define the underlying general rules and guidelines for the use and deployment of
all IT resources and assets across the enterprise
- reflect a level of consensus among the various elements of the enterprise, and
form the basis for making future IT decisions
Name Should both represent the essence of the rule as well as be easy to remember.
Statement Should succinctly and unambiguously communicate the fundamental rule.
Rationale Should highlight the business benefits of adhering to the principle, using business
terminology.
Implications Should highlight the impact of not adhering to the principle.
- Frequently, Architecture Principles are developed by the Lead Architect with input
from various stakeholders.
- 5 criteria:
Understandable
Robust
Complete
Consistent
Stable
Principle 8:
IT Responsibility
Statement:
The IT organization is responsible for owning and implementing IT processes
and infrastructure that enable solutions to meet user-defined requirements for
functionality, service levels, cost, and delivery timing.
Rationale:
Effectively align expectations with capabilities and costs so that all projects are
cost-effective. Efficient and effective solutions have reasonable costs and clear
benefits.
Implications:
• A process must be created to prioritize projects.
• The IT function must define processes to manage business unit expectations.
• Data, application, and technology models must be created to enable integrated
quality solutions and to maximize results.
24. Architecture Stakeholder Management
• KLP 24-1 (2N) Why stakeholder management is important
1. Identify Stakeholders
2. Classify Stakeholder Positions
3. Determine Stakeholder Management Approach
4. Tailor Engagement Deliverables
CxO This stakeholder group is interested in the high-level drivers, KEEP Business Footprint
(Corporate Functions); goals, and objectives of the organization, and how these are SATISFIED
e.g., CEO, CFO, CIO, translated into an effective process and IT architecture to
Goal/Objective/
COO advance the business.
Service Model
Organization Chart
Program Management This stakeholder group is interested in prioritizing, funding, and KEEP Roadmaps
Office aligning change activity. An understanding of project content and SATISFIED
(Corporate Functions); technical dependencies between projects adds a further
Business Footprint
e.g., Project Portfolio dimension of richness to portfolio management decision-making.
Managers
Application
Communication
Functional
Decomposition
Enterprise Security Major concerns for this group are understanding how to ensure KEY Data Security View
(Corporate Functions); that the information, data, and systems of the organization are PLAYERS
e.g., Corporate Risk available to only those that have permission, and how to protect
Networked
Management, Security the information, data, and systems from unauthorized tampering.
Computing
Officers, IT Security
Hardware View
Managers
Communications
View
• KLP 26.1-2 (1) When the business scenario technique is used within TOGAF
- Throughout all phases of the DAM but figure most prominently in Phase A -
Architecture Vision
- The stakeholders (e.g., business managers, end users) will tell you what they
want
- If the stakeholders do not know what they want:
Take time, observe, and record how they are working today
Structure information in such a way that it can be used later
Uncover critical business rules from domain experts
Stay focused on what needs to be accomplished, and how it is to be
accomplished
- Identifying, Documenting and Ranking the Problem
- Identifying the Business & Technical Environment and Documenting in Models
- Identifying and Documenting Objectives
- Identifying Human Actors and their Place in the Business Model
- Identifying Computer Actors and their Place in the Technology Model
- Documenting Roles, Responsibilities, Measures of Success, Required Scripts
- Checking for Fitness-for-Purpose and refining if necessary
- Goals must be stated in general terms with measures attached to them (SMART)
- SMART – Specific, Measurable, Actionable, Realistic, Time-bound
- Objectives should be derived from business goals
27. Gap Analysis
A
• KLP 27.1-1 (2
2)Where the gap analysis
s technique is used with
hin TOGAF and why
- Widely
y used in the
e ADM to hig
ghlight a sho
ortfall betwe
een the Base
eline Architec
cture
and th
he Target Arrchitecture; that
t is, items that have been
b deliberrately omitte
ed,
accide
entally left out,
o or not ye
et defined
- Potential Gap in:
Business Domain
D
Data Domain
Application created, im
mpacted or eliminated
e
Technolog mpacted or eliminated
gy created, im
• KLP 27.2-1 (1
1)The technique of gap analysis
a
ation Plannin
28. Migra ng Techniqu
ues
• KLP 28-1 (2N ation Factor Assessment and Deduc
N)Implementa ction Matrix
- hnique used to group the Gaps identified in the domain architecture and
A tech
assess
s potential solutions
s and
d dependenc
cies to one or
o more Gap
ps
- A tech
hnique that allows
a the Architect
A to plan
p a series of Transitio
on Architectu
ures
KLP 28-4
4 (2N) Enterp
prise Archite
ecture State Evolution Ta
able
- A tech
hnique that allows
a the Architect
A to show
s the pro
oposed stage
e of the
Archittectures at various
v level using the TRM
• KLP 28-5 (2N
N)Business Va
alue Assessm
ment Techniique
- A tech
hnique to assess Busines
ss Value bas
sed on Value
e Index dime
ension and Risk
R
Index dimension
29. Intero
operability Requirement
R ts
• KLP 29.1-1 (1
1N) Where th
he determina
ation of interoperability is used with
hin the ADM
Phase C - Applica
ation A
Application s
sharing of in
nformation and
a services is
s
specified
Phase D T
Technical me
echanisms to
o permit info
ormation and
s
service exchanges are sp
pecified
Phase E A
Actual solutions are sele
ected
- Have to ensure that there are no interoperability conflicts especially if there is no re-
use of SBBs and/or COTs
- Business Interoperability – beware of changing embedded business processes vs
reuse of solutions
- Interoperability Constraints – check the following:
Architecture Vision
Target Architectures
Implementation Factor Assessment Deduction Matrix
Consolidated Gaps, Solutions and Dependencies Matrix
30. Busin
ness Transfo
ormation Rea
adiness Asse
essment
• KLP 30.1-1 (1 he Business Transformattion Readine
1N) Where th ess Assessment is used
w
within the AD
DM
- Phase A – Phase D
Determ
mine the rea
adiness facto
ors that will impact the organization
o n
Presen ness factors using maturity models
nt the readin
Assess the readiness factors, including de
etermination
n of readines
ss factor ratings
Assess the risks for diness factorr and identiffy improvement actions to
f each read
mitiga
ate the risk
- Phase E – Phase F
Use th
he informatio
on from Pha
ase A to Phas
se D to unde
erstand the enterprise
e
busine
ess readines
ss for Implem
mentation an
nd Migration
n
• KLP 30.1-2 (1
1N) Characte
eristics of the Business T
Transformation Enablem
ment Program
m
- BTEP provides
p guiidance on ho
ow to identiffy Business Transformat
T tion related
issues
s
- Assessment is bas
sed upon the determina
ation and ana g of a series of
alysis/rating
readin
ness factors
- Readiness Factors
s (organizations will hav
ve their own unique set)
- Assessment of Re
eadiness Factors using Maturity
M Mod
dels
- Readiness Factor Vision (Targ
get State)
- Readiness Factor Rating
- Readiness Factor Risks & Actions
-
• KLP 30.2-1 (2
2N) Identify factors that influence Arrchitecture Transformat
T ion Readiness
• KLP 30.3-1 (2N) Understand how to apply Architecture Maturity Models
- A list of well-defined factors that make up the Maturity Model should be agreed
upon, along with criteria for each level of maturity
- This list is then passed around to relevant stakeholders and each factor is
assessed
- The score is tallied to come up with a Maturity Rating
31. Risk
• KLP 31.1-1 (1N) Where Risk Management is used within the ADM Management
- Risk classification
- Risk identification
- Initial Risk assessment
- Risk mitigation and Residual Risk assessment
- Risk Monitoring
- Corporate
e strategic direction driv
ves the Architecture Vision in Phase A
- Specific capabilities ta
argeted for completion
c w be the fo
will ocus of the Architecture
A e
Definition
n (Phases B, C, and D)
- on the identified work packages,
Based upo p Phase E projec
cts will be co
onceived
- Capability s will be the drivers for the
y increments t Transitio
on Architectu
ures (Phase E)
- Actual delivery will be
e co-ordinatted through the Impleme
entation and
d Migration Plans
P
(Phase F).
Module 3: Content Framework
33 Introduction
• KLP 33.1-1 (1N) An overview of the Architecture Content Framework including
explanations of key concepts: deliverable, artifact, building block and their relationship
- Provides a definition of all the types of building blocks that may exist within an
architecture, showing how these building blocks can be described and related to
one another
• KLP 33.3-1 (2N) The content Framework and the TOGAF ADM
- ADM describes what needs to be done to create an architecture and the content
framework describes what the architecture should look like once it is done
34 Content Metamodel
• KLP 34.2-1 (2N) Describe the metamodel entities that form the core of the TOGAF
Metamodel
• KLP 34.2-2 (2N) Identify the catalogues, matrices and diagrams relevant to the different
ADM phases
ADM Phase Artifacts
Role Catalog
Actor/Role Matrix
System/Data Matrix
Class Diagram
System/Organization Matrix
Role/System Matrix
System/Function Matrix
System/Technology Matrix
Benefits Diagram
- Proces
ss should no
ormally be used to descrribe flow
- Function describe
es units of bu
usiness capa
ability at all levels of gra
anularity
- Busine ganizational objectives and
ess services support org a are defin
ned at a leve
el of
granularity consis
stent with the level of go
overnance ne
eeded
- Busine
ess services are deploye
ed onto application components
- Applic
cation components are deployed
d onto technolog
gy components
• KLP 34.4-1 (-
-) Explain wh
hen Contentt Metamodel extensions should be used
u
- Goverrnance exten
nsion is inten
nded to allow
w additionall structured data to be held
h
agains
st objectives ess services, supporting operational governance
s and busine e of
the landscape
- Extension should be used when
When an organization
o is consideriing IT chang
ge that will re
esult in a
significantt impact to existing
e vernance models
operational gov
When an organization
o has granula
ar requireme
ents for serv
vice levels that
differ from
m service to service
When an organization
o is looking to
t transform its operatio
onal governa
ance
practice
When an organization
o has very strrong focus on
o business drivers, goa
als,
and objecttives and ho ce to service levels
ow these trac
• KLP 34.4.2-1 (-) Explain the purpose of the Services Extension
• KLP 34.4.3-1 (-) Explain the purpose of the Process Modelling Extension
- The data extension is intended to allow more sophisticated modeling and the
encapsulation of data. The core model provides a data entity concept which
supports the creation of data models, which is then extended by this extension
to include the concept of a data component. Data components form a logical or
physical encapsulation of abstract data entities into units that can be governed
and deployed into applications.
- This extension should be used in the following situations:
Where the architecture features significant complexity and risk around
the location, encapsulation, and management of or access to data
• KLP 34.4.5-1 (-) Explain the purpose of the Infrastructure Consolidation Extension
• KLP 35.1-2 (1
1) Provide a simple exam
mple of a vie
ew and viewp
point
• KLP 35.1-3 (1
1) Discuss th
he relationsh
hip between Stakeholderrs, Concerns
s, Views, and
d
Viewpoints
- A "view
w" is a repre
esentation of a whole sy
ystem from the perspective of a relatted
set off concerns.
- A "view
wpoint" defiines the pers
spective from
m which a viiew is taken
- Stakeh
holders and concerns arre elements of viewpointts used to de
efine a view
• KLP 35.2-1 (1
1) Discuss an
nd describe the view cre
eation process
Viewpoint Description
Element
Stakeholders Management Board, Chief Executive Officer
Concerns Show the top-level relationships between geographical sites and
business functions.
Modeling Nested boxes diagram.
technique Outer boxes = locations; inner boxes = business functions.
Semantics of nesting = functions performed in the locations.
• KLP 35.6-2 (2N) What are the classes of viewpoints associated with the TOGAF Core
Content Metamodel?
- specific classes of viewpoint are as follows:
Catalogs
• specific foundational viewpoints that represent lists of building
blocks
Matrices
• specific foundational viewpoints that show the relationships
between building blocks of specific types
Diagrams
• graphical viewpoints that present building blocks in a rich and
visual way, more suited to stakeholder communication
- The TOGAF architecture domains are themselves viewpoints that can be used to
group the foundational catalogs, matrices, and diagrams:
Business Architecture domain
Data Architecture domain
Application Architecture domain
Technology Architecture domain
36 Architecture Deliverables
• KLP 36.1-1 (1) Understand and explain the purpose of this section of the document
• KLP 36.1-2 (2N) Understand where within the ADM each architecture deliverable is used
Architecture Contract F G
Architecture Roadmap B, C, D, E, F C, D, E, F, G, H
Capability Assessment A, E B, C, D, E, F
Change Request H -
Communications Plan A B, C, D, E, F
Compliance Assessment G H
Transition Architecture E, F G, H
KLP 36.2-1 (1N) Understand the purpose of each architecture deliverable
• KLP 36.2-2 (2N) Understand the high level contents of each architecture deliverable
- Architecture Contract
Architecture Contracts are the joint agreements between development
partners and sponsors on the deliverables, quality, and fitness-for-
purpose of an architecture
Content
Typical contents of an Architecture Design and Development Contract are:
• Introduction and background
• The 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 metrics
- Architecture Principles
Provide rules and guidelines for architecture work
Content – Refer to Module 23
- Architecture Repository
as a holding area for all architecture-related projects within the
enterprise
allows projects to manage their deliverables, locate re-usable assets,
and publish outputs to stakeholders and other interested parties
Content
Typical contents of an Architecture Repository are:
• Architecture Framework
• Standards Information Base
• Architecture Landscape
• Reference Architectures
• Governance Log
- Architecture Roadmap
The Architecture Roadmap lists individual increments of change and lays
them out on a timeline to show progression from the Baseline
Architecture to the Target Architecture
Content
Typical contents of an Architecture Roadmap are:
• Project list:
o Name, description, and objectives of each impacted
project
o Prioritized list of impacted projects to implement the
proposed architecture
• Time-oriented Migration Plan:
o Benefits of migration, determined (including mapping to
business requirements)
o Estimated costs of migration options
• Implementation recommendations:
o Criteria measures of effectiveness of projects
o Risks and issues
o Solution Building Blocks (SBBs) - description and model
- Architecture Vision
provides a high-level, aspirational view of the end architecture product
supports stakeholder communication by providing an executive summary
version of the full Architecture Definition
Content
Typical contents of an Architecture Vision are:
• Problem description:
o Stakeholders and their concerns
o List of issues/scenarios to be addressed
• Detailed objectives
• Environment and process models:
o Process description
o Process steps mapped to environment
o Process steps mapped to people
o Information flow
• Actors and their roles and responsibilities:
o Human actors and roles
o Computer actors and roles
o Requirements
• Resulting architecture model;
o Constraints
o IT principles
o Architecture supporting the process
o Requirements mapped to architecture
- Capability Assessment
understand the baseline and target capability level of the enterprise
Content
Typical contents of a Capability Assessment are:
• Business Capability Assessment, including:
o Capabilities of the business
o Baseline state assessment of the performance level of each
capability
o Future state aspiration for the performance level of each
capability
o Baseline state assessment of how each capability is realized
o Future state aspiration for how each capability should be
realized
• IT Capability Assessment, including:
o Baseline and target maturity level of change process
o Baseline and target maturity level of operational processes
o Baseline capability and capacity assessment
o Assessment of likely impacts to the IT organization resulting
from execution of the architecture project
• Architecture maturity assessment, including:
o Architecture governance processes, organization, roles, and
responsibilities
o Architecture skills assessment
o Breadth, depth, and quality of landscape definition with the
Architecture Repository
o Breadth, depth, and quality of standards definition with the
Architecture Repository
o Breadth, depth, and quality of reference model definition with
the Architecture Repository
o Assessment of re-use potential
• Business Transformation Readiness Assessment, including:
o Readiness factors
o Vision for each readiness factor
o Current and target readiness ratings
o Readiness risks
- Change Request
when there is a need to change the original Architecture Definition and
requirements, a Change Request is submitted to kick-start a further cycle of
architecture work
Content
Typical contents of a Change Request are:
• Description of the proposed change
• Rationale for the proposed change
• Impact assessment of the proposed change, including:
o Reference to specific requirements
o Stakeholder priority of the requirements to date
o Phases to be revisited
o Phase to lead on requirements prioritization
o Results of phase investigations and revised priorities
o Recommendations on management of requirements
• Repository reference number
- Communications Plan
To ensure that effective communication of targeted information to the right
stakeholders at the right time is carried out within a planned and managed
process
Content
Typical contents of a Communications Plan are:
• Identification of stakeholders and grouping by communication
requirements
• Identification of communication needs, key messages in relation to the
Architecture Vision, communication risks, and Critical Success Factors
(CSFs)
• Identification of mechanisms that will be used to communicate with
stakeholders and allow access to architecture information, such as
meetings, newsletters, repositories, etc.
• Identification of a communications timetable, showing which
communications will occur with which stakeholder groups at what time
and in what location
- Compliance Assessment
Period compliance reviews of implementation projects provide a mechanism
to review project progress and ensure that the design and implementation is
proceeding in-line with the strategic and architectural objectives
Content
Typical contents of a Compliance Assessment are:
• Overview of project progress and status
• Overview of project architecture/design
• Completed architecture checklists:
o Hardware and operating system checklist
o Software services and middleware checklist
o Applications checklists
o Information management checklists
o Security checklists
o System management checklists
o System engineering checklists
o Methods and tools checklists
• KLP 37.1-2 (1) What is the relationship of Building Blocks to other TOGAF deliverables?
- ABBs relate to the Architecture Continuum and are selected or defined as TOGAF
deliverables
• KLP 37.2-1 (1) Define what a building block is, and explain the attributes of a good
building block
• KLP 37.2-2 (1) Explain the distinction between Architecture Building Blocks and Solution
Building Blocks
ABB
• KLP 37.2-4 (2) What are the characteristics and specification content of Solution Building
Blocks?
SBB
• KLP 37.3-2 (2
2) What are the
t classes of
o Building Blocks?
B
• KLP 37.3-3 (2
2) How do building blocks evolve as a project moves
m throug
gh the phase
es of
th
he ADM?
- early stages
s and during
d views
s of the high
hest-level en
nterprise
ng blocks are often keptt at a broad integration definition
the buildin d
- as imp
plementation considerattions are add
dressed
more detailed views of building blocks can often be used to address
implementation decisions, focus on the critical strategic decisions, or aid
in assessing the value and future impact of commonality and re-usability
- Building block example shows that when executing major steps of the ADM
- Background information
Company XYZ
Objective is to improve the efficiency of its mobile sales force
Initiative is to replace paper-based configuration and ordering system
with an IT solution
• KLP 37.4.-2 (2) How are Building Blocks scoped in the Building Blocks example?
- Based on business goals and assumption that the proposed solution would fit
within financial and time constraint, it is assumed that the scope of the
architecture work would not extend beyond the sales arena
- The sales process was defined
- Any computing participants in the sale process became the first set of identified
candidate building block
• KLP 37.4.-3 (2) What are the key differences in the Baseline and Target Architecture
models?
- Return on investment is the driving force behind the decision to retain the
existing system for price data
- Quality problems with the price system highlighted in XYZ Baseline
Architecture will be resolved through a single metadata definition and rules for
synchronization
- legacy systems are integrated into the new SalesApp (Sales Order Application) by
developing adapter software
Module
e 4: Enterp
prise Contiinuum
Enterpris
se Continuum
m
• KLP 39.1-1 (1
1) What is th
he Enterprise
e Continuum
m (EC)?
• KLP 39.1-2 (1
1N) What is the
t relations
ship between
n the Enterprise Continu
uum and the
A
Architecture Repository?
R (See above)
• KLP 39.2-1 (1
1) How is the
e Enterprise Continuum used in organizing and developing
arrchitectures??
- provid
des a consisttent languag
ge in organiz
zing architec
ctures
- is an aid
a to comm
munications when
w develo
oping archite
ectures
• KLP 39.2-2 (1
1) How does the Enterprrise Continuu
um promote
e reuse of arc
chitecture
arrtifacts?
- Reuse
e is a major factor
f when considering
g which artifa eside in the EC
act should re
• KLP 39.3-1 (1
1) What are the
t constitue
ents of the Enterprise
E Co
ontinuum
• KLP 39.3-2 (1) What is the purpose of the Enterprise Continuum
• KLP-39.4-1 (2) What assets can be managed through the Enterprise Continuum?
- EC classifies architecture assets (building blocks) that are applicable across the
entire scope of the enterprise architecture.
- Assets can take the form of business goals and objectives, strategic initiatives,
capabilities, policies, standards and principles
• KLP 39.4-2 (2) What types of contextual factors are managed in the Enterprise
Continuum?
• KLP 39.4-4 (1) What are the stages of architecture evolution defined in the Architecture
Continuum?
• KLP 39.4-7 (1) What are the stages of architecture evolution defined in the Solution
Continuum?
• KLP 39.5-1 (1) What is the relationship between the Enterprise Continuum and the
TOGAF ADM?
- Throughout the ADM, there are to useful architecture assets at the relevant level
of generality in the continuum classification
- TOGAF itself provides two reference models for consideration for use in
developing an organization's architecture
• KLP 39.6-1 (2) What is the relationship between the three continua as the architecture
evolves?
- Enterprise Continuum
provides an overall context for architectures and solutions and classifies
assets that apply across the entire scope of the enterprise
- Architecture Continuum
provides a classification mechanism for assets that collectively define the
architecture at different levels of evolution from generic to specific
- Solutions Continuum
provides the classification for assets to describe specific solutions for the
organization that can be implemented to achieve the intent of the
architecture
Architecture Partitioning
• KLP 40.1-2 (2N) What are the reasons for partitioning the Enterprise Architecture?
- Subject Matter
Description of the solution (pre-conditions, post-conditions, consumers,
suppliers, ownership, operation, influencing factors)
- Time
- Maturity/Volatility
Extent to which the subject matter and environment of a solution are
likely to change over time
Highly volatile or immature solutions are likely to be managed and valued
very differently to very stable or mature solutions
- Subject Matter
Description (the subject matter, environment, time, and volatility)
- Viewpoint
- Level of Detail
- Level of Abstraction
- Accuracy
• KLP 40.4-1 (2N) How are the classifications employed to partition architectures?
• KLP 40.4-2 (2N) What are the tiers of enterprise architecture landscapes?
• KLP 40.4-3 (2N) How does Architecture Partitioning encourage good practices
• KLP 40.4-4 (2N) How can Policy enforcement and compliance be facilitated through
architecture partitioning?
- By partitioning standards
• KLP 40.4-5 (2N) What are the key architecture partitioning activities for each phase of
the ADM?
- Preliminary phase
supports the identification of appropriate architecture partitions and
establishment of governance relationships between related architecture
partitions
- ADM Phases A to F
allow definition of the architecture within a specific partition
- ADM Phases G and H
allow the implementation of an architecture to be governed
governance may apply to the direct realization of a solution, or may
address the governance of architectures being developed in other
partitions
• KLP 40.4-6 (2N) How can the TOGAF Content Framework be used to aggregate and
integrate architecture content to facilitate a coherent enterprise architecture strategy?
- TOGAF content framework can be used to specify standard building blocks and
artifacts that are the subject of content integration standards
• KLP 41.1-2 (1N) What are the classes of information that are held in an Architecture
Repository?
- 6 Classes of Information
Architecture Metamodel
Architecture Capability
Architecture Landscape
Standards Information Base
Reference Library
Governance Log
• KLP 41.2-1 (1N) What are the three levels of the Architecture Landscape?
- Strategic Architecture
- Segment Architecture
- Capability Architecture
• KLP 41.3-1 (1N) What types of content can be held in the Reference Library of the
Architecture Repository?
• KLP 41.4-2 (2N) What are the classes of standards held in the Standards Information
Base?
• KLP 41.5-1 (2N) What is the purpose of the Governance Log in the Architecture
Repository?
- Decision Log
A log of all architecturally significant decisions that have been made in
the organization
- Compliance Assessments
- Capability Assessments
- Calendar
should show a schedule of in-flight projects and formal review sessions
to be held against these projects
- Project Portfolio
- Performance Measurement:
• KLP 42.2-1 (1) An understanding of high level issues with tool standardization
- Functionality
- Intuitiveness/Ease-of-Use Factors
- Organizational Compatibility Factors
- Tool Capacity/Scalability Constraints
- Architecture of the Tool
- Full Lifecycle Support
- Interoperability Factors
- Financial Considerations
- Vendor Factors
Module
e 5: TOGAF
F Referencce Model
• KLP 43.1-1 (1
1) What is th
he TOGAF Fo
oundation Arrchitecture?
- is an architecture
a of generic services
s and functions th
hat provides
s a foundatio
on on
which more specific architectures and arc
chitectural components can be built
• KLP 43.1-2 (1
1) What is th
he role of the
e Technical Reference
R Model in the Foundation
F
A
Architecture?
- Found
dation Archittecture is em
mbodied with
hin the Tech
hnical Refere
ence Model (T
TRM)
• KLP 43.1-3 (1
1) What are the
t compone
ents of the TRM?
T
- Taxon
nomy and TR
RM Graphics
• KLP 43.2-1 (1
1) What are the
t major en
ntities in the
e TOGAF TRM
M?
• KLP 43.2-2 (1
1) What are the
t main arc
chitecture ob
bjectives tha
at can be ach
hieved by using
th
he TRM?
- Applic
cation Portab
bility, via the
e Application
n Platform In
nterface
- Intero
operability, via
v the Comm
munications Infrastructu
ure
• KLP 43.3-1 (1
1) What is th
he purpose, structure
s and use of the
e TRM?
• three entities:
o Application Softwa
are
o Application Platforrm
o Comm
munications Infrastructurre
• tw
wo interfaces
s:
o Application Platforrm Interface
o Comm
munications Infrastructurre Interface
• KLP 43.3-2 (2
2) What is th
he difference pplication and an
e between a Business Ap
In
nfrastructure
e Application
n?
- ess Applications
Busine
implementt business processes
p forr a particular enterprise or vertical
industry
- Infrastructure App
plications,
provide ge
eneral-purpo
ose business n infrastructure
s functionaliity, based on
services
• KLP 43.3-3 (2
2) What is th
he Applicatio
on Platform Interface?
- speciffies a comple
ete interface
e between th
he Applicatio
on Software and the
underrlying Applic vices are provided
cation Platforrm across which all serv
• KLP 43.3-4 (2
2) What is th
he Communications Infra
astructure In
nterface?
- Is the interface be
etween the Application
A P
Platform and
d the Commu
unications
Infrastructure
• KLP 43.3-5 (2
2) What is th
he Applicatio
on Platform Concept?
C
• KLP 43.4-1 (1
1) What is th
he Platform Services
S Taxonomy?
- Availa
ability (the degree to which somethin ble for use), including:
ng is availab
Manageab
bility, the abiility to gathe
er informatio
on about the
e state of
something
g and to control it
Serviceability, the ability to identiffy problems and take co
orrective action,
such as to
o repair or up
pgrade a com
mponent in a running sy
ystem
Performan
nce, the ability of a comp erform its tasks in an
ponent to pe
appropriatte time
Reliability,, or resistanc
ce to failure
bility, or the ability to res
Recoverab store a syste
em to a work
king state affter
an interruption
Locatability, the ability of a system to be found when needed
- Assurance, including:
Security, or the protection of information from unauthorized access
Integrity, or the assurance that data has not been corrupted
Credibility, or the level of trust in the integrity of the system and its data
Usability, or ease-of-operation by users, including:
International Operation, including multi-lingual and multi-cultural
abilities
- Adaptability, including:
Interoperability, whether within or outside the organization (for instance,
interoperability of calendaring or scheduling functions may be key to the
usefulness of a system)
Scalability, the ability of a component to grow or shrink its performance
or capacity appropriately to the demands of the environment in which it
operates
Portability, of data, people, applications, and components
Extensibility, or the ability to accept new functionality
• KLP 43.5-1 (1) For each of the Detailed Taxonomy Categories, be able to identify
examples of the services that are provided
• KLP 44.1-2 (1) Describe the relationship of the III-RM to the concept of Boundaryless
Information Flow
• KLP 44.1-3 (2) What are the key Business and Technical drivers for Boundaryless
Information Flow
- getting information to the right people at the right time in a secure, reliable
manner, in order to support the operations that are core to the extended
enterprise
- businesses require speed, flexibility, and responsiveness to changing markets
- provide access to information to each cross-functional team on an as-required
basis
• KLP 44.1-4 (2) How does the III-RM fulfil the solutions space for Boundaryless
Information Flow?
• KLP 44.3-1 (2
2) The detailled taxonom
my
Module 6: Capability Framework
45 Introduction
• KLP 45-1 (1) The existence of this Part and its purpose
• KLP 46.1-1 (1N)The approach of using the ADM to establish an Architecture Capability
- Establishing an Architecture Capability relative to the ADM using establishing an
Architecture Practice as example
47 Architecture Board
48 Archittecture Com
mpliance
• K 48.1-1 (1
KLP 1) The need for Architec
cture Compliance
- Archittecture Compliance is an
n essential part
p of the Architecture Governance
G
process
- It ensures that Arc
chitecture Guidelines
G an s are adhered to and if there
nd Standards
is any
y deviation, it is containe
ed and mitig
gated
• K 48.2-1 (1
KLP 1)The meaning of Archittecture Compliance
• K 48.3-1 (1
KLP 1)The purpose of Archite
ecture Comp
pliance Revie
ews
- Catch errors in the project arc
chitecture ea
arly
- Ensure best practices is applie
ed to the arc
chitecture work
w
- Provid
de an overvie
ew of the compliance off an architectture to mand
dated enterp
prise
standa
ards
- Indentify where sttandards ma
ay need mod
dification
- Identify services that
t ome part of the enterpriise infrastructure
can beco
- Docum
ment strateg
gies for colla
aboration, re
esource sharring and othe
er synergies
across
s multiple arrchitectural teams
t
- Take advantage
a o advances in
of i technolog
gy
- Comm
municate to managemen
m t the status of technical readiness of
o a project
- Identify key criterria for procurement activ
vities
- Identify and comm
municate sig
gnificant arch
hitectural ga
aps
• K 48.4-1 (1
KLP 1)The Architecture Comp
pliance Revie
ew Process
• K 48.6-1 (2
KLP 2)How to tailor and cond
duct an Arch
hitecture Com
mpliance Rev
view
- Tailorring checklists for review
w: Key consiiderations
Focus on high
h risk are
eas
Focus on differentiato
d ors
- Condu
ucting a review: Key con
nsiderations
nd the objecttives, conduct a producttive meeting and stay on
Understan n
track
Stay within
n scope of th
he review; ta
ake other ma
atters offline
e
Stay objec
ctive and bac
ckup discuss
sion with relevant and ac
ccurate data
a
Be sensitive to the politics and hidden agenda; use a depersonalize
approach to the discussion
Always treat the interviewees and their work with respect
49 Architecture Contracts
50 Architecture Governance
- 6 Characteristics of Governance
Discipline
Transparency
Independe
ence
Accountab
bility
Responsib
bility
Fairness
• K 50.2-1 (1
KLP 1)The main concepts
c tha
at make up an
a architectu
ure governan
nce framewo
ork
- Archittecture gove
ernance is a series of pro
ocesses
- processes are typically indepe
endent of the content which lends to
o a flexible
framework
• K 50.3-1 (1
KLP 1) Why is arc
chitecture go
overnance beneficial?
• KLP 51.3-1 (2)Understanding the concepts and level of the US Department of Commerce
Architecture Capability Maturity Model framework
- ACMM provides a framework that represents the key components of a productive
enterprise architecture process
- Helps in conducting assessment
- Goal is to enhance overall success of enterprise architecture by identifying weak
areas and providing a defined path to improve the process
- 3 sections
Enterprise Architecture Maturity Model
EA characteristics of operating units’ processes at different maturity level
EA CMM Scorecard
- 6 maturity levels
• KLP 51.3-2 (2)Ability to relate the levels of ACCM to the TOGAF ADM
Level 0 No ADM
Module 7: TOGAF 8 to TOGAF 9 Migration
In addition to meeting TOGAF 9 Foundation and Practitioner Requirements, the candidate must
be able to:
on part of th
Introductio he TOGAF 8.1.1 specifica
ation has be
een used as the
t
basis for creation
c of Part
P I: Introdu
uction in TO
OGAF 9
F 8.1.1 ADM has been retained in TO
Essence off the TOGAF OGAF 9. Part II:
Architecture Developm
ment Method
d (ADM)
Enterprise Continuum concept is retained
r with
hin Part V: Enterprise
E
Continuum
m & Tools.
TOGAF Technical Reference Model and Integrated Information
Infrastructure Reference Model are extracted and placed within Part VI:
TOGAF Reference Models in TOGAF 9
TOGAF 9 removes the Standards Information Base from the TOGAF
specification
Developing Architecture Views Elements retained within Part IV: Architecture Content Framework
Building Blocks Elements retained within Part IV: Architecture Content Framework
Business Process Domain Views Elements retained within Part IV: Architecture Content Framework
Case Studies Removed. Case Studies will be available on The Open Group web site.
Other Architectures & Frameworks Removed. This material will be available on The Open Group web site
as a White Paper.
Tools for Architecture Development Moved to Part V: Enterprise Continuum & Tools
ADM and the Zachman Framework Removed. This material will be available on The Open Group web site
as a White Paper.
• Describe the key differences between the ADM in TOGAF 8.1.1 and TOGAF 9
- TOGAF 9 provides more details in the following:
The Preliminary phase, which features extended guidance on establishing
an enterprise architecture framework and planning for architecture
development. The extended Preliminary phase also provides pointers to
the definition of a governance model for architecture benefit realization
and also discusses the linkage between TOGAF and other management
frameworks.
The Opportunities & Solutions phase and Migration Planning phase, which
feature a more detailed and robust method for defining and planning
enterprise transformation, based on the principles of capability-based
planning.
- Treat the migration of TOGAF 8.1.1 to TOGAF 9 as a change request for the
Architecture Practice and run through Phase H