TOGAF 9
Vinod Wilson – Architect – Crestron Electronics
TOGAF GENERAL STRUCTURE
ADM AND THE TOGAF CROP CIRCLE DIAGRAM
From baseline to target architecture
Transition architectures and increments
(states)
Gap analysis
• Which elements are new (organizations, applications,
infrastructures)?
• Which elements have been deleted?
• Which elements have been modified?
• Which elements remain unchanged?
Impact evaluation
• An enterprise is often a complex organization with multiple branches.
Consequently, the modification of one part of its architecture may
potentially affect other components situated outside the scope of the
implemented changes.
The concept of capability
• Capability designates the ability of an organization to provide a given
product or service. Capability manifests itself through a series of
factors that contribute to the realization of these products or services
at the required level of quality. These factors can vary widely in type:
for example,
• personnel training,
• availability of an expert in a field,
• surface area of premises,
• power of IT servers, and so on.
Capability
• “The ability of an organization, person, process, application, IT service
or other configuration item to carry out an activity.”
Architecture and description of architecture
1. “A formal description of a system, or a detailed plan of the system at
component level, to guide its implementation.”
2. “The structure of components, their inter-relationships, and the
principles and guidelines governing their design and evolution over
time.”
Domains and phases
• Business architecture, which covers strategy, goals, business processes,
functions, and organization.
• Data architecture, dedicated to the organization and management of
information.
• Application architecture, which presents applications, software
components, and their interactions.
• Technology architecture, which describes the techniques and components
deployed, as well as networks and the physical infrastructure upon which
the applications and data sources run.
Architecture Breakdowns
Architecture repository
• Naturally, enterprises need to conserve, diffuse, and reuse the EA
information that constitutes one of their key assets.
• This is the role of the architecture repository, which includes
descriptions from each of the four domains, as well as a whole host of
knowledge, guiding principles, and techniques linked to enterprise
architecture.
Architecture and solution
• Architecture - designates a description, and more precisely a logical
view
• Solution - represents a technical reality
• ABB(Architecture Building Block) - The logical specification of an
element
• SBB(Solution Building Block) – Physical specification of an element
GOALS, CONSTRAINTS, AND REQUIREMENTS
Strategic
Objectives or Goals
• Describe
general
orientation
Operational
Objectives
• Formalize the
goals in terms
of measurable
results at a
given date
Drivers
• Motivates
decisions
regarding
architectural
change
Requirements
• Specify what
will be
concretely
implemented to
reach the stated
goal
Constraints
• Which are
external that
influence the
system
Role of the enterprise architect
• The role of an enterprise architect is not to define objectives
(strategic or operational) for an organization
• He/She will formalize them within a structured context, and will use
this formalization to better link decisions and architectural elements
STAKEHOLDERS AND THE HUMAN FACTOR
• Stakeholder management
• Transformation Readiness Assessment
• Efficiency of communication through the concept of viewpoints
Managing stakeholders
• Who defines goals?
• Who gains and who loses from this change?
• Who controls the transformation process?
• Who designs new systems?
• Who will make the decisions?
• Who procures IT systems and who decides what to buy?
• Who controls resources?
• Who has or controls the necessary specialist skills?
• Who influences the project?
Degrees of Stakeholder involvement
Transformation Readiness Assessment
• A clear presentation of the impacts of changes made, notably on an
organizational level
• A concrete view of the expected business benefits, in the form of
“business cases”
• An objective assessment of the enterprise’s IT, business, and financial
aptitudes, with no overestimation of its real capacities
• An executive management team recognized as being able to defend
the project in the long term
• High-quality communication, which aims to promote a common
understanding of the stakes and the solutions to implement
Views and viewpoints
• If a message is to be successfully understood, the most important
aspect to consider is that its content and form must be tailored to the
intended recipient.
• Viewpoints - A viewpoint designates the most appropriate
perspective for a given participant, and is materialized by a certain
number of views of the architecture, in the form of diagrams,
documents, or other elements
• It is imperative that views and viewpoints be defined for each
stakeholder before beginning work on the four architecture domains
(business, data, application, and technology)
Governance
• To slow down the centrifugal forces and retain a certain level of
overall consistency, it is essential that an appropriate organization be
established
• This organization, called the “architecture board,” is responsible for
the following goals: to guarantee that common rules are respected,
and to ensure that implementation projects are supported. In its
capacity as a steering and control committee, the architecture board
also takes care of managing the architecture repository.
Architecture principles
• They establish a set of rules and recommendations, which encourage
the harmonization of choices and practices.
• Architecture principles properties
• Stability: Principles are stable by nature. They are only rarely modified
compared with the frequency of developments.
• General scope: A principle applies to the entire enterprise, and does not
depend on the transformation carried out.
• Comprehensibility: A principle is interpreted clearly by all stakeholders.
• Coherence: With regard to the set of principles. Two principles cannot be
contradictory.
Summarized view of Architecture
transformation project
TOGAF and DODAF
• DODAF viewpoints are structured as follows:
• All Viewpoint (AV)
• Capability Viewpoint (CV)
• Data and Information Viewpoint (DIV)
• Operational Viewpoint (OV)
• Project Viewpoint (PV)
• Services Viewpoint (SvcV)
• Standards Viewpoint (StdV)
• Systems Viewpoint (SV)
TOGAF Viewpoints
• As in TOGAF, each viewpoint is broken down into a collection of
views, each designed to represent a part of the architecture
Operational
Viewpoint
OV-1 High Level
Operational
Concept Graphic
OV-2 Operational
Node
Connectivity
Description
OV-3 Operational
Information
Exchange Matrix
OV-4
Organizational
Relationships
Chart
OV-5 Operational
Activity Model OV-6a
Operational Rules
Model
OV-6b
Operational State
Transition
Description
OV-6c
Operational
Event-Trace
Description
OV-7 Logical Data
Model
Enterprise architecture process maturity levels
•No enterprise architecture program. No enterprise architecture to speak of.Level 0: None
•Informal enterprise architecture process underway
Level 1: Initial
•Enterprise architecture process is under development.Level 2: Under Development
•Defined enterprise architecture including detailed written procedures and TRM.Level 3: Defined
•Managed and measured enterprise architecture process.Level 4: Managed
•Continuous improvement of enterprise architecture process.Level 5: Optimizing
Thank You

Togaf 9 introduction

  • 1.
    TOGAF 9 Vinod Wilson– Architect – Crestron Electronics
  • 2.
  • 3.
    ADM AND THETOGAF CROP CIRCLE DIAGRAM
  • 4.
    From baseline totarget architecture
  • 5.
    Transition architectures andincrements (states)
  • 6.
    Gap analysis • Whichelements are new (organizations, applications, infrastructures)? • Which elements have been deleted? • Which elements have been modified? • Which elements remain unchanged?
  • 7.
    Impact evaluation • Anenterprise is often a complex organization with multiple branches. Consequently, the modification of one part of its architecture may potentially affect other components situated outside the scope of the implemented changes.
  • 8.
    The concept ofcapability • Capability designates the ability of an organization to provide a given product or service. Capability manifests itself through a series of factors that contribute to the realization of these products or services at the required level of quality. These factors can vary widely in type: for example, • personnel training, • availability of an expert in a field, • surface area of premises, • power of IT servers, and so on.
  • 9.
    Capability • “The abilityof an organization, person, process, application, IT service or other configuration item to carry out an activity.”
  • 10.
    Architecture and descriptionof architecture 1. “A formal description of a system, or a detailed plan of the system at component level, to guide its implementation.” 2. “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”
  • 11.
    Domains and phases •Business architecture, which covers strategy, goals, business processes, functions, and organization. • Data architecture, dedicated to the organization and management of information. • Application architecture, which presents applications, software components, and their interactions. • Technology architecture, which describes the techniques and components deployed, as well as networks and the physical infrastructure upon which the applications and data sources run.
  • 12.
  • 13.
    Architecture repository • Naturally,enterprises need to conserve, diffuse, and reuse the EA information that constitutes one of their key assets. • This is the role of the architecture repository, which includes descriptions from each of the four domains, as well as a whole host of knowledge, guiding principles, and techniques linked to enterprise architecture.
  • 14.
    Architecture and solution •Architecture - designates a description, and more precisely a logical view • Solution - represents a technical reality • ABB(Architecture Building Block) - The logical specification of an element • SBB(Solution Building Block) – Physical specification of an element
  • 15.
    GOALS, CONSTRAINTS, ANDREQUIREMENTS Strategic Objectives or Goals • Describe general orientation Operational Objectives • Formalize the goals in terms of measurable results at a given date Drivers • Motivates decisions regarding architectural change Requirements • Specify what will be concretely implemented to reach the stated goal Constraints • Which are external that influence the system
  • 16.
    Role of theenterprise architect • The role of an enterprise architect is not to define objectives (strategic or operational) for an organization • He/She will formalize them within a structured context, and will use this formalization to better link decisions and architectural elements
  • 17.
    STAKEHOLDERS AND THEHUMAN FACTOR • Stakeholder management • Transformation Readiness Assessment • Efficiency of communication through the concept of viewpoints
  • 18.
    Managing stakeholders • Whodefines goals? • Who gains and who loses from this change? • Who controls the transformation process? • Who designs new systems? • Who will make the decisions? • Who procures IT systems and who decides what to buy? • Who controls resources? • Who has or controls the necessary specialist skills? • Who influences the project?
  • 19.
  • 20.
    Transformation Readiness Assessment •A clear presentation of the impacts of changes made, notably on an organizational level • A concrete view of the expected business benefits, in the form of “business cases” • An objective assessment of the enterprise’s IT, business, and financial aptitudes, with no overestimation of its real capacities • An executive management team recognized as being able to defend the project in the long term • High-quality communication, which aims to promote a common understanding of the stakes and the solutions to implement
  • 21.
    Views and viewpoints •If a message is to be successfully understood, the most important aspect to consider is that its content and form must be tailored to the intended recipient. • Viewpoints - A viewpoint designates the most appropriate perspective for a given participant, and is materialized by a certain number of views of the architecture, in the form of diagrams, documents, or other elements • It is imperative that views and viewpoints be defined for each stakeholder before beginning work on the four architecture domains (business, data, application, and technology)
  • 22.
    Governance • To slowdown the centrifugal forces and retain a certain level of overall consistency, it is essential that an appropriate organization be established • This organization, called the “architecture board,” is responsible for the following goals: to guarantee that common rules are respected, and to ensure that implementation projects are supported. In its capacity as a steering and control committee, the architecture board also takes care of managing the architecture repository.
  • 23.
    Architecture principles • Theyestablish a set of rules and recommendations, which encourage the harmonization of choices and practices. • Architecture principles properties • Stability: Principles are stable by nature. They are only rarely modified compared with the frequency of developments. • General scope: A principle applies to the entire enterprise, and does not depend on the transformation carried out. • Comprehensibility: A principle is interpreted clearly by all stakeholders. • Coherence: With regard to the set of principles. Two principles cannot be contradictory.
  • 24.
    Summarized view ofArchitecture transformation project
  • 25.
    TOGAF and DODAF •DODAF viewpoints are structured as follows: • All Viewpoint (AV) • Capability Viewpoint (CV) • Data and Information Viewpoint (DIV) • Operational Viewpoint (OV) • Project Viewpoint (PV) • Services Viewpoint (SvcV) • Standards Viewpoint (StdV) • Systems Viewpoint (SV)
  • 26.
    TOGAF Viewpoints • Asin TOGAF, each viewpoint is broken down into a collection of views, each designed to represent a part of the architecture Operational Viewpoint OV-1 High Level Operational Concept Graphic OV-2 Operational Node Connectivity Description OV-3 Operational Information Exchange Matrix OV-4 Organizational Relationships Chart OV-5 Operational Activity Model OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event-Trace Description OV-7 Logical Data Model
  • 27.
    Enterprise architecture processmaturity levels •No enterprise architecture program. No enterprise architecture to speak of.Level 0: None •Informal enterprise architecture process underway Level 1: Initial •Enterprise architecture process is under development.Level 2: Under Development •Defined enterprise architecture including detailed written procedures and TRM.Level 3: Defined •Managed and measured enterprise architecture process.Level 4: Managed •Continuous improvement of enterprise architecture process.Level 5: Optimizing
  • 28.