Zachman framework: definition, matrix, template and examples

The Zachman framework is one of the most established models in enterprise architecture. Here’s how it works, what it includes and how to apply it.

Contents

1. What is Zachman framework?
2. What is it used for?
3. Benefits & disadvantages
4. Zachman matrix
5. Template (incl. PDF download)
6. Example
7. Zachman vs. TOGAF vs. FEAF

Key takeaways: Zachman framework

• Developed by John Zachman at IBM in 1987 and now in version 3.0, the Zachman framework for enterprise architecture is among the most widely recognised reference models available to architects and IT leaders
• 36 cells across six perspectives and six question categories provide a complete description of any enterprise architecture
• Technology-independent and compatible with frameworks such as TOGAF and COBIT
• All elements of the Zachman architecture are interconnected, making changes in one area immediately visible across the whole model
• SoSafe’s Human Risk Management Dashboard makes the human factor in your security architecture measurable and manageable

What is the Zachman framework? Definition and origins

A precise understanding of the Zachman framework starts with where it came from. John Zachman developed his framework in 1987 while working at IBM, at a time when the growing complexity of information systems was becoming increasingly difficult to manage.

He looked to classical architecture and engineering for inspiration. Buildings are planned from several perspectives at the same time, including structure, electrics and spatial layout. Zachman believed enterprise architecture needed a similar kind of structured, multi-perspective description.

The framework he created is a matrix with 36 cells. One axis covers six question categories, while the other covers six organisational perspectives. Together, they help describe the main elements of an enterprise, from IT systems, processes and data to locations and strategic goals.

In Zachman framework 3.0, the terminology was refined and the boundaries between the individual perspectives were made clearer. Put simply, the Zachman framework can be explained as a reference model for describing what an organisation is made of and how its components relate to each other. It is not a process model, but a structured way to analyse enterprise architecture.

How organisations use the Zachman framework

Anyone who has tried to document an enterprise architecture knows that the problem is rarely a lack of knowledge. It is a lack of structure. Systems are described in isolation. Processes exist, but ownership is unclear and nobody is sure which data they rely on. This is where the Zachman framework comes in. Not as a process model, but as a structured classification system.

It asks six questions: what, how, where, who, when and why. Each question is examined from six perspectives, from executive leadership down to technical implementation. Using the Zachman framework for enterprise architecture does not give you a recipe. It gives you a structured grid that shows what your organisation looks like and where important gaps remain.

Organisations typically use the Zachman framework in situations such as these:

• Before transformation projects, when architecture decisions need a solid foundation
• When introducing new technologies, to avoid losing sight of existing structures and dependencies
• When regulatory requirements call for thorough and traceable documentation
• When IT teams and business units need a shared language for architecture work

Zachman framework: benefits and limitations

No framework is equally suited to every purpose. The Zachman framework has clear strengths, but also real limitations worth considering before committing to it as your primary architecture reference. Understanding both helps organisations decide how and where the Zachman model fits into their broader architecture work.

Benefits

• Technology-independent: can be applied across platforms, tools and industries
• Relates the 36 cells of the matrix to each other, helping teams understand how changes in one area may affect others
• Provides different perspectives on the same organisation, from the strategic level to operational implementation
• Encourages a comprehensive view of enterprise architecture
• Can serve as a shared language between business units and IT

Limitations

• Not a process model: the framework does not explain how architecture work should be organised
• Can be demanding to start with, especially if teams try to complete all 36 cells
• Requires complementary methods to turn architectural documentation into practical implementation
• May feel too complex or extensive for smaller organisations
• The matrix can be difficult to use without guidance or training

Risk needs a metric

Book a demo

Make human risk visible, measurable and easier to manage within your broader security architecture.

The Zachman framework matrix: perspectives and questions

The Zachman framework matrix is its central element. Two axes define the grid: the vertical axis shows six perspectives, representing who is looking at the architecture. The horizontal axis shows six question categories, representing what is being examined. Each of the 36 intersections forms a clearly defined area for describing part of the architecture.

The six perspectives (rows)

When using the framework, organisations select the perspective relevant to their question, ranging from executive leadership to technical implementation.

Planner (scope): what is the overall context?
Before a single system is described, this level addresses the why: what purpose does the organisation serve and what is its overall scope? It forms the foundation for every other perspective in the Zachman framework matrix.

Owner (business model): how does the organisation see itself?
Management thinks in business processes, goals and responsibilities, rarely in system architecture. This perspective captures exactly that picture, seen through the eyes of those who run the organisation.

Designer (system model): how can the business model be represented technically?
At this level, system architects translate business requirements into a conceptual model. The Zachman framework deliberately separates business logic from technical implementation here.

Builder (technology model): what is actually being built?
Developers and technology leads describe how the system model is translated into concrete technologies. Platforms, interfaces and infrastructure all become tangible at this level.

Subcontractor (detailed representations): what are the technical specifications?
Delivery teams and external partners do not need concepts. They need precise instructions. This perspective provides exactly that: detailed implementation guidance for the relevant components of the system.

User (functioning enterprise): what actually runs in the real world?
In the end, what matters is not the model, but the operation. This perspective shows how the organisation functions day to day, including where reality differs from the original design.

The six question categories (columns)

The Zachman framework matrix applies six questions to each of the six perspectives. Working through all six columns does not produce an abstract model. It helps create a more concrete picture of how the organisation can be described through the Zachman framework matrix.

What (data): what data exists in the organisation?
What an organisation knows determines what it can do. This column captures which data objects exist, what they are called and how they relate to each other.

How (function): how do processes work?
This column is not about which system runs, but about what happens inside it. It describes workflows and functions as the organisation performs them.

Where (network): where does the work take place?
This column covers locations, networks and geographical distribution. It also shows how those locations are connected to each other.

Who (people): who is responsible for what?
This is not a place for an org chart. It is a structured view of who makes which decisions and who owns which processes. For security leaders in particular, this column can be valuable because it helps show where roles, responsibilities and human risk intersect within the enterprise architecture.

When (time): when do processes occur and what triggers them?
This column focuses on temporal structures: which triggers set off which downstream processes? Some workflows follow a regular cycle, while others respond to specific events.

Why (motivation): what drives the organisation?
Goals, strategies and the basis for decisions. This column asks why the organisation acts as it does across all six levels. Answering it helps lay the groundwork for more strategic architecture decisions.

Zachman framework template: download the matrix and get started

You do not need a dedicated software tool to start working with the Zachman framework. Our Zachman framework template provides a clear matrix with six perspectives and six question categories. You can print it, fill it in during a workshop or use it as a digital starting point for architecture work.

The Zachman framework PDF includes two pages:

Page 1: an empty matrix with all 36 cells, ready to be filled in according to your project scope

Page 2: a completed example based on a retail company, showing how concrete architecture decisions can be reflected in the matrix

Whether you are preparing a kick-off workshop or structuring an ongoing architecture project, the PDF gives you a clear basis to work from. Teams using the Zachman framework for the first time can use the example on page 2 for orientation. Teams that already work with the framework can start directly with the empty matrix.

Not all 36 cells need to be completed in the first round. It is often more useful to start with the perspectives and question categories that are most relevant to the current project. The framework itself does not define a mandatory scope.

If the human factor has been difficult to capture in your architecture, the SoSafe Human Risk Management Dashboard can provide a measurable starting point. It helps make human risk more visible, measurable and easier to manage within the people-related perspective described in the Zachman framework’s “who” column.

Your architecture, clearly structured

Download the Zachman framework template

Download an empty matrix and completed example in one PDF, ready to use as a starting point for workshops and architecture decisions.

Zachman framework example: how to fill in the matrix

Our Zachman framework example shows the difference between theory and application. The example below explains how a retail company could fill in the Zachman framework matrix and use it as a point of reference for its own architecture work.

The company sells products through physical stores, a central warehouse and an online shop. It has three sales channels, distributed locations and different stakeholder groups. Structures like these can be captured systematically with the Zachman architecture and used to create a clearer view of enterprise dependencies.

Here is how a Zachman framework implementation example could look across the six question categories:

• What (data): key objects include customer, product and order. At planner level, naming these objects may be enough. At builder level, the team would define concrete database structures.
• How (function): at business level, the process is “receive and fulfil orders”. The designer translates this into a system model with order management and warehouse management.
• Where (network): stores, the central warehouse and the online shop are connected through shared cloud infrastructure. Each perspective describes the same network, but with different means and a different level of detail.
• Who (people): the board and executive management hold overall strategic responsibility. The deeper the matrix goes, the more specific the assignments become. At subcontractor level, this may include named people, teams and external service providers.
• When (time): the business year is structured around seasonal planning cycles. At builder level, this becomes a concrete release calendar with defined deployment windows.
• Why (motivation): at planner level, the strategic goal is to protect market share and strengthen customer loyalty. The operational levels translate this into measurable KPIs and contractual SLA targets.

This Zachman framework implementation example shows how the same organisation can be described from six different perspectives. The result is not contradiction, but depth. Each perspective adds another layer to the overall architecture picture.

The completed example is included in the free Zachman framework download.

Zachman framework, TOGAF and FEAF compared

Enterprise architecture frameworks take different approaches and can support security architecture work in different ways. The Zachman framework describes what needs to be documented. TOGAF provides a process for organising architecture work through its ADM. FEAF standardises architecture work across US federal agencies.

When comparing TOGAF vs the Zachman framework, the choice is not binary. The two frameworks can complement each other: Zachman provides the structure, TOGAF provides the method. Depending on regulatory requirements and security goals, frameworks such as ISO 27001, the NIST Cybersecurity Framework 2.0 or COBIT may also be relevant.

Zachman, TOGAF and FEAF at a glance

A sensible starting point for many organisations is to use the Zachman framework for enterprise architecture as a structural reference and TOGAF for implementation. For private sector organisations, the Zachman model and TOGAF are often more directly applicable than FEAF. FEAF is usually most relevant when working closely with public sector clients or government bodies.

Human risk deserves visibility

Book a demo

Technical controls protect systems. SoSafe helps you understand where behaviour, roles and security decisions affect risk.