Enterprise Quantum Mechanics (Part 2)

John A.  Zachman
John A. Zachman Chief Executive Officer, Zachman International Read Author Bio || Read All Articles 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:  http://www.BRCommunity.com/a202/b108a.html. 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:

citations icon
John A. Zachman , "Enterprise Quantum Mechanics (Part 2)" Business Rules Journal Vol. 3, No. 5, (May 2002)
URL: http://www.brcommunity.com/a2002/b108b.html

About our Contributor:

John  A. Zachman
John A. Zachman Chief Executive Officer, Zachman International

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). He served IBM for 26 years, retiring in 1990 to devote his life to the science of Enterprise Architecture.

Mr. Zachman is the Founder and Chairman of his own education and consulting business, Zachman International®. He is also Founder of the Zachman Institute™, a nonprofit organization devoted to leveraging Zachman International's vast network of professionals and resources to offer services to small businesses and nonprofit organizations as they prepare for and experience growth.

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 (DAMAI) 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.

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 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 Management at Emporia State University, on the Advisory Council to the School of Library and Information Management at Dominican University and on the Advisory Board for the Data Resource Management Program at 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.

Read All Articles by John A. Zachman
Subscribe to the eBRJ Newsletter
Enterprise Architecture Defined: (2) Complexity and Change
Enterprise Architecture Defined: (1) What is Architecture?
The Business Agility Manifesto — The Authors Speak Out Q&A with Roger T. Burlton, Ronald G. Ross, & John A. Zachman
Strategy Spectrum for Enterprise Engineering and Manufacturing
In The Spotlight
 Jim  Sinur
 John A. Zachman
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.