The Zachman Framework

Shortly after you start your inquiry about software architecture, or enterprise architecture as it is often called, you will come across the Zachman Framework.

Shortly after you start your inquiry about software architecture, or enterprise architecture as it is often called, you will come across the Zachman Framework. The Zachman Framework is a product of John Zachman who has been championing this cause for at least 15 years, first with IBM and then on his own. As with so many things in this domain, we have an opinion on the Zachman Framework and are more than willing to share it.

What Is the The Zachman Framework?

First though, let's describe just what the Zachman Framework is. John Zachman believes, as we do, that software is a human created artifact of large-scale and as such we may learn a considerable amount from the analogy between software and other large-scale artifacts of human creation. In the early days of software development, there were many who felt that perhaps software was a creative activity more akin to writing or artistry or perhaps craftsmanship on a small-scale.

However, this idea has mostly faded as the scale and interconnectedness of the pieces has continued to increase. Some of John's early writings compared software or enterprise architecture to the architectures needed to support airframe manufacturing, aircraft, rockets and the like. His observation was that in order to deal with the complexity of the problem in these domains, people have historically divided the problem into manageable pieces. The genius of John's approach and his framework has been in the orthogonality of the dimensions of which he divided the framework.

The Zachman Framework is displayed as a matrix. However, John is careful to point out that it is not a "matrix" but a "schema" and should not be extended or modified, as in his belief it is complete in its depth and breadth.

The orthogonal dimensions referred to above are shown in rows and columns here. In the rows are the points of view of the various stakeholders of the project or the enterprise. So for instance, at the highest level is the architecture from the point of view of the owner of the project or the enterprise and as we transform the architecture through the succeeding rows we gradually get to a more and more refined scope, as would be typical of the people who need to implement the architecture or eventually the products of the architecture. In a similar way, the columns are orthogonal dimensions and in this case, John refers to them as the interrogatories So, each column is an answer to one of Rudyard Kipling's six able servants: who, what, when, where, how, and why. Each column is a different take on the architecture, so for instance, the "what" column deals with information, the "things"about which the system is dealing.

In the aircraft analogy, it would be the materials and the parts. Likewise, the "how" column refers primarily to functions or processes; the "where" to the distribution of networking; the "when" to scheduling cycle times and workflow; the "who" to the people and organizations involved in each of the processes; and the "why" to strategy and eventually down to business rules.

Behind this framework then are models which allow you to describe an architecture or any artifact; a specific design of a part of a product or database table, or whatever, within the domain of that cell. Many people have the misperception that at the high-level there is less detail and that you add detail as you come down the rows. As John is very fond of pointing out, you need "excruciating" detail at every level and what is occurring at the transition from row to row is the addition of implementation constraints that make the thing buildable.

John has been a tireless champion of this cause, and from that standpoint we have him to thank for pointing out that this is an issue, and furthermore for championing it and keeping it in the forefront of discussion for a long, long period of time. He's been instrumental in making sure that senior management understands the importance and the central role of enterprise architectures.

What the Zachman Framework Is Not

At this point though, we need to point out that the Zachman Framework is not an architecture. And the construction of models behind the framework is not, in and of itself, an architecture. It may be a way to describe an architecture, it may be a very handy way for gathering and organizing the input you need into an architectural definition project, but it is not an architecture nor is it a methodology for creating one. We believe the framework is an excellent vehicle for explaining, communicating, and understanding either a current architecture or a proposed architecture.

However, it is our belief that a software architecture, much like a building architecture or an urban plan, is a created and designed artifact that can only be described and modeled after it has been created and that the act of modeling it is not the act of creating it. So in closing, to reconcile our approach with the Zachman Framework we would say that firstly, we have a methodological approach to creating enterprise software architecture. Secondly, we have considerable experience in actually performing this and creating architectures that people have used to develop and implement systems. Thirdly, these architectures that we have designed/developed can be modeled, described, and communicated using the Zachman Framework. But that does not mean that they were, or in our opinion, even could be created through a methodological modeling process as suggested by the Zachman Framework.

Read Next
Human Scale Software Architecture

Software Architecture can benefit as much as physical architecture from paying attention to human scale concerns.

Interested in an occasional email about semantics, enterprise ontology and enterprise information systems?
Sign up for the Semantic Arts newsletter.