TOGAF Certification

1. TOGAF 9.2
Training
TOGAF 9
Certification
This module describes TOGAF® 9 Certification Program
B2BTOGAF010

2. 2
18
Learning Outcomes
Slide addresses a
level 2 Learning
Outcome
Slide addresses a
level 1 Learning
Outcome
Slide addresses level
1 and 2 Learning
Outcomes
• The syllabus for the TOGAF® 9
certification examinations is defined
by a series of Learning Outcomes.
• Each slide that addresses a TOGAF®
9.2 Learning Outcome is annotated
by a sign in the bottom left corner.
1
2
1 2

3. 3
18
TOGAF® 9 Certification
Level Tag Objective
1 TOGAF® 9 Foundation To provide validation that the candidate has gained
knowledge of the terminology and basic concepts of
The TOGAF Framework and understand the core
principles of Enterprise Architecture and TOGAF
2 TOGAF® 9 Certified To provide validation that in addition to knowledge
and comprehension, the candidate is able to
analyze and apply knowledge of The TOGAF
Framework
1

4. 4
18
TOGAF 9 Certified
TOGAF
Bridge
Paths to TOGAF 9 Certified
1
TOGAF 8
Certified
?
Yes No
TOGAF 9
Foundation
Part 1
Combine
d
Part 1
+
Part 2
2 STEP APPROACH 1 STEP APPROACH
One
Option
Part 2
TWO
Options

5. 5
18
TOGAF 9 Certified
TOGAF
Bridge
Paths to TOGAF 9 Certified
1
TOGAF 8
Certified
?
Yes No
TOGAF 9
Foundation
Part 1
Combine
d
Part 1
+
Part 2
2 STEP APPROACH 1 STEP APPROACH
One
Option
Part 2
TWO
Options
Closed
Book

6. 6
18
Two types of question in TOGAF 9 certification examination
SHORT multi-choice.
4 alternative answers,
• 1 is right,
• the others are wrong
SCENARIO BASED multi-choice
• 1 is right 5 marks
• 1 is nearly right 3 marks
• 1 is almost wrong 1 mark
• 1 is completely wrong 0 marks
Examination Styles

7. 7
18
What is the name of the document that initiates the Architecture
Vision phase (Phase A of the TOGAF ADM)
A.Project mandate
B.Statement of Architecture Work
C.Request for Architecture Work
D.Architecture Contract
Sample short question

8. 8
18
What is the name of the document that initiates
the Architecture Vision phase (Phase A of the
TOGAF ADM)
A.Project mandate
B.Statement of Architecture Work
C.Request for Architecture Work
D.Architecture Contract
Sample short question

9. 9
18
Acme Global IT Services is the results of a series of mergers of companies who were originally computer manufacturers
and extended into software and services. Individually all of the companies were too small to survive. Collectively, they
become the fourth largest computer systems and service provider in the world.
As can be expected, the companies bring with them different cultures, different business practices, and different IT
systems based on the computer platforms sold by each of the constituent companies.
In order to succeed, the new company must make substantial savings in all areas, and must convince its existing
customer base that it represents a safe and stable supplier for the foreseeable future.
A merger task force has been created to determine how the business operations of the new company should be
harmonised. This task force is to produce an interim report in three months with the objective of a complete review of
business operations within two years. The interim report is expected to provide some indication of existing business
operations that are likely to be retained and those which are to be replaced.
Meanwhile the CEO has commented that expenditure on IT operations within the combined organization is “totally out
of control” and has tasked the CTO, who has responsibility for this area, with producing a reduction in costs of IT
operations of 40% within one year.
Sample long question - Scenario

10. 10
18
Using TOGAF version 9, how would you as the Chief Enterprise Architect set about developing a plan for Enterprise
Architecture that supports both the short term objectives of the CTO and the longer term harmonization of business
operations?
A.Establish two architecture projects running in parallel.
1. To develop a Technology Architecture to meet the short term need to reduce the costs of IT
operations.
2. To develop a full Enterprise Architecture to ensure IT support for the harmonization of business
operations
B.Establish a 2 year project to work with the merger task force to ensure effective IT support for the harmonized business
operations and leave the IT technical people to sort out how to reduce the cost of IT operations.
C.For the first three months, work with the merger task force to develop a high level strategic architecture to provide
context for future work. Use this context to provide direction for the development of
1. A technology architecture to meet the short term need to reduce the costs of IT operations
2. A series of segment architectures to support the harmonization of business operations
D.Ignore the long term business harmonization and focus on the development of a Technology Architecture to meet the
short term need to reduce the cost of IT operations.
Sample long question – Alternative Solutions

11. 11
18
Using TOGAF version 9, how would you as the Chief Enterprise Architect set about developing a plan for Enterprise
Architecture that supports both the short term objectives of the CTO and the longer term harmonization of business
operations?
A.Establish two architecture projects running in parallel.
1. To develop a Technology Architecture to meet the short term need to reduce the costs of IT
operations.
2. To develop a full Enterprise Architecture to ensure IT support for the harmonization of business
operations
B.Establish a 2 year project to work with the merger task force to ensure effective IT support for the harmonized
business operations and leave the IT technical people to sort out how to reduce the cost of IT operations.
C.For the first three months, work with the merger task force to develop a high level strategic architecture to provide
context for future work. Use this context to provide direction for the development of
1. A technology architecture to meet the short term need to reduce the costs of IT operations
2. A series of segment architectures to support the harmonization of business operations
D.Ignore the long term business harmonization and focus on the development of a Technology Architecture to meet
the short term need to reduce the cost of IT operations.
Sample long question – Alternative Solutions

12. The TOGAF 9
Examinations
• ESL : English as a Second Language
Examination Short Long
Time
Limit ESL
TOGAF 9 Part 1 40 1:00 1:30
TOGAF 9 Part 2 8 1:30 2:15
TOGAF 9 Combined
Part 1 and 2 40 8 2:30 3:45

13. 13
18
Moving to TOGAF 9
Certification
Best2BEE cannot guarantee
success in the TOGAF 9
examinations
Depends on the level of your EA experience
Depends on the quality of your memory
Depends on your ability to handle examination
conditions
Best2BEE can
Advise you on whether you are ready to take the
examination
Help you prepare for the examination
Additional Exam preparation – online tests
Provide facilities for you to take the examination
(in some territories)

14. 14
18
What you
learned
from this
module?
•This module has described the TOGAF® 9
Certification Program
• What are the levels of certification
• Structure of the TOGAF 9 examination

15. 15
18
Learning
Outcomes
•Explain the TOGAF Certification
program, and distinguish between the
levels for certification

16. 16
18
Transition
from
TOGAF 8.1.1
to TOGAF 9 THIS MATERIAL IS NEW IN TOGAF
VERSION 9
TOGAF® 8 CERTIFICATION WAS BASED
ON SUCCESSFULLY COMPLETING A
CERTIFIED TRAINING COURSE

18. TOGAF 9.2
Training
TOGAF 9
Certification
This module gives a context on Enterprise Architecture and Introduces
THE TOGAF ARCHITECTURE FRAMEWORK
B2BTOGAF02
0

19. 19
18
The TOGAF version 9 specification establishes a common
language for communication among architects
A list of terms defined in the TOGAF specification is included in
your course materials
• Those that are learning outcomes for the TOGAF® 9
certification examinations are annotated with a definition
reminder on the left
A “Glossary of Supplementary Definitions” are included in the
TOGAF 9 specification
Adapting to local terminology is an essential part of configuring
the TOGAF Architecture Development Method
TOGAF Terminology
SLIDE 19 of 43
1
Definition
reminder

20. 20
18
Wild growth from short-term
planning
• Perversion of Standards (proprietary additions)
• Isolation of information in silos
Misleading regarding
Interoperability
• Massive pressure for increased Return on Investment
• Poor management understanding of IT capabilities and
exploitation
Disappointment of
management in cost and
benefits
Rationalization of the IT
Landscape
Constant Innovation via new
technologies
SLIDE 20 of 43
Information Technology History
In order to manage business and IT changes across the
enterprise, a structure or a framework was needed

21. 21
18
The definition of Enterprise Architecture
The Architecture of an Enterprise
1

22. 22
18
The definition of Enterprise Architecture
The Architecture of an Enterprise
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.

23. 23
18
The definition of Enterprise Architecture
SLIDE 23 of 43
The Architecture of an Enterprise
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.
Architecture
A formal description of a system, or a
detailed plan of the system at component
level, to guide its implementation (ISO/IEC
42010:2007).
The structure of components, their inter-
relationships, and the principles and
guidelines governing their design and
evolution over time.

24. 24
18
The definition of Enterprise Architecture
The Architecture of an Enterprise
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.
Architecture
A formal description of a system, or a
detailed plan of the system at component
level, to guide its implementation (ISO/IEC
42010:2007).
The structure of components, their inter-
relationships, and the principles and
guidelines governing their design and
evolution over time.
The TOGAF Specification considers the Enterprise as a System

25. 25
18
Enterprise Architecture is the structure that can
help
AT ITS MOST EFFECTIVE, ENTERPRISE
ARCHITECTURE ENABLES EFFECTIVE
EXECUTION OF AN ORGANIZATION’S STRATEGY
TO ACHIEVE CHANGE
BUSINESS ARCHITECTURE IS A MAJOR
ENABLING COMPONENT OF AN ENTERPRISE
ARCHITECTURE
IT ARCHITECTURE IS A MAJOR ENABLING
COMPONENT OF AN ENTERPRISE
ARCHITECTURE
1

26. 26
18
What is Enterprise Architecture
Description of an
enterprise as a system in
terms of its
Components
Their inter-relationships
Principles and Guidelines
governing the design and its
evolution
Usually done to identify
gaps between
Current state
Desired future state
Provides roadmap for
organization to
Achieve its goals
Deliver its objectives
Often described at
multiple levels of
Breadth
Depth
1

27. 27
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Information Systems
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together

28. 28
18
Domains of Architecture
Business Architecture
How the business is
organised to meet its
objectives
Information Systems
Architecture
How Information Systems
supports the objectives of
the business
Technology
Architecture
How the technology fits
together
IT
Architectur
e

29. 29
18
Domains of Architecture
Business Architecture
How the business is
organised to meet its
objectives
Information Systems
Architecture
How Information Systems
supports the objectives of
the business
Technology
Architecture
How the technology fits
together
IT
Architectur
e
Enterprise
Architecture

30. 30
18
Domains of Architecture
Business Architecture
How the business is
organised to meet its
objectives
Information Systems
Architecture
How Information Systems
supports the objectives of
the business
Technology
Architecture
How the technology fits
together
IT
Architectur
e
Enterprise
Architecture
Baseline “As
Is”
Target “To
Be”
A specification that has
been formally reviewed
and agreed upon
The description of a
future state of the
architecture being
developed for an
organization
1

31. 31
18
Why do I need an
Enterprise Architecture?
•Effective management and exploitation of information
is key to business success and competitive advantage
•A good Enterprise Architecture
• Optimises the (fragmented) legacy of processes
(manual and automated) to an integrated
environment
• Responds to change
• Supports delivery of the business strategy
• Enables the right balance between IT efficiency
and business innovation
1

32. 32
18
Business Benefits from a Good Enterprise
Architecture
A more efficient
business operation
Better return on
existing investment,
reduced risk for
future investment
A more efficient IT
operation
Faster, simpler and
cheaper
procurement
1

33. 33
18
Business Benefits from a Good Enterprise
Architecture
A more efficient
business operation
Better return on
existing investment,
reduced risk for
future investment
A more efficient IT
operation
Faster, simpler and
cheaper
procurement
1
▪ Lower business operation costs
▪ More agile organization
▪ Business capabilities shared across the organization
▪ Lower Change Management costs
▪ More flexible workforce
▪ Improved business productivity

34. 34
18
Business Benefits from a Good Enterprise
Architecture
A more efficient
business operation
Better return on
existing investment,
reduced risk for
future investment
A more efficient IT
operation
Faster, simpler and
cheaper
procurement
1
▪ Reduced complexity in Business and IT
infrastructure
▪ Maximum return on investment in
existing business and IT infrastructure
▪ The flexibility to make, buy, or out-source
business and IT solutions
▪ Reduced overall risk in new investment,
and their cost of ownership

35. 35
18
Business Benefits from a Good Enterprise
Architecture
A more efficient
business operation
Better return on
existing investment,
reduced risk for
future investment
A more efficient IT
operation
Faster, simpler and
cheaper
procurement
1
▪ Lower software development, support
and maintenance costs
▪ Increased portability of applications
▪ Improved interoperability and easier
system and network management
▪ Improved ability to address critical
enterprise-wide issues like security
▪ Easier upgrade and exchange of system
components

36. 36
18
Business Benefits from a Good Enterprise
Architecture
A more efficient
business operation
Better return on
existing investment,
reduced risk for future
investment
A more efficient IT
operation
Faster, simpler and
cheaper procurement
1
▪ Buying decisions are simpler, because the
information governing procurement is
readily available in a coherent plan.
▪ The procurement process is faster -
maximizing procurement speed and
flexibility without sacrificing architectural
coherence.
▪ The ability to procure heterogeneous,
multi-vendor open systems.
▪ The ability to secure more economic
capabilities

37. What
prompts
Enterprise
Architecture
development?
• Preparation for business transformation or radical
infrastructure changes initiates an enterprise architecture
review or development
• Key people identify areas of change required for new
business goals to be met
• These “stakeholders” have areas of interest - known as
concerns - that need to be addressed
• The architect
• Identifies and refines stakeholders’ requirements
• Develops views of the architecture that address those
concerns
• Shows trade-offs that are necessary between
conflicting concerns
• Without the Enterprise Architecture it is unlikely that all the
concerns and requirements will be considered and met

38. 38
18
What is an Architecture Framework?
Framework: A structure for
content or process that can be
used as a tool to structure
thinking, ensuring consistency
and completeness.
Architecture Framework: A
conceptual structure used to
develop, implement and sustain
an architecture.
May be used to deliver a broad range of
architectures
It should contain
A method for designing a system in terms of a
set of building blocks
A method for showing how the building blocks
fit together
A common vocabulary
A content framework
1

39. 39
18
Introducing The TOGAF Architecture Framework
Developed by the collaborative efforts of 300
member companies of The Open Group
Architecture Forum
Leading IT customers
Leading IT vendors
Leading service providers
Allows architectures to be developed that are
Consistent
Reflect the needs of stakeholders
Employ best practices
De-risk the architecture development process
Provides a platform for adding value
Enables organizations to build workable and economic solutions
to meet their business issues and needs
The TOGAF® Framework is vendor neutral and open systems based
1

40. 40
18
93 94 96 02 03
Demand
Customer
members
demand
architecture
standards …
Donate
DoD
Information
Systems
Agency
(DISA)
donate
TAFIM as
Published
The TOGAF
Specification
first
published.
TOGAF
7
Technical
Edition
TOGAF
8
Enterprise
Edition
06 09 11 17
TOGAF 8.1.1
Enterprise
Edition
TOGAF
9
Enterprise
Edition
TOGAF 9.1
Enterprise
Edition
TOGAF 9.2
Enterprise
Edition
Evolution of TOGAF Framework

41. Introducing
TOGAF Version
9.2

42. 42
18
Design Objectives of
TOGAF Version 9
•Evolution not Revolution
• No change to the top level process
• Individual features from TOGAF 9 can be
adopted into a “TOGAF 8 environment”
•Stronger Link to Business
• Strategic planning
• Deployment decisions
•Easier to Use
• A more formal meta-model
• More guidelines, techniques and templates
• Improved structure

43. What’s New in
TOGAF Version 9
• Architecture Partitioning
• Content Framework and
Metamodel
• Capability Based Planning
• Business Transformation
Readiness
• Architecture Repository
• Stakeholder Management
• Using TOGAF to develop
Security Architectures
• Using TOGAF to develop
Service Oriented
Architectures
1

44. 44
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
1

45. 45
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ High-level introduction to the
key concepts of enterprise
architecture, the TOGAF
approach
✓ Definitions of terms
✓ Release notes
1

46. 46
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Core of The TOGAF Framework
✓ Step-by-step approach to
developing an Enterprise
Architecture
1

47. 47
18
The Structure of the
TOGAF 9.1
Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and Techniques
• Architecture Content Framework
• Enterprise Continuum and Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Collections of guidelines and
techniques that support
application of the TOGAF ADM
1

48. 48
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Structured metamodel for
architectural artifacts
✓ Re-usable architecture building
blocks
✓ Typical architecture deliverables
1

49. 49
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Taxonomies and tools to categorize
and store the outputs of an
Enterprise Architecture activity
1

50. 50
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Taxonomies and tools to categorize
and store the outputs of an
Enterprise Architecture activity
1

51. 51
18
The Structure of the
TOGAF 9.1 Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and
Techniques
• Architecture Content
Framework
• Enterprise Continuum and
Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ Selection of architecture reference
models, including
TOGAF Technical Reference
Model
Integrated Information
Infrastructure Reference Model
1

52. 52
18
The Structure of the
TOGAF 9.1
Specification
• Introduction
• Architecture Development
Method
• ADM Guidelines and Techniques
• Architecture Content Framework
• Enterprise Continuum and Tools
• TOGAF Reference Models
• Architecture Capability
Framework
✓ How to establish and operate an
architecture function within an
enterprise
Organizations
Processes
Skills
Roles
Responsibilities
1

53. 53
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Application + Data
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together
1

54. 54
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Application + Data
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together
➢Documents the
▪ Business goals
▪ Business strategy
▪ Organization of the enterprise
▪ Key business processes
▪ Product and/or service strategy
➢Guides the development of the
Information Systems and Technology
Architecture(s)
➢Must be accurately documented to
ensure it is shared and understood by the
Enterprise and IT architects
➢May be constrained by the Information
and Technical Architectures

55. 55
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Application + Data
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together
➢Defines
▪ Individual application services to be deployed
▪ The interaction between these applications
▪ The relationship between the applications and
the core business processes
➢Guides the Data Architecture and the
Technology Architecture
▪ Applications usually consume services of the
Technology Architecture
▪ Technology Architecture will need to support the
integration of different application architectures

56. 56
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Application + Data
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together
➢Describes
▪ Structure of the logical data
(information) assets
▪ Structure of the physical data
assets
▪ Data management resources
➢Guides the Application
Architecture and the Technology
Architecture
▪ Data intertwined with the
Applications Architecture
▪ Technology Architecture will need
to support the storage, access,
data movement and location
requirements

57. 57
18
Domains of Architecture
Business Architecture
How the business is organised to
meet its objectives
Application + Data
Architecture
How Information Systems supports
the objectives of the business
Technology Architecture
How the technology fits together
➢Defines
▪ Hardware and Network Infrastructure
▪ Software infrastructure
▪ Middleware
➢Supports the requirements of the Business
and Information Systems Architectures
▪ The Technology Architecture may impose
constraints and requirements on the Business
and Information Systems Architectures

58. 58
18
Enterprise
Architecture
and the
TOGAF®
Framework
•This module has set the scene for
Enterprise Architecture and
introduced The Open Group
Architecture Framework
• What is Enterprise
Architecture?
• Why is it important?
• Domains of Architecture
• A brief history of The TOGAF®
Framework
• The structure of the TOGAF 9.1
Specification

59. 59
18
Learning
Outcomes
•Describe what an enterprise is
•Explain the purpose of having an enterprise
architecture
•List the business benefits of having an enterprise
architecture
•Define what an architecture framework is
•Explain why TOGAF is suitable as a framework for
enterprise architecture
•Describe the structure of TOGAF and briefly
explain the contents of each part
•Briefly explain what TOGAF is
•Explain what architecture is in the context of
TOGAF
•List the different types of architecture that TOGAF
deals with

61. TOGAF 9.2
Training
TOGAF 9 Core
Concepts
This module introduces the core concepts within The TOGAF Framework,
including the Architecture Development Method and the Content Framework
B2BTOGAF03
0

62. 62
18
The
Components
of the TOGAF
9 Framework
1

63. 63
18
Architecture Development Method (ADM)
The core of The TOGAF Framework.
A step-by-step approach to develop and use an
enterprise architecture.
Source: TOGAF Version 9
1

64. 64
18
The TOGAF
Architecture
Development Method
•The ADM comprises a series of linked phases
which enable
• the full life-cycle management of an
Enterprise Architecture
•from planning to operational deployment
and change
*This is the standard ADM graphic in
the TOGAF 9.1 specification
1

65. 65
18
Preliminary Phase
Objectives:
•Prepare the enterprise for successful Enterprise Architecture
•Determine desired Architecture Capability
•Review organizational context for EA
•Identify and scope affected enterprise organizations
•Identify established frameworks, methods and processes
•Establish Capability Maturity target
•Establish Architecture Capability
•Define and establish Organizational Model for Enterprise Architecture
•Define and establish process and resources for architecture governance
•Select and implement tools
•Define architecture principles
1

66. 66
18
Architecture Vision
Objectives:
•Initiate a cycle of the ADM
•Develop a high-level aspirational vision of the
capabilities and business value to be delivered as a
result of the proposed enterprise architecture
•Obtain approval for a Statement of Architecture
Work that defines a program of works to develop and
deploy the architecture outlined in the Architecture
Vision
1

67. 67
18
Business Architecture
Objectives:
•Develop Target Business Architecture
•How the enterprise needs to operate
•To achieve business goals
•To respond to strategic drivers
•Set out in the Architecture Vision
•Addresses Statement of Architecture Work and Stakeholder Concerns
•Identify candidate Architecture Roadmap components
•Based on gaps between Baseline and Target Business Architectures
1

68. 68
18
Information System
Architecture
Objectives:
•Develop Target Information Systems (Data and Application)
Architectures
•Enable the Business Architecture and Architecture Vision
•Addresses Statement of Architecture Work and Stakeholder
Concerns
•Identify candidate Architecture Roadmap components
•Based on gaps between Baseline and Target Information
Systems Architectures
1

69. 69
18
Technology Architecture
Objectives:
•Develop Target Technology Architecture
•Enables the logical and physical application and data
components and Architecture Vision
•Addresses Statement of Architecture Work and Stakeholder
Concerns
•Identify candidate Architecture Roadmap components
•Based on gaps between Baseline and Technology Architectures
1

70. 70
18
Opportunities and
Solutions
Objectives:
•Generate initial complete version of the Architecture Roadmap
•Based upon gap analysis and candidate Architecture Roadmap
components
•From Phases B, C, and D
•Determine whether an incremental approach is required
•If so identify Transition Architectures
•That will deliver continuous business value
1

71. 71
18
Migration Planning
Objectives:
•Finalize Architecture Roadmap and supporting
Implementation and Migration Plan
•Ensure that Implementation and Migration Plan is
coordinated with enterprise’s approach to managing and
implementing change in overall change portfolio
•Ensure that business value and cost of work packages
and Transition Architectures is understood by key
stakeholders
1

72. 72
18
Implementation
Governance
Objectives:
• Ensure conformance with Target Architecture by
implementation projects
• Perform appropriate Architecture Governance
functions for
• The solution
• Any implementation-driven Change Requests
1

73. 73
18
Architecture Change
Management
•Objectives:
• Ensure that Architecture lifecycle is maintained
• Ensure that Architecture Governance Framework is
executed
• Ensure that Enterprise Architecture Capability
meets current requirements
1

74. 74
18
Requirements
Management
Objectives:
•Ensure that Requirements Management process is
sustained and operates for all relevant ADM phases
•Manage architecture requirements identified during
any execution of the ADM cycle or a phase
•Ensure that relevant architecture requirements are
available for use by each phase as phase is executed
During each phase, work is validated against the
current business requirements that motivate the
development
1

75. 75
18
Deliverables,
Artifacts and
Building
Blocks
1

76. 76
18
Deliverables,
Artifacts and
Building
Blocks
Deliverable – A work product that is contractually specified,
formally reviewed, agreed and signed off by stakeholders
1

77. 77
18
Deliverables,
Artifacts and
Building
Blocks
Deliverable – A work product that is contractually specified, formally
reviewed, agreed and signed off by stakeholders
Artifact – Architectural work product that describes an aspect of the
architecture
1

78. 78
18
Deliverables,
Artifacts and
Building
Blocks
Building Block – A (potentially
re-usable) component of
business, IT or architectural
capability
Architecture Building
Blocks (ABBs) Describe
required capability and
shape specification of
solutions
Solution Building Blocks
(SBBs) Represent
components that will be
used to implement required
capability.
1

79. 79
18
Deliverables,
Artifacts and
Building
Blocks
1

80. 80
18
TOGAF Deliverables,
Artifacts and Building
Blocks
• Deliverables: The decisions and information generated
and consumed by each Phase is passed between the
Phases as named deliverables
EXAMPLE OF DELIVERABLE: Statement of Architecture Work.
• Building Blocks: Specifications of Building Blocks that
define the specific architecture are collated in the
Architecture Definition Document.
EXAMPLE OF BUILDING BLOCKS: Target Technology Architecture
V1.0
• Artifacts: architectural work products that describe an
aspect of the architecture
EXAMPLE OF ARTIFACTS: Requirement Specification Document
A
B
C
1

81. 81
18
Deliverable Numbering Convention
Version 0.1
A high-level outline of the architecture is in
place
Version 1.0
A formally reviewed, detailed architecture
1

82. 82
18
The Enterprise Continuum
1

83. 83
18
Architecture Repository
1

84. 84
18
Defines a set of entities and relations between them that allow architectural
concepts to be managed in a way that supports consistency, completeness and
traceability
TOGAF Content Framework and Metamodel
The TOGAF Content Framework
1

85. 85
18
TOGAF Content Metamodel - Relationships
1

86. 86
18
Establishing and Maintaining an Enterprise Architecture Capability
1

87. 87
18
Establishing and Maintaining an Enterprise Architecture Capability
Enterprise Architecture Practice establishes
capabilities for a varied number of areas in
the Entperise, such as:
➢Resource Management
➢Performance Management
➢Financial Management
➢Risk Management
➢Service Management
➢Etc.
By recognizing gaps on Enterpise
Capabilities, an Enterprise Architecture
Capability Framework, supports long term
planning initiatives.

88. 88
18
TOGAF Technical
Reference Model
•The objective of a Reference Model is
• To facilitate communication
• To enable systems to be analyzed in
a consistent manner
•The TOGAF Framework contains 2
reference models
• Technical Reference Model
• Integrated Information
Infrastructure Reference Model (III-
RM)
1

89. 89
18
The
Integrated
Information
Infrastructur
e Reference
Model
1

90. 90
18
An
Enterprise’s
Adaption of
The TOGAF
Framework
•It is expected that enterprises will
tailor and adapt The TOGAF
Framework capabilities to meet
specific needs
•
•For example
• To reflect state of maturity of
Architecture in enterprise
• To integrate with other
architecture frameworks
• already in use
• mandated by the enterprise
or its partners
1

91. 91
18
TOGAF and Others
TOGA
F
COBIT
ITIL
PMI,PRINCE
, DSDMI
SCRUM,
LEAN
DODAF
FEA
MDA
ETOM
Framework
s
Best practices
Method
s
1

92. 92
18
TOGAF Core
Concepts
•Questions?
•This module introduced the core concepts
within The TOGAF Framework
• The Architecture Development Method
• Content Framework and Metamodel
• Architecture Continuum and Repository
• Enterprise Architecture Capability
Framework
• Reference Models
• Adapting The TOGAF Framework

93. 93
18
Learning
Outcomes
• Define and explain the core concepts of TOGAF
• Understand the ADM cycle, its phases and the
objectives of each phase
• Briefly describe the key points of the ADM cycle
• List the main reasons you may need to adapt the
ADM
• Briefly explain the role of architecture deliverables
across the ADM cycle
• Describe the versioning convention for deliverables
used in Phases A to D
• Briefly describe the relationship between the ADM
and other parts of TOGAF (Enterprise Continuum,
Architecture Repository, Foundation Architecture,
Supporting Guidelines and Techniques)

94. 94
18
Transition from TOGAF 9 to TOGAF 9.1
“Objectives” sections of
phases reworked to focus on
actual objectives (rather than
techniques or a list of steps)
Corrections have been made
to metamodel diagrams and
aspects of the metamodel
The term “artifact” has been
clarified and made consistent
with “viewpoint”
The diagram of the
Architecture Repository has
been changed to clarify the
relationship to the Enterprise
Repository
The Building Block example
has been removed

96. TOGAF 9.2
Training
Content Framework and
Metamodel
This module introduces the TOGAF Content Framework and Metamodel which
provides a framework for understanding the major TOGAF artifacts and
relationships between them
B2BTOGAF04
0

97. 97
18
The Components of TOGAF 9
TOGAF Capability
Framework
TOGAF ADM and
Content Framework
TOGAF Enterprise
Continuum & Tools
Architecture Development Method
(Part II)
ADM Guidelines and Techniques
(Part III)
Enterprise Continuum & Tools
(Part V)
TOGAF Reference Models (Part
VI)
Architecture Content
Framework (Part IV)
Architecture Capability
Framework
(Part VII)

98. 98
18
Deliverables, Artifacts and Building Blocks

99. 99
18
Building Blocks
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.

100. 100
18
Building Blocks
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.
• Instances of architectural entities, such
as
• Organisation,
• Actor, Role
• Function
• Business Service
• Data Entity
• Logical Application Component
• Logical Technology Component
• Can be defined at various levels of detail

101. 101
18
Building Blocks
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.
• Instances of architectural entities, such
as
• Organisation,
• Actor, Role
• Function
• Business Service
• Data Entity
• Logical Application Component
• Logical Technology Component
• Can be defined at various levels of detail

102. 102
18
Building Blocks
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.
➢Architecture Building Blocks (ABBs)
▪ Describe required capability
▪ Shape the specification of SBBs
➢Solution Building Blocks (SBBs)
▪ Candidate solution which conforms to
the specification of an ABB

103. 103
18
Artifacts Artifact – A granular architectural work
product related to a specific viewpoint

104. 104
18
Artifacts Artifact – A granular architectural work
product related to a specific viewpoint
➢Artifacts form the content of the Architecture Landscape
➢An architectural deliverable may contain many artifacts
➢ Examples
▪ Business Interaction Matrix
▪ Use-case Diagram
▪ Requirements Catalog

105. 105
18
Enterprise Architecture Artifacts
Diagrams
Matrices
Catalogs

106. 106
18
Catalog
➢ List of building blocks

107. 107
18
Matrix
► Grid that shows relationships between two or
more model entities
► Used to represent relationships that are difficult to
represent graphically

108. 108
18
Diagram
► Renders architecture in a graphical format
► Allows stakeholders to retrieve information
► Help architects populate architecture content

109. 109
18
Interactions between Building Blocks, Artifacts
and Stakeholders

110. 110
18
Deliverables
SLIDE 110 of 63
Deliverable – A work product that is
contractually specified, formally
reviewed, agreed and signed off by
stakeholders

111. 111
18
Deliverables
SLIDE 111 of 63
• Deliverables represent the output of projects
• Typically archived at completion of a project, or
• Transitioned into an Architecture Repository
Deliverable – A work product that is
contractually specified, formally
reviewed, agreed and signed off by
stakeholders

112. 112
18
SLIDE 112 of 63
An Architecture Definition Document
► A deliverable that documents an architecture description
► Contains
► Artifacts - views of building blocks relevant to the architecture
► Other important related information.

113. 113
18
TOGAF Content
Framework and
Metamodel
• A framework for classifying ALL
aspects of the Enterprise
Architecture activity
• A more detailed model of the
“things” in the enterprise that are
being modelled and the
relationships between them

114. 114
18
The Content Framework and Metamodel
► The content framework is
intended to
■ Provide a detailed model of
architectural work products
■ Drive greater consistency in the
outputs that are created when
following ADM
■ Provide a comprehensive
checklist of architecture outputs
that could be created and so
■ Reduce the risk of gaps within the
final architecture deliverable set
■ Help an enterprise mandate
standard architectural concepts,
terms, and deliverables
► The content metamodel defines
a set of entities and relationships
that allows architectural
concepts to be
■ Captured
■ Stored
■ Filtered
■ Queried
■ Represented
► In a way that supports
■ Consistency
■ Completeness
■ Traceability

115. 115
18
TOGAF Content Framework Overview
SLIDE 115 of 63
► Divided into five broad areas, centered on the architecture domains

116. 116
18
TOGAF Content Framework Overview
► Divided into five broad areas, centered on the architecture domains
Contents capture the context
for formal architecture
models including principles,
strategic context and
requirements

117. 117
18
TOGAF Content Framework Overview
► Divided into five broad areas, centered on the architecture domains
Contents capture the
architecture models of business
operation including factors that
➢ motivate the enterprise,
➢ how the organization is
structured
➢ what functional capabilities
the organization possesses

118. 118
18
TOGAF Content Framework Overview
► Divided into five broad areas, centered on the architecture domains
Contents capture the
architecture models of
information systems defined
using the ADM domains of
➢ Applications
➢ Data

119. 119
18
TOGAF Content Framework Overview
► Divided into five broad areas, centered on the architecture domains
Contents capture procured
technology assets that are used
to implement and realize
information systems solutions

120. 120
18
TOGAF Content Framework Overview
► Divided into five broad areas, centered on the architecture domains
Contents capture roadmaps showing the
transition between architecture states
and binding statements that are used to
steer and govern an implementation of
the architecture.

121. 121
18
Mapping
Artifacts to
the TOGAF
ADM -
Preliminary
Phase
1
➢Principles Catalog
>

122. 122
18
Mapping
Artifacts to
the TOGAF
ADM -
Architecture
Vision
1
➢ Stakeholder Map Matrix
➢ Value Chain Diagram
➢ Solution Concept Diagram
>

123. 123
18
Mapping
Artifacts to the
TOGAF ADM -
Business
Architecture
1
➢ Organization/Actor Catalog
➢ Driver/Goal/Objective Catalog
➢ Role Catalog
➢ Business Service/Function Catalog
➢ Location Catalog
➢ Process/Event/Control/Product Catalog
➢ Business Interaction Matrix
➢ Actor/Role Matrix
➢ Business Footprint Diagram
➢ Business Service/Information Diagram
➢ Functional Decomposition Diagram
➢ Product Lifecycle Diagram
➢ Goal/Objective/Service Diagram
➢ Use-Case Diagram
➢ Organization Decomposition Diagram
➢ Process Flow Diagram
➢ Event Diagram
>

124. 124
18
Mapping
Artifacts to the
TOGAF ADM -
Information
Systems
Architecture
1
➢ Data Entity/Data Component Catalog
➢ Data Entity/Business Function Matrix
➢ Application /Data Matrix
➢ Business Service/Information Matrix
➢ Conceptual Data Diagram
➢ Logical Data Diagram
➢ Data Dissemination Diagram
➢ Data Lifecycle Diagram
➢ Data Security Diagram
➢ Data Migration Diagram
>

125. 125
18
Mapping
Artifacts to the
TOGAF ADM -
Information
Systems
Architecture
1
➢ Application Portfolio Catalog
➢ Interface Catalog
➢ Application/Organization Matrix
➢ Role/System Matrix
➢ Application/Function Matrix
➢ Application Interaction Matrix
➢ Application Communication Diagram
➢ Application and End User Location
Diagram
➢ Enterprise Manageability Diagram
➢ Process/Application Realization Diagram
➢ Application Migration Diagram
➢ Software Distribution Diagram
➢ Software Engineering Diagram
➢ System Use-Case Diagram
>

126. 126
18
Mapping
Artifacts to the
TOGAF ADM -
Technology
Architecture
1
➢ Technology Standards Catalog
➢ Technology Portfolio Catalog
➢ Application/Technology Matrix
➢ Environment and Locations Diagram
➢ Platform Decomposition Diagram
➢ Processing Diagram
>

127. 127
18
Mapping
Artifacts to the
TOGAF ADM -
Opportunities
and Solutions
1
➢ Project Context Diagram
➢ Benefits Diagram
>

128. 128
18
Mapping
Artifacts to the
TOGAF ADM -
Requirements
Management
1
➢ Requirements Catalog
>

129. 129
18
Core Content
Metamodel and
Internal
Structure
Categories of
Building Blocks
that may exist
2

130. 130
18
Core and Extension Content
The TOGAF Framework provides an open
standard for architecture that is applicable in
many scenarios and situations, including
A fully featured enterprise architecture meta model for content
The ability to avoid carrying out unnecessary activities by
supporting tailoring
The metamodel must provide
A basic model with the minimum feature set
Optional extensions for use during tailoring
2

131. 131
18
Core and Extension Content
Core
Provides minimum architectural content to
support modeling and traceability across
artifacts
Extensions
Contain additional concepts to support
• More specific modeling
• More in-depth modeling
Logically cluster extension artifacts,
allowing focus in areas of specific interest
Should be selected during the Preliminary
phase
Are only a suggestion ... further tailoring
may be carried out to suit specific needs
2

132. 132
18
Core and Extension Content
2

133. 133
18
Core and
Extension
Entities
White entities are
Core Entities
Other colours are
Extension Entities
2

134. 134
18
Core Entities and Relationships
2

135. 135
18
Core and Extension Entities and Relationships
2

136. 136
18
Core and Extension Entities and Relationships
Defines a set of entities and relations between
them that allow architectural concepts to be
managed in a way that supports consistency,
completeness and traceability
2

137. 137
18
Core Entities Defined
Organization Unit: A self-
contained unit of resources
with goals, objectives, and
measures. Organization
units may include external
parties and business
partner organizations.
2

138. 138
18
Core Entities Defined
Actor:
A person, organization,
or system that has a role
that initiates or interacts
with activities.
Organization Unit: A self-
contained unit of resources
with goals, objectives, and
measures. Organization
units may include external
parties and business
partner organizations.
2

139. 139
18
Core Entities Defined
Actor:
A person, organization,
or system that has a role
that initiates or interacts
with activities.
Role:
The usual or expected
function of an actor, or
the part somebody or
something plays in a
particular action or
event.
Organization Unit: A self-
contained unit of resources
with goals, objectives, and
measures. Organization
units may include external
parties and business
partner organizations.
2

140. 140
18
Core Entities Defined
Function:
Delivers business
capabilities closely
aligned to an
organization, but not
explicitly governed by the
organization.
2

141. 141
18
Core Entities Defined
Function:
Delivers business
capabilities closely
aligned to an
organization, but not
explicitly governed by the
organization.
Business Service:
Supports business capabilities
through an explicitly defined
interface and is explicitly governed
by an organization.
2

142. 142
18
Core Entities Defined
Function:
Delivers business
capabilities closely
aligned to an
organization, but not
explicitly governed by the
organization.
Business Service:
Supports business capabilities
through an explicitly defined
interface and is explicitly governed
by an organization.
Process:
Describes the flow of
interactions between functions
and business service. The
activities undertaken by the
function to deliver the business
service
2

143. 143
18
Core Entities Defined
Data Entity:
An encapsulation of data that is
recognized by a business domain
expert as a discrete concept. Data
entities can be tied to applications,
repositories, and services and may
be structured according to
implementation considerations.
2

144. 144
18
Core Entities Defined
Data Entity:
An encapsulation of data that is
recognized by a business domain
expert as a discrete concept. Data
entities can be tied to applications,
repositories, and services and may
be structured according to
implementation considerations.
Logical Application Component:
An encapsulation of application
functionality that is independent of
a particular implementation.
2

145. 145
18
Core Entities Defined
Physical Technology Component:
A specific technology infrastructure
product or technology
infrastructure product instance. For
example, a particular product
version of a Commercial Off-The-
Shelf (COTS) solution, or a specific
brand and version of server.
2

146. 146
18
Core Entities Defined
Physical Technology Component:
A specific technology infrastructure
product or technology
infrastructure product instance. For
example, a particular product
version of a Commercial Off-The-
Shelf (COTS) solution, or a specific
brand and version of server.
Platform Service: A technical
capability required to provide
enabling infrastructure that
supports the delivery of
applications.
2

147. 147
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
2

148. 148
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
A process is A flow of interactions between functions and services
Cannot be physically deployed
Should describe the flow of execution for a function and therefore the
deployment of a process is through the function it supports
For example: an application implements a function this is part of a process
not an application implements a process
2

149. 149
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
The term
‘‘function’’
describes a unit of business capability at all levels of granularity,
encapsulates terms such as value chain, process area, capability, business
function, etc.
Any bounded unit
of business function
should be described
as a service
2

150. 150
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
A business service
operates as a
boundary for one
or more functions
The granularity is
dependent on the focus
and emphasis of the
business
as reflected by its drivers,
goals, and objectives
2

151. 151
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
Business services may
be realized by business
activity that does not
relate to IT, or may be
supported by IT
Business services that
are supported by IT are
deployed onto
application components
2

152. 152
18
Key Relationship Concepts
Process should
normally be used to
describe flow
Function describes
units of business
capability at all
levels of granularity
Business services
Support organizational
objectives
Defined at a level of
granularity consistent with
the level of governance
needed
Business services
are deployed onto
application
components
Application
components are
deployed onto
technology
components
Application components can be
hierarchically decomposed and
may support one or more
business services.
It is possible for a business service
to be supported by multiple
application components, but this is
problematic from a governance
standpoint
business services that are too
coarse-grained
application components that are
too fine-grained
2

153. 153
18
The Role of the
Content Framework
•The Content Framework provides a
structure to bring everything together
• Core Artifacts
• Extension Artifacts

154. 154
18
And it looks like.......
SLIDE 154 of 63

155. 155
18
The Content
Framework
with other
frameworks
• You can use The TOGAF Framework
stand-alone for architecture within an
enterprise
• Or you can opt to use another
framework (such as DODAF, ACORD,
Zachman, TMF Frameworks) in
conjunction with The TOGAF Framework
• In which case, the content framework
provides a useful reference and starting
point for mapping TOGAF content to
other frameworks
1

156. 156
18
Content
Framework and
Metamodel
•Questions?
•This module introduced the TOGAF
Content Framework and Metamodel
• Metamodel Entities
• Catalogs, Matrices,
Diagrams
• Core and Extension Content
• Metamodel Relationships

157. 157
18
Learning
Outcomes
•Define what a building block is, and explain what a good building block is
•Explain the distinction between Architecture Building Blocks and Solution
Building Blocks
•Explain the purpose of the architecture content framework
•Describe the main components of the content metamodel
•Describe the relationship between the content framework and the TOGAF
ADM
•Describe the core metamodel concepts
•Explain the purpose of dividing the metamodel into core and extensions
•Describe the key concepts related to the core metamodel entities
•

159. TOGAF 9.2
Training
Enterprise Continuum and Archtitecture
Repository
This module describes the Architecture Repository, a system that manages all
of the Architecture assets of an enterprise, and the Enterprise Continuum, a
method for classifying architecture and solution artifacts
B2BTOGAF05
0

160. 160
18
Enterprise Continuum
A categorization mechanism useful 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.
Source: TOGAF Version 9
1

161. 161
18
The Enterprise Continuum
Any Architecture is context-
specific
To individual customers
To industries
To sub-systems
To products and services
A view of the Architecture
Repository
Methods for classifying architecture and
solution artifacts
Internal and external to the Architecture
Repository
From generic Foundation Architecture to
Organization-Specific Architectures
The Enterprise Continuum
provides a consistent language to
communicate the differences
between architectures
Aid to organizing re-usable architecture and
solution assets
1

162. 162
18
The Enterprise Continuum
1

163. 163
18
The Enterprise Continuum
Classifies assets
related to the
context of the
enterprise
architecture
1

164. 164
18
The Enterprise Continuum
Contextual assets may include
➢ Policies
➢ Standards
➢ Strategic Initiatives
➢ Organizational Standards
➢ Enterprise Level Capabilities
1

165. 165
18
The Enterprise Continuum
Architecture Continuum provides a
consistent way to define and
understand the building blocks with
➢ Generic Rules
➢ Representations
➢ Relationships
These aid traceability and integrity of
the architectures
1

166. 166
18
The Enterprise Continuum
Solutions Continuum
provides a consistent
way to describe and
understand the
implementation of
assets and building
blocks as a result of
➢ Agreements with
customers and
business partners
➢ Commonalities and
differences between
products, systems
and services
1

167. 167
18
The Enterprise Continuum
Deployed Solutions are
instances of the
Solutions within a
specific context
1

168. 168
18
Architecture Continuum
• The TOGAF Framework identifies
the following four types of
architecture to indicate the
range of different types of
architecture that may be
developed at different points in
the continuum:
• Foundation Architectures
• Common System
Architectures
• Industry Architectures
• Organisation Architectures
• These are not fixed stages in a
process
• Apply across all Architecture
domains – business, data,
application and technology.
1

169. 169
18
Foundation Architectures
► Architectures of generic components, inter-relationships, principles and
guidelines which form the basic foundation for the architectures
► On and from which more specific architectures and architectural components
can be built
► The TOGAF ADM is a process that supports specialization of such Foundation
Architectures in order to create organization-specific models
► The TOGAF Technical Reference Model (TRM) describes a fundamental
architecture upon which more specific architectures can be based
1

170. 170
18
Foundation
Architecture
Characteristics
• Reflects generic components of the
enterprise architecture including their
• Inter-relationships
• Principles
• Guidelines
• Which provide a foundation on which
more specific architectures can be built
• For example
• Defines technology standards for
implementing the enterprise
architecture building blocks
1

171. 171
18
Common Systems Architectures
► Guide the selection and integration of specific services from the Foundation
Architecture
► To create an architecture useful for building common and reusable solutions
across a wide number of relevant domains Common Systems Architectures.
The TOGAF Integrated Information Infrastructure Reference Model (III-RM) is a
REFERENCE MODEL that supports describing a Common Systems Architecture IN THE
APPLICATION DOMAIN
1

172. 172
18
Common System
Architecture
Characteristics
• Each is
• Incomplete in terms of overall information
system functionality
• Complete in terms of a particular problem
domain
• Examples
• Security Architecture
• Management Architecture
• Network Architecture
• E-Mail Architecture
1
• Solutions implementing the common systems architecture
constitute reusable building blocks for the creation of functionally
to complete information systems

173. 173
18
Industry Architectures
► Guide integration of common systems components with industry-specific
components, and
► Guide creation of industry solutions for targeted user problems within a
particular industry
► For example: telecommunications industry, retail industry, banking industry
1

174. 174
18
Industry
Architecture
Characteristics
• Reflect requirements and standards
specific to a vertical industry
• Define building blocks specific to a generic
problem domain
• Contain industry-specific models
• Logical data models, Process models,
Applications, Business rules
1
• An industry-specific example is a model representing the
business functions and processes specific to a particular
vertical industry:
• TMF for Telecoms Industry, Energistics Data Model,
ACORD Standards.

175. 175
18
Organization-Specific Architectures
► Describe and guide the final deployment of solution components for
► A particular enterprise
► Extended network of connected enterprises
► May be a continuum of Organization Architectures needed to effectively cover
the organization’s requirements
► May result in several more detailed Organizations Architectures for specific
entities within the global enterprise
1

176. 176
18
Organization-
Specific Architecture
Characteristics
• Provides a means to communicate and manage
business operations across all four architectural
domains
• Defines building blocks specific to a particular
enterprise
• Contains organization specific business models,
data, applications and technologies
• Provides a means to encourage implementation of
solutions to meet business needs
• Provides an evolutionary path to support growth
and new business needs
• Provides criteria to measure and select
• Products
• Solutions
• Services
1

177. 177
18
Examples of the Continuum of Solutions
Foundation
Architecture
Common System
Architecture
Industry
Architecture
Organization
Specific
Architecture
• TOGAF TRM
• Industry
Standards
Information
Bases
• Management
Architecture
• Security
Architecture
• Network
Architecture
• Email Architecture
• TMF for Telecoms
Industry
• Energistics Data
Model
• Insurance ACORD
Reference
Architecture.
• Solutions
that will only
work for your
Organization
1

178. 178
18
Linking
Architecture
and
Solutions
Continuums
•Guidance, Direction
and Support that help
improve productivity
through leverage of
consistent architectures
and solutions
1

179. 179
18
Solutions Continuum
► Solutions represent the detailed specification and construction of the architectures
► Solution Architectures are populated with reference building blocks – purchased or
developed for the enterprise architecture
► Moving from left to right is focused on building solutions value
► Moving from right to left is focused on addressing enterprise needs
Common Systems
Solutions
Industry
Solution
s
Organization-Specific
Solutions
Foundation
Solutions
1

180. 180
18
Foundation Solutions
► Highly generic concepts, tools, products, services and solution components that are
fundamental providers of capabilities
► Services include professional services
■ Training and consulting services - ensure maximum investment value from solutions in shortest
time
■ Support services - ensure maximum possible value from solutions e.g. Help Desk
■ Includes
■ Programming languages
■ Operating systems
■ Foundational data structures (such as EDIFACT)
■ Generic approaches to organizational structuring
■ Structures for organizing IT operations (such as ITIL)
1

181. 181
18
Common Systems Solutions
► Implementation of a Common System Architecture
■ A set of products and services
■ May be certified or branded
► Represent collections of common requirements and capabilities
► System Solutions provide organizations with operating environments specific to operational and
informational needs
■ High Availability Transaction Processing
■ Scaleable Data Warehousing systems
■ Enterprise Management System product
■ Security System product
■ Software as a Service
■ Business process Outsourcing
1

182. 182
18
Industry Solutions
► Implementation of an Industry Architecture
■ Re-usable package of products and services specific to an industry
► Made up of System Solution and/or Products and Services
■ Augmented with industry specific components, examples
● Physical database schema
● Industry specific point-of-service device
► Industry-specific, ready to be tailored to the requirements of an individual
enterprise
1

183. 183
18
Organization-Specific Solutions
► Implementation of the Enterprise Architecture that provides required business
functions
► Unique content to meet varying specific needs of people and processes of
organizations
► Supports specific Service level Agreements (SLAs) and Key operating parameters and
quality metrics
► Key link between architecture, development and operations personnel for
agreements
► Primary purpose of connecting Architecture Continuum to Solutions Continuum is to
build Organization Solutions from
■ Industry Solutions
■ Systems Solutions
■ Products and Services
1

184. 184
18
Examples of the Continuum of Solutions
Foundation
Solutions
Common System
Solutions
Industry
Solutions
Organization
Specific Solutions
• Desktop Products
• IT Services
• Management
Solutions, Email,
Security
• Solutions that can
be used to build
multiple
applications, or to
a Common use,
such as
Integration
platforms.
• Telecom Oriented
Products:
Mediation
Platforms, ERPs for
Telecoms, etc.
• Insurance
Oriented Solutions:
Policy Manaement
Solutions, ERPs for
Insurance, etc.
• Solutions
that will only
work for your
Organization

185. 185
18
The Enterprise
Continuum and the
ADM
•The ADM describes the process of developing an enterprise-
specific architecture and solution(s)
• By adopting and adapting generic architecture and
solutions
•Every phase of the ADM
• Uses the Enterprise Continuum as a structure for
identification of useful, reusable, architecture assets
• Encourages the development of re-usable building
blocks
• Promotes the use of the Enterprise Continuum as a
structure for publishing newly developed building
blocks for future re-use

186. Where to apply Enterprise
Continuum
• Foundation Architecture to govern all their systems
• Common Systems Architectures to govern major shared
infrastructure systems
• Industry Architectures to govern the way their systems must
behave within their industry and others
• Any business unit or department within the enterprise may
need its own individual Organization – Specific Architecture to
govern the Systems within their unit
• The TOGAF Enterprise Continuum is a tool that helps to
determine and generate any type of architecture required to
support the Enterprise Architecture
• Used by the ADM to enable re-use of architecture assets to
encourage efficiency and effectiveness of the organization as a
whole.

187. 187
18
Architecture Repository
An architectural content storage
capability that manages all of the
architectural information of an
enterprise, including
Data and process models
Other enterprise information.
Allows an enterprise to distinguish
between different types of
architectural assets that exist at
different levels of abstraction in
the organization
One part of the wider Enterprise
Repository, which provides the
capability to link architectural
assets to components of other
repositories
Design
Deployment
Service Management
1

188. 188
18
1/2
Architectural Information in the Repository
➢ There are six classes of
architectural information
held within the
Architecture Repository
▪ Architecture Metamodel
▪ Architecture Capability
▪ Architecture Landscape
▪ Standards Information Base
▪ Reference Library
▪ Governance Log
2
1

189. 189
18
1/2
Architecture Metamodel
➢ The Architecture Metamodel
describes the organizationally
tailored application of an
architecture framework,
including a method for
architecture development
and a content framework and
metamodel for architecture
content
2
1

190. 190
18
1/2
Architecture Landscape
➢ The Architecture Landscape
shows an architectural view
of the building blocks that
comprise the enterprise’s
architectures at a particular
point in time
2
1

191. 191
18
1/2
Architecture Capability
➢ The Architecture Capability
defines the parameters,
structures, and processes that
support governance of the
Architecture Repository
2
1

192. 192
18
1/2
Reference Library
➢ The Reference Library
provides
▪ Guidelines
▪ Templates
▪ Patterns
▪ Other forms of reference
material
➢ Can be leveraged in order to
accelerate the creation of
new architectures for the
enterprise
➢ Can use the Architecture
Continuum as method for
classification
2
1

193. 193
18
1/2
Standards Information Base
➢ The Standards Information
Base captures the standards
with which new architectures
must comply
➢ May include industry
standards, selected products
and services from suppliers,
or shared services already
deployed within the
organization
➢ Three classes of standard
▪ Legal and Regulatory
Obligations
▪ Industry Standards
▪ Organizational Standards
2
1

194. 194
18
1/2
Governance Log
➢ The Governance Log provides
a record of governance
activity across the enterprise
▪ Decision Log
▪ Compliance Assessments
▪ Capability Assessments
▪ Calendar
▪ Project Portfolio
▪ Performance Measurement
2
1

195. 195
18
Relationship to the Broader Enterprise Repository
2
1

196. 196
18
The Enterprise Repository
2
Enterprise Repository also
includes
Requirements Repository used by the
requirements Management Phase to record
and manage all information relevant to the
architecture requirements covering strategic,
segment and capability requirements
Solutions repository holds the Solutions
building Blocks
External Repositories – includes all external
supporting repositories holding reference
model, standards
Reflects the Enterprise
Continuum
A view of the Architecture Repository
Methods for classifying architecture and
solution artifacts
Includes the Architecture
Repository
A content storage system that manages all of
the Architecture assets of an enterprise

197. 197
18
Enterprise Continuum
and
Architecture Repository
•Questions?
This module described
• The Enterprise Continuum, a
method for classifying
architecture and solution
artifacts, and
• The Architecture Repository, a
system that manages all of
the Architecture assets of an
enterprise

198. 198
18
Learning
Outcomes
•Briefly explain what the Enterprise Continuum is
•Explain how it is used in organizing and developing an architecture
•Explain how the EC promotes reuse of artifacts
•Describe the constituents of the Enterprise Continuum
•Explain the purpose of the Enterprise Continuum
•Explain the purpose of the Architecture Continuum
•List the stages of architecture evolution defined in the Architecture Continuum
•Explain the purpose of the Solutions Continuum
•List the stages of architecture evolution defined in the Solutions Continuum
•Explain the relationship between the Enterprise Continuum and the TOGAF
ADM
•Explain the role of the TRM as a Foundation Architecture
•Describe the characteristics of a Foundation Architecture

199. 199
18
Learning
Outcomes
•Describe the Architecture Repository
•Describe the relationship between the Enterprise Continuum and
Architecture Repository
•Describe the classes of information held in the Architecture Repository
•List the three possible levels of the Architecture Repository
•Explain the purpose of the Standards Information Base within the
Architecture Repository
•Explain the relationship between the Architecture Repository and the
Enterprise Repository
•Describe the purpose of the repository areas that hold output of
projects
•Explain how the concepts of levels is used to organize the Architecture
Landscape