Blog Posts BPMN Service Oriented Architecture (SOA)

TOGAF vs. Zachman: Choosing an Enterprise Architecture Framework

Blog: Good eLearning

When people think of ‘enterprise architecture (EA)’, TOGAF is always one of the first things that come to mind. After all, ‘The Open Group Architecture Framework’ has been setting the standard in EA for nearly two decades.

Because of this, it can be easy to forget that TOGAF is by no means perfect. Senior practitioners can often name a few things ‘wrong’ with TOGAF, primarily in the sense of what kind of experience and expertise is required to get the most out of the framework. Indeed, adopting TOGAF is not always the best choice – not that it is the only solution on the market.

One of the most prominent competitors for TOGAF is the ‘Zachman’ enterprise architecture framework. Developed by John Zachman in 1987, it was originally created for the sake of IT-driven businesses and has remained relevant even as digital and IT management continues to evolve.

So, what is it that distinguishes the TOGAF and Zachman frameworks for enterprise architecture? How can enterprise architects choose which framework is right for them? In this article, we’re going to answer the debate once and for all!

TOGAF vs. Zachman comparison

The TOGAF framework

An ‘enterprise architecture’ is a representation of the structure of an organization and the relationships between the functions and stakeholders within. It offers a level of perspective that can be of great help when organizing large scale changes, as well as optimization initiatives in general.

Developing a concise enterprise architecture requires an awareness of the relevant elements and connections. Given how vastly businesses, departments, and teams can differ, enterprise architects also need a certain degree of versatility, and this is where TOGAF comes in.

TOGAF’s methodology lays out processes for designing, planning, implementing, and governing enterprise architectures. It is open and adaptable, helping businesses to avoid being locked-in with specific EA consultants or vendors. At the same time, it also helps to create artifacts that can be scaled and adapted over time, removing the need to worry about elements like technological integration, mounting costs, security, and so on.

The key to TOGAF’s success is the ‘Architectural Development Method (ADM)’, a non-prescriptive guide to EA development. It can be adapted and even reordered depending on the requirements of the user. The ADM also works as part of an interactive and ongoing cycle, making the process of incorporating new elements far more organic.

Architecture vision – The first phase of the ADM looks at the scope of the EA project and identifies key stakeholders. Goals are communicated between relevant parties, and a capability assessment is usually carried out to assess the viability of the existing enterprise architecture.
Business architecture – In this phase, business modeling and analysis are conducted. Stakeholders help establish tangible targets for the sake of meeting Architecture Vision.
Information systems architecture – Data and application architecture analysis is performed to support the Architecture Vision. As with the previous phase, tangible targets are also established.
Technology architecture – This phase addresses what kind of technological infrastructure will be required to not only meet the Architecture Vision but also support the targets established in phases two and three. Input and approval will be required from IT managers and technology-focused executives.
Opportunities & solutions – This phase examines implementation scenarios in light of the architectural design choices made previously. Actors will also need to weigh technical and business considerations in order to establish an acceptable tradeoff.
Migration planning – Risks, costs, and opportunities are evaluated in this phase to establish an acceptable implementation strategy. Individual projects associated with implementation are also listed in terms of priority.
Implementation governance – This phase involves establishing specifications for each project. Change requests, solution building blocks, compliance assessments, and other elements are all addressed as part of a complete architectural oversight.
Architectural change management – The final phase of the ADM has practitioners define a comprehensive change management process that includes all the changes established throughout previous phases.

The Zachman framework

The Zachman framework’s approach to EA management is model-based. It focuses on describing the relationships between different EA artifacts and perspectives within a business and usually takes the form of a grid with 36 cells.

This matrix format clearly represents actors and their relationships with decision criteria. The perspectives that appear in rows include:

Executive perspective – The purpose of the EA program in relation to business strategy.
Business management perspective – Business concepts are described in terms of the organization’s design choices, processes, and enterprise models.
Architect perspective – How established business requirements will be realized in terms of system logic.
Engineer perspective – How technology will be utilized to implement system choices.
Sub-contractor perspective – Are there any requirements that will require modular tooling components?
Enterprise perspective – How will end-users perceive the system within its operating environment?

The columns of a Zachman framework address the questions:

What?
How?
Where?
When?
Why?
Who?

A key distinction between TOGAF and Zachman is that the latter does not provide any implementation guidelines for actually creating architectural artifacts. Instead, it prioritizes creating awareness and providing viewers with a holistic overview of perspectives and relationships across an enterprise.

In other words, Zachman is not necessarily a methodology but rather a template for mapping out the fundamental structure of enterprise architectures.

Should I choose TOGAF or Zachman?

To answer this question, it’s important to realize that the two frameworks are not identical in their approach.

TOGAF offers a systematic process for creating or improving enterprise architectures, and the ADM provides a model for implementing choices in order to produce desired models.

Zachman, on the other hand, is more of an ontology. In other words, it prioritizes awareness of architectures and the relationships between the elements therein, including artifacts and departmental perspectives. Zachman tables can then be used to scope, design, and plan out details relating to individual subsets of enterprise architectures.

In short, the best way to choose between TOGAF and Zachman is to ask whether your intentions are to create or categorize enterprise architectures.

It is worth pointing out that, despite the differences between these two enterprise architectural methodologies, they do not actually negate or conflict with each other. In fact, they are quite complementary and can even help teams and departments implement other frameworks such as PRINCE2, COBIT 2019, or ITIL 4.