«    »

Impressions of TOGAF

I recently took a four day course on TOGAF - The Open Group Architecture Framework covering both Part I (foundation) and Part II (certified), and I wanted to share my impressions. The TOGAF standard is available online and has an excellent executive summary. The following quotes serve as an elevator pitch for TOGAF:

TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture.

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Overall, I feel that learning about TOGAF was quite beneficial. If you are an architect, especially at the enterprise or solution level, I recommend taking the course.


One of the biggest strengths of TOGAF, in my opinion, is the core concepts it espouses throughout the framework. The TOGAF standard weighs in at almost 700 pages, making it virtually impossible to remember all the details. These concepts are valuable in their own right and serve as a summary of much of the content.

Architecture Domains

Architecture domains is the first core concept. TOGAF divides architecture into four domains:

  1. Business
  2. Application
  3. Data
  4. Technology

The order is intentional. In TOGAF, business architecture comes first. One lesson I personally took away from this is to always explicitly identify business drivers for any request for architectural work. Better understanding the business has been an increasing focus for me over the last few years, and TOGAF really drives this point home. All too often as architects we are presented with problems concerning solutions, applications, or technology, and sometimes I have discovered that the issue being worked on will not actually address the underlying business need. We in I.T. are quick to offer up solutions / technologies when asked without taking even a few minutes to understand what the business is really trying to accomplish.

Gap Analysis

The second core concept is using a process of understanding the baseline (current) and target (future) state, then doing a gap analysis to serve as the basis for defining the building blocks (aka components) that are required to achieve the target architecture (in any domain). At first glance this seems obvious, but there are actually different scenarios that the gap analysis can identify:

  1. Components that do not currently exist but are required in the target architecture, and thus need to be obtained. (This is the obvious scenario.)
  2. Components that currently exist and are missing from the target architecture because they are not required, which means they can be decommissioned.
  3. Components that currently exist, but are missing from the target architecture because they were forgotten - they are actually still needed. This means the target architecture needs to be revised to include them.
  4. Components that currently exist and are present in the target architecture, but which currently do not meet all the needs of the target architecture. These components will need to be enhanced.
  5. Components that currently exist and map perfectly to the target architecture. No gap exists, so nothing needs to be done.

The outcomes required from these various scenarios lead directly to the next core concept.

Migration Planning

TOGAF has phases in its architecture development method for determining how to implement organizationally a target architecture, linking as required with other enterprise processes such as budgeting, project management, procurement, etc. Based on my own experience, it is easy to come up with a vision of a better future for an organization but much harder to turn it into reality. So I am quite happy to see TOGAF explicitly emphasize this in its method.

Architecture Governance

Ensuring ongoing alignment across an enterprise with an architecture is a difficult problem - one that is often ignored. TOGAF has an explicit phase called Implementation Governance to ensure that this is addressed.

Fitness for Purpose Principle

Each piece of documentation (i.e. artifact / deliverable) produced has a purpose: it needs to address the specific concerns of a set of stakeholders, who need to be able to understand it. Documentation should not be produced otherwise.


As the quote goes, all models are wrong but some are useful, and TOGAF is no exception. Below are some of the key aspects of the material that I found lacking.


TOGAF is written by architects who understand the importance of context. This is good - TOGAF provides the flexibility of customization and tailoring to fit the enterprise, and avoids being overly prescriptive. Unfortunately, one side effect is that some of the phases of the architecture development method like Migration Planning and Implementation Governance end up feeling rather vague. The concept of each phase is clear, but how to specifically do it is not really specified.

Formality Bias

Both the standard as written and the course material seem to emphasize a heavily formalized approach with a large set of deliverables, use of sign-offs and contracts, and the like. The course instructor, however, explained that TOGAF is just as useful as an informal model, and gave an example where when presented with a particular problem one could run through an iteration of the architecture development cycle mentally within a few minutes.

For a recent rushed project I was involved in that was done relatively informally, I was able to map many of the initial architecture discussions and whiteboard drawings to TOGAF phases, which was further confirmation to me that TOGAF can be applied informally.

Unfortunately, the formality bias of TOGAF might deter architects with a low-ceremony mindset from learning about it. That was one of the reasons I myself held off learning about TOGAF until now.

Integration with Agile Development

While TOGAF does discuss iteration, it is only limited to iteration within architecture development. TOGAF does not address at all integrating architecture with agile development methods, which I find surprising given the wealth of material I have seen on the subject. See for example the book Disciplined Agile Delivery by Scott Ambler and Mark Lines. Hopefully the next version of TOGAF addresses this lack.

Change Management

The change management phase of TOGAF's architecture development method (ADM) feels arbitrarily jammed in to fit the model. The steps described in the phase really describe ongoing processes rather than an explicit phase of architecture development. I really feel this should have been modeled within the ADM in the same fashion as requirements management.

If you find this article helpful, please make a donation.

«    »