Understand the Zachman Framework – An Easy Example

The Zachman Framework dates back to 1987 when John Zachman, an IBM employee until 1982, published the article “A Framework for Information Systems Architecture”. The basic idea of the Zachman framework is that one thing can be described with different purposes and for different roles. Putting it together as a matrix, the latest Zachman framework, which is version 3.0, has six different roles and six different purposes, summing to a total of 36 different viewpoints.

The purposes are called classification names, which are:

1. What: What inventory?

2. How: How to … the process?

3. Where: Where to distribute …?

4. Who: Who is responsible for…?

5. When: When is the time for…?

6. Why: Motivation for…?

The different roles are called audience perspectives, which are:

1. Executive perspective: Identification

2. Business management perspective: Definition

3. Architect perspective: Representation

4. Engineer perspective: Specification

5. Technician perspective: Configuration

6. Enterprise perspective: Instantiation

The goal of Zachman is therefore to provide a framework that helps to understand from which viewpoint an architecture should be looked at, depending on the goals and the audience.

What purposes (classifications) are there?

Let´s take a CRM system as example:

What do we do? We provide a CRM system.

How do we do it? New leads are registered as soon as they register through a campaign and are followed up.

Where do we do it? We use the system in all our subsidiaries worldwide.

Who does it? Our marketing experts from the Marketing Department.

When do we do it? Every time when a potential lead registers through one of our active campaigns.

Why do we do it? We want to maximize the sales potential of leads and customers that are somehow interested in our products and services.


What roles (audiences) are there?

The executive wants to identify what the CRM system is about.

Business management wants to define how business can use the CRM system and benefit from it.

The architect wants to describe the structure and the blueprint of the system and understand how it fits into the overall IT landscape.

The engineer wants to determine the specifications that are needed in order to run the CRM system.

The technician manages the configurations and ensures that they represent the specifications from the engineer.

The enterprise perspective ensures that the CRM system fits into the overall organization´s IT landscape, that releases are managed and that the instances work.

Of course, the classification and the audience can be combined in such a way that a total of 36 different viewpoints are created. For instance, the purpose, the “why” for a CRM system would be different for an executive (maximize revenue per lead / customer) than for an enterprise architect (ensure that the CRM system fits into the overall landscape as it is a large system that is critical to our business continuity).

However, the creation of 36 different viewpoints for every architecture work is definitely not necessary. Zachman rather promotes that one considers the different views and possibilities that there are. In the end, the consideration of the classification or the audience would often be sufficient – without defining the viewpoints that result when you combine the two in a matrix.

What do you think? Do you think that such enterprise architecture frameworks are still relevant in today´s digital enviroment?

Leave a comment

Your email address will not be published. Required fields are marked *