TOGAF9 Zimele Training
TOGAF9 Zimele Training
TOGAF9 Zimele Training
1
By: Samuel Mandebvu
Welcome!
This presentation is for you if:
Want to know what TOGAF is and what its all about.
Have gone through the training and are now studying to write
the exams.
2
TOGAF 9.1 Parts
Part I – Introduction
Part II – The ADM
Part III - ADM Guidelines and Techniques
Part IV - Architecture Content Framework
Part V - Enterprise Continuum and Tools
Part VI - Reference Models
Part VII - Architecture Capability Framework
3
What is TOGAF?
7
Key Terms
Architecture View : A view is a representation of a system from the perspective of a
related set of concerns. A view is what you see (or what a stakeholder sees). Views are
specific.
Architecture Viewpoint: where you are looking from; the vantage point or perspective.
Viewpoints are generic. A model (or description) of the information contained in a view.
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 /Level of granularity of work to be done.
Baseline :A specification that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development or change and that can be
changed only through formal change control procedures or a type of procedure such as
configuration management.
Baseline Architecture :The existing defined system architecture before entering a
cycle of architecture review and redesign.
8
Key Terms
Business Governance :Concerned with ensuring that the business processes and policies
(and their operation) deliver the business outcomes and adhere to relevant business
regulation.
Capability :An ability that an organization, person, or system possesses. Capabilities are
typically expressed in general and high-level terms and typically require a combination
of organization, people, processes, and technology to achieve; or example, marketing,
customer contact, or outbound telemarketing.
Concerns :The key interests that are crucially important to the stakeholders in a
system, and determine the acceptability of the system. Concerns may pertain to any
aspect of the system’s functioning, development, or operation, including considerations
such as performance, reliability, security, distribution, and evolvability. Longer lasting
than problem (eg. state of the economy), not a requirement, which is short term.
Enterprise : The highest level (typically) of description of an organization and typically
covers all missions and functions. An enterprise will often span multiple organizations.
A "pattern" has been defined as: "an idea that has been useful in one practical context
and will probably be useful in others" [Analysis Patterns - Re-usable Object Models].
9
The ADM
10
ADM
The TOGAF ADM is
Preliminary
9 Phases
framework-agnostic, and
helps IT architects fill in the 4 Domains (B.D.A.T)
framework they might A.
Architecture
already have in use. Vision
H. B.
Architecture Business 1.Business
Change Architecture
Management
2.Data
G. C.
Requirements I.S
Implementation
Architectures
Governance Management 3.Application
F. D.
Migration Technology
Planning Architecture 4.Technology
E.
Opportunities
&
Solutions
O Preliminary
12
Objective
13
Approach
14
Defining the Enterprise
“How big is this animal?”
The enterprise scope will determine those stakeholders who will derive most benefit
from the new or enhanced enterprise architecture.
It is important to appoint a sponsor at this stage.
The enterprise may include many organizations and the duty of the sponsor is to ensure
that all stakeholders are included in some part of the architecture work.
15
Identifying key drivers and elements in
the organizational context
16
Defining The Requirements For
Architecture Work
Business imperatives drive the requirements and performance metrics. One or more of the
following requirements need to be articulated so that the sponsor can identify the key
decision-makers and stakeholders and generate a Request for Architecture Work:
Business requirements
Cultural aspirations
Organization intents
Strategic intent
Forecast financial requirements
17
Defining The Architecture Principles
Architecture work is informed by business principles as well as architecture principles.
The architecture principles themselves are also normally based in part on business
principles.
Principles are general rules and guidelines, intended to be enduring and seldom
amended, that inform and support the way in which an organization sets about fulfilling
its mission.
Depending on the organization, principles may be established within different domains
and at different levels. Two key domains inform the development and utilization of
architecture:
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform
how the organization sets about fulfilling its mission.
Architecture principles are a set of principles that relate to architecture work. They reflect a
level of consensus across the enterprise, and embody the spirit and thinking of existing
enterprise principles.
18
Example Principle
Statement:
Enterprise operations are maintained in spite of system interruptions.
Rationale:
As system operations become more pervasive, we become more dependent on them; therefore, we must
consider the reliability of such systems throughout their design and use. Business premises throughout the
enterprise must be provided with the capability to continue their business functions regardless of external
events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop
enterprise activities. The enterprise business functions must be capable of operating on alternative
information delivery mechanisms.
Implications:
Dependency on shared system applications mandates that the risks of business interruption must be
established in advance and managed.
Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or
designing mission-critical services to ensure business function continuity through redundant or
alternative capabilities.
Recoverability, redundancy, and maintainability should be addressed at the time of design.
Applications must be assessed for criticality and impact on the enterprise mission, in order to determine
what level of continuity is required and what corresponding recovery plan is necessary.
19
Management Frameworks
TOGAF has to co-exist with and enhance the operational capabilities of other
management frameworks that are present within any organization either
formally or informally.
The main frameworks suggested to be co-ordinated with TOGAF are:
Business Capability Management (Business Direction and Planning) that
determines what business capabilities are required to deliver business value
including the definition of return on investment and the requisite
control/performance measures.
Portfolio/Project Management Methods that determine how a company
manages its change initiatives.
Operations Management Methods that describe how a company runs its
day-to-day operations, including IT.
Solution Development Methods that formalize the way that business
systems are delivered in accordance with the structures developed in the IT
architecture.
20
Preliminary Phase Steps
The order of the steps should be adapted to the
situation. In particular you should determine
whether it is appropriate to do the Baseline 1. Scope the Enterprise Organizations Impacted
Business Architecture or Target Business
Architecture development first
2. Confirm Governance and Support Frameworks
21
A Architecture Vision
22
Objective
23
Creating the Architecture Vision
The Architecture Vision provides the sponsor with a key tool to sell the benefits of the
proposed capability to stakeholders and decision-makers within the enterprise.
Architecture Vision describes how the new capability will meet the business goals and
strategic objectives and address the stakeholder concerns when implemented.
The Architecture Vision provides a first-cut, high-level description of the Baseline and
Target Architectures, covering the business, data, application, and technology domains.
Business scenarios are an appropriate and useful technique to discover and document
business requirements, and to articulate an Architecture Vision that responds to those
requirements.
24
Business Scenarios
25
1. Establish the Architecture Project
6. Define Scope
27
Objective
28
Developing the Baseline Description
If an enterprise has existing architecture descriptions, they should be used as the basis
for the Baseline Description.
The normal approach to Target Architecture development is top-down.
In the Baseline Description, however, the analysis of the current state often has to be
done bottom-up, particularly where little or no architecture assets exist.
Whatever the approach, the goal should be to re-use existing material as much as
possible, and to gather and analyze only that information that allows informed decisions
to be made regarding the Target Business Architecture.
29
Business Modelling
Business models should be logical extensions of the business scenarios from the
Architecture Vision, so that the architecture can be mapped from the high-level
business requirements down to the more detailed ones.
30
Architecture Repository
As part of Phase B, the architecture team will need to consider what relevant
Business Architecture resources are available from the Architecture
Repository. In Particular:
Generic business models relevant to the organization's industry sector.
These are "Industry Architectures", in terms of the Enterprise Continuum.
Business models relevant to common high-level business domains.
Enterprise-specific building blocks (process components, business rules, job
descriptions, etc.).
31
The Architecture Repository
Supporting the Enterprise Continuum is the concept of an Architecture Repository which
can be used to store different classes of architectural output at different levels of
abstraction, created by the ADM.
The major components within an Architecture Repository are as follows:
The Architecture Metamodel describes the organizationally tailored application of an
architecture framework, including a metamodel for architecture content.
The Architecture Capability defines the parameters, structures, and processes that
support governance of the Architecture Repository.
The Architecture Landscape shows an architectural view of the building blocks that are
in use within the organization today (e.g., a list of the live applications). The landscape
is likely to exist at multiple levels of abstraction to suit different architecture objectives.
The Standards Information Base (SIB) captures the standards with which new
architectures must comply, which may include industry standards, selected products and
services from suppliers, or shared services already deployed within the organization.
The Reference Library provides guidelines, templates, patterns, and other forms of
reference material that can be leveraged in order to accelerate the creation of new
architectures for the enterprise.
The Governance Log provides a record of governance activity across the enterprise.
32
The Architecture Repository
33
Phase B Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to the
situation. In particular you should determine
whether it is appropriate to do the Baseline 2. Develop Baseline Business Architecture Description
Business Architecture or Target Business
Architecture development first
3. Develop Target Business Architecture Description
35
Objective
Develop the Target Information Systems (Data and Application) Architecture, describing
how the enterprise's Information Systems Architecture will enable the Business
Architecture and the Architecture Vision, in a way that addresses the Request for
Architecture Work and stakeholder concerns.
Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Information Systems (Data and Application) Architectures.
36
Data Architecture part of Phase C
(Objectives)
Develop the Target Data Architecture that enables the Business Architecture and the
Architecture Vision, while addressing the Request for Architecture Work and
stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Data Architectures
37
Key Considerations for Data Architecture
Data Management
Considerations include:
A clear definition of which application components in the landscape will serve as the
system of record or reference for enterprise master data.
Will there be an enterprise-wide standard that all application components, including
software packages, need to adopt?
Clearly understand how data entities are utilized by business functions, processes, and
services.
Clearly understand how and where enterprise data entities are created, stored,
transported, and reported.
What is the level and complexity of data transformations required to support the
information exchange needs between applications?
What will be the requirement for software in supporting data integration with the
enterprise's customers and suppliers?
38
Key Considerations for Data Architecture
Data Migration
Considerations include:
When an existing application is replaced, there will be a critical need to migrate data
(master, transactional, and reference) to the new application.
The Data Architecture should identify data migration requirements and also provide
indicators as to the level of transformation, weeding, and cleansing that will be
required to present data in a format that meets the requirements and constraints of the
target application.
The objective being that the target application has quality data when it is populated.
Ensure that an enterprise-wide common data definition is established to support the
transformation.
39
Key Considerations for Data Architecture
Data Governance
Data governance considerations ensure that the enterprise has the necessary dimensions
in place to enable the transformation, as follows:
Structure: This dimension pertains to whether the enterprise has the necessary
organizational structure and the standards bodies to manage data entity aspects of the
transformation.
Management System: Here enterprises should have the necessary management system
and data-related programs to manage the governance aspects of data entities
throughout its lifecycle.
People: This dimension addresses what data-related skills and roles the enterprise
requires for the transformation. If the enterprise lacks such resources and skills, the
enterprise should consider either acquiring those critical skills or training existing
internal resources to meet the requirements through a well-defined learning program.
40
Phase C Data Architecture Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to the
situation.
2. Develop Baseline Data Architecture Description
Develop the Target Application Architecture that enables the Business Architecture and
the Architecture Vision, while addressing the Request for Architecture Work and
stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Application Architectures
42
Phase C Applications Architecture Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to the
situation.
2. Develop Baseline Application Architecture
Description
44
Objectives
Develop the Target Technology Architecture that enables the logical and physical
application and data components and the Architecture Vision, addressing the Request
for Architecture Work and stakeholder concerns.
Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Technology Architectures
45
The Architecture Repository
•Existing IT services as
documented in the IT repository
or IT service catalog
•TOGAF Technical Reference
Model (TRM)
•Generic technology models
relevant to the organization's
industry "vertical" sector
46
Phase D Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to the
situation.
2. Develop Baseline Technology Architecture
Description
3. Develop Target Technology Architecture
Description
48
Objective
49
Stakeholders
• Phase E is a collaborative effort with stakeholders required
from both the business and IT sides.
• It should include both those that implement and those
that operate the infrastructure.
• It should also include those responsible for strategic
planning, especially for creating the Transition Stakeholders
Architectures.
52
Objective
53
• The focus of Phase F is the creation of an Implementation
and Migration Plan in co-operation with the portfolio and
project managers.
• Phase E provides an incomplete Architecture Roadmap and
Implementation and Migration Plan that address the
Request for Architecture Work. In Phase F this Roadmap
and the Implementation and Migration Plan are integrated
with the enterprise's other change activity.
• The Architecture Roadmap, Version 0.1 and
Implementation and Migration Plan, Version 0.1 from
Phase E will form the basis of the final Implementation
and Migration Plan that will include portfolio and project-
level detail.
54
Phase F Steps
The order of the steps should be adapted to the
situation.
56
Objective
57
• Note that, in parallel with Phase G, there is the execution
of an organizational-specific development process, where
the actual development happens.
• To enable early realization of business value and benefits,
and to minimize the risk in the transformation and
migration program, the favoured approach is to deploy the
Target Architecture as a series of transitions.
• Each transition represents an incremental step towards
the target, and each delivers business benefit in its own
right
58
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.
59
Approach
60
Architecture Governance
“the practice and orientation by which enterprise architectures and other
architectures are managed and controlled at an enterprise-wide level..”
Corporate governance
Each of these domains of governance may exist
Technology governance
at multiple geographic levels - global, regional,
IT governance and local - within the overall enterprise.
Architecture governance
61
Architecture Governance : Characteristics
Architecture governance is the practice and orientation by which enterprise architectures
and other architectures are managed and controlled at an enterprise-wide level. It
includes the following:
Implementing a system of controls over the creation and monitoring of all architectural
components and activities, to ensure the effective introduction, implementation, and
evolution of architectures within the organization.
Implementing a system to ensure compliance with internal and external standards and
regulatory obligations.
Establishing processes that support effective management of the above processes within
agreed parameters.
Developing practices that ensure accountability to a clearly identified stakeholder
community, both inside and outside the organization.
Architecture governance needs to be supported by an Architecture Governance
Framework which assists in identifying effective processes so that the business
responsibilities associated with architecture governance can be elucidated,
communicated, and managed effectively.
62
Architecture Governance Framework
“a conceptual and organizational framework for architecture governance.”
Conceptual Structure
63
Architecture Governance Framework
Organizational Structure
64
Phase G Steps
The order of the steps should be adapted to the
situation.
65
H Architecture Change
Management
66
Objective
67
• In Phase H it is critical that the governance body establish
criteria to judge whether a Change Request warrants just
an architecture update or whether it warrants starting a
new cycle of the Architecture Development Method (ADM).
It is especially important to avoid "creeping elegance",
and the governance body must continue to look for
changes that relate directly to business value.
There are three ways to change the existing infrastructure that have to be
integrated:
69
Enterprise Architecture Change
Management Process
70
A good rule-of-thumb is:
• If the change impacts two stakeholders or more, then it is
likely to require an architecture redesign and re-entry to
the ADM.
• If the change impacts only one stakeholder, then it is
more likely to be a candidate for change management.
• If the change can be allowed under a dispensation, then it
is more likely to be a candidate for change management.
71
Phase H Steps
The order of the steps should be adapted to the
situation.
3. Manage Risks
73
Objective
74
Architecture Content Framework
“provides a detailed model of architectural work products, including deliverables, artefacts
within deliverables, and the Architecture Building Blocks (ABBs) that deliverables represent.”
75
Content Framework
The Architecture Content Framework uses the following three categories to describe
the type of architectural work product within the context of use:
77
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.
78
Metamodel entities and Their Relationships
79
Building Blocks
Building blocks have generic characteristics as follows:
A building block is a package of functionality defined to meet the business needs across
an organization.
A building block has a type that corresponds to the TOGAF content metamodel (such as
actor, business service, application, or data entity)
A building block has a defined boundary and is generally recognizable as "a thing" by
domain experts.
A building block may interoperate with other, inter-dependent, building blocks.
A good building block has the following characteristics:
It considers implementation and usage, and evolves to exploit technology and standards.
It may be assembled from other building blocks.
It may be a subassembly of other building blocks.
Ideally a building block is re-usable and replaceable, and well specified.
80
The Enterprise Continuum
82
The Architecture Continuum
A Foundation Architecture is an
architecture of building blocks
Organization-Specific Common Systems Architectures guide
and corresponding
Architectures standards
are the most the selection and integration of
Industry Architectures guide the
thatto
relevant supports all the Common
the IT customer specific services from the Foundation
integration of common systems
Systemssince
community, Architectures and,
they describeArchitecture to create an architecture
components with industry-
therefore,
and guide the deployment
the final complete useful for building common solutions
specific components, and guide
enterprise or
of user-written operating
third-party across a wide number of relevant
the creation of industry solutions
environment.Eg
components the Technical
that constitute domains. Eg Integrated Information
for specific customer problems
Reference
effective Model(TRM)
solutions for particular
Infrastructure Reference Model (III-RM)
within a particular industry.
enterprises.
83
The Solutions Continuum
An Organization-Specific Common Systems Solutions represent
Foundation
Solution Solutions are
is an implementation ofhighly of common requirements
collections
An Industry Solution is angeneric concepts, tools, products,
the Organization- Specific and capabilities, rather than those specific to
implementation of an Industry
services, and solutionthe
components
a particular customer or industry. Common
Architecture that provides
Architecture, which provides re- the fundamental
thatbusiness
are providers
required functions. Systems Solutions provide organizations with
usable packages of common of capabilities. Eg programming
operating environments specific to operational
They contain the highest amount
components and serviceslanguages,
specific to
of unique contentoperating
in order tosystems,
and informational needs, such as high
an industry. Fundamental componentsstructuresavailability
foundational for transaction processing and scalable
accommodate the varying
are provided by Commonorganizing
Systems IT operations (such
data as
warehousing systems. Examples of
people and processes of specific
Solutions and/or Foundation
ITIL)Solutions, Common Systems Solutions include: an
organizations.
and are augmented with industry- enterprise management system product and a
specific components. security system product.
84
Architecture Capability Framework
Architecture Capability Framework Contents:
Chapter Description
Establishing an Architecture Guidelines for establishing an Architecture
Capability Capability within an organization.
Architecture Board Guidelines for establishing and operating an
enterprise Architecture Board.
Architecture Compliance Guidelines for ensuring project compliance to
architecture.
Architecture Contracts Guidelines for defining and using Architecture
Contracts.
Architecture Governance Framework and guidelines for Architecture
Governance.
Architecture Maturity Models Techniques for evaluating and quantifying
an organization’s maturity in enterprise
architecture.
Architecture Skills Framework A set of role, skill, and experience norms for
staff undertaking enterprise architecture work.
85
Architecture Capability Framework
86
TOGAF Document Categorization Model
87
Version Management
Phase Deliverable Content Version Description
Business 0.1
Architecture
Data 0.1
Architecture Version 0.1 indicates that
A: Architecture Architecture
a high-level outline of the
Vision Vision Application 0.1 architecture is in place.
Architecture
Technology 0.1
Architecture
B: Business Architecture Business 1.0
Architecture Definition Architecture
Document
C: Information Architecture Data 1.0
Systems Definition Architecture Version 1.0 indicates
Architecture Document a formally reviewed,
Application 1.0 detailed architecture.
Architecture
D: Technology Architecture Technology 1.0
Architecture Definition Architecture
Document
88
Stakeholder Management
“helps them ensure that their projects succeed where others fail by managing Stakeholders.”
C D
High
Keep Satisfied Key Players
Power
A B
Low
Minimal Effort Keep Informed
Low High
Level Of Interest 89
Gap Analysis
“It is used to validate an architecture that is being developed.”
Draw up a matrix with all the Architecture Building Blocks (ABBs) of the Baseline
Architecture on the vertical axis, and all the ABBs of the Target Architecture on the
horizontal axis.
Add to the Baseline Architecture axis a final row labeled "New", and to the Target
Architecture axis a final column labeled "Eliminated".
Where an ABB is available in both the Baseline and Target Architectures, record this
with "Included" at the intersecting cell.
Where an ABB from the Baseline Architecture is missing in the Target Architecture, each
must be reviewed. If it was correctly eliminated, mark it as such in the appropriate
"Eliminated" cell. If it was not, an accidental omission in the Target Architecture has
been uncovered that must be addressed by reinstating the ABB in the next iteration of
the architecture design - mark it as such in the appropriate "Eliminated" cell.
Where an ABB from the Target Architecture cannot be found in the Baseline
Architecture, mark it at the intersection with the "New" row as a gap that needs to
filled, either by developing or procuring the building block.
90
Gap Analysis Example :
91
Migration Planning Technique
Business Value Assessment Technique
92
Iteration Cycles
93
Views & View Points
Key: Data
(What)
Function
(How)
Network
(Where)
People
(Who)
Time
(When)
Motivation
(Why)
Entity
Business Process Logistics Organizational Business Master
what a stakeholder sees). Views are specific.
Owner’s View Relationship
Model Network Chart Schedule
Business Rules
diagram
Architecture Viewpoint: where you are looking
Information Architecture from; the vantage point or perspective.
Essential data
Designer’s
View
Data model
flow,
application
Distributed
system
Human
interface
Dependency
diagram, entity
Business Rule
model
Viewpoints are generic. A model (or
architecture architecture life history
architecture
description) of the information contained in a
Information & comm. Technology Architecture view.
System design:
Builder’s Data Systems User interface Control flow Business Rule
structure chart,
View Architecture Architecture design diagram design
pseudo code
Rule
Data design, Detailed Network Timing of
Detailed View physical storage program design Architecture
Screens
definitions
specification in
program logic
94
Zachman Framework
Capability-Based Planning
“focuses on the planning, engineering, and delivery of strategic business capabilities to
the enterprise.”
95
Capability-Based Planning
96
Architecture Landscape
Shows how the AM (Architectural Model) has changed over time.
Strategic Architecture provides an organizing framework for operational and change
activity and allows for direction setting at an executive level.
Segment Architecture provides an organizing framework for operational and change
activity and allows for direction setting and the development of effective architecture
roadmaps at a program or portfolio level.
Capability Architecture provides an organizing framework for change activity and the
development of effective architecture roadmaps realizing capability increments.
98
Foundation Architecture: Technical
Reference Model (TRM)
The Foundation Architecture is embodied within the Technical Reference Model (TRM),
which provides a model and taxonomy of generic platform services.
The TRM is universally applicable and, therefore, can be used to build any system
architecture.
Any TRM has two main components: (same as III-RM)
1. A taxonomy, which defines terminology, and provides a coherent description of the
components and conceptual structure of an information system.
2. An associated TRM graphic, which provides a visual representation of the taxonomy, as
an aid to understanding.
99
Foundation Architecture: Technical
Reference Model (TRM)
TRM graphic
10
Integrated Information Infrastructure
Reference Model (III-RM)
The 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 - in order to provide help in addressing one of the key
challenges facing the enterprise architect today: the need to design an integrated
information infrastructure to enable Boundaryless Information Flow.
The model assumes the underlying existence of a computing and network platform, as
described in the TRM.
This is a Common
Systems Architecture.
10
Integrated Information Infrastructure
Reference Model (III-RM)
Detailed III-RM Graphic
102
The End