Qrs Togaf 8-9 Study Guide

Prepared by : QRS (www.quickresponse.
ca) TOGAF is a Registered Trademark of The Open Group
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
Module 1: Introduction to TOGAF .................................................................................................................... 3
Module 2: ADM, Guidelines and Techniques................................................................................................... 18
ADM Overview ........................................................................................................................................ 18
Architecture Development Methods ........................................................................................................... 21
Guidelines: ............................................................................................................................................. 53
Techniques ............................................................................................................................................. 61
Module 3: Content Framework .................................................................................................................. 73
Module 4: Enterprise Continuum ............................................................................................................... 98
Module 5: TOGAF Reference Model ........................................................................................................ 105
Module 6: Capability Framework ............................................................................................................. 113
Module 7: TOGAF 8 to TOGAF 9 Migration .............................................................................................. 122
How to KLP to Modules and Level of Learning

Module
e 1: Introduction t
to TOGAF
Introducttion
• KLP 1.1-1 (1N

N) The high level structu
ure of TOGAF 9, its organization and
d contents as
sh
hown in Figu
ure 1-1.
• KLP 1.1-2 (1N

N) The seven
n main parts to TOGAF.
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 allow for different areas of specialization to be considered in detail and

potentially addressed in isolation
• KLP 1.2-1 (1) What is an enterprise?
- TOGAF defines "enterprise" as any collection of organizations that has a common

set of goals
- An extended enterprise includes partners, suppliers, and customers
• KLP 1.2-2 (1) What is enterprise architecture?
- a formal description of a system, or a detailed plan of the system at component

level, to guide its implementation
- the structure of components, their inter-relationships, and the principles and

guidelines governing their design and evolution over time
• KLP 1.2-3 (1) Why do I need an enterprise architecture?
- 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?
- a foundational structure, or set of structures used for developing a broad range

of different architectures
- 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
- should contain a set of tools
- provide a common vocabulary
- include a list of recommended standards and compliant products that can be

used to implement the building blocks
• KLP 1.2-5 (1) Why do I need TOGAF as a framework for enterprise architecture?
- represents best practice in architecture development
- allows architectures to be developed that are consistent, reflect the needs of

stakeholders, employ best practice, and give due consideration both to current
requirements and to the likely future needs of the business
- helps to "de-mystify" and de-risk the architecture development process
2 Core Concepts
• KLP 2.1-1 (1) What is TOGAF?
- TOGAF is an architecture framework - The Open Group Architecture Framework
- based on an iterative process model supported by best practices and a re-usable

set of existing architecture assets
• KLP 2.2-1 (1) What is architecture in the context of TOGAF?
- In TOGAF, architecture has two meanings:
1. A formal description of a system, or a detailed plan of the system at

component level to guide its implementation
2. The structure of components, their inter-relationships, and the principles
and guidelines governing their design and evolution over time
• KLP 2.3-1 (1) What kind of architecture does TOGAF deal with?
- Business, Data, Application, Technology

• KLP 2.4-1 (1) The high level overview of the ADM , the phase names and their purpose
- Preliminary Phase describes the preparation and initiation activities required to

meet the business directive for a new enterprise architecture
- Phase A: Architecture Vision describes the initial phase of an architecture
development cycle
- Phase B: Business Architecture describes the development of a Business
Architecture to support an agreed Architecture Vision
- Phase C: Information Systems Architectures describes the development of
Information Systems Architectures for an architecture project, including the
development of Data and Application Architectures
- Phase D: Technology Architecture describes the development of the Technology
Architecture for an architecture project.
- Phase E: Opportunities & Solutions conducts initial implementation planning and
the identification of delivery vehicles for the architecture defined in the previous
phases
- Phase F: Migration Planning addresses the formulation of a set of detailed
sequence of transition architectures with a supporting Implementation and
Migration Plan
- Phase G: Implementation Governance provides an architectural oversight of the
implementation
- Phase H: Architecture Change Management establishes procedures for managing
change to the new architecture
- Requirements Management examines the process of managing architecture
requirements throughout the ADM
• KLP 2.5-1 (1N) Deliverables, Artifacts and Building Blocks (explaining these key concepts
and the relationships between them)
- A deliverable is a work product that is contractually specified and in turn

formally reviewed, agreed, and signed off by the stakeholders
- An artifact is a more granular architectural work product that describes an

architecture from a specific viewpoint. i.e. network diagram, a use-case
specification
- A building block represents a (potentially re-usable) component of business, IT,

or architectural capability that can be combined with other building blocks to
deliver architectures and solutions
- Deliverables contain artifacts
- Artifacts describe building blocks

• KLP 2.6-1 (1)Enterprise Continuum (introduces the concept)
- Enterprise Continuum is a view of the Architecture Repository that provides

methods for classifying architecture and solution artifacts, both internal and
external to the Architecture Repository, as they evolve from generic Foundation
Architectures to Organization-Specific Architectures
• KLP 2.7-1 (1N)Architecture Repository (introduces the concept)
- used to store different classes of architectural output at different levels of

abstraction, created by the ADM
• KLP 2.8-1 (1N)Establishing and maintaining an Enterprise Architecture Capability
- The following must be established in order to execute enterprise architecture

activities:
Appropriate business capability for architecture

Thorough organization structures
Defined roles, responsibilities, skills and processes
• KLP 2.9-1 (1N) Establishing the Architecture Capability as an operational entity.
- To be effective, an enterprise architecture practice must be run like an operation

unit, with governance and have the following capabilities:
Financial Management
Performance Management
Service Management
Risk Management
Resource Management
Communications and Stakeholder Management
Quality Management
Supplier Management
Configuration Management
Environment Management
• KLP 2.10-1 (1)Using TOGAF with other frameworks
- as a generic framework and method for enterprise architecture, TOGAF

complements other frameworks that are aimed at specific vertical business
domains, specific horizontal technology areas or specific application areas
• KLP 2.11-1 (1N) TOGAF Document Categorization Model (purpose and overview)
- is a model to structure the release management of TOGAF specifications

- categories are TOGAF Core, TOGAF Mandated, TOGAF Recommended, TOGAF
Supporting
3 Definitions
• KLP 3-1 The existence of the Definitions section and its purpose
- provides common vocabulary
• KLP 3.1-1 (-)Abstraction

- the technique of providing summarized or generalized descriptions of detailed
and complex content
• KLP 3.2-1 (1) Activity

- a task or collection of tasks that support the functions of an organization
• KLP 3.4-1 (1) Application

- a deployed and operational IT system that supports business functions and
services
• KLP 3.5-1 (1) Application Architecture

- a description of the major logical grouping of capabilities that manage the data
objects necessary to process the data and support the business
• KLP 3.9-1 (1) Architecture

- a formal description of a system, or a detailed plan of the system at component
level, to guide its implementation
- the structure of components, their inter-relationships, and the principles and
guidelines governing their design and evolution over time
• KLP 3.10-1 (1) Architecture Building Block (ABB)

- a constituent of the architecture model that describes a single aspect of the
overall model
• KLP 3.12-1 (1) Architecture Development Method (ADM)

- core of TOGAF
- a step-by-step approach to develop and use an enterprise architecture
• KLP 3.13-1 (1) Architecture Domain

- architectural area being considered
- there are four architecture domains within TOGAF: business, data, application,
and technology
• KLP 3.14-1 (1) Architecture Framework
- a foundational structure, or set of structures used for developing a broad range

of different architectures
- 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
- should contain a set of tools
- provide a common vocabulary
- include a list of recommended standards and compliant products that can be
used to implement the building blocks
• KLP 3.17-1 (1) Architecture Principles

- a qualitative statement of intent that should be met by the architecture
- has at least a supporting rationale and a measure of importance
• KLP 3.18 -1(1) Architecture View

- representation of a related set of concerns
- an architecture view may be represented by a model to demonstrate to
stakeholders their areas of interest in the architecture
• KLP 3.19-1 (1) Architecture Vision
- a high-level, aspirational view of the Target Architecture

- a phase in the ADM which delivers understanding and definition of the
Architecture Vision
- a specific deliverable describing the Architecture Vision
• KLP 3.20-1 (1N) Artifact

- an architectural work product that describes an architecture from a specific
viewpoint
• KLP 3.21-1 (1) Baseline

- a specification that has been formally reviewed and agreed upon, that thereafter
serves as the basis for further development or change
• KLP 3.22-1 (1) Baseline Architecture

- existing defined system architecture before entering a cycle of architecture
review and redesign
• KLP 3.24-1 (1) Building Block

- represents a (potentially re-usable) component of business, IT, or architectural
capability that can be combined with other building blocks to deliver
architectures and solutions
• KLP 3.25 -1 (1)Business Architecture
- the business strategy, governance, organization, and key business processes
information, as well as the interaction between these concepts
• KLP 3.28 -1 (1)Business Governance

- ensuring that the business processes and policies (and their operation) deliver
the business outcomes and adhere to relevant business regulation
• KLP 3.30 -1 (1N)Capability

- an ability that an organization, person, or system possesses
• KLP 3.34-1 (1) Concerns

- key interests that are crucially important to the stakeholders in a system, and
determine the acceptability of the system
• KLP 3.35-1 (1) Constraint

- an external factor that prevents an organization from pursuing particular
approaches to meet its goals
• KLP 3.36-1 (1) Data Architecture

- structure of an organization's logical and physical data assets and data
management resources
• KLP 3.37-1 (1) Deliverable

- an architectural work product that is contractually specified and in turn formally
reviewed, agreed, and signed off by the stakeholders
- deliverables represent the output of projects and those deliverables that are in
documentation form
• KLP 3.38-1 (1) Enterprise

- the highest level (typically) of description of an organization and typically covers
all missions and functions
- an enterprise will often span multiple organizations
- TOGAF defines "enterprise" as any collection of organizations that has a common
set of goals
• KLP 3.42-1 (1) Foundation Architecture

- an architecture of generic services and functions that provides a foundation on
which more specific architectures and architectural components can be built
- TOGAF Foundation Architecture includes a Technical Reference Model (TRM)
• KLP 3.44-1 (1) Gap

- difference between two states
• KLP 3.45-1 (1) Governance

- the discipline of monitoring, managing, and steering a business (or IS/IT
landscape) to deliver the business outcome required
• KLP 3.46-1 (1) Information

- any communication or representation of facts, data, or opinions, in any medium
or form, including textual, numerical, graphic, cartographic, narrative, or audio-
visual forms
• KLP 3.47-1 (1) Information Technology (IT)

- lifecycle management of information and related technology used by an
organization
• KLP 3.49-1 (-) Knowledge

- awareness and understanding of facts, truths, or information gained in the form
of experience or learning or through introspection
• KLP 3.50-1 (1) Logical

- an implementation-independent definition of the architecture, often grouping
related physical entities according to their purpose and structure
• KLP 3.51-1 (1) Metadata

- data about data, of any sort in any media, that describes the characteristics of an
entity
• KLP 3.52-1 (1N) Metamodel

- a model that describes how and with what the architecture will be described in a
structured way
• KLP 3.53-1 (1) Method

- a defined, repeatable approach to address a particular type of problem
• KLP 3.54-1 (1) Methodology

- defined, repeatable series of steps to address a particular type of problem
• KLP 3.55-1 (1) Model

- a representation of a subject of interest
• KLP 3.56-1 (1) 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
• KLP 3.57-1 (1) Objective
- a time-bounded milestone for an organization used to demonstrate progress
towards a goal
• KLP 3.58-1 (-) Organization

- a self-contained unit of resources with line management responsibility, goals,
objectives, and measures
• KLP 3.61-1 (1) Physical

- a description of a real-world entity
- physical elements in an enterprise architecture may still be considerably
abstracted from Solution Architecture, design, or implementation views
• KLP 3.66-1 (1) Reference Model (RM)

- a reference model is an abstract framework for understanding significant
relationships among the entities of [an] environment, and for the development of
consistent standards or specifications supporting that environment
• KLP 3.67-1 (1) Repository

- a system that manages all of the data of an enterprise, including data and
process models and other enterprise information
• KLP 3.68-1 (1) Requirement

- a quantitative statement of business need that must be met by a particular
architecture or work package
• KLP 3.72-1 (2N) Segment Architecture

- a detailed, formal description of areas within an enterprise, used at the program
or portfolio level to organize and align change activity
• KLP 3.77-1 (1) Solution Architecture

- a description of a discrete and focused business operation or activity and how
IS/IT supports that operation
• KLP 3.78-1 (1) Solution Building Block (SBB)

- a candidate physical solution for an Architecture Building Block (ABB)
• KLP 3.80-1 (1) Stakeholder

- an individual, team, or organization (or classes thereof) with interests in, or
concerns relative to, the outcome of the architecture
- different stakeholder will have different concerns
• KLP 3.82-1 (1N) Strategic Architecture

- a formal description of the enterprise, providing an organizing framework for
operational and change activity, and an executive-level, long-term view for
direction setting
• KLP 3.83-1 (1) Target Architecture

- description of a future state of the architecture being developed for an
organization
• KLP 3.86-1 (1) Technology Architecture

- the logical software and hardware capabilities that are required to support
deployment of business, data, and application services
• KLP 3.87-1 (1) Transition Architecture

- a formal description of the enterprise architecture showing periods of transition
and development for particular parts of the enterprise
• KLP 3.88-1 (1) View

- representation of a related set of concerns
• KLP 3.89-1 (1) Viewpoint

- is where you are looking from - the vantage point or perspective that determines
what you see
4 Release Notes
• KLP 4-1 (1N) The existence of the Release Notes section and its purpose
• KLP 4.1-1 (1N) What’s new in TOGAF 9?
- 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
• KLP 4.2-1 (1N) The Benefits of TOGAF 9 (vs TOGAF 8)
- 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
TOGAF 8.1.1 Resource Current Location
Architecture Board Moved to Part VII: Architecture Capability Framework
Architecture Compliance Moved to Part VII: Architecture Capability Framework
Architecture Contracts Moved to Part VII: Architecture Capability Framework
Architecture Governance Moved to Part VII: Architecture Capability Framework
Architecture Maturity Models Moved to Part VII: Architecture Capability Framework
Architecture Patterns Moved to Part III: ADM Guidelines and Techniques
Architecture Principles Moved to Part III: ADM Guidelines and Techniques
Architecture Skills Framework Moved to Part VII: Architecture Capability Framework
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
Business Scenarios Moved to Part III: ADM Guidelines and Techniques
Case Studies Removed. Case Studies will be available on The Open Group web site.
Glossary Moved to Part I: Introduction
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
TOGAF 9 Chapter Derivation from TOGAF 8.1.1
Part I: Introduction
1 Introduction Material revised; based on Chapter 1
2 Core Concepts New chapter
3 Definitions Material derived from Chapter 36, reworked into formal

definitions and abbreviations sections
4 Release Notes New chapter
Part II: Architecture Development Method
5 Introduction Material revised; based on Chapter 3
6 Preliminary Phase Material revised; based on Chapter 4
7 Phase A: Architecture Vision Material revised; based on Chapter 5
8 Phase B: Business Architecture Material revised; based on Chapter 6
9 Phase C: Information Systems Architectures Material revised; based on Chapter 7
10 Phase C: Data Architecture Material revised; based on Chapter 8
11 Phase C: Application Architecture Material revised; based on Chapter 9
12 Phase D: Technology Architecture Material revised; based on Chapter 10
13 Phase E: Opportunities & Solutions Material revised; based on Chapter 11
14 Phase F: Migration Planning Material revised; based on Chapter 12
15 Phase G: Implementation Governance Material revised; based on Chapter 13
16 Phase H: Architecture Change Management Material revised; based on Chapter 14
17 ADM Architecture Requirements Management No material change; maps to Chapter 15
Part III: ADM Guidelines and Techniques
18 Introduction New chapter
19 Applying Iteration to the ADM New chapter
20 Applying the ADM at Different Enterprise Levels New chapter
21 Security Architecture and the ADM New chapter; derived from Security White Paper (W055)
22 Using TOGAF to Define & Govern SOAs New chapter
23 Architecture Principles No material change; maps to Chapter 29
24 Stakeholder Management New chapter
25 Architecture Patterns No material change; maps to Chapter 28

26 Business Scenarios No material change; maps to Chapter 34
27 Gap Analysis New chapter; derived from Gap Analysis
28 Migration Planning Techniques New chapter
29 Interoperability Requirements New chapter
30 Business Transformation Readiness Assessment New chapter
31 Risk Management New chapter
32 Capability-Based Planning New chapter
Part IV: Architecture Content Framework
34 Content Metamodel New chapter
35 Architectural Artifacts Derived from Chapter 31, plus new material
36 Architecture Deliverables Revised; was Chapter 16
37 Building Blocks Revised from Chapter 32
Part V: Enterprise Continuum & Tools
39 Enterprise Continuum Derived from Chapters 17 and 18 with substantial

revisions
40 Architecture Partitioning New chapter
41 Architecture Repository New chapter
42 Tools for Architecture Development No material change; maps to Chapter 38
Part VI: TOGAF Reference Models
43 Foundation Architecture: Technical Reference Model No material change; maps to Chapters 19 and 20
44 Integrated Information Infrastructure Reference Model No material change; maps to Chapter 22
Part VII: Architecture Capability Framework
46 Establishing an Architecture Capability New chapter
47 Architecture Board Minimal change; maps to Chapter 23
48 Architecture Compliance Minimal change; maps to Chapter 24
49 Architecture Contracts Minimal change; maps to Chapter 25
50 Architecture Governance Minimal change, maps to Chapter 26
51 Architecture Maturity Models Minimal change; maps to Chapter 27
52 Architecture Skills Framework Some cosmetic changes; maps to Chapter 30
A Glossary of Supplementary Definitions Derived from Chapter 36

B Abbreviations Derived from Chapter 36
• KLP 4.5-1 (1) The conditions of use for TOGAF
- TOGAF documentation is freely available for viewing online without a license

- Complete TOGAF documentation set may be downloaded and stored under license,
as explained on the TOGAF information web site

Module 2: ADM, Guidelines and Techniques
ADM Overview
5.1 ADM Overview

• KLP 5.1-1 (1) The relationship between the ADM and other parts of TOGAF (Enterprise
Continuum, Architecture Repository, Foundation Architecture, Supporting Guidelines
and Techniques)
- Enterprise Continuum is a view of the Architecture Repository. At different ADM

touch points, architects will use relevant assets in the Architecture Repository such
as the Foundation Architecture. Supporting guidelines and techniques are resources
that an architect will use to support the application of ADM.
• 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
5.2 Architecture Development Cycle

• KLP 5.2.1-1 (1) The Architecture Development Cycle, the key points
- 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
• KLP 5.2.2-2 (1)

( The phases are divide
ed into steps
• KLP 5.2.2-3 (1)

( The versioning of outtput is mana
aged by vers
sion numberrs
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
5.4 Architecture Gov

vernance
• KLP 5.4-1 (1)) The need to

o govern the
e ADM proce
ess
• KLP 5.4-2 (1)) The major information areas mana

aged by a governance repository
- Reference Data, Process Status, Audit Information
5.5 Scoping the Architecture
• KLP 5.5-1 (1) The reasons for constraining the scope of the architectural activity.
- Due to limits in the following:
organizational authority of the team producing the architecture

objectives and stakeholder concerns to be addressed within the
architecture
availability of people, finance, and other resources
• KLP 5.5-2 (1) The dimensions to define and limit scope of an architecture
- Four dimensions:
Enterprise Scope or Focus

Architecture Domains
Vertical Scope or Level of Detail
Time Period
5.6 Architecture Integration

• KLP 5.6-1 (1) The need for an integration framework that sits above individual
architectures
- Integration framework allows for interoperability, migration, and
conformance between federated architectures
Architecture Development Methods
Preliminary Phase
• Objectives
- To review the organizational context for conducting enterprise

architecture
- To identify the sponsor stakeholder(s) and other major stakeholders
impacted by the business directive
- determine their requirements and priorities from the enterprise
- their relationships with the enterprise
- required working behaviours with each other
- To ensure commitment to the success of the architectural process
- To enable the architecture sponsor to create requirements for work
- To identify and scope the elements of the enterprise organizations
- To define the "architecture footprint" for the organization - the people
responsible for performing architecture work, where they are located, and
their responsibilities
- To define the framework and detailed methodologies
- To confirm a governance and support framework
- To select and implement supporting tools and other infrastructure to
support the architecture activity
- To define the architecture principles
• Approach
Preliminary phase is about defining "where, what, why, who, and how we do
architecture"
- Defining the enterprise

- Identifying key drivers and elements in the organizational context
- Defining the requirements for architecture work
- Defining the architecture principles that will inform any architecture work
- Defining the framework to be used
- Defining the relationships between management frameworks
- Evaluating the enterprise architecture maturity
• Inputs
- Reference Materials External to the Enterprise
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
- Architectural Inputs: Pre-existing models (if any) for operating an

enterprise architecture capability can be used as a baseline for the
Preliminary phase. Inputs would include:
Organizational Model for Enterprise Architecture including:
• Scope of organizations impacted
• Maturity assessment, gaps, and resolution approach
• Roles and responsibilities for architecture team(s)
• Budget requirements
• Governance and support strategy
Existing Architecture Framework including:
• Architecture method
• Architecture content (deliverables and artifacts)
• Configured and deployed tools
Existing Architecture Principles
Existing Architecture Repository
• Steps
1. Scope the enterprise organization impacted

2. Confirm Governance and support framework
3. Define and Establish Enterprise Architecture Team and Organization
4. Indentify and Establish Architecture Principles
5. Select and Tailor Architecture Framework
6. Implement Architecture Tools
• Outputs
- Organizational Model for Enterprise Architecture

- Tailored Architecture Framework including Architecture Principles
- Initial Architecture Repository
- Restatement of, or reference to, Business Principles, Business Goals, and
Business Drivers
- Request for Architecture Work
- Governance Framework
Phase A – Architecture Vision
• Objectives
- To ensure recognition and endorsement from the corporate management

and the commitment of the necessary LOB for this phase
- To define and organize an architecture development cycle within the
overall context of the architecture framework
- To validate the business principles, business goals, and strategic
business drivers of the organization and the enterprise architecture KPIs
- To define the scope of, and to identify and prioritize the components of
the Baseline Architecture effort
- To define the relevant stakeholders, and their concerns and objectives
- To define the key business requirements to be addressed in this
architecture effort, and constraints
- To articulate an Architecture Vision and formalize the value proposition
that demonstrates a response to those requirements and constraints
- To create a comprehensive plan that addresses scheduling, resourcing,
financing, communication, risks, constraints, assumptions, and
dependencies, in line with the project management frameworks adopted
by the enterprise
- To secure formal approval to proceed
- To understand the impact on, and of, other enterprise architecture
development cycles ongoing in parallel
• 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

Architecture Reference Model
Request for Architecture Work
Business principles, goals and drivers
- Architectural Inputs
Organizational Model for Enterprise Architecture including:
• Constraints on architecture work
• Re-use requirements
• Requests for change
• Tailored Architecture Framework, including:
• Tailored architecture method
• Tailored architecture content (deliverables and
artifacts)
• Architecture Principles
• Populated Architecture Repository
• Steps
1. Establish the Architecture Project

2. Identify Stakeholders, Concerns, and Business Requirements
3. Confirm and Elaborate Business Goals, Business Drivers, and Constraints
4. Evaluate Business Capabilities
5. Assess Readiness for Business Transformation
6. Define Scope
7. Confirm and Elaborate Architecture Principles, including Business Principles
8. Develop Architecture Vision
9. Define the Target Architecture Value Propositions and KPIs
10. Identify the Business Transformation Risks and Mitigation Activities
11. Develop Enterprise Architecture Plans and Statement of Architecture Work;
Secure Approval
• Outputs
- Approved Statement of Architecture Work

- Refined statements of Business Principles, Business Goals, and Business
Drivers
- Architecture Principles
- Capability Assessment
- Tailored Architecture Framework (for the engagement)
- Architecture Vision, including:
Refined key high-level stakeholder requirements

Baseline Business Architecture, Version 0.1
Baseline Technology Architecture, Version 0.1
Baseline Data Architecture, Version 0.1
Baseline Application Architecture, Version 0.1
Target Business Architecture, Version 0.1
Target Technology Architecture, Version 0.1
Target Data Architecture, Version 0.1
Target Application Architecture, Version 0.1
- Communications Plan
- Additional content populating the Architecture Repository
Phase B – Business Architecture
• Objectives
- To describe the Baseline Business Architecture

- To develop a Target Business Architecture, describing the product and/or
service strategy, and the organizational, functional, process, information,
and geographic aspects of the business environment, based on the
business principles, business goals, and strategic drivers
- To analyze the gaps between the Baseline and Target Business
Architectures
- To select and develop the relevant architecture viewpoints that will enable
the architect to demonstrate how the stakeholder concerns are addressed
in the Business Architecture
- To select the relevant tools and techniques to be used in association with
the selected viewpoints
• Approach
- Determine if key elements of the Business Architecture have been done in

other activities, if so, validate and update and or/bridge business
strategy, goals and drivers
- Decide what relevant assets are available from the Architecture
Repository
- Develop As-Is and Target Business Architecture
• Inputs

Architecture reference materials
Business principles, goals and drivers
Capability Assessment
Communications Plan
Organizational Model for Enterprise Architecture, including:
Tailored Architecture Framework, including:
• Tailored architecture content
Approved Statement of Architecture Work
Architecture Principles including business principles
Enterprise Continuum
Architecture Repository, including:
• Re-usable building blocks
• Publicly available reference models
• Organization-specific reference models
• Organization standards
Architecture Vision, including:
• Refined key high-level stakeholder requirements
• Baseline Business Architecture, Version 0.1
• Baseline Technology Architecture, Version 0.1
• Baseline Data Architecture, Version 0.1
• Baseline Application Architecture, Version 0.1
• Target Business Architecture, Version 0.1
• Target Technology Architecture, Version 0.1
• Target Data Architecture, Version 0.1
• Target Application Architecture, Version 0.1
• Steps
1. Select Reference Models, Viewpoints, and Tools

2. Develop Baseline Business Architecture Description
3. Develop Target Business Architecture Description
4. Perform Gap Analysis
5. Define Roadmap Components
6. Resolve Impacts Across the Architecture Landscape
7. Conduct Formal Stakeholder Review
8. Finalize the Business Architecture
9. Create Architecture Definition Document
• Outputs
- Updated versions of the Architecture Vision phase deliverables, where

applicable, including:
Statement of Architecture Work
Validated Business Principles, Goals, and Drivers
Architecture Principles
- Draft Architecture Definition Document, including:
Baseline Business Architecture, Version 1.0
Target Business Architecture including:
• Organization structure - identifying business locations and
relating them to organizational units
• Business goals and objectives - for the enterprise and each
organizational unit
• Business functions
• Business services
• Business processes, including measures and deliverables
• Business roles, including development and modification of
skills requirements
• Business data model
• Correlation of organization and functions
Views corresponding to the selected viewpoints addressing key
stakeholder concerns
- Draft Architecture Requirements Specification, including such Business
Architecture requirements as:
Gap analysis results
Technical requirements - identifying, categorizing, and
prioritizing the implications for work in the remaining architecture
domains
Updated business requirements
- Business Architecture components of an Architecture Roadmap
Phase C – Information Systems Architectures: Data
• Objectives
- Define major types and sources of data necessary to support the business
• Approach
- Take into account data management, data migration and data governance
Repository in particular industry specific data models
- Develop the As-Is and Target Data Architecture
• Inputs
- Reference Materials external to the Enterprise

Communications Plan
- Architectural inputs
Data Principles, if existing
Architecture Vision
Draft Architecture Definition Document, including:
• Baseline Business Architecture, Version 1.0 (detailed), if
appropriate
• Target Business Architecture, Version 1.0 (detailed)
• Baseline Data Architecture, Version 0.1, if available
• Target Data Architecture, Version 0.1, if available
• Baseline Application Architecture, Version 1.0 (detailed) or
Version 0.1 (Vision)
• Target Application Architecture, Version 1.0 (detailed) or
• Baseline Technology Architecture, Version 0.1 (Vision)
• Target Technology Architecture, Version 0.1 (Vision)
Draft Architecture Requirements Specification, including:
• Gap analysis results (from Business Architecture)
• Relevant technical requirements that will apply to this
phase
Business Architecture components of an Architecture Roadmap
• Steps

2. Develop Baseline Data Architecture Description
3. Develop Target Data Architecture Description
8. Finalize the Data Architecture
• Outputs
- updated versions of the Architecture Vision phase deliverables

Statement of Architecture Work, updated if necessary
Validated Data Principles, or new data principles (if generated
here)
Baseline Data Architecture, Version 1.0
Target Data Architecture, Version 1.0
• Business data model
• Logical data model
• Data management process models
• Data Entity/Business Function matrix
- Draft Architecture Requirements Specification, including such Data
Data interoperability requirements
Relevant technical requirements that will apply to this evolution of
the architecture development cycle
Constraints on the Technology Architecture about to be designed
Updated business requirements, if appropriate
Updated application requirements, if appropriate
- Data Architecture components of an Architecture Roadmap
Phase C – Information Systems Architectures: Application
• Objectives
- define the major kinds of application system necessary to process the

data and support the business
• Approach

Repository in particular generic business models and or generic
application models
- Identify major business processes
- Identify capability services such as business rule engine, collaboration
and messaging services
- Develop the As-Is and Target Application Architecture
• Inputs

Communications Plan
Application Principles, if existing
Architecture Vision
• Baseline Business Architecture, Version 1.0 (detailed), if
appropriate
• Target Business Architecture, Version 1.0 (detailed)
• Baseline Data Architecture, Version 1.0 (detailed), or
• Target Data Architecture, Version 1.0 (detailed), or Version
0.1 (Vision)
• Baseline Application Architecture, Version 0.1, if
appropriate and if available
• Target Application Architecture, Version 0.1, if available
• Baseline Technology Architecture, Version 0.1 (Vision)
• Target Technology Architecture, Version 0.1 (Vision)
• Gap analysis results (from Business Architecture and Data
Architecture, if available)
• Relevant technical requirements that will apply to this
phase
Business and Data Architecture components of an Architecture
Roadmap, if available
• Steps

2. Develop Baseline Application Architecture Description
3. Develop Target Application Architecture Description
8. Finalize the Application Architecture
• Outputs
- Refined and updated versions of the Architecture Vision phase

deliverables, where applicable:
Validated application principles, or new application principles (if
generated here)
Baseline Application Architecture, Version 1.0, if appropriate
Target Application Architecture, Version 1.0
• Process systems model
• Place systems model
• Time systems model
• People systems model
Views corresponding to the selected viewpoints, addressing key
- Draft Architecture Requirements Specification, including such Application
Applications interoperability requirements
Relevant technical requirements that will apply to this evolution of
the architecture development cycle
Constraints on the Technology Architecture about to be designed
Updated business requirements, if appropriate
Updated data requirements, if appropriate
- Application Architecture components of an Architecture Roadmap
Phase D – Technology Architecture
• Objectives
- map application components defined in the Application Architecture

phase into a set of technology components
• Approach
- Identify major application components required

Repository in particular exiting IT services, TOGAF TRM, generic industry
specific technology models and technology models relevant to common
systems architecture
- Define Cost Model and Timeline Model
- Develop the As-Is and Target Technology Architecture
• Inputs

Communications Plan
Technology Principles, if existing
Architecture Vision
• 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 (vision)
• Target Technology Architecture, Version 0.1 (vision)
• Gap analysis results (from Business, Data, and Application
Architectures)
• Relevant technical requirements from previous phases
Business, Data, and Application Architecture components of
an Architecture Roadmap
• Steps

2. Develop Baseline Technology Architecture Description
3. Develop Target Technology Architecture Description
8. Finalize the Technology Architecture
• Outputs
- Refined and updated versions of the Architecture Vision phase

deliverables, where applicable:
Validated technology principles, or new technology principles (if
generated here)
Target Technology Architecture, Version 1.0 (detailed), including:
• Technology Components and their relationships to
information systems
• Technology platforms and their decomposition, showing
the combinations of technology required to realize a
particular technology "stack"
• Environments and locations - a grouping of the required
technology into computing environments (e.g.,
development, production)
• Expected processing load and distribution of load across
technology components
• Physical (network) communications
• Hardware and network specifications
Baseline Technology Architecture, Version 1.0 (detailed), if
appropriate
- Draft Architecture Requirements Specification, including such Technology
Requirements output from Phases B and C
Updated technology requirements
- Technology Architecture components of an Architecture Roadmap
Phase E – Opportunities and Solutions
• Objectives
- To review the target business objectives and capabilities, consolidate the

gaps from Phases B to D, and then organize groups of building blocks to
address these capabilities
- To review and confirm the enterprise's current parameters for and ability
to absorb change
- To derive a series of Transition Architectures that deliver continuous
business value
- To generate and gain consensus on an outline Implementation and
Migration Strategy
• Approach
- This phase focuses on how to deliver the proposed architecture by
balancing both enterprise needs and tactical business needs
- 3 Approaches
Top down with enterprise perspective
Tactical with needs in focus
Balanced using top down with limited and scalable scope
- Level of detail is dependent on the maturity of the portfolio management
practice
• Inputs
Product Information
Communications Plan
Planning Methodology
Governance models and frameworks:
• Enterprise Architecture Management Framework
• Capability Management Framework
• Portfolio Management Framework
• Project Management Framework
• Operations Management Framework
Architecture Vision
• Baseline Technology Architecture, Version 0.1 (detailed)
• Target Technology Architecture, Version 0.1 (detailed)
• 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
1. Determine/Confirm Key Corporate Change Attributes

2. Determine Business Constraints for Implementation
3. Review and Consolidate Gap Analysis Results from Phases B to D
4. Review IT Requirements from a Functional Perspective
5. Consolidate and Reconcile Interoperability Requirements
6. Refine and Validate Dependencies
7. Confirm Readiness and Risk for Business Transformation
8. Formulate High-Level Implementation and Migration Strategy
9. Identify and Group Major Work Packages
10. Identify Transition Architectures
11. Create Portfolio and Project Charters and Update the Architectures
• Outputs
- Refined and updated versions of the Architecture Vision, Business

Architecture, Information Systems Architecture, and Technology
Architecture phase deliverables, where applicable:
Architecture Vision, including definition of types and degrees of
interoperability
• Identification of increments
• Interoperability and co-existence requirements
• Inclusion of project list and project charters
Draft Architecture Requirements Specification
- 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
Phase F – Migration Planning
• Objectives
- To ensure that the Implementation and Migration Plan is co-ordinated

with the various management frameworks in use within the enterprise
- To prioritize all work packages, projects, and building blocks by
assigning business value to each and conducting a cost/business analysis
- To finalize the Architecture Vision and Architecture Definition
Documents, in line with the agreed implementation approach
- To confirm the Transition Architectures defined in Phase E with relevant
stakeholders
- To create, evolve, and monitor the detailed Implementation and Migration
Plan providing necessary resources to enable the realization of the
Transition Architectures, as defined in Phase E
• 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
Communications Plan
Architecture Vision
• Strategic Migration Plan
• Baseline Technology Architecture, Version 0.1 (detailed)
• Target Technology Architecture, Version 0.1 (detailed)
• Impact Analysis – Project List and Charters
• 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
1. Confirm Management Framework Interactions for Implementation and

Migration Plan
2. Assign a Business Value to Each Project
3. Estimate Resource Requirements, Project Timings and Availability/Delivery
Vehicles
4. Prioritize the Migration Projects through the Conduct of a Cost/Benefit
Assessment and Risk Validation
5. Confirm Transition Architecture Increments/Phases and Update Architecture
Definition Document
6. Generate the Architecture Implementation Roadmap (Time-Lined) and
Migration Plan
7. Establish the Architecture Evolution Cycle and Document Lessons Learned
• Outputs
- Implementation and Migration Plan, Version 1.0

- Finalized Architecture Definition Document
- Finalized Architecture Requirements Specification
- Finalized Architecture Roadmap
- Finalized Transition Architecture
- Re-Usable Architecture Building Blocks
- Requests for Architecture Work for the architecture aspects of
implementation projects (if any)
- Architecture Contracts (standard) for implementation projects
- Implementation Governance Model
- Change Requests arising from lessons learned
Phase G – Implementation Governance
• Objectives
- To formulate recommendations for each implementation project

- To govern and manage an Architecture Contract covering the overall
implementation and deployment process
- To perform appropriate governance functions while the solution is being
implemented and deployed
- To ensure conformance with the defined architecture by implementation
projects and other projects
- To ensure that the program of solutions is deployed successfully, as a
planned program of work
- To ensure conformance of the deployed solution with the Target
Architecture
- To mobilize supporting operations that will underpin the future working
lifetime of the deployed solution
• 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

Communications Plan
Architecture Vision
Architecture Definition Document
Architecture Requirements Specification, including:
Architecture Roadmap
Transition Architecture including:
Implementation Governance Model
Architecture Contract (standard)
Request for Architecture Work identified during Phases E and F
Implementation and Migration Plan
• Steps
1. Confirm Scope and Priorities for Deployment with Development Management

2. Identify Deployment Resources and Skills
3. Guide Development of Solutions Deployment
4. Perform Enterprise Architecture Compliance Reviews
5. Implement Business and IT Operations
6. Perform Post-Implementation Review and Close the Implementation
• Outputs
- Architecture Contract (signed), as recommended in the architecture-

compliant implemented architectures
- Compliance Assessments
- Change Requests
- Architecture-compliant solutions deployed including:
The architecture-compliant implemented system
Populated Architecture Repository
Architecture compliance recommendations and dispensations
Recommendations on service delivery requirements
Recommendations on performance metrics
Service Level Agreements (SLAs)
Architecture Vision, updated post-implementation
Architecture Definition Document, updated post-implementation
Transition Architecture, updated post-implementation
Business and IT operating models for the implemented solution
Phase H – Architecture Change Management
• Objectives
- To ensure that baseline architectures continue to be fit-for-purpose

- To assess the performance of the architecture and make
recommendations for change
- To assess changes to the framework and principles set up in previous
phases
- To establish an architecture change management process for the new
enterprise architecture baseline that is achieved with completion of Phase
G
- To maximize the business value from the architecture and ongoing
operations
- To operate the Governance Framework
• Approach
- The goal of an architecture change management process is to ensure that

the architecture achieves its original target business value.
- Depending on the nature of the change, consider the following
approaches:
Simplification Change
• Can normally be handled via change management
techniques
Incremental Change
• Either change management techniques or it may require
partial re-architecting
Re-architecting Change
• Requires putting the whole architecture through the
Architecture Development Cycle
• Inputs

Request for Architecture Work identified during Phase E & F
Architecture Vision
Architecture Definition Document
Architecture Requirements Specification, including:
Architecture Roadmap
Change Request – technology changes:
• New technology reports
• Asset management cost reduction initiatives
• Technology withdrawal reports
• Standards initiatives
Change Request, - business changes:
• Business developments
• Business exceptions
• Business innovations
• Business technology innovations
• Strategic change developments
Change Request, - from lessons learned
Transition Architecture
Implementation Governance Model
Architecture Contract (signed)
Compliance Assessments
Implementation and Migration Plan
• Steps
1. Establish Value Realization Process

2. Deploy Monitoring Tools
3. Manage Risks
4. Provide Analysis for Architecture Change Management
5. Develop Change Requirements to Meet Performance Targets
6. Manage Governance Process
7. Activate the Process to Implement Change
• Outputs
- Architecture updates (for maintenance changes)

- Changes to architecture framework and principles (for maintenance
changes)
- New Request for Architecture Work, to move to another cycle (for major
changes)
- Statement of Architecture Work, updated if necessary
- Architecture Contract, updated if necessary
- Compliance Assessments, updated if necessary
ADM Architecture Requirement Management
• Objectives
- To define a process whereby requirements for enterprise architecture are

identified, stored and fed into and out of the relevant ADM phases
• Approach
- Process does not prioritize, dispose or address any requirements

- There are many approaches such as using Business scenarios, Volere
Requirements template or Requirement tools
- Create a Requirement Impact Statement
• Inputs
- A populated Architecture Repository

- 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
- Tailored Architecture Framework, including:
Tailored architecture method
Tailored architecture content (deliverables and artifacts)
Configured and deployed tools
- Statement of Architecture Work
- Architecture Vision
- Architecture requirements, populating an Architecture Requirements
Specification
- Requirements Impact Assessment
• Steps
Requirements Management Steps ADM Phase Steps
Step 1 Identify/document requirements - use business

scenarios, or an analogous technique
Step 2 Baseline requirements:
a. Determine priorities arising from current

phase of ADM
b. Confirm stakeholder buy-in to resultant
priorities
c. Record requirements priorities and place in
requirements repository
Step 3 Monitor baseline requirements
Step 4 Identify changed requirements:
a. Remove or re-assess priorities

b. Add requirements and re-assess
priorities
c. Modify existing requirements
Step 5 Identify changed requirements and record priorities:
a. Identify changed requirements and ensure

the requirements are prioritized by the
architect(s) responsible for the current
phase, and by the relevant stakeholders
b. Record new priorities
c. Ensure that any conflicts are identified and
managed through the phases to a
successful conclusion and prioritization
d. Requirements Impact Assessment for
steering the architecture team
Notes
• Changed requirements can come in

through any route. To ensure that the
requirements are properly assessed and
prioritized, this process needs to direct the
ADM phases and record the decisions
related to the requirements.
• The Requirements Management phase
needs to determine stakeholder
satisfaction with the decisions. Where there
is dissatisfaction, the phase remains
accountable to ensure the resolution of the
issues and determine next steps.
Step 6 a. Assess impact of changed

requirements on current (active) phase
b. Assess impact of changed
requirements on previous phases
c. Determine whether to implement
change, or defer to later ADM cycle; if
decision is to implement, assess
timescale for change management
implementation
d. Issue Requirements Impact Statement,
Version n+1
Step 7 Implement requirements arising from Phase H
The architecture can be changed through its

lifecycle by the Architecture Change
Management phase (Phase H). The requirements
management process ensures that new or
changing requirements that are derived from
Phase H are managed accordingly.
Step 8 Update the requirements repository with

information relating to the changes requested,
including stakeholder views affected
Step 9 Implement change in the current phase
Step 10 Assess and revise gap analysis for past phases
The gap analysis in the ADM Phases B through D

identifies the gaps between Baseline and Target
Architectures. Certain types of gap can give rise
to gap requirements.
The ADM describes two kinds of gap:
• Something that is present in the

baseline, but not in the target (i.e.,
eliminated - by accident or design)
• Something not in the baseline, but
present in the target (i.e., new)
A "gap requirement" is anything that has been

eliminated by accident, and therefore requires a
change to the Target Architecture.
If the gap analysis generates gap requirements,

then this step will ensure that they are
addressed, documented, and recorded in the
requirements repository, and that the Target
Architecture is revised accordingly.
• Outputs
- Requirement Impact Assessment

- Architecture Requirement Specifications, if necessary
Guideliines:
18 Introd
duction
• 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
• KLP 19-1 (2N

N) Understand the factors influencing
g the use of iteration
- 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
• KLP 19-2 (2N

N) How to apply iteration
n cycles to th
he ADM
- 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
• KLP 20-1 (2N ent types of architecture

N) Understand the differe e engagemen
nt
- 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
- Iterations within a Single ADM Cycle
a single architecture team is tasked with defining architectures at many

levels within the enterprise
this approach should be used when a number of architectures are being
developed within a similar time period by a single team
- Hierarchy of ADM processes
larger-scale architectures need to be developed by a number of different
architecture teams
this approach should be used when architectures are being developed
over different timelines by different teams
21. Security Architecture and the ADM
• KLP 21-1 (2N) Characteristics of Security Architecture for the Enterprise Architect
- has its own methods

- composes its own discrete view and viewpoints
- addresses non-normative flows through systems and among applications
- introduces its own normative flows through systems and among applications
- introduces unique, single-purpose components in the design
- calls for its own unique set of skill requirements in the IT architect
• KLP 21-2 (2N) Define the Security Architecture influences on ADM Architecture
Requirements Management
- Security policy and security standards will influence the Architecture

Requirements management phase
- Security policy becomes requirement for all architecture projects
- Changes to the security standards supporting security policies will drive changes
to the security building blocks in the Enterprise Continuum
• KLP 21-3 (2N) Define the Security Architecture influences on the Preliminary Phase
- Define and document applicable regulatory and security policy requirements

- Identify a security architect or security architecture team
- Identify first-order security assumptions and boundary conditions
Identify Enterprise scope for security
Is there a need to establish interfaces and protocols for exchange related
to identity, authentication and authorization?
• KLP 21-4 (2N) Define the Security Architecture influences on Phase A
- Obtain management support for security measures

- Define necessary security-related management sign-off milestones
- Determine and document applicable disaster recovery or business continuity
plans/requirements
- Identify and document the anticipated physical/business/regulatory
environment(s) in which the system(s) will be deployed
Different physical environment will have different security concerns
Business environment will required different interfaces and protocols
- Determine and document the criticality of the system: safety-critical/mission-
critical/non-critical
• KLP 21-5 (2N) Define the Security Architecture influences on Phase B
- 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 and baseline current security-specific architecture elements

(enhancement of existing objective)
- Identify safe default actions and failure states
- Identify and evaluate applicable recognized guidelines and standards
- Revisit assumptions regarding interconnecting systems beyond project control
- Determine and document the sensitivity or classification level of information
stored/created/used
- Identify and document custody of assets
- Identify the criticality of the availability and correct operation of each function
- Determine the relationship of the system under design with existing business
disaster/continuity plans
- Identify what aspects of the system must be configurable to reflect changes in
policy/business environment/access control
- Identify lifespan of information used as defined by business needs and
regulatory requirements
- Determine approaches to address identified risks
- Identify actions/events that warrant logging for later review or triggering
forensic processes
- Identify and document requirements for rigor in proving accuracy of logged
events (non-repudiation)
- Identify potential/likely avenues of attack
• KLP 21-7 (2N) Define the Security Architecture influences on Phase D
- Assess and baseline current security-specific technologies (enhancement of

existing objective)
- Revisit assumptions regarding interconnecting systems beyond project control
- Identify and evaluate applicable recognized guidelines and standards
- Identify methods to regulate consumption of resources
Bandwidth, battery, disk space, etc
- Engineer a method by which the efficacy of security measures will be measured
and communicated on an ongoing basis
- Identify the trust (clearance) level of:
All users of the system
All administrators of the system
All interconnecting systems beyond project control
- Identify minimal privileges required for any entity to achieve a technical or
business objective
- Identify mitigating security measures, where justified by risk assessment
• KLP 21-8 (2N) Define the Security Architecture influences on Phase E
- Identify existing security services available for re-use

- Engineer mitigation measures addressing identified risks
- Evaluate tested and re-usable security software and security system resources
- Identify new code/resources/assets that are appropriate for re-use
• KLP 21-9 (2N) Define the Security Architecture influences on Phase F
- 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
• KLP 21-10 (2N) Define the Security Architecture influences on Phase G
- 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?"
• KLP 21-11 (2N) Define the Security Architecture influences on Phase H
- Determine "what has gone wrong?"

- Incorporate security-relevant changes to the environment into the requirements
for future enhancement (enhancement of existing objective)
Changes that arise as a result of a security problem or new security
technology will feed into the Requirements Management process
22. Using TOGAF to Define and Govern SOAs
• KLP 22-1 (2N) Characteristics of SOA
- autonomous
- loosely coupled: minimized dependencies
- re-usable
- contractual: adhere to agreement on service description
- composable: facilitate the assembly of composite services
• KLP 22-2 (2N) Identify the complexities arising from SOA
- Due to increased number of services, there is increased complexity around the

usage of and interaction between services. New stress points are created around
the following:
understanding the relationships between technology portfolio and service
portfolio
SLA definition, governance, and impact management
tracing business to IT
communication, alignment and semantics
platform and interoperability
performance visibility and optimization
• KLP 22-3 (2N) Explain how Enterprise Architecture Supports SOA
- 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
- Tools and Techniques such as:
Enterprise architecture defines structured traceable representations of

business and technology that link IT assets to business. These models in
turn support impact assessment and portfolio management.
Enterprise architecture defines principles, constraints, frameworks,
patterns, and standards that form the basis of design governance,
ensuring aligned services, interoperability, and re-use.
Enterprise architecture links many different perspectives to a single
business problem (e.g., business, data, application, technology,
abstracted, concrete, etc.) providing a consistent model to address
various problem domains and extensive test for completeness.
Enterprise architecture provides consistent abstractions of high-level
strategies and project deliverables, enabling both bottom-up and top-
down outputs to be collated in a shared repository to support planning
and analysis.
• KLP 22-4 (-) Using the TOGAF meta-model to capture SOA concepts
- A number of concepts are captured in the TOGAF content metamodel that

support the modeling of SOA concepts:
Function: A function is a thing that a business does. Services support

functions, are functions, and have functions, but functions are not
necessarily services. Services have more specific constraints than
functions.
Business Service: A business service is a thing that a business does that
has a defined, measured interface and has contracts with consumers of
the service. A business service is supported by combinations of people,
process, and technology.
Information System Service: An information system service is a thing that
a business does that has a defined, measured interface and has contracts
with consumers of the service. Information system services are directly
supported by applications and have associations to SOA service
interfaces.
Application Component: An application component is a configured and
deployed system, or independently governed piece of a configured and
deployed system. Application components provide information system
services. Application components can be physical applications and also
logical applications that group together applications of a similar type.
Technology Component: A technology component is a piece of software
or hardware that can be purchased from an internal or external supplier.
Technology components are configured, combined, built on, and
deployed in order to produce application components.
• KLP 22-5 (-) How to implement service contracts for SOA
- SOA artifacts are governed by specific business, technical, and regulatory

policies. Polices play a major role in implementing service contracts for SOA.
Service contracts must contain all pertinent policy information.
- Policies must be used to validate services before they are published whereas for
non-SOA applications, policy is typically embedded in the application code.
Techniques
23. Architecture Principles

• KLP 23.1-1 (1) Understanding the need for Architecture Principles and where they are
used within the ADM
- Architecture Principles are rules and guidelines defined to guide architecture

work
- Within ADM
Defined in Preliminary Phase
Confirmed in Phase A
Input in Phase B
• KLP 23.2-1 (2) Characteristics of Architecture Principles
- 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
• KLP 23.3-1 (1) A standard template
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.
• KLP 23.4-1 (2) Developing Architecture Principles
- Frequently, Architecture Principles are developed by the Lead Architect with input
from various stakeholders.
- Development of principles is typically influenced by:
Enterprise mission and plans

Enterprise strategic initiatives
External constraints
Current systems and technology
Computer industry trends
• KLP 23.4-2 (1) Criteria for quality Principles
- 5 criteria:
Understandable
Robust
Complete
Consistent
Stable
• KLP 23.5-1 (2) Applying Architecture Principles
- Architecture Principles are used in a number of ways:
Framework for consistent decision maker regardless of the decision

maker
Guideline for Evaluation Criteria
Drivers for Functional Requirements
Guideline for Future IT Investment Decision
Rationale Statements
Implication Statements
Support Architecture Governance activities
• KLP 23.6-1 (2) Example sets of Principles
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
- Used to help win support from others

- The most powerful stakeholders can be identified early and their input can then
be used to shape the architecture
- Support from the more powerful stakeholders will help the engagement win
more resource
- By communicating with stakeholders early and frequently, the architecture team
can ensure that they fully understand the architecture process, and the benefits
of enterprise architecture
- The architecture engagement team can more effectively anticipate likely
reactions to the architecture models and reports, and can build into the plan the
actions that will be needed to capitalize on positive reaction whilst avoiding or
addressing any negative reactions
• KLP 24-2 (2N) Developing a stakeholder approach
- Stakeholder analysis should be used during Phase A (Architecture Vision) to

identify the key players in the engagement
- updated throughout each phase
- different stakeholders may be uncovered as the engagement progresses through
into Opportunities & Solutions, Migration Planning, and Architecture Change
Management
• KLP 24-3 (2N) Defining the steps in Stakeholder management
1. Identify Stakeholders
2. Classify Stakeholder Positions
3. Determine Stakeholder Management Approach
4. Tailor Engagement Deliverables
• KLP 24-4 (2N) Example Stakeholder Map

Relevant
Stakeholder Involvement Class Viewpoints
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
25. Architecture Patterns

• KLP 25.1-1 (1) Characteristics of Architecture Patterns
- Architecture Pattern is in its infancy, not yet integrated in TOGAF

- Think of patterns as a way of putting building blocks in context
- No accepted standard format
- Elements in a pattern:
Name
Problem
Context
Forces
Solution
Resulting Context
Examples
Rationale
Related Patterns
Known Uses
• KLP 25.1-2 (1) How to use Architecture Patterns
- Architecture Patterns can be used in:

Patterns in the Architecture Continuum
Patterns in Architecture View representing a complete System
Architecture
Relevant Architectures in Business Scenarios
• KLP 25.2-1 (-) Example Architecture Patterns
- US Treasury Architecture Development Guide (TADG), IBM Pattern for e-Business

26. Business Scenarios
• KLP26.1-1 (1) What a business scenario is and its purpose
- It is a technique used to help identify and understand business needs – business

architecture requirements
- A business scenario describes:
A business process, application, or set of applications that can be
enabled by the architecture
The business and technology environment
The people and computing components (called "actors") who execute the
scenario
The desired outcome of proper execution
• 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
• KLP 26.3-1 (2) The contents of a business scenario

- 2 main types of contents: graphics (models) and descriptive text
• KLP 26.7-1 (2) Guidelines on developing business scenarios
- 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
• KLP 26.9-1 (2) Guidelines on Goals and Objectives
- 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
1. Draw up a matrix with

h all the Baseline Archite
ecture Buildiing Blocks (A
ABBs) on the
e
vertical ax
xis and Targ
get ABBs on the horizontal axis
2. Add to the Baseline axis a row for "New" ABBs
s, and to the
e Target axis
s a column for
f
"Eliminate
ed" ABBs
3. Compare Baseline to Target
T and note
n what ne
eeds to be created, mod
dified and
eliminated
d
ation Plannin
28. Migra ng Techniqu
ues
• KLP 28-1 (2N ation Factor Assessment and Deduc
N)Implementa ction Matrix
- hnique used to documen

A tech mpacting the Architecture
nt factors im e
Implementation and
a Migration
n Plan
- Deduc
ction: action
ns or constra
aints that hav
ve to be take
en into cons
sideration
• KLP 28-2 (2N
N)Consolidated Gaps, Solutions, and Dependencies 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
• KLP 28-3 (2N

N)Architecturre Definition Increments Table
- 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 A d exchange is first reveals

Information security and
w
within busine
ess scenario
os
Phase B Information and service exchanges are

a further
d
defined in bu
usiness term
ms
Phase C - Data Information exchange arre detailed the corporate

e
d
date and/or information exchange model
m
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
Phase F Interoperability is logically implemen

nted
• KLP 29.2-1 (1N) Defining interoperability
- Different ways to define interoperability – need to be consistent throughout the

enterprise and extended enterprise
- Can be categorized as:
Operational/Business Interoperability
Information Interoperability
Technical Interoperability
- From an IT perspective, can be categorized as:
Presentation Integration/ Interoperability
Information Integration/ Interoperability
Application Integration/ Interoperability
Technical Integration/ Interoperability
• KLP 29.4-1 (2N) Refining interoperability
- Key to success – clear measure of Interoperability

- Should be refined to meet the needs of the enterprise in an ambiguous way
- Should be embedded in the Target Architecture and implemented in the Transition
Architecture
- Can be refined to the nth level as long as it is meaningful to the implementation
• KLP 29.5-1 (2N) Determining interoperability requirements
- Need to look at emerging and exiting systems, especially during transformation

- Use Gap analysis results and business scenarios as a foundation for requirements
- In many organizations, Business Architecture describes the nature of the information
shared between shareholders and/or organizations and the Data Architecture
specifies the information shared between systems
• KLP 29.6-1 (2N) Reconciling Interoperability Requirements with Potential Solutions
- 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 management is an integral part of ADM
• KLP 31.1-2 (1N) Characteristics of Risk Management
- Risk classification
- Risk identification
- Initial Risk assessment
- Risk mitigation and Residual Risk assessment
- Risk Monitoring
• KLP 31.4-1 (2N) Determine requirements for Risk Assessments
- Effect such as Catastrophic, Critical, Marginal, Negligible

- Frequency such as Frequent, Likely, Occasional, Seldom, Unlikely
• KLP 31.7-1 (2N) Risk monitoring and governance in Phase G
- Residual risks must be approved by the IT governance framework

- Within Phase G, there is risk monitoring, maintenance of risk identification and
mitigation worksheets
- Implementation Governance can identify critical risks that are not being
mitigated
32. Capability Based Planning

• KLP 32.1-1 (1N) Characteristics of Capability based planning
- Business driven, Business-led

- combines the requisite efforts of all lines of business to achieve the desired
capability
- accommodates most, if not all, of the corporate business models
- benefits are often reaped at the enterprise and not the line of business level
- Must be managed with respect to dimensions and increments
• KLP 32.4-2 (2
2N) Applying
g capability based
b planning in an Enterprise Architecture
co
ontext
- 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
- Refer to KLP 2.5-1
• KLP 33.2-1 (2N) An introduction to the Content Metamodel
- 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
- Actor: person, organization, or system that is outside the consideration of the

architecture model, but interacts with it
- Application Component: encapsulation of application functionality
- Business Service: supports business capabilities
- Data Entity: encapsulation of data
- Function: delivers business capabilities
- Organization
- Platform Service: technical capability required to provide enabling infrastructure
that supports the delivery of applications
- Role
- Technology Component: encapsulation of technology infrastructure
• KLP 34.2-2 (2N) Identify the catalogues, matrices and diagrams relevant to the different
ADM phases
ADM Phase Artifacts
Preliminary Principles Catalog
Phase A - Architecture Vision Stakeholder Map Matrix
Value Chain Diagram
Solution Concept Diagram

Phase B - Business Architecture Organization/Actor Catalog
Role Catalog
Business Service/Function Catalog
Business Interaction Matrix
Actor/Role Matrix
Business Footprint Diagram
Business Service/Information Diagram
Functional Decomposition Diagram
Product Lifecycle Diagram
Phase C - Information Systems Data Entity/Data Component Catalog
(Data Architecture) Data Entity/Business Function Matrix
System/Data Matrix
Class Diagram
Data Dissemination Diagram
Phase C - Information Systems Application Portfolio Catalog
(Application Architecture) Interface Catalog
System/Organization Matrix
Role/System Matrix
System/Function Matrix
Application Interaction Matrix
Application Communication Diagram
Application and User Location Diagram
System Use-Case Diagram
Phase D - Technology Architecture Technology Standards Catalog
Technology Portfolio Catalog
System/Technology Matrix
Environments and Locations Diagram
Platform Decomposition Diagram
Phase E - Opportunities and Solutions Project Context Diagram
Benefits Diagram
Requirements Management Requirements Catalog

• KLP 34.3.1-1 (-) Analyse the relation
nships betwe
een the meta
amodel entitties in the co
ore
co
ontent metamodel
- 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.3.2-1 (-) Decide which

w core artefacts
a are needed to support
s each
h of the ADM
M
phases for a given
g ple/case study/scenario
examp
- Refer 34.2-2 for a list of core

e artefacts
• KLP 34.3.3-1 (-) Demons
strate how new metamod
del entities are
a introduced into the core
c
co
ontent metamodel when
n all the exte
ensions are applied.
a
- Need to define relationship off entities witthin the core

e content me
etamodel to the
extensions
• KLP 34.3.3-2 (-) Justify th
he relationsh
hips between entities in the full mettamodel
• KLP 34.4-1 (-
-) Explain wh
hen Contentt Metamodel extensions should be used
u
- Should e concerns require more

d be used if architecture e in-depth co
onsideration
n
• KLP 34.4.1-1 (-) Explain the purpose

e of the Gove
ernance Exte
ension
- 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
o has granula
ar requireme
ents for serv
vice levels that
differ from
m service to service
o is looking to
t transform its operatio
onal governa
ance
practice
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
- The services extension is intended to allow more sophisticated modeling of the

service portfolio by creating a concept of IS services in addition to the core
concept of business services.
- This extension should be used in the following situations:
When the business has a preset definition of its services that does not
align well to technical and architectural needs
When business and IT use different language to describe similar
capabilities
Where IT service is misaligned with business need, particularly around the
areas of quality of service, visibility of performance, and management
granularity
Where IT is taking initial steps to engage business in discussions about IT
architecture
• KLP 34.4.3-1 (-) Explain the purpose of the Process Modelling Extension
- The process modeling extension is intended to allow detailed modeling of

process flows by adding events, products, and controls to the metamodel.
Typically, enterprise architecture does not drill into process flow, but in certain
process-centric or event-centric organizations it may be necessary to elaborate
process in a much more formal manner using this extension module.
Where the architecture must pay specific attention to state and events
Where the architecture is required to explicitly identify and store process
control steps; for example, to support regulatory compliance
Where the architecture features critical or elaborate process flows
• KLP 34.4.4-1 (-) Explain the purpose of the Data 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.
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
- The infrastructure consolidation extension is intended to be used in landscapes

where the application and technology portfolios have become fragmented and
the architecture seeks to consolidate the business as usual capability into a
smaller number of locations, applications, or technology components.
Where many technology products are in place with duplicate or
overlapping capability
Where many applications are in place with duplicate or overlapping
functionality
Where applications are geographically dispersed and the decision logic
for determining the location of an application is not well understood
When applications are going to be migrated into a consolidated platform
When application features are going to be migrated into a consolidated
application
• KLP 34.4.6-1b (-) Explain the purpose of the Motivation Consolidation
- The motivation extension is intended to allow additional structured modeling of

the drivers, goals, and objectives that influence an organization to provide
business services to its customers. This in turn allows more effective definition
of service contracts and better measurement of business performance.
When the architecture needs to understand the motivation of
organizations in more detail than the standard business or engagement
principles and objectives that are informally modeled within the core
content metamodel
When organizations have conflicting drivers and objectives and that
conflict needs to be understood and addressed in a structured form
When service levels are unknown or unclear
35 Archittectural Artiffacts
• KLP 35.1-1 (1
1) The Basic Architectura
al Concepts surrounding
g artifacts --
- system,
arrchitecture, architecture
e description
n, stakeholde
ers, concerns, view, view
wpoints
• KLP 35.1-2 (1
1) Provide a simple exam
mple of a vie
ew and viewp
point
- View – Airport Sys

stem
- point – pilot, controller, baggage
Viewp b han
ndler
• 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
- at the present tim

me TOGAF en ut does not mandate the
ncourages bu e use of ISO/
/IEC
42010
0:2007
- Where
e ISO/IEC 42010:2007 has been ado
opted, the steps for crea
ating a view are:
a
Refer to an existing library of viewpoints
Select the appropriate viewpoints
Generate views of the system by using the selected viewpoints as
templates
- Without ISO/IEC 42010:2007 adoption or no appropriate viewpoint, the steps for
creating a view are:
the architect may choose to develop a new viewpoint that will cover the
outstanding need, and then generate a view from it
or
the architect can create an ad hoc view for a specific system and later
consider whether a generalized form of the implicit viewpoint should be
defined explicitly and saved in a library, so that it can be re-used
• KLP 35.6-1 (2) Identify elements of the Taxonomy of Architecture Viewpoints
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
- provides descriptions of deliverables referenced in the Architecture Development

Method (ADM)
• KLP 36.1-2 (2N) Understand where within the ADM each architecture deliverable is used
Deliverable Output from... Input to...
Architecture Building Blocks F, H A, B, C, D
Architecture Contract F G
Architecture Definition Document B, C, D C, D, E, F, G, H
Architecture Principles Preliminary, A, B, C, D Preliminary, A, B, C, D, E, F, G, H
Architecture Repository Preliminary Preliminary, A, B, C, D, E, F, G, H,

Architecture Requirements Specification B, C, D, E, F, Requirements C, D, Requirements Management

Management
Architecture Roadmap B, C, D, E, F C, D, E, F, G, H
Architecture Vision A B, C, D, E, F, G, H, Requirements

Management
Business Principles, Business Goals, and Preliminary, A, B A, B

Business Drivers
Capability Assessment A, E B, C, D, E, F
Change Request H -
Communications Plan A B, C, D, E, F
Compliance Assessment G H
Implementation and Migration Plan E, F F
Implementation Governance Model F G, H
Organizational Model for Enterprise Preliminary Preliminary, A, B, C, D, E, F, G, H,

Architecture Requirements Management
Request for Architecture Work Preliminary, F A, G
Requirements Impact Assessment H, Requirements Management Requirements Management
Solution Building Blocks G A, B, C, D
Statement of Architecture Work A, B, C, D B, C, D, E, F, G, H, Requirements

Management
Tailored Architecture Framework Preliminary, A Preliminary, A, B, C, D, E, F, 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 Building Blocks

Reusable Architecture documentation and models in the enterprise's
Architecture Repository
Reference for Architecture work
Content – Refer to Module 37
- 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
Typical contents of a Business Users' Architecture Contract are:

• Introduction and background
• The nature of the agreement
• Scope
• Strategic requirements
• Conformance requirements
• Architecture adopters
• Time window
• Architecture business metrics
• Service architecture (includes Service Level Agreement (SLA))
- Architecture Definition Document

Architecture Definition Document is the deliverable container for the core
architectural artifacts created during a project
provides a qualitative view of the solution and aims to communicate the
intent of the architects
Content
Typical contents of an Architecture Definition Document are:
• Scope
• Goals, objectives, and constraints
• Architecture principles
• Baseline Architecture
• Architecture models (for each state to be modeled):
o Business Architecture models
o Data Architecture models
o Application Architecture models
o Technology Architecture models
• Rationale and justification for architectural approach
• Mapping to Architecture Repository:
o Mapping to Architecture Landscape
o Mapping to reference models
o Mapping to standards
o Re-use assessment
• Gap analysis
• Impact assessment
- Architecture Principles
Provide rules and guidelines for architecture work
- 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 Requirements Specification

provides a set of quantitative statements that outline what an
implementation project must do in order to comply with the architecture
Content
Typical contents of an Architecture Requirements Specification are:
• Success measures
• Architecture requirements
• Business service contracts
• Application service contracts
• Implementation guidelines
• Implementation specifications
• Implementation standards
• Interoperability requirements
• Constraints
• Assumptions
- 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
- Business Principles, Business Goals, and Business Drivers

provide context for architecture work
Content – varies
- 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
o Breadth, depth, and quality of standards definition with the
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
- Implementation and Migration Plan

provides a schedule for implementation of the solution described by a
Transition Architecture
Content
Typical contents of an Implementation and Migration Plan are:
• Implementation and Migration Strategy:
o Strategic implementation direction
o Implementation sequencing approach
• Interactions with other management frameworks:
o Approach to aligning architecture and business planning
o Approach to integration of architecture efforts
o Approach to aligning architecture and portfolio/project
management
o Approach to aligning architecture and operations management
• Project charters:
o Capabilities delivered by projects
o Included work packages
o Business value
o Risk, issues, assumptions, dependencies
• Implementation Plan:
o Phase and workstream breakdown of implementation effort
o Allocation of work packages to phase and workstream
o Milestones and timing
o Work breakdown structure
o Resource requirements and costs
- Implementation Governance Model

ensures that a project transitioning into implementation also smoothly
transitions into appropriate architecture governance
Content
Typical contents of an Implementation Governance Model are:
• Governance processes
• Governance organization structure
• Governance roles and responsibilities
• Governance checkpoints and success/failure criteria
- Organizational Model for Enterprise Architecture

Use to define boundaries between different enterprise architecture
practitioners and the governance relationships that span across these
boundaries
Defined roles, responsibilities and structure to support architecture
framework
Content
Typical contents of an Organizational Model for enterprise architecture are:
- Request for Architecture Work
a document that is sent from the sponsoring organization to the architecture
organization to trigger the start of an architecture development cycle
Content
Requests for Architecture Work typically include:
• Organization sponsors
• Organization's mission statement
• Business goals (and changes)
• Strategic plans of the business
• Time limits
• Changes in the business environment
• Organizational constraints
• Budget information, financial constraints
• External constraints, business constraints
• Current business system description
• Current architecture/IT system description
• Description of developing organization
• Description of resources available to developing organization
- Requirements Impact Assessment

assesses the current architecture requirements and specification to identify
changes and implications resulting from new information discovered that
invalidates the current architecture
Content
Typical contents of a Requirements Impact Assessment are:
• Reference to specific requirements
• Stakeholder priority of the requirements to date
• Phases to be revisited
• Phase to lead on requirements prioritization
• Results of phase investigations and revised priorities
• Recommendations on management of requirements
• Repository reference number
- Solution Building Blocks

Implementation-specific building blocks from the enterprise's Architecture
Repository
- Statement of Architecture Work
defines the scope and approach that will be used to complete an architecture
project
Content
Typical contents of a Statement of Architecture Work are:
• Statement of Architecture Work title
• Project request and background
• Project description and scope
• Overview or outline of Architecture Vision
• Managerial approach
• Change of scope procedures
• Roles, responsibilities, and deliverables
• Acceptance criteria and procedures
• Project plan and schedule
• Support of the Enterprise Continuum
• Signature approvals
- Tailored Architecture Framework

TOGAF framework tailored to the enterprise and to the specific architecture
project to meet project and stakeholder needs
Content
Typical contents of a Tailored Architecture Framework are:
• Tailored architecture content (deliverables and artifacts)
• Interfaces with governance models and other frameworks:
o Enterprise Architecture Management Framework
o Capability Management Framework
o Portfolio Management Framework
o Project Management Framework
o Operations Management Framework
- Transition Architecture
shows the enterprise at incremental states reflecting periods of transition
that sit between the Baseline and Target Architectures
used to allow for individual work packages and projects to be grouped into
managed portfolios and programs, illustrating the business value at each
stage
Content
Typical contents of a Transition Architecture are:
• Opportunity portfolio:
o Consolidated gaps, solutions, and dependency assessment
o Opportunity description
o Benefit assessment
o Capabilities and capability increments
o Interoperability and co-existence requirements
• Work package portfolio:
o Work package description (name, description, objectives,
deliverables)
o Functional requirements
o Dependencies
o Relationship to opportunity
o Relationship to Architecture Definition Document and
Architecture Requirements Specification
• Milestone and milestone Transition Architectures:
o Definition of transition states
o Business Architecture for each transition state
o Data Architecture for each transition state
o Application Architecture for each transition state
o Technology Architecture for each transition state
• Implementation Factor Assessment and Deduction matrix, including:
o Risks
o Issues
o Assumptions
o Dependencies
o Actions
• Consolidated Gaps, Solutions, and Dependencies matrix, including:
o Architecture domain
o Gap
o Potential solutions
o Dependencies
37 Building Blocks
• KLP 37.1-1 (1) What are the general characteristics of Building Blocks in TOGAF?
- is a package of functionality defined to meet the business needs across an

organization
- has a type that corresponds to the TOGAF content metamodel (such as actor,
business service, application, or data entity)
- has a defined boundary and is generally recognizable as "a thing" by domain
experts
- may interoperate with other, inter-dependent, building blocks
• 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
- a (potentially re-usable) component of business, IT, or architectural capability

that can be combined with other building blocks to deliver architectures and
solutions
- A good building block has the following characteristics:
considers implementation and usage and evolves to exploit technology
and standards
may be assembled from other building blocks
may be a subassembly of other building blocks
Ideally a building block is re-usable and replaceable, and well specified
• KLP 37.2-2 (1) Explain the distinction between Architecture Building Blocks and Solution
Building Blocks
- ABBs are used to direct and guide the development of SBBs

• KLP 37.2-3 (2) What are the characteristics and specification content of Architecture
Building Blocks?
ABB
Description relate to the Architecture Continuum
Characteristics • Capture architecture requirements

• Direct and guide the development of SBBs
Specification • Fundamental functionality and attributes
Content • Interfaces: chosen set, supplied
• Interoperability and relationship with other building blocks
• Dependent building blocks with required functionality and
named user interfaces
• Map to business/organizational entities and policies
• KLP 37.2-4 (2) What are the characteristics and specification content of Solution Building
Blocks?
SBB
Description relate to the Solutions Continuum
Characteristics • Define what products and components will implement the

functionality
• Define the implementation
• Fulfil business requirements
• product or vendor-aware
Specification • Specific functionality and attributes
Content • Interfaces: the implemented set
• Required SBBs used with required functionality and names
of the interfaces used
• Mapping from the SBBs to the IT topology and operational
policies
• Specifications of attributes shared across the environment
(not to be confused with functionality) such as security,
manageability, localizability, scalability
• Performance, configurability
• Design drivers and constraints, including the physical
architecture
• Relationships between SBBs and ABBs
• KLP 37.3-1 (1
1) Explain th
he use of Building Blocks
s in the ADM
M cycle
• KLP 37.3-2 (2
2) What are the
t classes of
o Building Blocks?
B
- 3 classes of building blocks:

Re-usable building blo
ocks, such as
a legacy item
ms
Building blocks to be the
t subject of
o developm
ment, such as
s new
application
ns
Building blocks to be the
t subject of
o purchase; COTS appliications
• 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
• KLP 37.4-1 (1) Understand and be able to explain the example
- Building block example shows that when executing major steps of the ADM
How building block context is captured

How building blocks are identified
How building blocks are defined
- 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
- Steps used in the example are:

Identifying Building Block Scope
• information such as business goals, assumptions, business
processes were use to narrow down the scope and produce the
first set of candidate building block
Identifying Building Block Requirements and Constraints
• Baseline showed current building blocks
• information from Phase B, C and D used to define requirements
and constraints
Architecture Modeling
• Model from Baseline and Target Architectures
Opportunity Identification
Building Block Re-Use Level
• 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)?
- is a view of the Arrchitecture Repository

R th
hat provides
s methods fo
or classifying
g
architecture and solution
s artiffacts, both internal and external to the Architec
cture
Repos
sitory, as the
ey evolve fro
om generic Foundation
F A
Architectures
s to
Organ
nization-Spe
ecific Archite
ectures
• 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
- is intended to represent the classification of all assets that are available to an

enterprise
• 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?
- specific contextual factors to be identified and incorporated in an architecture

will vary from architecture to architecture
- typical contextual factors for architecture development are likely to include:
External influencing factors, such as regulatory change, technological
advances, and competitor activity
Business strategy and context, including mergers, acquisitions and other
business transformation requirements
Current business operations, reflecting deployed architectures and
solutions
• KLP 39.4-3 (1) What is the purpose of the Architecture Continuum?
- illustrates how architectures are developed and evolved across a continuum

ranging from Foundation Architectures, such as the one provided by TOGAF,
through Common Systems Architectures, and Industry Architectures, and to an
enterprise's own Organization-Specific Architectures
• KLP 39.4-4 (1) What are the stages of architecture evolution defined in the Architecture
Continuum?
- Stages are not specified in the TOGAF material

- It only shows that within the Architecture Continuum, Architecture showing
enterprise needs and business requirements are addressed in increasing detail
from left to right
- In the TOGAF material, four architectures are shown but they are NOT fixed
stages in the process
• KLP 39.4-5 (2) What is the progression of evolutionary transformation of architectures in

the Architecture Continuum?
- Progression occurs at several levels:

Logical to physical
Horizontal (IT-focused) to vertical (business-focused)
Generalization to specialization
Taxonomy to complete and specific architecture specification
• KLP 39.4-6 (1) What is the purpose of the Solutions Continuum?
- represents the detailed specification and construction of the architectures at the

corresponding levels of the Architecture Continuum
• KLP 39.4-7 (1) What are the stages of architecture evolution defined in the Solution
Continuum?
- Stages are not specified in the TOGAF material

- It only shows that within the Solution Continuum:
"Moving to the right" on the Solutions Continuum is focused on providing
solutions value
"Moving to the left" on the Solutions Continuum is focused on addressing
enterprise needs
• KLP 39.4-8 (2) What is the progression of evolutionary transformation of solution

architectures in the Solution Continuum?
- Solution architectures become more specific
• 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-1 (2N) What is Architecture Partitioning?
- Decomposing Enterprise Architecture into a set of architectures with manageable

complexity
• KLP 40.1-2 (2N) What are the reasons for partitioning the Enterprise Architecture?
- Key drivers are:
Addressing all problems within a single architecture is too complex

Different architectures conflict with one another
Different people need to work on different elements of architecture at the
same time and partitions allow for specific groups of architects to own
and develop specific segments of the architecture
Effective architecture re-use requires modular architecture segments that
can be taken and incorporated into broader architectures and solutions
• KLP 40.2-1 (2N) What are the characteristics of Solutions?
- 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
• KLP 40.3-1 (2N) What are the characteristics of Architectures?
- 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?
- The characteristics of Architectures and solutions are used to partition and

organize the Enterprise Continuum into a set of related solutions and
architectures
• KLP 40.4-2 (2N) What are the tiers of enterprise architecture landscapes?
- Strategic, Segment, Capability
• KLP 40.4-3 (2N) How does Architecture Partitioning encourage good practices
- By partitioning the reference model
• 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
The Architecture Repository
• KLP 41-1 (1N) What is an Architecture Repository?
- used to store different classes of architectural output at different levels of

abstraction, created by the ADM
• KLP 41.1-1 (1N) What is the relationship between the Architecture Repository and the
Enterprise IT repository?
- Architecture Repository is one part of the Enterprise IT repository
• 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?
- hold best practice or template materials that can be used to construct

architectures within an enterprise
• KLP 41.4-1 (1) What is the Standards information Base?
- Provides a repository area to hold a set of specifications, to which architectures

must conform
• KLP 41.4-2 (2N) What are the classes of standards held in the Standards Information
Base?
- Legal and Regulatory Obligations

- Industry Standards
- Organizational Standards
• KLP 41.4-3 (2N) What is the lifecycle of standards?
- Trial, Active, Deprecated, Obsolete
• KLP 41.5-1 (2N) What is the purpose of the Governance Log in the Architecture
Repository?
- provides a repository area to hold shared information relating to the ongoing

governance of projects
• KLP 41.5-2 (2N) What are the types of content that can be managed in the Governance
Log of an 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:
Tools for Architecture Development
• KLP 42.2-1 (1) An understanding of high level issues with tool standardization
- Tool Vendors and Clients

Tool vendors and client organizations have not agreed on the definition
of the problem that the tool is trying to solve
- a single "one size fits all" tool or a multi-tool suite for modeling architectures
- a single tool would not accommodate a variety of architecture development
"maturity levels" and specific needs across an enterprise
• KLP 42.3-1 (2) Criteria and Guidelines for evaluating tools
- 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
43 Foundation Architecture: Tec

chnical Referrence 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?
- objecttive of the TOGAF TRM is to provide

e a widely accepted core taxonomy, and
an appropriate vis
sual representation of th
hat taxonom
my
• 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
- In building an architecture, users select the services,

s erfaces, and standards that
inte
satisfy the
eir own busiiness needs from the TR
RM
• 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
- Is a single, generic entity thatt holds all po

ossible serviices that is needed
n to
address enterprise’s business
s needs
• KLP 43.4-1 (1
1) What is th
he Platform Services
S Taxonomy?
• KLP 43-4-2 (1) What is th

he Service Quality
Q Taxon
nomy?
- 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
- Data Interchange Services

Document generic data typing and conversion services
Graphics data interchange services
Specialized data interchange services
Electronic data interchange services
Fax services
Raw graphics interface functions
Text processing functions
Document processing functions
Publishing functions
Video processing functions
Audio processing functions
Multimedia processing functions
Media synchronization functions
Information presentation and distribution functions
Hypertext functions
- Data Management Services
Data dictionary/repository services
Database Management System (DBMS) services
Object-Oriented Database Management System (OODBMS) services
File management services
Query processing functions
Screen generation functions
Report generation functions
Networking/concurrent access functions
Warehousing functions
- Graphics and Imaging Services
Graphical object management services
Drawing services
Imaging functions
- International Operation Services
Character sets and data representation services
Cultural convention services
Local language support services
- Location and Directory Services
Directory services
Special-purpose naming services
Service location services
Registration services
Filtering services
Accounting services
- Network Services
Data communications services
Electronic mail services
Distributed data services
Distributed file services
Distributed name services
Distributed time services
Remote process (access) services
Remote print spooling and output distribution services
Enhanced telephony functions
Shared screen functions
Video conferencing functions
Broadcast functions
Mailing list functions
- Operating System Services
Kernel operations services
Command interpreter and utility services
Batch processing services
File and directory synchronization services
- Software Engineering Services
Programming language services
Object code linking services
Computer-aided software engineering (CASE) environment and tools
services
Graphical user interface (GUI) building services
Scripting language services
Language binding services
Run-time environment services
Application binary interface services
- Transaction Processing Services
Transaction manager services
- User Interface Services
Graphical client/server services
Display objects services
Window management services
Dialog support services
Printing services
Computer-based training and online help services
Character-based services
- Security Services
Identification and authentication services
System entry control services
Audit services
Access control services
Non-repudiation services
Security management services
Trusted recovery services
Encryption services
Trusted communication services
- System and Network Management Services
User management services
Configuration management (CM) services
Performance management services
Availability and fault management services
Accounting management services
Security management services
Print management services
Network management services
Backup and restore services
Online disk management services
License management services
Capacity management services
Software installation services
Trouble ticketing services
• KLP 43.5-2 (2) Be able to describe how to customize the Foundation Architecture TRM to
meet your organization’s needs
- Select services specific to the organization, augment details where required
44 Integrated Information Infrastructure Reference Model
• KLP 44.1-1 (1) The basic concepts of the III-RM
- Is a reference model that focuses on the Application Software space

- Has 2 components: taxonomy and III-RM Graphics
- III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also
expands certain parts of the TRM - in particular, the business applications and
infrastructure applications parts
- III-RM is intended as a useful tool in the execution of the TOGAF Architecture
Development Method (ADM)
• KLP 44.1-2 (1) Describe the relationship of the III-RM to the concept of Boundaryless
Information Flow
- There is a need for integrated information infrastructure to achieve Boundaryless

Information Flow
- III-RM depicts the major components required to address the Boundaryless
Information Flow problem
• 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?
- III-RM depicts the major components required to address the Boundaryless

Information Flow problem space
• KLP 44.2-1 (1
1) The high level
l view off the III-RM
• 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
46 Establishing an Architecture Capability
• 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
Phase A: • Identify stakeholders and concerns, business

Architecture Vision requirements and Architecture Vision
• Identify Business goals and driver
• Define Scope
• Define Constraints
• Review Architecture Principles
• Develop Statement of Work
• Secure Approval
Phase B: • Architecture Ontology – architecture terms and

Business Architecture definitions
(Key areas of focus) • Architecture Process – ADM including Governance
processes
• Architecture Views and Viewpoints
• Architecture Framework
• Architecture Accountability Matrix
• Architecture Performance Matrix
• Architecture Governance Framework
Phase C: • Specify and govern the structure of the

Information Systems organization’s Enterprise Continuum and
Architecture - Data Architecture Repository
Phase C: • Define the functionality required to generate,

Information Systems maintain, publish, distribute and govern
Architecture - Architecture deliverables as defined in the
Application Architecture Framework
Phase D: • Define technology infrastructure supporting the

Technology Architecture practice
Architecture
Phase E: • Critical factor to consider is Organizational
Opportunities and change that is required and how it will be
Solutions achieved
Phase F: • Focus on Information Systems Architecture

Migration Planning components and also on Business Architecture
Phase G: • Focus on implementation of the Business

Implementation Architecture of the Architecture practice
Governance
Phase H: • Focus on managing changes to the architecture
Architecture Change of the Architecture practice
Management
Requirements • Focus on understanding and management
Management requirements for the Architecture practice
47 Architecture Board
• KLP 47.1-1 (1)The need for an Architecture Board

- A cross organization board is required to oversee the implementation of the
Architecture Governance strategy
• KLP 47.2-1 (1)The responsibilities of an Architecture Board
- Architectures – ensure consistency, flexibility, usability and adoption
- Operation – Architecture contracts, escalation resolution, support and
compliance
- Governance – implement, support and enforce
- Continuous improvement of the Architecture Practice
• KLP 47.3-1 (2) Setting up an Architecture Board

- Size
4 or 5 permanent members (10 max)
- Key Considerations
Architecture Board needs an executive sponsor from the highest level of
management
Rotating members as one of the strategies to ensure an enterprise-wide
representation and a solution to resource constraint
Best practice structure
- Typical Structure
Global Governance Board
Local Governance Board
Design Authorities
Working Parties
• K 47.4-1 (2
KLP 2) Operating
g an Architec
cture Board
- Meetin b conducted with explicit objective
ngs should be es, content coverage
c and
d
define
ed actions
- Mecha
anism should be in place
e for:
Dispute re
esolution
Dispensations
Complianc
ce Assessme
ents
Control for ensuring effective
e arch
hitecture implementation
Maintainin een architecture implem
ng link betwe mentation and organizatiion
strategy
Identifying
g divergence
e from archittecture contracts
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
• KLP 49.1-1 (1)The role of Architecture Contracts

- Architecture contracts are joint agreements between developing partners and
sponsors on deliverables, quality and fit-for-purpose of an architecture
• KLP 49.2-1 (2) Contents of Architecture Contracts

- Contents vary dependent on the contract
- Examples of contract: Statement of Architecture Work in Phase A
Statement of Architecture Work Title
Project request and background
Project description and scope
Overview or outline of Architecture Vision
Managerial approach
Change of scope procedures
Roles, responsibilities and deliverables
Acceptance criteria and procedures
Project plan and schedule
Support of the enterprise continuum
Signature approvals
• KLP 49.3-1 (2)Relationship to Architecture Governance

- An architecture contract is produced in Phase G – Architecture Governance
- Contract is often used to drive Architectural changes
50 Architecture Governance
• KLP 50.1-1 (1) What is architecture governance? (nature, characteristics ..)

- The practice by which enterprise architectures and architectures are managed
and controlled at the enterprise-wide level
- Nature of Governance
use guidance, effective and equitable usage of resources; not overt
control
focuses on the rights, roles and equitable treatment of shareholders
disclosure and transparency
- 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?
- s, resources, and inform

Links IT processes mation to org
ganizational strategies and
a
objecttives
- Integrrates and ins
stitutionalize
es IT best prractices
- s with industtry frameworks such as COBIT (planning and organizing,
Aligns
plementing, delivering and
acquirring and imp a supporting, and mon
nitoring IT
perforrmance)
- Enable
es the organ
nization to ta
ake full adva
antage of its information
n, infrastructture,
and hardware and
d software as
ssets
- Protects the underlying digital assets of the organization
- Supports regulatory and best practice requirements such as auditability, security,
responsibility and accountability
- Promotes visible risk management
-
• KLP 50.3-2 (2) The key success factors for architecture governance in practice
- Best practices for the submission, adoption, re-use, reporting and retirement of
architecture policies, procedures, roles, skills, organizational structures and
support services
- Organizational responsibilities and structures to support the Architecture
Governance process and reporting requirements
- Integration of tools and processes to facilitate the take-up of the process, both
procedurally and culturally
- Criteria for the control of the Architecture Governance process, dispensations,
compliance assessments, SLAs and OLAs
- Internal and external requirements for the effectiveness, efficiency,
confidentiality, integrity, availability, compliance and reliability of all architecture
governance related information, services and process
51 Architecture Maturity Models
• KLP 51.1-1 (2)Understanding the Role of Capability Maturity Models

- Describes the practices that any organization must perform in order to improve
its processes
- Provide a yardstick for organizations to periodically measure improvements
against
- Contain a proven framework within which to manage the improvement efforts
• KLP 51.2-1 (2)Understanding the evolution and adoption of CMMI

- Original CMM developed by the Software Engineering Institute in the early 1990s
- Gained wide-scale acceptance over the last decade
- Model originally applied to IT solutions, there are now CMMs supporting other
areas
• 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
ACMM Level TOGAF ADM
Level 0 No ADM
Level 1 - Initial Informal ADM
Level 2 – Under Development ADM process is under development
Level 3 – Defined Defined ADM with TRM
Level 4 – Managed 100% ADM, Managed and measured

process
Level 5 – Optimize Exploiting ADM as a business capability
• KLP 51.4-1 (2)Awareness of the existence of other Architecture Capability Maturity

Models
52 Architecture Skills Framework
• KLP 52.2-1 (2)The need for the Architecture Skills Framework

- There is a need for better classification and definition of “Enterprise Architect”
- Will help organizations in recruiting the right resources for their architecture
practice by knowing the skills and proficiency level required
- Provides a rapid mean for identifying skill gaps
• KLP 52.3-1 (2)Benefits of adopting the framework

- Reduce time, cost and risk in training, hiring and managing internal and external
architecture professionals
- Reduce time and cost to set up an internal architecture practice
- Reduce time, cost and risk of overall solution development
• KLP 52.4-1 (2)Skills and Categories of the framework

- Generic skills: leadership, team working, interpersonal skills
- Business skills and methods: creating business cases, analysis of business
process, strategic planning
- Enterprise Architecture skills: modeling, building block design, role and
application design, system integration
- Program and Project Management skills: managing business change, project
management methods and tools
- IT General Knowledge skills: brokering applications, assets management,
migration planning, SLAs
- Technical IT skills: software engineering, security, data interchange
- Legal Environment: data protection laws, contract law, procurement

Module 7: TOGAF 8 to TOGAF 9 Migration
In addition to meeting TOGAF 9 Foundation and Practitioner Requirements, the candidate must
be able to:
• Describe the new features in TOGAF 9

- Modular Structure
Specification content is structured in a modular way
- Content Framework
TOGAF content framework provides a detailed model of architectural work
products, including deliverables, artifacts within deliverables, and the
architectural building blocks that artifacts represent
Includes an extended set of concepts and guidelines to support the
establishment of an integrated hierarchy of architectures being developed by
teams that operate within an overarching architectural governance model
In particular, the following concepts are introduced:
Partitioning
• In order to develop architectures that have manageable levels
of cost and complexity, it is necessary to partition the
enterprise into specific architectures.
• TOGAF provides a logical information model for an
Architecture Repository, which can be used as an integrated
store for all outputs created by executing the ADM
Capability Framework:
• provides a more structured definition of the organization,
skills, roles, and responsibilities required to operate an
effective enterprise architecture capability
• provide guidance on a process that can be followed to identify
and establish an appropriate architecture capability
- Explicit Consideration of Architectural Styles, including SOA and Security
Architecture
new Part III: ADM Guidelines and Techniques
The new guidelines discuss:
The varying uses of iteration that are possible within the ADM and
when each technique should be applied
The linkages between the TOGAF ADM and Service Oriented
Architecture (SOA)
The specific considerations required to address security architecture
within the ADM
The various types of architecture development required within an
enterprise and how these relate to one another
- Additional ADM Detail
This version of the TOGAF specification includes more detailed information
supporting the execution of the ADM. Particular areas of enhancement are:
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.
• Explain the benefits of the new features

- Refer to Module 4 Modular Structure
modular seven-part structure of TOGAF allows for the concepts in each part
to be developed with limited impacts on other parts
intended to support greater usability
supports more sophisticated release management of the TOGAF specification
individual parts may evolve at different speeds and the current
specification structure is intended to allow changes in one area to
take place with limited impacts across the specification
- Content Framework
drive greater consistency in the outputs that are created when following an
Architecture Development Method (ADM)
within a single architecture development initiative the content framework
provides a comprehensive checklist of architecture outputs that could be
created and consequently reduce the risk of gaps within the final architecture
deliverable set
easier to integrate architectural work products across an enterprise
provides a detailed open standard for how architectures should be described
this standard allows tools vendors, product vendors, and service vendors to
adopt consistent ways of working, which in turn will result in greater
consistency between architecture tools, better tool interoperability, more
consistent reference architectures, and better comparability between related
reference architectures
an
n extended set
s of concep
pts and guid
delines supports the esta
ablishment of
o an
erarchy of architectures being develo
inttegrated hie oped by team
ms that operrate
wiithin an overrarching architectural go
overnance model
m
- Explicit Consideration
n of Architec
ctural Styles,, including SOA
S and Security
Architectu
ure
ne
ew Part III: ADM Guidelin
nes and Tech
hniques brin
ngs together a set of
su
upporting ma
aterials that show in mo
ore detail how
w the ADM can
c be applied to
pecific situations
sp
- Additiona
al ADM Detaiil
Be
etter guidanc
ce on how to
o apply ADM
M
• xplain the high-level strructural chan

Ex nges betwee
en TOGAF 8.1.1 to TOGA
AF 9
- TOGA
AF 9 is organized into 7 main
m part with the follow
wing change
es:
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
TOGAF 8.1.1 Resource Current Location
Architecture Board Moved to Part VII: Architecture Capability Framework
Architecture Compliance Moved to Part VII: Architecture Capability Framework
Architecture Contracts Moved to Part VII: Architecture Capability Framework
Architecture Governance Moved to Part VII: Architecture Capability Framework
Architecture Maturity Models Moved to Part VII: Architecture Capability Framework
Architecture Patterns Moved to Part III: ADM Guidelines and Techniques
Architecture Principles Moved to Part III: ADM Guidelines and Techniques
Architecture Skills Framework Moved to Part VII: Architecture Capability Framework
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
Business Scenarios Moved to Part III: ADM Guidelines and Techniques
Case Studies Removed. Case Studies will be available on The Open Group web site.
Glossary Moved to Part I: Introduction
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.
• Discuss approaches to migrate an enterprise from TOGAF 8.1.1 to TOGAF 9

- Treat the migration of TOGAF 8.1.1 to TOGAF 9 as part of Capability-based
Planning and deliver a Transition Architecture
- Treat the migration of TOGAF 8.1.1 to TOGAF 9 as a change request for the
Architecture Practice and run through Phase H
- Treat the migration as a Architecture Requirements and create a Requirements

Impact Assessment
- Educate and recertified Staff to TOGAF 9, augment ADM and Enterprise

Architecture Practice with new features in TOGAF 9 deemed as enterprise needs

Qrs Togaf 8-9 Study Guide

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Qrs Togaf 8-9 Study Guide

Transféré par

Droits d'auteur :

Formats disponibles

Prepared by : QRS (www.quickresponse.

ca) TOGAF is a Registered Trademark of The Open Group

Module 1: Introduction to TOGAF .................................................................................................................... 3

Module 2: ADM, Guidelines and Techniques................................................................................................... 18

ADM Overview ........................................................................................................................................ 18

Architecture Development Methods ........................................................................................................... 21

Guidelines: ............................................................................................................................................. 53

Techniques ............................................................................................................................................. 61

Module 3: Content Framework .................................................................................................................. 73

Module 4: Enterprise Continuum ............................................................................................................... 98

Module 5: TOGAF Reference Model ........................................................................................................ 105

Module 6: Capability Framework ............................................................................................................. 113

Module 7: TOGAF 8 to TOGAF 9 Migration .............................................................................................. 122

How to KLP to Modules and Level of Learning

• KLP 1.1-1 (1N

• KLP 1.1-2 (1N

- To allow for different areas of specialization to be considered in detail and

• KLP 1.2-1 (1) What is an enterprise?

- TOGAF defines "enterprise" as any collection of organizations that has a common

- An extended enterprise includes partners, suppliers, and customers

• KLP 1.2-2 (1) What is enterprise architecture?

- a formal description of a system, or a detailed plan of the system at component

- the structure of components, their inter-relationships, and the principles and

• KLP 1.2-3 (1) Why do I need an enterprise architecture?

- a foundational structure, or set of structures used for developing a broad range

- should contain a set of tools

- provide a common vocabulary

- include a list of recommended standards and compliant products that can be

- represents best practice in architecture development

- allows architectures to be developed that are consistent, reflect the needs of

- helps to "de-mystify" and de-risk the architecture development process

• KLP 2.1-1 (1) What is TOGAF?

- TOGAF is an architecture framework - The Open Group Architecture Framework

- based on an iterative process model supported by best practices and a re-usable

• KLP 2.2-1 (1) What is architecture in the context of TOGAF?

- In TOGAF, architecture has two meanings:

1. A formal description of a system, or a detailed plan of the system at

- Business, Data, Application, Technology

- Preliminary Phase describes the preparation and initiation activities required to

- A deliverable is a work product that is contractually specified and in turn

- An artifact is a more granular architectural work product that describes an

- A building block represents a (potentially re-usable) component of business, IT,

- Deliverables contain artifacts

- Artifacts describe building blocks

- Enterprise Continuum is a view of the Architecture Repository that provides

• KLP 2.7-1 (1N)Architecture Repository (introduces the concept)

- used to store different classes of architectural output at different levels of

• KLP 2.8-1 (1N)Establishing and maintaining an Enterprise Architecture Capability

- The following must be established in order to execute enterprise architecture

 Appropriate business capability for architecture

• KLP 2.9-1 (1N) Establishing the Architecture Capability as an operational entity.

- To be effective, an enterprise architecture practice must be run like an operation

• KLP 2.10-1 (1)Using TOGAF with other frameworks

- as a generic framework and method for enterprise architecture, TOGAF

- is a model to structure the release management of TOGAF specifications

• KLP 3.1-1 (-)Abstraction

• KLP 3.2-1 (1) Activity

• KLP 3.4-1 (1) Application

• KLP 3.5-1 (1) Application Architecture

• KLP 3.9-1 (1) Architecture

• KLP 3.10-1 (1) Architecture Building Block (ABB)

• KLP 3.12-1 (1) Architecture Development Method (ADM)

• KLP 3.13-1 (1) Architecture Domain

Appropriate business capability for architecture