Part1: TOGAF luuuurvs Agile!

Intro — Structures and Agile methods can coexist and sometimes, they just have to, to keep things moving.

There is a common misconception that I come across day-to-day in some environments which seems to indicate a disconnect between the opinion of TOGAF in the development community and what it truly entails.

This is particularly evident in the world of agile methods, where such things as ‘up front design’, ‘documentation’ and ‘long term strategy’ are often cited as reasons to compete in the ‘urinational’ championships.

The truth of the matter is Agile and Enterprise architecture frameworks cover different domains, though agile Methodists can’t seem to generalise their thinking into the enterprise architecture world whilst TOGAF practitioners definitely can scale down (even if they can’t write code). This post will attempt to address the 12 principles of the agile manifesto and relate them to TOGAF 9.x. However, in order to do that, an incredibly quick, summary crash course in TOGAF will be ‘just enough’ information to get the job done :-)

In the first of a series of posts, I’ll look at what TYOGAF is, how it helps enteprise scale programmes and crucially, why most people mistakely reject TOGAF s too heavyweight.


TOGAF 9.x Overview

The Open Group released the version 9 of the TOGAF standard in 2009. It is a set of structured tools, including an iterative Architecture Development Method (ADM for short), reference models, content framework,
enterprise continuum and repositories for the production of a set of interconnected functional and reusable enterprise capabilities for the satisfaction of varying levels of strategy, when constraining a business (which is just a system like any other) by factors such as legislation, finance, time, organisational capabilities, business goals and other constraints.

What this allows is the ability to bridge the gap between the CEO/CIO vision and strategy and the operation of a company in terms of its capabilities to deliver that vision, including the IT functions.

TOGAF concentrates its architectural effort on four domains of architecture. Namely:

  • Business Architecture
  • Information Systems Architecture, which is subdivided into:
  • Data Architecture
  • Application Architecture
  • Technology Architecture

…and it can be applied at many different levels by going through an ‘architecture partitioning’ exercise which create strategic architecture (which may be a 5 year plan for the whole enterprise), segmented architectures and capability architectures, in order of increasing levels of detail and decreasing levels of scope.

An IT department is but one capability in a myriad of others, such as HR, Customer Services and Finance. It just so happens that it is significant enough a capability to have dedicated responsibilities in phases of the ADM at the capability architecture level.

Additionally, TOGAF specifies the use of Architectural Principles, which are reasoned, qualitative, yet normative statements which constrain the architectural solution space in some way. They can be based on regulatory, best-practice, performance, security, auditing dimensions, amongst a host of others, but they generally pertain to one of the four groupings of:

  • Assurance
  • Adaptability
  • Availability
  • Usability

However, in all cases, they must be SMART goals.

  • Specific
  • Measurable
  • Achievable
  • Realistic
  • Time-boxed

When the ADM is started, there can be many cycles at many levels and they may all use the ADM to deliver the capability. So a strategic enterprise architecture exercise may initiate a 5 year plan together with segmented architectures to look at which are segmented deliverables, which will in turn be broken down through their own ADM instance to capabilities for each segment, which can be delivered using the ADM. Alternatively, an iteration of the ADM may deliver a higher level architecture, which initiates the development of lower level capabilities after it has been completed.

An IT capability can easily be delivered using agile principles, but a few things have to come to the fore and the TOGAF terminology, which is foundational in nature, needs to be augmented with and a mapped to common systems terminology (such as security, auditing, monitoring functions), industry architecture concepts (such as those general to all travel agents, or HR systems) and specific organisational terms.

How does Agile fit within this?

Enterprise architecture, whether agile or not, is the bridge between the business strategy delivered by a board and all the different capabilities that exits in an organisation. The corporation’s vision, portfolio, strategy and governance are input to it and the capabilities (of which IT is but one part) are output after each iteration of the ADM, either in the form of transition architectures or target architecture.

Agile methods deliver the functional technology that makes the application and data architectures happen, which are in turn delivered by the technology architecture phase. However, half the problem is that an exercise connecting the terminology used by enterprise architects and solution level developers is normally never carried out.

TOGAF mandates this exercise as the framework is very abstract and The Open Group were so aware of the effects of this abstraction on the use and uptake of TOGAF, that they strongly encourage the use of a reference library which maps TOGAF terminology to the terms used in specific capabilities in the enterprise and/or to the enterprise as a whole. Without this, a large amount of confusion can occur, for example what does a ‘service’ mean to different people?

Next time, we will start to look at how the Agile Manifesto’s 12 principles can be mapped to TOGAF’s use.


This article first appeared in GoadingTheITGeek in April 2012. It was the most visited article with 4,490 readers.


Like this article? Let other people know about it by hitting the heart.

Show your support

Clapping shows how much you appreciated Ethar Alali’s story.