My friend Roger Sessions recently quoted me in a tweet on Twitter as saying “Architecture is relative.” He likely got that quote from one of two places – either he was reading the original article I wrote in 1982 that was subsequently published in the IBM Systems Journal in 1987 in which I developed the idea that “There is a set of architectural representations produced over the process of building a complex engineering product representing the different perspectives of the different participants.” I went on to identify those different participants as the Owner of the end product (the ‘customer’), the Designer of the product (the ‘engineer’ or ‘architect’) and the Builder of the product (the ‘manufacturing engineer’ or ‘contractor’).
Yes, “Enterprise Architecture Is Relative”
I also referred to these points in a really good interview article about myself and Enterprise Architecture that Roger wrote and published in ObjectWatch in 2007.
The more likely source of Roger’s quote came from a one hour presentation I recently made in New York City in which I said, referring to the Owner’s, Designer’s and Builder’s perspectives, that in the original Framework graphic, I labeled Row 2 “Conceptual,” Row 3 “Logical” and Row 4 “Physical.” This caused a lot of confusion because many people interpreted what I said to mean Conceptual, a high level of detail; Logical, a medium level of detail; and Physical, an excruciating level of detail.
That is not at all what I meant. I meant “Conceptual Models” are the Row 2 Models, the perspective of the Owners of the Enterprise; “Logical Models” are the Row 3 Models, the perspective of the Designers of the Enterprise; and “Physical Models” are the Row 4 Models, the perspective of the Builder’s of the Enterprise.
In the original article, I had made the case that the Row 4 Models, the Builder’s perspective, are not more detail than the Row 3 Designer’s perspective models… they are different models. The Row 3 Models, the Designer’s perspective models, are not more detail than the Row 2 Owner’s perspective models… they are different models. What differentiates the Rows of the Framework is not levels of detail… the models in the different Rows are different models. They are the result of transformations, not decomposition.
In an effort to clarify this point, years ago I wrote an article: “Conceptual, Logical, Physical: It Is All Relative” in which I pointed out that when I used the terms “Conceptual,” “Logical” and “Physical,” I was using those words in the context of the ENTERPRISE in which case, “Conceptual” meant the Row 2 models, the Owner’s perspective; “Logical” meant the Row 3 Models, the Designer’s perspective and “Physical” meant the Row 4 Models, the Builders perspective. I said that maybe one could use the terms “Conceptual,” “Logical” and “Physical” relative to an application or a system to mean high level, medium level and excruciating level of detail… but that is not at all what I meant relative to the ENTERPRISE.
We have been working with some linguists for about 10 years now and they have been infinitely helpful in clarifying my classification concepts. They explain that an adjective-modified noun is always subject to interpretation. You always have to understand the context in which the adjective is being employed before you can understand the meaning of the adjective… and even if you understand the context, it is still subject to interpretation. In contrast a noun-modified noun is always very precise because a noun represents a set and you can count the members of the set. Another noun is a different set and you can count the members of that set. A noun-modified noun is an intersecting set and you can count the members of the intersecting set and it is not subject to interpretation… it is precise. In fact, set theory actually works in this case.
Therefore, in the present Framework graphic, you will find only nouns… no adjectives. “Conceptual Models” is now Row 2 “Concepts Models;” “Logical Models” is now Row 3 “Logic Models;” “Physical Models” is now Row 4 “Physics Models.” It is still relative, but it is very precise and it is not arbitrary… it is absolute in the context of the ENTERPRISE.
Roger was correct… architecture is relative… which of the 36 “Primitive” Models, (Cells of the Framework) you think is Architecture will depend upon what you are trying to do. If you are trying to transcribe the Business Management's (the Owner’s) perspective, you will be working on the Row 2 Business Concepts Models. If you are the Architect (the Designer) trying to design the systems to support the Business Management's concepts, you will be working on the Row 3 System Logic Models. If you are the Engineer (the Builder) trying to build the systems as designed by the Architects, you will be working on the Row 4 Technology Physics Models. Etc., etc.
The further specialization… if you are working on Inventories (i.e. Entities) you will be working on the Column 1, Inventory Models. If you are working on the Processes (i.e. Transformations), you will be working on the Column 2, Process Models… and so on.
Enterprise Architecture is relative… but it is not arbitrary… it is absolute. There is a well-defined set of descriptive representations that constitute Enterprise Architecture just like there is a well-defined set of descriptive representations that constitute architecture for buildings, airplanes, locomotives, battleships, computers, automobiles, oil refineries, space shuttles, nuclear reactors and every other complex object humanity has ever built.
Architecture for anything is not arbitrary. If every Building Architect, General Contractor, Airplane Manufacturer, Electrical Engineer, Aeronautical Engineer, Plumber, Manufacturing Engineer, Electrician, Lathe Operator, and Dry Wall Hanger decided that architecture was whatever they wanted it to be, it would be chaos. We would not have 100-story buildings, Boeing 747’s, super-computers, PC’s, ocean liners any other complex object. We would still be living in log cabins, riding horses, shooting muzzle-loaders, writing on parchment paper and using candles.
This is what is killing Enterprise Architecture… every computer programmer, systems designer, software architect, solutions architect, technology architect, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager and CIO calls whatever they want to or maybe, whatever they are doing, “Architecture.” It is chaos. No wonder we don’t have Enterprises that are coherent, integrated, flexible, dynamic, interoperable, reusable, aligned, lean and mean and working.
Referring to an article I recently wrote entitled “Architecture Is Architecture Is Architecture,” we are arguing about the wrong thing… we’re arguing about what architecture is. We ought to accept the definitions of architecture that the older disciplines of Architecture and Construction, Engineering and Manufacturing have already determined and use them to learn how to actually engineer and manufacture Enterprises.
Actually, as I described in the “Architecture Is Architecture Is Architecture” article, I did not invent "The Zachman Framework." I was looking at engineering design artifacts for airplanes, buildings, computers, automobiles… complex industrial products… and I saw the pattern… it is all the same… architecture is architecture is architecture. All I did was put Enterprise names on the same engineering design artifacts that are descriptive of any complex object. The Zachman Framework for Enterprise Architecture IS Enterprise Architecture.
I love this quote by Jay Forrester, author of “Industrial Dynamics” in a speech at Universidad de Seville in 1998… “Organizations built by committee and intuition perform no better than would an airplane built by the same methods… As in a bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the capability of real-life managers.”
Yes, architecture is relative, but it is not arbitrary. As long as we continue to consider it arbitrary or negotiable, we are going nowhere. We are just adding to the legacy. “Keeping on doing the same thing and expecting different results is one definition of insanity” (Einstein).
© 2009-2011 John A. Zachman
Zachman International, Inc.
15954 Jackson Creek Pkwy, Ste B463
Monument, CO 80132