EA Articles

Zachman's Genius by: Matthew Kern, ZCEA CEA³ CISSP-ISSAP PMP

Recently I read a commentary about Zachman's work by an enterprise architect. He had admittedly not used Zachman's work for many years in his early career, he was just now examining it. Then he rendered faint praise. This struck me as odd, as Zachman's work is fundamental to understanding enterprise architecture. If you do not understand Zachman's work, how can you claim to be an enterprise architect? Certainly you cannot have a good grasp of the subject. Regardless of what framework you use (even no framework), you need to understand Zachman's work.



Let me explain why it is so important, so general, and so profound. I will do so in my own words. For a full account, see the Zachman International website. (I will refer to John A. Zachman (the elder) simply as John, as many do (he was in customer support for years and is very personable), but do not mistake me. This man is my elder and I have great respect for him. If we stand on the shoulders of our predecessors, my foot is solidly on John's upper clavicle somewhere.)


Zachman's Genius



as posted in Linkedin:
Full Linkedin Article



The Problem

In the 1980s John and IBM were faced with the problem of how to improve the articulation and analysis of an architecture for complex computer systems. The fundamentals of architectural description were well known: A set of engineering drawings accompanied by schedules (lists) and matrices were common and well known artifacts used to convey architecture. Engineering documents using technical writing accompanied these. An architecture was some set of things connected (or related) in some way, and some description of how they operate as a whole, and was conveyed by these documents.

John's paper "A Framework for Information Systems Architecture" in 1987:

This was the state of the art at the time. There was more to an architecture of complex information systems than parts and cables and software. You needed human processes and motivations and business unit information and such. The key missing element was any notion of completeness. How do you know if all required information is present in an architecture, or what information is required? This was a huge problem for integration, sales, contracts and configuration of complex mainframe systems.

To put it succinctly, what kinds of boxes do you need on your drawings to have an architecture?


John selected a set of columns designed to contain and categorize architectural information. Ultimately he happened to settle on the same categories of information used by news reporters, the five Ws. This set of information had been proven historically to be sufficient for describing almost any news ever written on any subject ever published.

He added the engineering "How". All together these are the interrogative pronouns of the English language, the kinds of questions you can ask about a thing. Some small debate has continued over the years if this is the most complete set of interrogatives, classifying all possible relevant questions. The consensus is mostly yes, though occasionally someone adds another interrogative to capture some particular information more explicitly. This list is a rather complete set of categories for all the facts to describe anything.


John started our with a list of the most relevant persons in the process of building something. Each had a viewpoint, and might have a different take on the relevant facts. Just like a news reporter, these were the people you might interview to obtain a complete picture.

However, over the years he sought for more. He really wanted something that conveyed the complete engineering process. Recently, his focus has shifted to the process of reification, taking an abstract concept as real. I would say the word concretization might imply the intent a bit more clearly, the notion of what it takes to bring a concept into reality.

This philosophical grounding in the required stages of realization of a concept or design makes the rows as complete as the columns, as a basis for describing all aspects of an architecture.

So far we have a means to accomplish Newtonian Subdivision, or Reductionism, for almost anything one might imagine. This is one of the two great paradigms for understanding in science and technology.


Having row and column titles, independent categorizations in two orthogonal directions and sets, to contain all architecture information gives you strong confidence that you are capturing all architecture, the complete description for building a thing. The next order of business is to define exactly what type of information goes in each cell of the matrix.

Each cell represents a list of facts. By filling in every cell you have a complete list of facts, with some confidence. John supplies guidance regarding which facts go in each cell.

The cell contents are interpreted in a way most relevant to describing a system or enterprise. Mostly these facts describe the existence of elements of the architecture, things in it.


More informative than the facts in these cells are the relationships between these facts. This represents holism, this expression of not only the parts but their relationships. Any sort of relationship can be captured between facts in John's matrix. This holism is the basis of systems theory and systems thinking.

Holism is the other major paradigm for understanding in science and engineering. It goes beyond reductionism describing the dynamics of any system.


Why is this so important? Well, before John Zachman a computer architecture contained engineering lists of physical computer component parts,and matrices describing physical interconnection. The crisis, at the time, was that an information system architecture was more than physical, but how much more was not clear. John described the other types of elements of an architecture, comprehensively.

Today if you tell me that systems engineering must address socio-technical systems for example, I can tell you that that Zachman's matrix captures the people (who), motivations (why) (including values) and processes (when) involved. I can make short work of any other aspects of your favorite paradigm that you may describe as important for inclusion.

John Zachman moved us from physical engineering description to description of all aspects from all angles (points of view). Thus his matrix, his work, designed at first to better describe a single complex information system became the basis for description and analysis for the entire enterprise and the whole portfolio of systems it may contain as a complete entity.


John Zachman's matrix provides two orthogonal categorizations of the facts to describe anything under analysis. By providing two categorizations, each independently complete, you can have high confidence that you have asked every question from every perspective and found all the relevant facts. In the cells not addressed you can see what you do not yet know. Combining this with the complete set of relevant relationships provides both reductionist and holistic description of the item under analysis or being described.

As a tool it is simple, reliable, flexible and philosophically or logically correct.


This is pretty profound and fundamental stuff. Neither Newtonian Subdivision nor Holism are going away. They have lasted for centuries in various forms. There is little chance of obsolescence or incorrectness, and only small issues of completeness exist with very high confidence.

If you say Zachman's work or enterprise architecture are somehow obsolete or incomplete, you may perhaps be a functional idiot or simply ignorant of their basis. Both are comprehensive and durable. To make them obsolete you had better break out the philosophy books and rewrite key elements of mathematics, engineering and science that have lasted for generations in various forms.

It is obvious to me that anyone claiming to be an enterprise architect omitting an understanding of Zachman's work has missed the boat. Without it you will be hobbled with no intellectual bridge between the engineering and the business, and their distinct methods of analysis.

I salute John Zachman, the genius at the root of enterprise architecture theory and concept.


Article Comments:

"Never seen anything half as genius as the one page ZF. Easy and deep, my favorite"

"Matt, I concur with your conclusions and summary. Like you said, if you do not know John and take the time to understand his Framework, then you are an Architect without a firm foundation or understanding of an Enterprise."

"Excellent!! Excellent!! Excellent!! The timeless points of the ZF suggestive matrix is what I have been communicating for decades. Admittedly since I am 'older than dirt', and had the many advantages of working with and alongside Founders like John, Steve, et al. I learned so much through the practical experiences.... and when I make comments about the times of "drawing on the chalkboards", it is literal. Great Job,, Matt..... No matter what it is, no matter the millennium... it will always come down to the 5Ws and the H."

"John Zachman's EA ontology, as everyone has noted has earned respect and its place in EA history."

"Zachman's pathbreaking creation of ontology needs to be seen from an eye of an abstraction not as physically laid out layers.....and abstracting all the way from the cells - the primitives to the grand scale enterprise architecture describing the enterprise in its continuum....all these into confluence - The Discourse of the Universe and Also The Universe of Discourse."


Stay Connected