Subscribe to the FREE Business Rules Journal Newletter





Enterprise Quantum Mechanics (Part 1)

by John A. Zachman

It is my contention throughout my new book[1] that Enterprise Engineering and Manufacturing is the applied physics of systems theory.[2]  There is an enormous body of knowledge supporting not only formal systems theory but also the related subjects that are foundational for modeling, like systematics, the science of classification.[3]  Classification leads to categorization, which leads to taxonomies and semiotics (syntactics, semantics, and pragmatics), which leads to ontology, cosmology, and epistemology, the branches of metaphysics, which leads to philosophy, which ultimately leads to origins, that is, theology.

Modeling is like the tip of the iceberg. You don't have to know about the rest of the iceberg, only that it is down there.

Similarly, arithmetic is the tip of the mathematical iceberg, which can also be traced back ultimately to metaphysics, philosophy, and theology.

You don't have to know everything about the entire iceberg of knowledge to practice modeling any more than you have to know everything about the theories and philosophy of mathematics to do arithmetic. However, in both cases, it can get really complex and ethereal really quickly. In the case of Enterprise modeling, I would call this the "Quantum Mechanics" of Enterprise Architecture.

I have written my book from a very conceptual standpoint. I have not attempted to address the potentially enormous complexity implicit in the subject and all the underlying disciplines. Clearly, Enterprises are enormously complex. Even rather small Enterprises are enormously complex. Life is too short. I cannot possibly know all there is to know about the enormous supporting body of knowledge.

It will remain for others (maybe many others) to take the concepts, including any concepts that I have explored, and form them into a coherent theory of Enterprise Quantum Mechanics. In fact, I doubt that any one person will ever be able to integrate all the complexity of the entire body of knowledge into a unified field theory of Enterprise Architecture. The best we can hope for is a coherent Framework to guide our further study and investigation of the laws of nature relative to Enterprises.

This topic draws from an appendix in my new book, where it was too extensive to present as a footnote. But I didn't want to include it in the main body of the text because I didn't want anyone to be discouraged or intimidated by the complexity or the fact that in 2002, we simply haven't yet integrated all the body of knowledge or understood all of the laws of nature related to Enterprises. At the same time, I am aware that it is useful to discuss some of the complexity because, as practitioners, we are confronted by anomalies to resolve, and clearly the meta community (e.g., the tool and repository suppliers) presently are making explicit trade-offs relative to the structural complexities.

To reiterate, we don't have to know everything before we can begin working on Architecture. Where there are some unknowns, my observation is we just need to use our common sense and understanding of the principles we do know.

Having said all that, let me address the issues of 'primitives' versus 'composites' that are core to this subject. Clearly, the Framework identifies six categories of descriptions, based on the six primitive interrogatives:[4]

What Things Material Composition
How Process Functional Characteristics
Where Location Distribution
Who People Operating Instructions
When Events Timing Diagrams
Why Ends Desired State Specifications

I am confident that these are all primitive because they are all unique, independent variables.

I am confident that they are all comprehensive because they derive directly from the comprehensive six, primitive interrogatives.

To be interesting from a systems theory standpoint as descriptive of the Enterprise (see again note [2]), structure would have to be added to the categories -- internal structure within each category, and external structure across all categories.

Regarding the internal structure, each primitive component would be related to all like components of the primitive category. For example, in Column 1, the primitive component Thing would be related to all the other like components (Things) in the category. Therefore, the internal structure of the Column 1 models would be Things and Relationships, where Relationships would express the existence constraints between the Things.

In Column 2, the primitive components would be Processes and Inputs/Outputs where the Input is some material that is transformed by the Process into some (other) material Output which is Input to some (other) Process, forming the structure of the Process models.

In Column 3, the primitive components are Location and Link, where Link is the connection between the Locations.

In Column 4, the primitive components are Organization (People) and Work Product, where the work product is some physical object or report or decision that one Organization produces and upon which another Organization is dependent.

In Column 5, the primitive components are Events (points in time) and Cycles (lengths of time).

In Column 6 the primitive components are Ends (desired states) and Strategies (the choices of actions to realize the states).

Regarding the external structure across all of the Columns, the model would relate all of the primitive components in all of the Cells across a Row, as appropriate. That is, since all of the primitive components are Things (that is, nouns, for example, Things, Relationships, Processes, Inputs/Outputs, Locations, Links, Organizations, Work Products, Events, Cycles, Ends, Strategies), they can be related to each other in a typical Thing Relationship Thing fashion. The horizontally-integrated model across any one Row of the Framework will express the existence constraints between the various primitive components of the whole Row.

Next time, I will conclude with some other interesting observations about the nature of Architectural primitives and composites. I will explain why I say that if you are not building primitive models you are not doing Architecture; you are doing implementations. be continued


[1]  For information on John Zachman's new book visit return to article

[2]  "Formal System," (from the Encyclopaedia Britannica) also called Logistic System, in logic and mathematics, abstract, theoretical organization of terms and implicit relationships that is used as a tool for the analysis of the concept of deduction. Models -- structures that interpret the symbols of a formal system -- are often used in conjunction with formal systems.
    Each formal system has a formal language composed of primitive symbols acted on by certain rules of formation (statements concerning the symbols, functions, and sentences allowable in the system) and developed by inference from a set of axioms. The system thus consists of any number of formulas built up through finite combinations of the primitive symbols -- combinations that are formed from the axioms in accordance with the stated rules.
    In an axiomatic system, the primitive symbols are undefined; and all other symbols are defined in terms of them. In the Peano postulates for the integers, for example, 0 and ' are taken as primitive, and 1 and 2 are defined by 1 = 0' and 2 = 1'. Similarly, in geometry such concepts as "point," "line," and "lies on" are usually posited as primitive terms.
    From the primitive symbols, certain formulas are defined as well formed, some of which are listed as axioms; and rules are stated for inferring one formula as a conclusion from one or more other formulas taken as premises. A theorem within such a system is a formula capable of proof through a finite sequence of well-formed formulas, each of which either is an axiom or is inferred from earlier formulas.
    A formal system that is treated apart from intended interpretation is a mathematical construct and is more properly called logical calculus; this kind of formulation deals rather with validity and satisfiability than with truth or falsity, which are at the root of formal systems.
    In general, then, a formal system provides an ideal language by means of which to abstract and analyze the deductive structure of thought apart from specific meanings. Together with the concept of a model, such systems have formed the basis for a rapidly-expanding inquiry into the foundations of mathematics and of other deductive sciences and have even been used to a limited extent in analyzing the empirical sciences. See also deontological ethics; metalogic; metatheory.
    Copyright © 1994-2000 Encyclopædia Britannica, Inc. return to article

[3]  Merriam Webster Dictionary return to article

[4]  I have used some slight terminology variations when I have discussed these, but the essence of the ideas is constant. return to article

standard citation for this article:

John A. Zachman, "Enterprise Quantum Mechanics (Part 1)," Business Rules Journal, Vol. 3, No. 3 (March 2002), 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 ]