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.

Notes

[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.

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

[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.

# # #