Architecture is Architecture is Architecture
© 2007-2011 John A. Zachman, Zachman International, Inc.
There appears to be a gross misunderstanding about Architecture, particularly in the information technology community. Many people seem to think that an implementation, an end result, is Architecture. To use an Architecture and Construction example, many people think that the Roman Coliseum is Architecture.
Figure 1: The Roman Coliseum
The Roman Coliseum is NOT Architecture. The Roman Coliseum is the RESULT of Architecture. The RESULT of Architecture is an instance of Architecture, an implementation. In the end result, the implementation, you can see an instantiation of the Architect’s Architecture. If an Architect had not created the descriptive representations (the Architecture) of the Roman Coliseum, they could not have built the Roman Coliseum. They couldn’t have even ordered the stones they required in order to build the Coliseum without the Coliseum Architecture, which had to be created long before the Coliseum was constructed.
Architecture is the set of descriptive representations that are required in order to create an object. If you can’t describe it, you can’t create it. Also, if you ever want to change the object you created, Architecture constitutes the baseline for changing the object once it is created, that is, it is the baseline for changing the object IF you retain the descriptive representations used in its creation and IF you ensure that the descriptive representations are always maintained consistent with the instantiation.
If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can “wing it” and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).
So, the question is, what constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption and cost?
The answer lies in several hundred years of empirical experience learning how to create and change complex industrial products.
There is a universal1 set of descriptive representations for describing any or all industrial products. It is not mysterious what one dimension of the set of descriptions is as it is derived from the classic six primitive interrogatives that have existed since the origins of language. Answers to the six primitive interrogatives constitute a complete description of anything. Therefore, one set of descriptions includes:
I have labeled this set of descriptions “Abstractions” in the sense that out of the total set of relevant descriptive characteristics of the object, we “abstract” one of them at a time for producing a formal, explicit, description. The Abstractions are universal in the sense that they are common to all industrial products as illustrated below:
By the same token, all industrial products have another dimension of descriptive representations. This set of descriptions is deriving from the philosophical concept of “reification”, transforming an idea, something you can think about into reality, a physical thing. This is not a “decomposition”… it is a series of “transformations” as each stage in the series has its own unique manifestation with unique characteristics accommodating different purposes of different participants in the reification process. Here is the other dimension of descriptive representations:
(Identification - Strategists)
Figure 3: Perspectives as depicted in the Zachman Framework™
The Perspectives are universal in the sense that they are common to all industrial products as illustrated below:
e.g. Requirements (the Owner’s Perspective)
Airplanes have Requirements.
Locomotives have Requirements.
Computers have Requirements.
All Industrial Products have Requirements.
e.g. Schematics (the Designer’s Perspective)
Airplanes have Schematics.
Locomotives have Schematics.
Computers have Schematics.
All Industrial Products have Schematics.
e.g. Blueprints (the Builder’s Perspective)
Airplanes have Blueprints.
And so on … and so on … and so on.
WHY WOULD ANYONE THINK THAT THE DESCRIPTIVE REPRESENTATIONS FOR ENTERPRISES ARE GOING TO BE ANY DIFFERENT THAN THE DESCRIPTIVE REPRESENTATIONS OF ANYTHING ELSE THAT HUMANITY HAS EVER DESCRIBED ?
In fact, we, the ENTERPRISE Engineering and Manufacturing community (of which I/S is only a part) have been reinventing the same descriptive representations that have already been invented by the older disciplines of Engineering/Manufacturing and Architecture/Construction, only we are putting our own names on them.
Here are the Enterprise equivalent descriptive representations:
e.g. Enterprise Descriptive Equivalents of Abstractions
Entity Structures equal Bills of Material (Entity Models ARE Bills of Material)
Process Models (or better, “Transformation” Models) equal Functional Specs
Distribution Models (Geography) equal Geometry (Drawings)
Work Flow models equal Operating Instructions
Dynamics Models or (or better, “Timing” Models) equal Timing Diagrams
Design Objectives equal Design Objectives
By the same token:
e.g. Enterprise Descriptive Equivalents of Perspectives
Scoping Models equal Scope Boundaries (CONOPS or Concepts Packages)
Models of the Business (Concepts) equal Requirements
Models of the Systems (Logic) equal Schematics (Engineering Descriptions)
Technology Models (Technology Constrained Models) equal Blueprints
(Manufacturing Engineering Descriptions)
Tooling Configurations equal Tooling Configurations
The Enterprise implementation equals the Industrial Engineering Product instantiation.
Therefore, ENTERPRISE ARCHITECTURE is the total set of intersections between the Abstractions and the Perspectives that constitute the total set of descriptive representations relevant for describing an Enterprise. This is the same total set of descriptive representations relevant for describing airplanes, locomotives, buildings, computers, all industrial products. I simply put the Enterprise names on the descriptive representations because I was interested in engineering and manufacturing Enterprises.
The Framework for Enterprise Architecture (the “Zachman Framework”) is simply a schema, a classification scheme for descriptive representations of anything (I put Enterprise names on the descriptions and their contents – the “metamodel”) such that the schema is “normalized”, that is, no one (meta) fact can show up in more than one Cell.
Figure 4: The Zachman Framework™ IS Enterprise Architecture
Figure 5: The manufactured RESULT – NOT the “Architecture”
John A. Zachman
Zachman International®, Inc.
2222 Foothill Blvd. Suite 337
La Cañada, CA 91011