Mar
12
2013

An introduction to TOGAF

togaf-home-graphic-R

Hi all !

In this post I’ll cover the basic TOGAF principles and purposes.

What is it ?

The typical enterprise architecture can have four sub-types:

togaf_architecture

TOGAF stands for the The Open Group Architectural Framework. This means  that TOGAF, empowers you to design, evaluate, and build the right IT architecture for your organization. TOGAF also addresses those parts of the business, data and application architectures that impact on the development of the IT architecture.

Why TOGAF and not other EA ?

If you are already a solutions architect looking for a technique or a framework to structure a whole group of enterprise IT processes, it might be interesting to explore TOGAF. If you’re an engineer like myself  whose aim is to pursue a career as an enterprise architect studying TOGAF, could also be an interesting  source of information.

TOGAF is not the only EA architecture around. There are others like:

  • Zachman Framework
  • Federal Enterprise Architecture
  • The Gartner Methodology

Each of these EA architectures has its own strengths and weaknesses which  I won’t cover here. On Microsoft’s library there’s a very good article about it. The main advantages of TOGAF comparing  with similar EA are :

  • Free: to use and implement. No licencing fees are associated with implementing TOGAF on your organization.
  • Supported by the Open Group : the open group is a not-for-profit consortium committed to delivering greater business efficiency by bringing together buyers and suppliers of information systems to lower the barriers of integrating new technology across the enterprise
  • Vendor neutral:  it is not likely you get locked-in to a specific consulting organization by adopting this methodology.
  • Information availability:  amount and quality of free or inexpensive information about this methodology is high.
  • Process completenessTOGAF guides you through a step-by-step process for creating an enterprise architecture.

What would my role be as an Enterprise Architect ?

First of all, you should also be a great communicator. You should be able not only to listen but also to find common ground when a range of opposite technology  are on the discussion table.

Businessman Conducting a Meeting with His Staff

EA architects need roughly 50% communication skills, 25%   ability to understand the business model, and 25% ability to understand the actual supporting technology.

As an enterprise architect you can become responsible for :

* defining the delivery process
* defining or determining the key stakeholders that will help enforcing the defined delivery process
* defining or determining how the interactions between members of different teams should occur
* understanding the difference between business architecture and IT architecture and suggest integration bridges between both of them.

You can also become responsible for defining common standards for the whole enterprise.

How do I use TOGAF?

To understand how we can do architecture in an organization from the TOGAF perspective, lets look into the TOGAF ADM(Architecture Development Method) guidelines and techniques.

The TOGAF ADM  is described in the picture below:

TOGAF ADM

Everything starts at the PRELIMINARY PHASE, and from there, we enter the ADM cycle from A to H, updating the REQUIREMENTS MANAGEMENT inner phase along the way.

The basic principle of the ADM is that every phase is validated against and validates the current requirements of the business.I will now briefly describe each ADM phase. The list of outputs produced as a result of each phase is quite large, so please consider the description of outputs for each phase a summary. I’ve also included references to the TOGAF 9.1 specs pdf book, so if you are curious about the deliverables details, just check the book, or wait for my next posts ;)

Preliminary Phase

In this phase we prepare the organization to undertake a successful enterprise project. Typically this process only happens once according to the  following steps :

  1. Assess the maturity of the organization.
  2. Look for EA architects within the company and try to understand if they already have a method to do enterprise architecture and if that method is being followed.
  3. Define what principles should be put in place.
  4. Determine who is the approval authority and how governance will be made.

Phase Inputs :

  • high level business requirements.

Phase Outputs:

Organizational Model for Enterprise Architecture (see Part IV, Section 36.2.16), including:

  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy

Tailored Architecture Framework (see Part IV, Section 36.2.21), including:

  • Tailored architecture method and content (deliverables and artifacts)
  • Architecture Principles (see Part IV, Section 36.2.4)
  • Configured and deployed tools

Other outputs include:

  • Initial Architecture Repository (see Part IV, Section 36.2.5), populated with framework content
  • Restatement of, or reference to, business principles, business goals, and business drivers (see Par t IV, Section 36.2.9)
  • Request for Architecture Work (optional) (see Part IV, Section 36.2.17)
  • Architecture Governance Framework

(Phase A) Architecture Vision

This is the first phase of the iteration process, where the main documents to be created are the architecture vision document and the statement of architecture work. In this phase, the scope, expectations and constraints are defined. It is up to the EA architect to meet the various project stakeholders and not only to validate with them the business context, but also to make all the stakeholders agree on a common vision.

Phase Inputs :

  • data from the preliminary phase.

Phase Outputs:

Approved Statement of Architecture Work (see Part IV, Section 36.2.20), including in
particular:

  • Architecture project description and scope
  • Overview of Architecture Vision
  • Architecture project plan and schedule

Architecture Vision (see Part IV, Section 36.2.8), including:

  • Problem description
  • Objective of the Statement of Architecture Work
  • Summary views
  • Business Scenario (optional)
  • Refined key high-level stakeholder requirements

Draft Architecture Definition Document, including (when in scope):

  • Baseline Business, Technology,Data and Application Architecture, Version 0.1
  • Target Business, Technology,Data and Application Architecture, Version 0.1

Other outputs include:

  • Refined statements of business principles, business goals, and business drivers (see Part IV, Section 36.2.9)
  • Architecture principles (see Part IV, Chapter 23)
  • Capability Assessment (see Part IV, Section 36.2.10)
  • Tailored Architecture Framework (see Part IV, Section 36.2.21)
  • Communications Plan (see Part IV, Section 36.2.12)
  • Additional content populating the Architecture Repository

(Phase B) Business Architecture

In this phase we should create, but not close, two documents; the architecture definition document that will be populated through phases C,D,E,F ; the requirements specification document that will have quantitative descriptions like service level agreements(SLAs).

To create the architecture definition document the following steps should be taken:

  1. Select reference models, viewpoints and tools.
  2. Define the Baseline Architecture Description.
  3. Define the Target Architecture Description.
  4. Perform GAP analysis.
  5. Define roadmap components.
  6. Conduct formal stakeholder review.
  7. Finalize the Architecture.
  8. Create the Architecture Definition Document.

Phase Inputs :

  • data from the preliminary phase.

Phase Outputs:

Draft Architecture Definition Document (see Part IV, Section 36.2.3), including:

  • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
  • Target Business Architecture, Version 1.0 (detailed)
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns

Draft Architecture Requirements Specification (see Part IV, Section 36.2.6, on page 440)
Other outputs include:

  • updated Statement of Architecture Work from previous phase(see Part IV, Section 36.2.20)
  • validated previous business principles, business goals, and business drivers (see Par t IV, Section 36.2.9)
  • updated Architecture principles from previous phase

(Phase C) Information Systems Architecture

In this phase we should identify the major types of information and the application systems that process them. We should be able to identify :

  • the relationship between IT systems.
  • the relationship between IT systems and the environment. 
  • the principles governing the design and evolution of IT systems.

Phase Inputs :

  • data from the preliminary phases.

Phase Outputs:

Draft Architecture Definition Document (see Part IV, Section 36.2.3), including:

  • Baseline Data and Application Architecture, Version 1.0
  • Target Data and Application Architecture, Version 1.0
  • Data Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Application Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns

Draft Architecture Requirements Specification (see Part IV, Section 36.2.6), including such Information Systems Architecture requirements as:

  • Gap analysis results
  • Relevant technical requirements that will apply to this evolution of the architecture development cycle
  • Constraints on the Technology Architecture about to be designed
  • Updated business requirements, if appropriate

Other outputs include:

  • Refined and updated versions of the Architecture Vision phase deliverables
  • Information systems components of an Architecture Roadmap (see Par t IV, Section 36.2.7)

(Phase D) Technology Architecture 

In this phase we describe the fundamental organization of an IT system embodied in :

  • hardware, software and communications technology.

Phase Inputs :

  • data from the preliminary phases

Phase Outputs:

Draft Architecture Definition Document (see Part IV, Section 36.2.3), including:

  • Target Technology Architecture, Version 1.0 (detailed)
  • Baseline Technology Architecture, Version 1.0 (detailed), if appropriate

  • Views corresponding to the selected viewpoints addressing key stakeholder concerns

Draft Architecture Requirements Specification (see Part IV, Section 36.2.6), including such Technology Architecture requirements as:

  • Gap analysis results
  • Requirements output from Phases B and C
  • Updated technology requirements

Other outputs include:

  • Refined and updated versions of the Architecture Vision phase deliverables
  • Technology Architecture components of an Architecture Roadmap

(Phase E) Opportunities and Solutions

In this phase we typically define the implementation strategy. This strategy should take into account what projects should  be developed and the identified transition phases/architectures. If possible the service provider should also be included in this analysis.

Phase Inputs :

  • data from the preliminary phases.

Phase Outputs:

Draft Architecture Definition Document (see Part IV, Section 36.2.3), including:

  • updated Baseline and Target Business Architectures, Version 1.0
  • updated Baseline and Target Data Architectures, Version 1.0
  • updated Baseline and Target Application Architectures, Version 1.0
  • updated Baseline and Target Technology Architecture, Version 1.0
  • Transition Architecture - Transition roadmap from baseline architecture to target architecture
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns

Capability Assessments, including:

  • Business Capability Assessment
  • IT Capability Assessment

Architecture Roadmap (see Part IV, Section 36.2.7), including:

  • Work package portfolio
  • Identification of Transition Architectures, if any
  • Implementation recommendations

Implementation and Migration Plan, Version 0.1, including:

  • Implementation and Migration Strategy

Other outputs include:

  • Draft Architecture Requirements Specification (see Par t IV, Section 36.2.6)

(Phase F) Migration Planning

In this phase for the projects identified in the previous phase, we should perform a cost/benefit analysis and also perform a risk assessment. We should also help the stakeholders to prioritize the projects 0f the previous phase by developing a detailed implementation and migration plan. In this phase the Requirements Specification Document is also closed and delivered to the implementation team at the beginning of the PHASE G.

Phase Inputs:

  • data from the preliminary phases

Phase Outputs:

Implementation and Migration Plan, Version 1.0 (see Par t IV, Section 36.2.14), including:

  • Implementation and Migration Strategy
  • Project and portfolio breakdown of the implementation.
  • optional project charters like related work packages, business value, etc..

Other outputs include:

  • Finalized Architecture Definition Document (see Part IV, Section 36.2.3)
  • Finalized Architecture Requirements Specification (see Part IV, Section 36.2.6)
  • Finalized Architecture Roadmap (see Part IV, Section 36.2.7)
  • Re-Usable Architecture Building Blocks (see Part IV, Section 36.2.1)
  • Implementation Governance Model (if any) (see Part IV, Section 36.2.15)
  • Change Requests for the Architecture Capability arising from lessons learned

If a new iteration of the ADM cycle is going to be started a Requests for Architecture Work (see Part IV, Section 36.2.17) could also be produced as output of this phase.

(Phase G) Implementation Governance

In this phase we should provide an architecture oversight for the implementation. This can be achieved through recommendation guidance and compliance reviews.

Phase Inputs:

  • data from the preliminary phases.

Phase Outputs:

Architecture-compliant solutions deployed including:

  • The architecture-compliant implemented system. The implemented system is actually an output of the development process, but given the importance of this output, it is stated here as an output of the ADM. The direct involvement of architecture staff in implementation will vary according to organizational policy.
  • Populated Architecture Repository
  • Architecture compliance recommendations and dispensations
  • Recommendations on service delivery requirements
  • Recommendations on performance metrics
  • Service Level Agreements (SLAs)
  • Architecture Vision, updated post-implementation
  • Architecture Definition Document, updated post-implementation
  • Business and IT operating models for the implemented solution

Other outputs include:

  • Signed Architecture Contract
  • Compliance Assessments (see Par t IV, Section 36.2.13)
  • Change requests

(Phase H) Architecture Change Management

The purpose of this phase is to provide continual monitoring and a change management process that will ensure that the changes to the architecture are managed in a cohesive and architected way.

Phase Inputs:

  • data from the preliminary phases.

Phase Outputs:

  • Architecture updates (for maintenance changes)
  • Changes to architecture framework and principles (for maintenance changes)
  • New Request for Architecture Work (see Part IV, Section 36.2.17), to move to another cycle (for major changes)
  • Statement of Architecture Wor k (see Part IV, Section 36.2.20), updated if necessary
  • Architecture Contract (see Part IV, Chapter 49), updated if necessary
  • Compliance Assessments (see Part IV, Section 36.2.13), updated if necessary

Final thoughts

All these phases may seem a little theoretical or not depending on your own experience. In the next series of TOGAF articles I’ll go deeper on each one of these phases.

References

[1] The Open Group; Leading the development of open, vendor-neutral IT standards and certifications ; http://www.opengroup.org

[2] Van Haren Publishing; Togaf V9 Pocket Guide; http://www.vanharen.net

[3] Wikipedia; The Zachman Framework ; http://en.wikipedia.org/wiki/Zachman_Framework

[4] Microsoft; A comparison of the top 4 Enterprise Architectures ; http://msdn.microsoft.com/en-us/library/bb466232.aspx

[5] Mike the Architect; TOGAF templates;  http://www.mikethearchitect.com/2012/10/togaf-templates.html

[6] The Open Arch; TOGAF 9 templates ; http://theopenarch.com/download

[7] Experiences of an IT Architect ;IT Architecture Report ; http://archreport.wordpress.com/

  • http://www.facebook.com/carl.nakamura.7 Carl Nakamura

    Nice introduction and writeup for people not familiar with TOGAF.

    Thanks!