An Overview Of TOGAF L1 / L2

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 1
 The Architecture Framework L1 / L2

The Open Group Architecture Framework (TOGAF) is

a tool for assisting in the acceptance, production,
use, and maintenance of enterprise architectures

It is based on an iterative process model supported

by best practices and a re-usable set of existing
architectural assets.
 
It is developed and maintained by The Open Group
Architecture Forum.

The first version of TOGAF, developed in 1995, was

based on the US Department of Defence Technical
Architecture Framework for Information
Management (TAFIM).

It has also incorporated elements from most of the

other major architecture approaches from across the
industry (e.g. Zachman, DODAF, MODAF, FEAF) into
an overall consistent framework and development
process.
 

– T
© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 2
 The Four Major Viewpoints Of The Architecture Framework L1 / L2

The latest version, TOGAF 9, was introduced in 2009.

It can be used for developing a broad range of
different enterprise architectures. TOGAF
Preliminary
complements, and can be used in conjunction with,
other frameworks that are more focused on specific Understanding your capability
deliverables for particular vertical sectors such as and setting the context
Government and Telecommunications. TOGAF is

A
• A framework, not an architecture Architecture
Creating , Defining
• A generic framework for developing architectures Vision
implementing the
to meet different business needs
& governing H B architecture
• Not a “one-size-fits-all” architecture solution Architecture Business building
• Focuses on business IT alignment building Change Architecture
blocks
Management
• Based in best practices blocks
• Widely adopted in the market C
G Information
• Tailorable to meet an organisation and industry Implementation
Requirements
Systems
Management
needs Governance Architecture

It is broken down into phases that have a continuous F D

Migration Technology Identifying
flow into each other as an organisation evolves its Planning Architecture
capability and the associated architecture views. candidate
solution
E
Opportunities building
The specific architectural elements within TOGAF are: & blocks
Final choice of
Solutions
solution building blocks
• Business architecture and implementation and
• Information systems architecture transition
• Technology architecture planning

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 3
 Document Deliverables Around the Lifecycle (Outputs) L1 / L2
Business Principles, Goals & Drivers
Each phase can Request For Architecture Work
generate a set Organisation Model For Enterprise Architecture Preliminary
Architecture Repository Approved Statement of Architecture Work
of deliverables Tailored Architecture Framework Communications Plan
to help manage Governance Framework Tailored Architecture Framework
Architecture Principles Architecture Vision
the evolution of Architecture Principles
Architecture Tools
the enterprise Capability Assessment
architecture Vision Architecture Definition Document
A Vision Architecture Requirements Specification
and each Architecture Vision Candidate Roadmap
specific change Vision
introduced into Approved Statement of Architecture Work
Managed Draft Architecture Definition Document (Business)
the Architecture Update H B Draft Architecture Requirements Spec. (Business)
organisation. Architecture Business Business Architecture Principles
Change Architecture Candidate Roadmap
Management
Signed Architecture Contract
Solution Building Block C Approved Statement of Architecture Work
Compliance Assessment G Information
Requirements Draft Architecture Definition Document (IS)
Architecture Compliant Solution Implementation Systems
Management Draft Architecture Requirements Spec. (IS)
Governance Framework Governance Architecture IS Architecture Principles
Change Request
Candidate Roadmap

Request For Architecture Work F D

Final Architecture Definition Document
Final Architecture Requirements Spec.
Final Architecture Roadmap
Final Transition Architecture
Draft Architecture Contract
Implementation & Migration Plan
Implementation & Migration Strategy
Implementation Governance Model
Finalised Architecture Building Block
Change Request
Consolidated Architecture Roadmap ( ) Transition Architecture
Migration Technology Approved Statement of Architecture Work
Planning ** Architecture Draft Architecture Definition Document (Technology)
Draft Architecture Requirements Spec. (Technology)
Technology Architecture Principles
E Candidate Roadmap
Opportunities
Architecture Requirement
&
Solutions Requirements Impact Assessment **
Approved Statement of Architecture Work
Draft Architecture Definition Document
Draft Architecture Requirements Spec.
(Initial) Implementation & Migration Plan
(Initial) Implementation & Migration Strategy

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 4
 The Content Framework Metamodel L1 / L2

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 5
 Example Specific Architecture Artefacts In The Content Framework L1 / L2

Preliminary Architecture Vision

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 6
 Making Sense Of The Capabilities and Layering L1 / L2

• The TOGAF content framework Identify which specific abilities a business should have
differentiates between the Business
processes of a business and the strategy layer Competencies Capabilities
services of a business.
provide the context for choosing which services to offer
– Business services are
specific processes that
have explicit, defined Business
boundaries that are management Business Services
explicitly governed. layer provide the contractual
terms for the execution of
– Services are
distinguished from provide the context for manage require the
processes through the and sequencing of the state of participation
Logical
explicit definition of a of
operations Processes Procedures Entities
service contract that
layer (Algorithms)
defines a post condition (Activities) (Objects)
and it performance
attributes. record
may invoke identify the processing required by the
state
• The granularity of business
IS / Application Services of
services should be determined
according to the business Physical
drivers, goals, objectives, and operations Application Data
change the
measures for this area of the layer Components state of Entities
business. Finer-grained services provide the
permit closer management and execution Platform/Technology/Infrastructure Services
measurement (and can be platform for
combined to create coarser-
grained services), but require Technology Components
greater effort to govern.

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 7
 Completing The Business Architecture View (POPIT) L1 / L2

Identify which specific abilities a business should have

Business
strategy layer Competencies Capabilities

provide the context for choosing which services to offer

Business
management
Business Services
provide the contractual
layer terms for the execution of

provide the context for manage require the

and sequencing of the state of participation
Logical of
operations Processes Procedures Entities
layer (Activities) (Algorithms) (Objects)
record
identify the processing required by the
may invoke
state
IS / Application Services of

Application Data
People Organisation Components
change the
Entities
state of
(Roles) (Structures)
Physical
operations provide the Platform/Technology/Infrastructure Services
layer Facilities and Non execution
platform for
Computing Technology Technology Components

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 8
 Solution Architecture Conformance Checkpoints

Project Management Cycle

Opportunity Feasibility Deliver Realise

Enterprise Architecture Conformance Cycle

Develop initial Develop high level Review on-going development, Review in-life reality against architectural expectations
architectural view solution architecture back track to develop high level solution architecture if respond appropriately
and align to enterprise changes during detailed design and build require it
architecture

EA Review Gate 1 EA Review Gate 2 EA Review Gate 3 EA Review Gate 4

Record project as Confirm or otherwise of Confirm or otherwise of architecture Identify effectiveness of
architecturally architecture compliance for compliance for specific solution that has architectural decisions and capture
impacting or exempt specific solution to be developed been developed learning points for improvement

Business Investment Cycle

Investment Business case Value creation Benefits
proposal realisation

© Enterprise Architecting / M.J. Anniss Ltd & The Open Group 2015 Slide 9