I successfully completed my TOGAF-9 certification in May 2013.
While preparing for the certification, I made short notes which really helped
me in revising concepts within short period of time and help me ace the
certification.
Here I am sharing these notes so that everyone can get help from
them.
Introduction –
·
7 parts
of TOGAF document -
o Part I - Introduction
o Part II - Architecture Development Method
o Part III - ADM Guidelines & Techniques
o Part IV - Architecture Content Framework
o Part V - Enterprise Continuum & Tools
o Part VI - TOGAF Reference Models
o Part VII - Architecture Capability framework
ADM
–
·
Every
phase is validated against current requirements and in turn validates the
current requirements of the business.
·
ADM is
an iterative process -
o Over the whole process
o Between phases
o Within phases
Preliminary phase
-
·
Understand
business environment
·
High
level management commitment
·
Agreement
on scope
·
Establish
principles
·
Establish
governance structure
·
Customization
of TOGAF
·
Definition
of an Organization-Specific Architecture framework
·
Definition
of principles
·
Determine
and establish architecture capability desired by organization.
·
Define
the requirements for architecture work.
·
Inputs
-
o Reference materials external to enterprise
o Architectural and non-architectural inputs
·
Outputs
-
o Organization model for enterprise architecture
o Tailored architecture framework
o Initial architecture repository
o Request for architecture work
o Architecture governance framework
Phase A -
Architecture vision
·
Sets
scope, constraints and expectations.
·
Create
architecture vision
·
Validate
business context
·
Create
architecture vision document.
·
Business
scenario technique can be used to create architecture vision
·
Create
statement of architecture work and obtain approval
·
Communication
plan is made in Phase A.
Phase B - Business
architecture
·
Business
architecture depicts fundamental organization of a business embodied in -
o Business processes and people
o Their relationship to each other and environment
o Principles governing its design and evolution.
·
Develop
target business architecture
Phase C - Information
systems architecture
·
Fundamental
organization of an IT system.
·
Top
down design - Business, Data, Applications, Technology
·
Bottom
up design - Technology, Applications, Data, Business
Phase D - Technology
architecture
·
Develop
target technology architecture
Phase E -
Opportunities and Solutions
·
Perform
initial implementation planning
·
Identify
major implementation projects
·
Group
changes into work packages
·
Determine
if an incremental approach is required. If yes, define 'Transition
architecture'.
·
Decide
on approach
o Make vs Buy vs Reuse
o Outsource
o COTS
o Open source
·
Assess
priorities
·
Identify
dependencies
Phase F - Migration
planning
·
For
work packages identified in phase E perform -
o Cost/benefit analysis
o Risk assessment
·
Develop
a detailed implementation and migration plan
·
Finalize
the architecture roadmap
Phase G - Implementation
governance
·
Define
architecture constraints on implementation projects
·
Govern
and manage an architecture contract
·
Monitors
implementation work for governance
·
Produce
a business value realization
·
Phase G
provides architectural oversight of the implementation.
·
Phase G
- Implementation Governance, ensure conformance with the defined architecture
by the implementation projects.
Phase H -
Architecture change management
·
Provide
continual monitoring and a change management process
·
Monitors
the business and capacity management
Requirements
Management phase -
·
Applies
to all phases of the ADM cycle
·
Is
central to the ADM process
·
Is a
dynamic process addressing the identification of requirements, their storage
and delivery to the phases
Enterprise
Architecture -
·
Reasons
for EA -
o Critical to business survival and success
o Enabled managed innovation within the enterprise
·
Pressure
to develop EA -
o Laws and regulations
o More extended enterprises
o More co-operative IT operations
o Greater publicity to failures
o Increase in litigation
o Audit requirements
·
Helps
an organization achieve its strategy.
·
EA is
as good as the decision making framework established around it - Governance
framework.
Enterprise continuum
-
·
View of
architecture repository.
·
Provides
methods for classifying artifacts.
·
Two
complementary concepts -
·
Architecture
continuum
·
Solution
continuum
·
The
architecture and solutions continuum are related by guidance, direction and
support.
·
Practical
implementation of enterprise continuum is architecture repository.
·
Enables
effective use of COTS products
·
Requirements
for missing elements are passed to the left of the continuum for inclusion.
·
The
continuum contains complete and work-in-progress solutions.
Content Metamodel -
·
Defines
all types of building blocks in an architecture.
·
Describe
building blocks and how they relate
·
Consists
of Core and Extensions
·
Core
content is designed not to be altered
·
Extension
content allows for more specific or more in-depth modeling
·
Extensions
available -
·
Governance
extensions - To support the enterprise
architecture with operational governance
·
Contract,
Service quality, measure
·
Services
extensions - To support definition of
discreet business & application services
·
Information
system service
·
Process
modeling extensions - To
support process modeling
·
Event,
control, product
·
Data
extensions - To support data modeling
·
Logical
data component, Physical data component
·
Infrastructure
consolidation extensions -
·
Location,
Physical application component, Logical technology component
·
Motivation
extensions - To support linkage of
drivers, goals and objectives to org & services
·
Driver,
Goal, Objective
·
Core
components -
·
Principle,
Constraint, Assumption, Requirement, Gap, Work package, Capability
·
Organization,
Actor, Role
·
Function,
Business service, Process
·
Data
entity
·
Logical
application component
·
Platform
service, Physical technology component
·
Architecture
realization artifacts capture the transitions between architecture states and
are used to steer and govern the implementation.
Architecture
Repository -
·
TOGAF
ADM has reminders when to use assets from the Architecture repository.
·
The
architecture repository is a model for a physical instance of Enterprise
continuum.
·
Six
classes of architectural information (repository areas) -
o Architecture Metamodel
o Architecture Capability
o Architecture Landscape
o Reference Library
o Standards Information base (SIB)
o Governance Log
·
Architecture
Metamodel
o Describes the architecture framework in use
within the enterprise.
·
Architecture
Capability -
o Describes the organization, roles, skills and
responsibilities of Enterprise architecture practice
·
Reference
Library -
o Should contain Reference architectures, Reference
Models, Viewpoint Library, Templates.
o In order to segregate different classes of
architecture reference materials, the Reference Library can use the
Architecture Continuum as a method for classification.
·
Standards
Information Base (SIB)
o Types of Standards -
·
Legal
and Regulatory obligations
·
Industry
standards
·
Organizational
standards
·
Governance
Log
·
Enterprise
Repository -
o Architecture Repository
o Requirements Repository
o Solutions repository (Holds SBBs)
·
External
Repositories -
o External reference models
o External standards
o Architecture board approvals
·
Architecture
requirements -
o Strategic requirements
o Segment requirements
o Capability requirements
TOGAF Technical
Reference Model (TRM) -
·
It can
be used to build any system architecture.
·
TRM has
two main components -
o Taxonomy - Terminology & description
o Associated Graphic - Visual representation of
taxonomy
·
Aims to
emphasize the aspect of
o Application Portability.
o Interoperability.
·
It is
an example and should be tailored to the needs of an organization.
·
The
core of TOGAF is its ADM: the TRM is a tool used in applying the ADM in the
development of specific architectures.
·
TRM is
composed of 3 major entities -
o Application software.
·
<Application
Platform interface>
o Application platform.
·
<Communications
infrastructure interface>
o Communications infrastructure.
·
The
high-level TRM seeks to emphasize two major common architectural objectives:
o Application Portability, via the Application
Platform Interface -
identifying the set of services that are to be made available in a standard way
to applications via the platform
o Interoperability, via the Communications
Infrastructure Interface -
identifying the set of Communications Infrastructure services that are to be
leveraged in a standard way by the platform
Integrated
Information Infrastructure Reference Model
·
IIM-RM
has two main components -
o Taxonomy - Terminology & description
o Associated Graphic - Visual representation of
taxonomy
·
III-RM
is an example of Application Architecture Reference Model.
·
Core
components of III-RM -
o Business applications
·
Brokering
applications
·
Information
provider applications
·
Information
consumer applications
o Infrastructure applications
·
Development
tools
·
Management
utilities
o Application platform
o Interfaces
o Qualities
Architecture content
framework -
·
Section
IV of TOGAF document - Detailed model of architectural work products
·
Content
framework provides a structure to the ADM that defines inputs and outputs in
detail and puts each deliverable into the context of the architecture.
·
Three
types of architectural work products -
o Deliverable
o Artifact
o Building block
·
Deliverable
- Contractually specified. Formally reviewed, agreed & signed by
stakeholders
·
Artifact
-
o Catalogs - List of things
o Matrices - Relationships between things.
o Diagrams - Pictures of things
·
Artifacts
will form the content of Architecture Repository.
·
Building
block -
o Architecture building blocks - Typically describe
required capability.
o Solution building blocks - Represent components
that will be used to implement the required capability.
·
Artifacts
describe building blocks.
·
Includes
detailed meta-model
Architecture
capability framework -
·
Section
VII of TOGAF document.
·
Describes
processes, skills and roles to establish and operate an architecture function
within an enterprise.
·
Provides
a set of reference materials for establishing an architecture function within
an organization.
·
Structured
as follows:
o Introduction
o Establishing an Architecture Capability
o Architecture Board
o Architecture Compliance
o Architecture Contracts
o Architecture Governance
o Architecture Maturity Models
o Architecture Skills Framework
Architecture
Compliance
·
Levels
of Architecture Conformance -
o Irrelevant
o Consistent
o Compliant
o Conformant
o Full Conformant
o Non conformance
·
Architecture
Compliance reviews -
o To review a project against established
architecture criteria and business objectives.
o A formal process for such reviews normally forms
the core of an enterprise Architecture Compliance strategy.
o Purpose -
·
Catch
errors in the project architecture early
·
Ensure
the application of best practices to architecture work.
·
Deciding
between architectural alternatives.
Architecture contract
-
·
Architecture
Contracts may occur at various stages of ADM -
o SOAW created in Phase A.
o Development of one or more architecture domains
(business, data, application, technology) in appropriate phases.
o At the beginning of Phase G (Implementation
Governance).
o When the enterprise architecture has been
implemented (at the end of Phase G).
·
Contents
-
o Statement of Architecture work (Contract b/w
architecting organization & sponsor of EA).
o Contract between Architecture Design and
Development Partners.
o Contract between Architecting Function and
Business Users. (End of phase F)
o Relationship to Architecture Governance. (End of
phase G)
Architecture Changes
-
·
Simplification
change:
o Driven by requirement to reduce investment.
o Can normally be handled via change management
techniques.
·
Incremental
change:
o Driven by requirement to derive additional value
from existing investments.
·
Re-architecting
change:
·
Top-down :
o Strategic, top-down directed change to enhance or
create new capability (capital)
·
Bottom-up :
o Changes to correct or enhance capability
Business
Transformation Readiness Assessment -
·
Recommended
activities -
o Determine the readiness factors that will impact
the organization
o Present the readiness factors using maturity
models
o Assess the readiness factors, including
determination of readiness factor ratings
o Assess the risks for each readiness factor and
identify improvement actions to mitigate the risk
·
Implementation
and Migration plan incorporates the actions arising from this technique.
·
Initial
assessment done in Phase A
·
Implemented
in Phase E & F.
·
Readiness
factor levels -
o Not defined
o Adhoc
o Repeatable
o Defined
o Managed
o Optimized
Business value
assessment technique -
·
Comes
under Migration planning techniques (Phase F).
·
Draw a
matrix - Risk(X) vs Value (Y).
Building Block
–
·
Building
blocks can relate to "architectures" or "solutions".
·
They
are a package of functionality intended to meet business needs across the
organization.
·
They
should have stable, published interfaces that allow other building blocks to
interoperate with them.
·
They
may be assembled from other building blocks.
·
Good
building block should be reusable and replaceable.
·
Architecture
Building blocks -
o Architecture documentation and models from the
enterprise's architecture continuum
o They are defined or selected mainly in phases A,
B, C & D.
o They define what functionality will be
implemented
o They capture business and technical requirements
o They are technology aware
o They direct and guide the development of solution
building blocks
·
Solution
building blocks -
o Relate to solutions continuum
o Can either be procured or developed
o They define the implementation
o They fulfill business requirements
o They are product or vendor aware
·
Three
classes of building blocks -
o Reusable building blocks such as legacy items
o Building blocks to be developed (new
applications)
o Building blocks to be purchased (COTS
applications)
Request for
Architecture work -
·
Sent
from sponsor to the architecture organization.
·
Initiates
a cycle of the ADM
Statement of
architecture work -
·
Deliverable
output from Phase A
·
A plan
for the architecture work
Architecture Vision
-
·
TOGAF
recommends use of business scenarios in developing architecture vision.
Architecture
definition document -
·
Deliverable
container for core artifacts
·
BDAT
architectures
·
Includes
baseline, target and transition architectures
·
Developed
through phases A, B, C, D
·
Provides
qualitative view of the solution
Architecture requirements
document -
·
Companion
to architecture definition document
·
Contains
measurable criteria - a quantitative view
·
Often
used as a component of architecture contract.
Architecture roadmap
-
·
Incrementally
developed in phases E & F.
·
Informed
by the candidate roadmap components identified in phases B, C, D
·
Shows
progression from baseline to target.
Techniques for
architecture development -
·
Architecture
principles
·
Stakeholder
management
·
Architecture
patterns
·
Business
Scenarios
·
Gap
analysis
·
Migration
planning techniques
·
Interoperability
requirements
·
Risk
management
·
Capability
based planning
Architecture
Principles -
·
Initial
output of preliminary phase
·
Architecture
principles template -
o Name
o Statement - To communicate rule/principle.
o Rationale - To highlight business benefit of adhering to principle.
o Implications - Effect/impact of following principle on business & IT.
Stakeholder
management -
·
Used in
phase A to identify key players and updated throughout each phase
·
Output
of this process forms part of communications plan
·
TOGAF
approach -
o Identify stakeholders
o Classify stakeholder positions
o Determine stakeholder management approach
(Power/interest matrix)
o Tailor engagement deliverables
·
Power/interest
matrix
o Minimal effort
o Keep informed
o Keep satisfied
o Key players
Architecture patterns
-
·
Architecture
patterns
·
Design
patterns
·
Idioms
- Low level patterns specific to a programming language.
·
Architecture
patterns in use -
o The US Treasury Architecture Development Guidance
(TADG)
o The IBM Patterns for e-Business
Business Scenario -
o Are methods used to help identify and understand
the business requirements that the architecture must address.
o Describes a business process, application or set
of applications.
o Describes the business and technology
environment.
o Describes the people and computing components
(actors) who execute the scenario.
o Describes the desired outcome of proper
execution.
o A good business scenario is SMART - Specific,
Measurable, Actionable, Realistic, and Time-bound.
o Mainly used in Architecture vision (Phase A) and
also Business Architecture phase (Phase B)
Gap Analysis
-
o Used to validate architecture that is being
developed.
o Technique used in phase - B, C, D & E.
o It highlights services that are yet to be
developed.
o Identify potential missing or overlapping
functions.
Interoperability
requirements -
·
Information
Interoperability:
o Knowledge management
o Business intelligence
o Information management
o Trusted identity
·
Business
Interoperability:
o Delivery networks
o e-Democracy
o e-Business
o Enterprise resource management
o Relationship and case management
·
Technical
Interoperability:
o IT infrastructure
Risk Management
-
·
Risks
are identified in Phase A as part of Business Transformation Readiness
Assessment.
·
Risk monitoring
is conducted in Phase G.
·
Initial
risk assessment is done by classifying risks with respect to effect and
frequency.
·
Effect
-
o Catastrophic - Critical financial loss
(bankruptcy)
o Critical - Serious financial loss (loss in
productivity and no ROI)
o Marginal - Minor financial loss (reduced ROI)
o Negligible
Capability based
planning -
·
Business
planning technique that focuses on business outcomes.
·
Steps -
o Phase A - Corporate strategic action must drive
this.
o Phases B, C, D - Specific capabilities must be
targeted for completion
o Phase E - Capability increments must drive this.
Architecture
Governance -
·
Governance
should be established in the preliminary phase
·
Architecture
board should ensure that ADM is being applied correctly
·
Governance
plays a key role in phases G & H.
·
Levels
of governance -
o Technology Governance
o IT Governance
o Architecture Governance
·
COBIT -
Open standard IT Governance framework
·
Process,
content and context
View & Viewpoint
-
·
View
o A view is used to describe how concerns of a
stakeholder are being met.
o Representation of an overall architecture.
·
Viewpoint
o Represents concerns of stakeholders.
o Defines how to construct and use a view
·
View
creation process -
o Refer to any existing library of viewpoints
o Select key stakeholders, analyze their concerns
and document them
o Select appropriate viewpoints
Architecture
Partitioning -
·
Need to
partition - Managing complexity, conflicts, parallel development, and reuse.
·
Solution
Partitioning -
o Subject matter (Breadth)
o Time
o Maturity/Volatility
·
Architecture
Partitioning -
o Depth (Level of detail)
·
The
Preliminary phase supports identification of appropriate architecture
partitions and establishment of governance relationship between related
architecture partitions.
ADM Iterations
-
·
Iteration
to describe a comprehensive architecture landscape.
·
Iteration
within an ADM cycle.
·
Iteration
to manage the architecture capability.
·
Architecture
Development iterations
support creation and evolution of architecture content by cycling through
phases B, C and D.
·
As
iterations converge on a target, extensions into phases E & F ensures the
viability of implementation is considered.
·
Transition
planning iteration
supports the creation of formal change roadmaps.
·
Architecture
capability iterations
support creation and evolution of architecture capability.
·
Approaches
to architecture development (iterations) -
o Baseline first
o Target first
·
Baseline first -
o An assessment of baseline landscape is used to
identify problem areas and opportunities for improvement.
o Suitable approach when baseline is complex or not
clearly understood.
o Iteration 1 - Define baseline architecture
o Iteration 2 - Define target architecture and gaps
o Iteration n - Refine baseline architecture,
target architecture and gaps
·
Target first -
o Target solution is elaborated in detail and then
mapped back to the baseline.
·
Classes of architecture engagement -
o Identification of change required
o Definition of change
o Implementation of change
·
Transition planning iteration -
o Iteration 1 - Define and agree a set of
improvement opportunities aligned against a provisional transitional
architecture
o Iteration n - Agree the transition architecture,
refining the identified improvement opportunities to fit.
·
Architecture governance iteration -
o Iteration 1 - Mobilize architecture governance
and change management process.
o Iteration n - Carry out architecture governance
and change control.
·
Organizing
architecture landscape -
o Breadth (subject matter)
o Depth
o Time
o Recency
ADM Security
-
·
Intended
to inform EA of the security architecture task and role.
·
Security
objectives have been developed for each ADM phase.
·
Typical
security artifacts -
o Business rules regarding handling of
data/information assets.
o Written and published security policy
o Codified data/information asset ownership and
custody
o Risk analysis documentation
o Data classification policy documentation
Miscellaneous
·
Request
for Architecture word document - This document is used to initiate a TOGAF ADM
cycle.
·
Purpose
of enterprise architecture - To optimize an enterprise into an environment that
is responsive to business needs.
·
Theory
suggests that data architecture comes first but that is not a rule.
·
Types
of TOGAF tailoring -
o Terminology tailoring
o Process tailoring - Tailoring ADM
o Content tailoring - using Architecture content
framework
·
There
are four architecture domains within TOGAF: business, data, application, and
technology (BDAT)
References
–