Subscribe to the FREE Business Rules Journal Newletter





Enterprise Quantum Mechanics (Part 2)

by John A. Zachman

In the first part of this topic,[1] I introduced the issue of 'primitives' versus 'composites,' which is core to what I call the "Quantum Mechanics" of Enterprise Architecture. That discussion brings up another interesting observation: there is something unusual about the Column 1 models in that they are Thing Relationship Thing models, and such models define the relationship between ALL the models. Adrienne Tannenbaum calls "Thing Relationship Thing" the Zen of metamodeling.

Another interesting observation is that Thing Relationship Thing models are bills-of-materials, not hierarchies. I am not sure what all of the implications of these observations are, only to make the observations.[2]

Here are some more observations.

In come cases, the primitive component that constitutes the relationship within any one Cell metamodel may be a composite derived from another Cell.

This is so easy to see in Row 3, Column 1 Logical Data Model and Column 2 Application Architecture. The Input/Output relationships between the logical Application Functions are actually "User Views," which are composed from the Attributes from the Logical Data Model.

This is simple. No one (anymore) has any problem seeing this.

A View is a primitive thing in its own right, but it is a composite of Attributes from a different Cell. No longer would anyone create a "file" for the View to serve as stand-alone Input/Output to an Application Function. That is what caused all the frustration with the legacy in the Enterprise due to inconsistencies, redundancies, discontinuities, etc., in the data. Database technologies were introduced to help avoid this problem. The data could be defined relative to the Enterprise (not relative to the Application Function) and then reused as Input/Output (Views) for whatever Application Function is being implemented.

This is not a hard concept. The Input/Output (View) is a primitive relative to the Process structure. It is a composite of Attributes from the primitive Logical Data Model, which is defined relative to the Enterprise as a whole. It is extremely important to separate the User View (composite) from the Logical Data Model (primitive) because the View changes independently from the Data Model. The View is dynamic, transient whereas the Data Model is stable, constant. That is, it is most constant if it is defined relative to the Enterprise rather than any subset of the Enterprise.

The Architecture rule for composites is: ALWAYS derive the composite from a primitive model that is defined relative to the Enterprise because the composite changes independently from the primitive. The composite is relatively transient whereas the primitive is relatively constant.

Conversely, if you DON'T derive the composite from the primitive model defined relative to the Enterprise, then you will have defined it relative to an implementation (in the case of Views above, relative to a Process) and it will NOT be reusable for any other implementation (Process), unless by accident.

This is why I say, if you are not building primitive models, you are not doing Architecture. You are doing implementations.

There is nothing the matter with implementations. There is nothing the matter with composites. They are good, in fact, they are necessary for implementations.

However, if you are trying to build an inventory of reusable assets that can be reused in many implementations, then building composites is not sufficient. You will have to build the primitives relative to the Enterprise so that your implementation composites can reuse the Enterprise assets, that is, Architecture.

This phenomenon where a primitive component is both a primitive (e.g., Input/Output) and a composite (e.g., View) may or may not happen in other Columns.

In Column 3, Location Link, it does not happen. The Link is the primitive connection between the Locations. The Link may be related to primitive components in other Cells as those components may traverse the Link between Locations, but the Link is not composed of other primitives.

In Column 4, Organization Work Product, clearly the phenomenon does exist as the Work Products could be composites of Inputs/Outputs from Column 2 or from Strategies (choices, decisions) from Column 6, depending upon whether it is a Work Product of an operational relationship or a Work Product of a control relationship.

In Column 5, Event Cycle, the phenomenon does not happen. The Cycle (time delay) is not composed of other primitives. (It could be related to or caused by other primitives.)

In Column 6, Ends Means, the phenomenon clearly exists again as the Means may be composites of Processes from Column 2. (They could be related to other primitives as well.)

In fact, the Business Rules community of folks would argue that in Column 1, Things Relationships, the Relationship is a composite of the constraint choices that are derived from the Means (Strategies) of Column 6.

This rather complex set of relationships (Column by Column, Row by Row) is what is being defined (or, in cases, overlooked) very explicitly in the "metamodels" of tools and repositories. In 2002, there is not exactly universal agreement as to the metamodel for each Cell and between the Cells in any Row and between the Cell above and Cell below in any Column. That is why there is little "integration" between and among the development tools and repositories.[3]

The tool and repository problem is further exacerbated by the history of models and modeling, which was implementation dominant, not architecture dominant. That is, the models were built for a specific implementation rather than for the Enterprise in its entirety; the tool/repository was not very meticulous about separating and managing the independent variables (primitive Cells).

In fact, for implementation purposes, you don't need Enterprise-defined primitives. You need complex multiple composites, that is complex models that are composed from components of several Cells, not the simple, single, primitive-to-primitive/composite case I posed above (i.e., the simple, single logical data model to user view). And, there may be an infinite number of different, complex, multiple Cell composites that may be useful for implementation purposes.

As the demand for tools and repositories begins to mature, I am sure the suppliers will address the Architecture issue in their metamodels, not simply the implementation issue. But until that time, remember that the magic is not in the tool, it is in the engineer. If you understand the limitations of the tool metamodel, you can compensate for them, and if the tool metamodel is extensible you can resolve the problem to your own satisfaction.

In fact, as Enterprise Engineering and Manufacturing experience grows, it is likely that every Enterprise will want (or need) their own metamodel and will have to be capable of evaluating the tool metamodels for meta-Architectural fit, just like they have to evaluate any application package model for Enterprise Architecture fit. Where Enterprises require inter-Enterprise collaboration, they will have to negotiate inter-Enterprise commonalities in their models and/or their metamodels.

There is no need to get depressed over this. Enterprises are complicated. There is not necessarily a need between Enterprises to agree to common multi-Enterprise-wide models or metamodels, but only to those portions impacted by or required for collaboration, and, then, there are some ways to compensate on a limited basis when the semantic structures themselves are not involved.

I began this topic by saying that, in 2002, we are not dealing with Enterprise Quantum Mechanics. That will come along later. You don't have to know everything about everything to begin building primitive models. Now we are just trying to get acquainted with Enterprise Newtonian Physics. I am sure Quantum Mechanics will come, but there is plenty of work for us to do and nothing is keeping us from doing it while we are learning.


[1]  John A. Zachman, "Enterprise Quantum Mechanics (Part 1)," Business Rules Journal, Vol. 3, No. 3 (March 2002), URL: return to article

[2]  I discussed some implications as I understand them in Chapter 7 of my new book, in a discussion on "Columnar Metamodels." return to article

[3]  In fact, I argued in the main body of my book that it is not exactly clear that there will EVER be universal agreement as to the metamodel. return to article

standard citation for this article:

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