TOGAF vs Zachman: What's The Difference?

Zachman and TOGAF are frameworks used to implement an Enterprise Architecture. In this article, we will discuss two of the most popular Enterprise Architecture frameworks: TOGAF and Zachman. We’ll also include tips on how to choose as well as additional resources.

What’s an enterprise architecture?

An enterprise architecture (EA) is a construct that communicates an organization’s entire enterprise system, consisting of technologies, processes, and information assets. It provides various perspectives from a technology and business standpoint, allowing organizations to take a disciplined approach for managing those systems.

In other words, your enterprise architecture defines the choice constraints that can be applied to enterprise IT and business systems and can have three core components: framework, methodology, and tooling. Utilizing an EA solves two key problems facing technology-driven business organizations:

1. Developing a thorough understanding between highly dependent subsets of enterprise systems allows organizations to reduce the overall complexity of the architecture.
2. Helping establish a structured and well-informed decision-making process aligns technology with business goals.

TOGAF: The Open Group Architecture Framework

TOGAF is the de facto industry standard framework, offering a methodological approach to Enterprise Architecture design, planning, implementation, and governance. It provides a consistent view of architectural artifacts that can be well understood by all stakeholders within the organization. The open nature of the framework, allows organizations to prevent a vendor lock-in with proprietary Enterprise Architecture solutions, allowing them to scale and adapt without running into significant cost, security, and technology-integration issues.

The TOGAF framework provides a series of actionable steps within the architectural process, known as the Architecture Development Method (ADM). The ADM process is not a prescriptive template but a generic and adaptable methodology that can be applied to a variety of organizational use cases in developing enterprise architecture. These phases can be modified and reordered as per changing requirements, which is especially useful considering that the TOGAF-ADM works iterative cycles to manage and develop new Enterprise Architectural requirements.

The ADM piece of TOGAF presents a process to implement the decision choices and producing the desired models. These steps are described as follows:

1. Architecture Vision: The initial phase that describes the scope of project, identifies stakeholders and obtains necessary approvals. Business goals and drivers are communicated. A capability assessment may be performed to evaluate the existing Enterprise Architecture.
2. Business Architecture: The process used to meet the Architecture Vision is defined in this phase. Detailed business analysis and modeling is performed at this phase in collaboration with multiple stakeholders. Formal targets for baseline and target goals are also specified.
3. Information Systems Architecture: Similar activities as the previous phase, are now performed for data and application architecture that supports the Architecture Vision. Target design principles for the data and application architecture will be specified in this phase.
4. Technology Architecture: The technology infrastructure required to support the Architecture Vision and specifically, aligned with the Business and Information Systems Architecture are specified in this phase. Key stakeholders will include IT department and executives responsible for technology decisions and investment approval.
5. Opportunities and Solutions: As the architectural design choices are finalized in the earlier phases, various implementation scenarios are evaluated. Both technical and business aspects are considered in this assessment and an optimal tradeoff scenario is identified.
6. Migration Planning: This phase brings traction to the most viable decision choices and Enterprise Architecture models as defined in the previous phase. An implementation strategy is devised based on cost, opportunities as well as risk. The projects are listed in terms of priority.
7. Implementation Governance: In this phase, the necessary architectural specifications for the selected projects are specified. A complete architectural oversight is provided during this phase, describing the change requests, compliance assessment and description of the solution building blocks.
8. Architectural Change Management: In this final phase, the new change management process is defined to incorporate new changes.

TOGAF has three pillars through which is explores your company’s architecture:

• Enterprise Architecture Domains
• ARM
• Enterprise Continuum

For more detail on the TOGAF three pillars and tips for implementing this enterprise architecture, see What is TOGAF? The Beginner’s Guide to TOGAF.

Zachman Enterprise Architecture

John Zachman was an IT pioneer who understood the problems facing IT-driven businesses. To solve these problems, he developed an early enterprise-architectural methodology in 1987—the Zachman Framework.

The Zachman Framework offers a model-based approach that:

1. Specifies the deliverables
2. Categorizes various aspects of enterprise system subsets into a matrix form
3. Associates them with the decision choices of the business-I environment.

Using a matrix, the rows categorize the view of different players in the organization based on decision criteria specified in the columns. The column headers describe the What, How, Where, When and Why. With this information, each matrix cell describes the relationship of each enterprise subsystem with the appropriate aspects of the organization. While the framework does not provide an implementation guideline or methodology, it offers a descriptive focus of artifacts by providing perspectives across the holistic enterprise architecture.

The row categories include:

• Executive Perspective: Scope context describing the business purpose and strategy.
• Business Management Perspective: Business concepts describing enterprise models, design choices, and processes as adopted by the organization.
• Architect Perspective: The system logic describing how the business requirements will be met.
• Engineer Perspective: Technology physics describing how technology solutions will be used to implement system choices.
• Sub-Contractor Perspective: These describe the requirements regarding specific modular tooling components.
• Enterprise Perspective: The functioning system as viewed by the user in its operational environment.

For more details on the framework and tips for putting it into practice for your company, see Introduction to the Zachman Framework.

Choosing TOGAF or Zachman

Which enterprise architecture you choose depends on your approach.

The TOGAF framework provides a systematic approach for defining the process of creating or improving an Enterprise Architecture. With its ADM, the framework offers a process for implementing the decision choices in order to produce your desired model.

The Zach Framework, on the other hand, is more of is an ontology—a structured set of expressions that describe how artifacts can be categorized, and thus created, operated, and changed. Unlike TOGAF, Zachman uses various enterprise perspectives in order to scope, define, and plan details regarding individual subsets of your enterprise system.

Your organization may choose to use one—or you can opt for both. Together, the frameworks can complement each other, with TOGAF describing the detailed process for creating the Enterprise Architecture, and Zachman categorizing the artefacts.

Or, you may opt to complement one framework with other well-known options, including ITIL^®, PRINCE2, or COBIT.

Additional resources