Enterprise Quantum Mechanics (Part 2)
by John A. Zachman
In the first part of this topic,
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.
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
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
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.
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.
 John A. Zachman, "Enterprise Quantum Mechanics
(Part 1)," Business Rules Journal, Vol. 3, No. 3 (March 2002), URL:
 I discussed some implications as I understand them
in Chapter 7 of my new book, in a discussion on "Columnar Metamodels."
 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.