A Practical Tutorial for TOGAF

TOGAF is an architecture framework that is the de facto global standard for assisting in the acceptance, production, use, and maintenance of architectures. Practical and proven, it is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.

• The first version of TOGAF, developed in 1995, was based on the US Department of Defense Technical Architecture Framework for Information Management (TAFIM).
• This document covers TOGAF Version 9, referred to as “TOGAF 9” within the text of this document. TOGAF 9 was first published in January 2009.
• TOGAF is developed and maintained by The Open Group Architecture Forum and its 350 members.

Why TOGAF?

TOGAF 9 can be used for developing a broad range of different enterprise architectures. TOGAF complements and can be used in conjunction with, other frameworks that are more focused on specific deliverables for particular vertical sectors such as Government, Telecommunications, Manufacturing, Defense, and Finance.

• A proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency
• The most prominent and reliable enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals
• Enterprise architecture professionals fluent in TOGAF standards enjoy greater industry credibility, job effectiveness, and career opportunities
• TOGAF helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment

TOGAF 9 – Six Components

TOGAF reflects the structure and content of an architecture capability within an enterprise, as shown in Figure below:

1. Architecture Development Method – This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an enterprise architecture.
2. ADM Guidelines and Techniques – This part contains a collection of guidelines and techniques available for use in applying the ADM.
3. Architecture Content Framework – This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.
4. Enterprise Continuum and Tools – This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
5. TOGAF Reference Models – This part provides two architectural reference models, namely the TOGAF Technical Reference Model (TRM), and the Integrated Information Infrastructure Reference Model (III-RM).
6. Architecture Capability Framework – This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.

ADM: The Central Part of TOGAF

The ADM describes how to derive an organization-specific enterprise architecture that addresses business requirements. The ADM is the major component of TOGAF and guides architects on several levels:

• The core of TOGAF
• A proven way of developing an architecture
• Specifically designed to address business requirements
• An iterative method
• A set of architecture views to ensure that a complex set of requirements are adequately addressed

1. ADM – Iterative Approach to the TOGAF ADM

The ADM is iterative, over the whole process, between phases, and within phases (the suggested iteration cycles for the TOGAF ADM as shown in the Figure). It can also be used to effectively group related architectural activities (Architecture Capability, Architecture Development Iteration, Transition Planning Iteration, and Architecture Governance Iteration) to achieve a specific purpose.

The Purpose of TOGAF ADM Development Phases

Phases within the ADM are as follows:

• The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles.
• Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
• Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
• Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision.
• Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision.
• Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase
• F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
• Phase G: Implementation Governance provides architectural oversight of the implementation.
• Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
• Requirements Management examines the process of managing architecture requirements throughout the ADM.

ADM Input and Output

TOGAF provides several input and output deliverables from each phase:

• These are suggestions and need not be followed exactly
• Each deliverable produced should be versioned to indicate when a change has occurred
• The version numbering shown is also a suggestion and need not be followed

Deliverables

A work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. It will typically be archived after a project or transitioned into an Architecture Repository as a reference model

2. ADM Guidelines and Techniques Component

A set of guidelines and techniques to support the application of the ADM. The guidelines help to adapt the ADM to deal with different scenarios, including different process styles (e.g. the use of iteration) and also specific requirements (e.g. security). The techniques support specific tasks within the ADM (e.g. defining principles, business scenarios, gap analysis, migration planning, risk management, etc). Guidelines and Techniques to support the application and adoption of the ADM

Guidelines: i.e. how to applying the ADM across the Architecture Landscape

Templates – Guide you how to perform Stakeholder Analysis using Template

Checklists – An Architecture Review Checklist example for Overall Architecture

1. What other applications and/or systems require integration with yours?
2. Describe the integration level and strategy with each.
3. How geographically distributed is the user base?
4. What is the strategic importance of this system to other user communities inside or outside the enterprise?
5. What computing resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise computing assets? Outside the enterprise and using their assets?
6. How can users outside the native delivery environment access your applications and data?
7. What is the life expectancy of this application?
8. Describe the design that accommodates changes in the user base, stored data, and delivery system technology.
9. What are the size of the user base and their expected performance level?
10. What performance and stress test techniques do you use?

Techniques – Show you how to categories of Stakeholder

3. Architecture Content Framework Component

This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables. It provides a detailed model of architectural work products, including Deliverables, Artifacts within deliverables, and the Architecture Building Blocks (ABBs) that deliverables represent.

• It drives for greater consistency in the outputs of TOGAF
• It provides a comprehensive checklist of architecture outputs
• It promotes better integration of work products
• It provides a detailed open standard for how architectures should be described
• It includes a detailed metamodel

4. Enterprise Continuum

A Model for Structuring a Virtual Repository and Methods for Classifying Architecture and Solution Artifacts. It has the following changes in TOGAF 9:

• Substantially revised
• New content added on Architecture Partitioning and the Architecture Repository
• The Standard Information Base (SIB) is removed

5. Reference Models

The definition of the Reference Models is substantially revised in TOGAF 9. There are two reference models are provides:

1. Technical Reference Model (TRM) – A Foundation Architecture which serves as a model and a taxonomy of generic platform services.
2. Integrated Information Infrastructure Model (III-RM) – A model for business application and infrastructure application

Relating Reference Models to Architecture Continuum

Architecture Continuum is composed of four states. The underlying process is to discover architectural requirements, analyze and understand architectures that are already in place in the organization, from foundation architectures (i.e. TRM), through common systems architectures III-RM), industry-standard architectures, (i.e. SOA), and to an organization’s architecture. The Figure below is an illustration of an architectural process based on four states:

• Foundation architectures (TRM)
• Common system architectures (III-RM)
• Industry architectures
• Organization architectures

Architectural changes made to states at the left will migrate to states at the right. The left-to-right direction implies a logical progression in organizing an enterprise architecture implementation.

6. Architecture Capability Framework Component

This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise. It is a new part in TOGAF 9 and derived based on the 8.1.1 Resource Base

Structure of Architecture Capability

An enterprise architecture development involves the generation of business capability, planning and managing architecture in the organization on all levels through different development phases. The enterprise needs to identify the governance bodies which is responsible to make architecture decisions as shown on the top of the Figure below.