#eavoices

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

Primitives are single-variable, ontologically-defined categories of the essential components upon which the Enterprise is dependent for existence. Only one type of Enterprise component can be classified in any one cell of the Zachman Framework. They are the domain of Engineering, that is, Architecture. They don’t “do” anything. In contrast, Composites are multi-variable, holistic constructs of parts or pieces of the Enterprise with components from multiple categories of the essential components. Representation of different categories of components (different Framework Cells) are prerequisite for implementation. They are the domain of Manufacturing. They implement (“run”).

There is a strong metaphorical correlation between the Elements and Compounds of the Chemistry discipline and the Primitives and Composites of the Enterprise Architecture domain. Elements (Primitives) are timeless. Compounds (Composites) are temporal. Elements (Primitives) have single types of components. Compounds (Composites) have multiple types of components. Elements (Primitives) are isolated theoretically for engineering work. Compounds (Composites) are integrated practically for manufacturing work. Elements (Primitives) are Architecture. Compounds (Composites) are implementations. Elements (Primitives) are needed for Engineering. Compounds (Composites) are used by and the result of Manufacturing. Compounds (Composites) can be manufactured without knowing anything about or reusing the Elements (Primitives), but for Compounds to be engineered to produce predictable and/or modifiable behavior, they must be created from “reusable” Elements (Primitives).

This brings up a very important point. If you had inventories of all of the Chemical Elements in their primitive states, you could manufacture ANY Chemical Compound you wanted. However, as soon as you create the compound, it is fixed … it is hard to change. By the same token, if you had all of the Enterprise Primitives in inventory in their pure Primitive state, you could create any Enterprise Composite implementation required. Once you create the Composite, it is fixed, a snapshot, a point in time instantiation… an implementation.

There is a metaphorical departure in Enterprise Architecture from Chemistry in the fact that the media of the Enterprise implementation is the same as the media of its descriptive representations, namely digital depictions. We do not have to go through a media transformation from our engineering descriptions to become our implemented reality. They can both be digital. We simply “compile” the implementation. However, we learned long ago that the moment you “bind” together the components of the Composite implementation, it is fixed … you can’t change it. Therefore, the optimum implementation strategy would be to “bind at execute time” … that is, don’t “compile” the implementation until you “click your mouse” … “late binding.”

Unfortunately, “bind at execute time” is not presently perceived to be technically feasible. I think most people would argue that it is because the current technology does not support the concept. I would suggest that this is not a technical issue at all. The fundamental problem is, we do not have an inventory of our Primitive (elemental) components in their pure Primitive state from which we could bind Composites together at the click of the mouse. The key to this capability is Enterprise Architecture, the inventory of Primitive components, “loosely coupled,” related only by “foreign keys” in a database (Repository). If we had the inventory of Primitive Models in a Repository, the current technology would, in fact, support the concept. This capability in Manufacturing, Industrial Age products, is called “Mass-Customization:” “Custom Products, Mass-Produced, in Quantities of One, for Immediate Delivery.” This is REALLY important for Enterprises in the Information Age … because of the dramatic escalation of complexity and of the rate of change, the ENTERPRISE needs to be mass- produced from reusable components already “in inventory” in quantities of one for immediate instantiation … dynamically creating (late-binding) a new Enterprise implementation. This is the urgent motivation for ENTERPRISE ARCHITECTURE!!!

After 30 years of talking about this, I am still shocked at the predominant misconception that the Rows of Zachman Framework define “level of detail,” or “waterfall,” or “decomposition.” This is just not true. The Rows of the Zachman Framework define TRANSFORMATION, NOT decomposition. Level of detail is defined in the HEIGHT of each cell (or Row), NOT the height of the Framework itself. While I originally I called the Rows “Perspectives,” the underlying theory that defines the Rows is the philosophical concept of Reification.

One day in Houston, I was doing a seminar for some folks and was describing the Perspectives that constitute the second dimension (the Rows) of classification depicted by my Framework and some guy in the back of the room said, “Ohhh! That’s reification!” I said, “Re-if-a-what???” I never heard the word before. I said, “spell it for me” “R-e-i-f-i-c-a-t-i-o-n.”

It turns out that “reification” is a word that comes out of Philosophy. The etymology of the word is from the Latin, where “RE” means “thing” so “RE – IFICATION” would mean “Thing-ifcation,” making a thing, an instantiation, out of an idea that you can think about such that the thing (instantiation) bears a resemblance with the idea that you start with. Plato and Aristotle and apparently some assemblage of early Philosophers knew that an idea that you can think about is one thing but the instantiation of that idea is a totally different thing… and if you want the instantiation to bear any resemblance with the idea, the idea has to go through a well-known set of transformations.

Reification (Rows of the Zachman Framework):

• Row 1: First you have to Identify it, name it so you can have some discussion about it.
• Row 2: Next you have to Define it, the semantic intentions. The meaning, the structural definitions of the Enterprise components. The elements of Row 1 did not get more detail, they were transformed into a different perspective.
• Row 3: Then you Represent it as all engineering is done with representations, not physical material. 
• Row 4: Next you Specify it based on the implementation technologies available. 
• Row 5: Next you Configure it based on the tooling to be used.
• Row 6: Then, you Instantiate it- it becomes reality.

If the idea goes through this set of transformations, the Instantiation will bear resemblance with the idea. Reification is likely the more fundamental definition of the Rows of the Framework since it has been employed by humanity for several thousands of years. However, there is a strong correlation between Reification and the Perspectives as I identified them from the older disciplines of Architecture and Construction and Engineering and Manufacturing. This should not come as a great shock… there is a natural classification structure, it is manifest consistently in any application or discipline.