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 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 of 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® and Owner and Executive Director of the Federated Enterprise Architecture Certification Institute in Washington, D.C.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has directed 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.

Read All Articles by John A. Zachman
Subscribe to the eBRJ Newsletter
7 Common Myths (Plus 1) About the Zachman Architecture Framework
Enterprise Architecture Defined: Architecture Abstractions
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
In The Spotlight

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.