Subscribe to the FREE Business Rules Journal Newletter





Architecture is Architecture is Architecture

by John A. Zachman

There appears to be a gross misunderstanding about Architecture, particularly in the information technology community.  Many people seem to think that an implementation, an end result, is Architecture.  To use an Architecture and Construction example, many people think that the Roman Coliseum is Architecture.

Figure 1.  The Roman Coliseum.

The Roman Coliseum is NOT Architecture.  The Roman Coliseum is the RESULT of Architecture.  The RESULT of Architecture is an instance of Architecture, an implementation.  In the end result, the implementation, you can see an instantiation of the Architect's Architecture.  If an Architect had not created the descriptive representations (the Architecture) of the Roman Coliseum, they could not have built the Roman Coliseum.  They couldn't have even ordered the stones they required in order to build the Coliseum without the Coliseum Architecture, which had to be created long before the Coliseum was constructed.

Architecture is the set of descriptive representations that are required in order to create an object.  If you can't describe it, you can't create it.  Also, if you ever want to change the object you created, Architecture constitutes the baseline for changing the object once it is created, that is, it is the baseline for changing the object IF you retain the descriptive representations used in its creation and IF you ensure that the descriptive representations are always maintained consistent with the instantiation.

If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don't need Architecture.  You can "wing it" and see if it works.  It is only when the object you are trying to create is complex to the extent that you can't see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE.  Once again, without Architecture, you are not going to be able to create an object of any complexity and you won't be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).

So, the question is, what constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption, and cost?

The answer lies in several hundred years of empirical experience learning how to create and change complex industrial products.

There is a universal[1] set of descriptive representations for describing any or all industrial products.  It is not mysterious what one dimension of the set of descriptions is as it is derived from the classic six primitive interrogatives that have existed since the origins of language.  Answers to the six primitive interrogatives constitute a complete description of anything.  Therefore, one set of descriptions includes:

Bills of Material — What the object is made of.
Functional Specs — How the object works.
Drawings — Where the components exist relative to one another.
Operating Instructions — Who is responsible for operation.
Timing Diagrams — When do things occur.
Design Objectives — Why does it work the way it does.

I have labeled this set of descriptions "Abstractions" in the sense that out of the total set of relevant descriptive characteristics of the object, we "abstract" one of them at a time for producing a formal, explicit, description.  The Abstractions are universal in the sense that they are common to all industrial products as illustrated below.

Figure 2.  Abstractions as depicted in the Zachman Framework™.

e.g., the Material Abstraction (WHAT it's made of)
Airplanes have Bills of Material.
Locomotives have Bills of Material.
Computers have Bills of Material.
All Industrial Products have Bills of Material.

e.g., the Functionality Abstraction (How it works)
Airplanes have Functional Specs.
Locomotives have Functional Specs.
Computers have Functional Specs.
All Industrial Products have Functional Specs.

e.g., the Geometry Abstraction (Where the components are)
Airplanes have drawings.
And so on… and so on… and so on.

By the same token, all industrial products have another dimension of descriptive representations.  This set of descriptions is deriving from the philosophical concept of "reification", transforming an idea, something you can think about into reality, a physical thing.  This is not a "decomposition"… it is a series of "transformations" as each stage in the series has its own unique manifestation with unique characteristics accommodating different purposes of different participants in the reification process.  Here is the other dimension of descriptive representations:

Scoping Boundaries

(Identification Strategists)

Requirements (Concepts)

(Definition Owners)

Schematics (Engineering descriptions)

(Representation Designers)

Blueprints (Manufacturing
                  Engineering descriptions)

(Specification Builders)

Tooling Configurations

(Configuration Implementers)

Implementation Instances

(Instantiation Operators)

I have labeled this set of descriptions "Perspectives" in the sense that each of the Abstractions is created uniquely for a different purpose.  Therefore, each of the six Abstractions has one of six different — I say again, "different" — manifestations, depending upon the Perspective of the intended audience (purpose) for whom the Abstraction is created.

Figure 3.  Perspectives as depicted in the Zachman Framework™.

The Perspectives are universal in the sense that they are common to all industrial products as illustrated below:

e.g., Requirements (the Owner's Perspective)
Airplanes have Requirements.
Locomotives have Requirements.
Computers have Requirements.
All Industrial Products have Requirements.

e.g., Schematics (the Designer's Perspective)
Airplanes have Schematics.
Locomotives have Schematics.
Computers have Schematics.
All Industrial Products have Schematics.

e.g., Blueprints (the Builder's Perspective)
Airplanes have Blueprints.
And so on … and so on … and so on.


In fact, we, the ENTERPRISE Engineering and Manufacturing community (of which I/S is only a part) have been reinventing the same descriptive representations that have already been invented by the older disciplines of Engineering/Manufacturing and Architecture/Construction, only we are putting our own names on them.

Here are the Enterprise equivalent descriptive representations:

e.g., Enterprise Descriptive Equivalents of Abstractions
Entity Structures equal Bills of Material (Entity Models ARE Bills of Material)
Process Models (or better, "Transformation" Models) equal Functional Specs
Distribution Models (Geography) equal Geometry (Drawings)
Work Flow models equal Operating Instructions
Dynamics Models or (or better, "Timing" Models) equal Timing Diagrams
Design Objectives equal Design Objectives

By the same token:

e.g., Enterprise Descriptive Equivalents of Perspectives
Scoping Models equal Scope Boundaries (CONOPS or Concepts Packages)
Models of the Business (Concepts) equal Requirements
Models of the Systems (Logic) equal Schematics (Engineering Descriptions)
Technology Models (Technology Constrained Models) equal Blueprints
(Manufacturing Engineering Descriptions)
Tooling Configurations equal Tooling Configurations
The Enterprise implementation equals the Industrial Engineering Product instantiation.

Therefore, ENTERPRISE ARCHITECTURE is the total set of intersections between the Abstractions and the Perspectives that constitute the total set of descriptive representations relevant for describing an Enterprise.  This is the same total set of descriptive representations relevant for describing airplanes, locomotives, buildings, computers, all industrial products.  I simply put the Enterprise names on the descriptive representations because I was interested in engineering and manufacturing Enterprises.

The Framework for Enterprise Architecture (the "Zachman Framework") is simply a schema, a classification scheme for descriptive representations of anything (I put Enterprise names on the descriptions and their contents — the "metamodel") such that the schema is "normalized" — that is, no one (meta) fact can show up in more than one Cell.


Figure 4.  The Zachman Framework™ IS Enterprise Architecture.   

THE ENTERPRISE itself is the implementation, the instantiation, the End Result of doing Enterprise Architecture, assuming that any Enterprise Architecture has been done.  I would observe that over the period of the Industrial Age until now, all airplanes, all locomotives, all buildings, all industrial products have been architected.  However, few (if any) Enterprises have been Architected.  Up until now, Enterprises have simply happened… somehow.  There may be many systems implementations, manual systems and/or automated systems, material handling systems (blue collar systems), and/or record keeping systems (white collar systems), a LOT of incoherence and discontinuity (ineffectiveness), and a LOT of compensation for that discontinuity (entropy, inefficiency).  There is no Architecture.  There are no "Primitive" Models.  There is no baseline for managing change.  No Enterprise engineering has been done.  Enterprise parts have been manufactured… but the Enterprise parts are not fitting together (they are dis-integrated, "stove-piped").

Jay Forrester, author of "Industrial Dynamics," a research project at M.I.T., said in a speech, "Designing the Future" at Seville University, "Airplanes built by intuition and committee would perform no better that an Enterprise built by the same methods."

I predict that over the period of the Information Age, the next one or maybe two hundred years, all Enterprises will be Architected.  The same factors that drove the formalization of Architecture for industrial products in the Industrial Age will drive the formalization of Architecture for Enterprises in the Information Age:  Complexity and Change.  We are already beginning to see the trend.

My observation is, Architecture is Architecture is Architecture.  What Architecture is, is not arbitrary and it is not negotiable.  Architecture is the total set of intersections between the Abstractions and the Perspectives that constitute the set of relevant descriptive representations for any object to be created.

If you cannot show me the Bill of Materials quite independent from Functional Specs quite independent from Geometry quite independent from Operating Instructions… etc., etc…

…and if you cannot show me Requirements quite independent from Schematics quite independent from Blueprints quite independent from Tooling Configurations… etc… etc…

…I do not believe you are doing Architecture work (Engineering).  A single variable model, that is, one Abstraction by one Perspective, a "Primitive" model, is the raw material for doing Engineering.  If you have no "Primitive" models, you have no raw material for doing Engineering and therefore, you are not doing Engineering (that is, you are not doing "Architecture").

In contrast, implementations, that is Manufacturing, the creation of the end results, are the instantiation of composite, multi-variable models, that is, models comprised of more than one Abstraction and/or more than one Perspective.  A manufactured part (Material) has some Functionality in some Geometric location for some Operation at some point in Time for some Objective.  An instantiation, by definition, is a "Composite."

The question turns out to be, how did you create the composite, implementation instance?  From Primitive models you have engineered from the perspective of the Enterprise?  (Architected?)  Or, did you simply create the Composite to produce an implementation ad-hoc to whatever you were implementing (i.e., it was implemented, but NOT architected – i.e., NO Primitives)?  And… is the Composite you created the whole complete object you are trying to create (the whole airplane, or whole locomotive or whole Enterprise) or is the composite just a part of the whole thing (a wing or a boiler or a "system" implementation)?

Once again, if you cannot show me "Primitive" models, I know that you are not doing Architecture (Engineering).  You are doing implementations (Manufacturing).  And, if you are not creating "Enterprise-wide" Primitives, I know you are risking creating implementations that will not integrate into the Enterprise as a whole.  You can manufacture parts of the whole iteratively and incrementally… however, they must be engineered to fit together or they are not likely to fit together (be integrated).  You can even do the engineering, the Architecture, iteratively and incrementally, but in this case you must do something over and above simply building incremental, iterative primitives to mitigate the risk of misalignment and disintegration.  Enterprise-wide integration and alignment do not happen by accident.  They must be engineered (Architected).

If one thinks that an implementation, a result, a Composite model is Architecture, (whether it is the whole thing or only a part of the whole thing), then this is probably contributing to the misconception that, for example, the Roman Coliseum is Architecture.

The whole finished product, the end result, is the total agglomerate instantiated Composite of all the Abstractions and all the Perspectives.  If one's perception is that the end result is Architecture, there is little wonder why Enterprise Architecture, that is, ENTERPRISE ARCHITECTURE (as in Enterprise-WIDE Architecture) is perceived to be big, monolithic, static, inflexible, unrealistic, impossible, and generally unachievable therefore creating a DIS-incentive for even attempting Enterprise Architecture.


If we ever want the Enterprise to be engineered so it is "lean and mean," so that it meets all the requirements of the "Owners," so that it is completely effective and efficient, so that it is integrated, so that it is dynamic, so that we can create new instances (implementations) on demand by assembling them to order from the Primitive constructs we already have in inventory, that is, so that we can "assemble the Enterprise to order" (in Manufacturing, "mass customization"), we have to start working on the raw material for doing Engineering, the single variable, "Primitive" models… ARCHITECTURE, ENTERPRISE Architecture.

YES!!!… we will have to continue to satisfy current demand for implementations by building Composite implementation constructs in the short term.  BUT, as we get some Primitives engineered (Architected) and into inventory, we can stipulate that any Composite models to be constructed MUST be constructed from the components of the architected Primitives we already have in inventory.  In that fashion, over some period of time, we could migrate (maybe "evolve") out of the disintegrated, discontinuous, inflexible legacy environment into an Architected, coherent, flexible, dynamic, optimized Enterprise.

Figure 5.  The manufactured RESULT – NOT the "Architecture".

We likely could achieve the quality and longevity for Enterprises as are ascribed to Boeing 747s or hundred-story buildings or other high-quality, long-lasting, superior-performing Industrial Age, complex engineering products that we have learned how to engineer over the last few hundred years if we could be humble enough to learn from the older disciplines of Architecture and Construction, Engineering, and Manufacturing.

Otherwise, nothing will have changed… we will just continue doing more of the same… building and running systems (legacy implementations, manual or automated, blue collar or white collar), and it doesn't make any difference what technologies we will be using.  It is not a technical issue.  It is an ENGINEERING issue, an ENTERPRISE engineering issue.

Are we going to start doing Enterprise engineering work (building Primitive models, i.e., Architecture)… or are we simply going to continue doing Enterprise manufacturing (building composite implementations, i.e., building and running systems… legacy)?

I would observe that it was Einstein that said something like, "keeping on doing the same thing and expecting different results is one definition of insanity."

This article can also be viewed on John's website.


[1]  The names of these descriptive representations may change slightly based on industry, but the concepts represented are consistent.  Furthermore, in some industries for some products, they may well be willing to assume the risks of not formalizing all of the relevant descriptive representations.  return to article

standard citation for this article:
John A. Zachman, "Architecture is Architecture is Architecture," Business Rules Journal, Vol. 16, No. 4 (Apr. 2015), URL:  

January 2017
By John A. Zachman

October 2016
Strategy Spectrum for Enterprise Engineering and Manufacturing
By John A. Zachman

July 2016
The New EA Paradigm
(4) The Assemble-to-Order Pattern

By John A. Zachman

June 2016
The New EA Paradigm
(3) The Provide-from-Stock Pattern

By John A. Zachman

May 2016
The New EA Paradigm
(2) The Make-to-Order Pattern

By John A. Zachman

April 2016
The New EA Paradigm
(1) Expenses and Assets

By John A. Zachman

March 2016
The Information Age: (3) Powershift
By John A. Zachman

February 2016
The Information Age: (2) The Third Wave
By John A. Zachman

January 2016
The Information Age: (1) Future Shock
By John A. Zachman

December 2015
Defining Enterprise Architecture: Economics and the Role of I.T.
By John A. Zachman

November 2015
Enterprise Physics 101
By John A. Zachman

September 2015
A Historical Look at Enterprise Architecture with John Zachman
By John A. Zachman

August 2015
Cloud Computing and Enterprise Architecture
By John A. Zachman

June 2015
The Zachman Framework Evolution (Part 2)
Special Guest: John P. Zachman

May 2015
The Zachman Framework Evolution (Part 1)
Special Guest: John P. Zachman

April 2015
Architecture is Architecture is Architecture
By John A. Zachman

April 2013
John Zachman's Concise Definition of The Zachman Framework
By John A. Zachman

November 2004
The Zachman Framework and Observations on Methodologies


November 2003

Framework Fundamentals: Frameworks, Reference Models, and Matrices


August 2003

Framework Fundamentals: A Dialog With John Zachman


June 2003

Framework Fundamentals: Miscellaneous Enterprise Engineering Concepts


April 2003

Framework Fundamentals: Framework Fundamentals: Level of Detail is a Function of a CELL


February 2003

Framework Fundamentals: Responding to Questions from the OMG


May 2002

Enterprise Quantum Mechanics (Part 2)


March 2002

Enterprise Quantum Mechanics (Part 1)


January 2002

"What" Versus "What"


November 2001

Security And The "Zachman Framework"


September 2001

Fatal Distractions (Part 2)


July 2001

Fatal Distractions (Part 1)


May 2001

You Can't "Cost-Justify" Architecture


March 2001

Conceptual, Logical, Physical: It Is Simple (Part 2 of 2)


January 2001

Conceptual, Logical, Physical: It Is Simple (Part 1 of 2)


September 2000

Building The Enterprise - An Infusion Of Honesty


July 2000

All the Reasons Why You Can't Do Architecture or ("We Has Met the Enemy and He Is Us")


May 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 2)


March 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 1)


November/December 1999 & January/February 2000

Enterprise Architecture: Issues, Ingibitors, and Incentives

July/August & September/October 1999

Packages Don't Let You Off The Hook

By John A. Zachman

January/February & March/April 1999

Life Is a Series of Trade-Offs and Change Is Accelerating!

November/December 1998

"Yes Virginia, There IS an Enterprise Architecture"

July/August 1998

Enterprise Architecture: Looking Back and Looking Ahead

January/February 1998

The Framework for Enterprise Architecture (The 'Zachman Framework') and the Search for the Owner's View of Business Rules



 about . . .



John A. Zachman is the originator of the “Framework for Enterprise Architecture” (The Zachman Framework™) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of his own education and consulting business, Zachman International®.

Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO) and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2009 Enterprise Architecture Professional Lifetime Achievement Award from the Center for Advancement of the Enterprise Architecture Profession as well as the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.  In August 2011,  he was awarded the Gen. Colin Powell Public Sector Image Award by the Armed Services Alliance Program.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.

In addition to his professional activities, Mr. Zachman serves on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California), the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way, the President’s Cabinet of the King’s College University, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir, the Board of Directors of Heavenworks, an international ministry to the French-speaking world and on the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people.

Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration"  for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Managementat Emporia State University, on the Advisory Council to the School of Library and Information Managementat Dominican University and on the Advisory Board for the Data Resource Management Programat the University of Washington. He has been a Fellow for the College of Business Administration of the University of North Texas and currently is listed in Cambridge Who’s Who.




[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]