Enterprise Architect

The creator of the Zachman Framework talks about the matrix at work.

• By William F. Zachmann
• August 15, 2007

In 1987, John A. Zachman wrote an article titled "A Framework for Information Systems Architecture" for the IBM Systems Journal. It was the first publication of what today is known as "The Zachman Framework for Enterprise Architecture." Zachman left IBM in 1990 after 26 years to start the Zachman Institute for Framework Advancement. His work has been influential in creating new disciplines of enterprise architecture and enterprise information systems architecture and planning. He also serves on the Executive Council for Information Management and Technology of the United States General Accounting Office.

I've known John since the mid-1980s, when we first met at an IDC conference where we were both speakers. So I was delighted when Redmond Developer News asked me to do an interview with John for the 20th anniversary of the publication of his original article. Here's the result of our conversation:

Today, 20 years after first coming up with it, how would you describe the Zachman Framework to a capable IT professional who's not already familiar with it?
There are two ways to describe the framework: conceptually and logically.

Conceptually, the framework defines enterprise architecture. People often don't realize that an enterprise has architecture just as a building does. But the architecture of an enterprise is not typically defined. Most enterprises are not explicitly designed in the first place. Enterprises kind of happen piecemeal, over time. That's why so many enterprises don't work very efficiently or effectively. No one really knows how they work and they're very difficult to change.

Logically, the Zachman Framework is a schema: A two-dimensional, normalized structure for descriptive representations such that you can put only one descriptive fact ["meta-thing"] in each category, or cell, of the schema. The intersection of two classifications-the interrogative abstraction and the perspective abstraction-defines the matrix, or schema, that is the framework.

The horizontal classification, interrogative abstraction, is the universal, linguistic communication classification that has been employed by humanity for thousands of years: what, how, where, who, when and why. The vertical classification, perspective abstraction, is the universal reification transformation-owner, designer, builder; conceptual, logical, physical; requirements, analysis, design; requirements, engineering, manufacturing engineering, etc.-bounded at the top for complex objects by a scoping perspective and at the bottom by a tooling-configuration perspective. This too has been around for thousands of years, at least since Aristotle.

I learned about the schema by looking at the structural pattern of descriptive representations for buildings, airplanes, computers, battleships, etc. I then put enterprise equivalent names on the rows, columns, cells and meta-model of the framework described conceptually above, because I was interested in enterprises.

"Enterprises kind of happen piecemeal, over time. That's why so many enterprises don't work very efficiently or effectively. No one really knows how they work and they're very difficult to change."
John Zachman, Creator of the Zachman Framework for Enterprise Architecture

How did the idea of the Zachman Framework come to you in the first place and how has it evolved and changed from your original conception of it?
I was simply trying to figure out how to align system implementations with the intent of the enterprise and I knew that architecture had something to do with that alignment. I just didn't know what architecture was relative to enterprises. I saw that the people who build complex industrial products-like 100-story buildings, airplanes, battleships, or computers-know what architecture is. My radical idea was to ask the older disciplines of architecture and construction, and of engineering and manufacturing, what their concepts of architecture were, because they had been building their products for a hundred years while we had been building systems for a mere 20 years or so.

I found there wasn't one architectural representation for complex products but a set of descriptive representations. These fall into a two-dimensional classification system or schema. I just put the equivalent enterprise names on the same set of descriptive representations relevant for describing anything. Why should descriptions of enterprises be different from the descriptions of anything else that humanity has learned to describe? We, in the information community, were re-inventing what the older disciplines had already invented, only we were putting enterprise names on them.

If the Zachman Framework were not already a well-established reference point for the IT industry and you were newly creating it today, would it be any different from what you came up with 20 years ago?
Actually, the classifications that constitute the columns and rows of the Zachman Framework have been in universal use by humanity for thousands of years. Therefore, they haven't changed. I did make one mistake though. Coming from the information community, my vocabulary was an information systems vocabulary, and I used its words and concepts to name some of the cells of the framework and some of the framework meta-entities. This led some to the erroneous conclusion that enterprise architecture is an information systems technology issue when, in fact, it's an enterprise engineering and manufacturing issue.

We've worked with some linguists to identify business-oriented words to more precisely reflect the concepts of the framework. We announced a new version of the framework about a year ago that uses these words. The framework schema and the meta-concepts haven't changed-only the words have changed to better reflect enterprise semantics of the schema.

What has surprised you most in the impact that the Zachman Framework has had on IT generally and on approaches to enterprise information architecture?
I think what surprised me most is that the Zachman Framework has had an impact on anything at all. I never set out to impact anything. I was just trying to find the natural laws affecting my ability to align systems implementations with the intent of the enterprise. In the process, I accidentally discovered a kind of periodic table of architectural elements ["primitives"] that can be reused to create a virtually infinite number of enterprise implementation compounds ["composites"]. I think I stumbled across the underlying structural characteristics of a new discipline that might someday be called "Enterprise Engineering and Manufacturing."

When Mendeleev defined the periodic table, it formed the basis for the science of chemistry. Until then, there was no discipline of chemistry. There was an art form called alchemy. Mendeleev probably knew what he was looking for when he defined the periodic table. In contrast, I had no idea what I was looking for when I defined the Zachman Framework. One might say it just fell onto my desk one day.

Various companies and individuals have attempted to use the Zachman Framework as a foundation for information-architecture design, planning and development tools. Which companies do you think have been successful? Why?
The only company that has successfully produced an enterprise planning, design and development tool for enterprise architecture is SIL International, the non-profit company of linguists we've been working with. They succeeded because they rigorously adhered to the classification concepts of the framework, creating primitive constructs that can be reused in more than one implementation of the enterprise. They knew that the end object is to engineer and manufacture the enterprise, not just to build and run systems.

What do you think are the most important lessons that young developers and development managers might be able to learn, if they're willing to do so, from IT veterans like yourself?
I think the most important thing to learn is that the end object is to engineer and manufacture the enterprise so it runs better and faster and can accommodate extreme change. The end isn't just to get systems implemented. The enterprise problem is an engineering problem, not a manufacturing problem. Until we learn this, we may optimize the systems but we'll continue to sub-optimize the enterprise.