Architecture is not what is tangible, that is the result of architecture. Architecture is the set of descriptive representations that are required to create an object
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.
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 needed to build the Coliseum.
Architecture is the set of descriptive representations that are required to create an object. If you cannot describe it, you cannot 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. 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 an 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 IMPERTIVE. 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 so 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 universal set of descriptive representations for describing any or all industrial products. The sets of descriptions include:
- Bills of Materials
- Functional Specifications (Specs)
- Drawings
- Operating Instructions
- Timing Diagrams
- Design Objectives
I have labeled this set of descriptions “Perspectives” in the sense that each of the abstractions is created uniquely for different audiences. Each of the Abstractions have five different, I say again, “different” manifestations, depending upon the perspective of the intended audience for whom the abstraction is created.
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 from the descriptive representations of anything else that has ever been created?
In fact, we, the ENTERPRISE Engineering and Manufacturing community (of which Information Technology, Enterprise Data Management, and Information Systems are 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
- Semantic structures equal Bills of Materials (semantic 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 “Control Structures” (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 and 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 Enterprises.
The Framework for Enterprise Architecture (the “Zachman Framework”) is simply a schema, a classification scheme for descriptive representations of objects (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.
The enterprise itself is the implementation, the instantiation. It is the end result of doing Enterprise Architecture, assuming that any Enterprise Architecture has been done.
I would observe that over the period of the Industrial Age until now, all airplanes, all locomotives, all buildings, all industrial products have been architected. However few (if any) Enterprises have been architected. Up until now, Enterprises have simply happened … somehow. There may be many systems implementations, manual systems and/or automated systems, material handling systems (blue collar systems) and/or record keeping systems (white collar systems), a LOT of incoherence and discontinuity (ineffectiveness) and a LOT of compensation for that discontinuity (entropy, inefficiency), lack of sufficient training for most systems professionals.
There is no architecture. There are no “Primitive” Models (all components occurring within a single cell of the Framework). There is no baseline for managing change. No Enterprise engineering has been done. Enterprise parts have been manufactured … but the Enterprise parts are not fitting together.
I predict that over the period of the Information Age, the next one or maybe two hundred years, all Enterprises will be architected. The same factors that drove the formalization of Architecture for industrial products in the Industrial Age will drive the formalization of Architecture for Enterprises in the Information Age: Complexity and Change. We are already beginning to see the trend.
My observation is that the definition of architecture is not in question and it is not negotiable. Architecture is the total set of intersections between the Abstractions and the Perspectives that constitute the set of relevant descriptive representations for any object to be created.
- If you cannot show me the Bill of Materials quite independent from Functional Specs quite independent from Geometry quite independent from Operating Instructions … etc., etc. …
- … And if you cannot show me Requirements quite independent from Schematics quite independent from Blueprints quite independent from Tooling Configurations … etc. … etc. …
- …. I do not believe you are doing Architecture work (aKa Engineering). A single variable model which is one Abstraction by one Perspective, a “Primitive” model, is the raw material for doing Engineering. If you have no “Primitive” models, you have no raw material for doing Engineering and therefore, you are not doing Engineering (that is, you are not doing “Architecture”).
In contrast, implementations (Manufacturing), are the instantiation of composite, multi-variable models. An implementation is the creation of the end results. These composite models are comprised of more than one Abstraction and/or more than one Perspective. A manufactured part (Material) has some functionality in some geometric location for some operation at some time for some objective. An instantiation, by definition, is a “composite.”
The question turns out to be, how did you create the composite, implementation instance? From Primitive models you have engineered from the perspective of the Enterprise? (Architected?) Or, did you simply create the Composite to produce an implementation ad hoc to whatever you were implementing (i.e. it was implemented, but NOT architected – i.e. you did not create any primitive models)? In addition … is the composite you created the whole complete object you are trying to create (the whole airplane, or whole locomotive or whole Enterprise) or is the composite just a part of the whole thing (a wing or a boiler or a “system”)?
Once again, if you cannot show me “Primitive” models, I know that you are not doing Architecture (Engineering). You are doing implementations (Manufacturing). And, if you are not creating “Enterprise-wide” primitive models, I know you are risking creating implementations that will not integrate into the Enterprise as a whole. You can manufacture parts of the whole iteratively and incrementally … however, they must be engineered to fit together or they are not likely to fit together (be integrated). You can even do the engineering, the Architecture, iteratively and incrementally, but in this case, you must do something over and above building incremental, iterative primitives to mitigate the risk of misalignment and disintegration. Enterprise-wide integration and alignment do not happen by accident. They must be engineered (architected).
If one thinks that an implementation, a result, a Composite model is Architecture, (whether it is the whole thing or only a part of the whole thing), then this is probably contributing to the misconception that, for example, the Roman Coliseum is Architecture.
The whole finished product, the end result, is the total collection of instantiated composites of all the abstractions and all the perspectives. If one’s perception that the end result is Architecture, there is little wonder why Enterprise Architecture (as in Enterprise-WIDE Architecture) is perceived to be big, monolithic, static, inflexible, unrealistic, impossible and generally unachievable. This misconception creates a DIS-incentive for even attempting Enterprise Architecture.
No! Implementations are not enterprise architecture! Implementations are the result of architecture … if any architecture has even been done!
If we ever want the Enterprise to be engineered so it is “lean and mean,” so that it meets all the requirements of the “owners” and “stakeholders,” we must start with architecture. If we want the Enterprise to be effective and efficient, so that it is integrated, so that it is dynamic, we must start with architecture. If we want to create new instances (implementations) on demand by assembling them to order from the primitive constructs (models) we already have in inventory, so that we can “assemble the Enterprise to order” (in Manufacturing, “mass customization”), we must start with architecture. If we want to have all these things we have to start working on the raw material for doing Engineering, we must start with the single variable, “Primitive” models … the basis for ARCHITECTURE.
I understand that we will have to continue to satisfy current demand for implementations by building Composite implementation constructs in the short term. However, as we get some Primitives engineered (architected) and into inventory, we can stipulate that any Composite models to be constructed MUST be constructed from the components of the architected Primitives we already have in inventory. In that fashion, eventually, we could migrate (maybe “evolve”) out of the disintegrated, discontinuous, inflexible legacy environment into an architected, coherent, flexible, dynamic, optimized Enterprise.
With planning and diligence using this approach, we could achieve the quality and longevity ascribed to Boeing 747’s or hundred story buildings or other high quality, long-lasting, superior performing Industrial Age, complex engineering products that we have learned how to engineer over the last few hundred years.
Otherwise, nothing will have changed … we will just continue doing more of the same … building and running systems (legacy implementations, manual or automated, blue collar or white collar) and it doesn’t make any difference what technologies we will be using. It is not a technical issue. It is an ENGINEERING issue, an ENTERPRISE engineering issue.
Conclusion
Are we going to start doing Enterprise engineering work (building Primitive models, i.e. Architecture) … or are we simply going to continue doing Enterprise manufacturing (building composite implementations, i.e. building and running systems)?
A quote often attributed to Albert Einstein, “Insanity is doing the same thing over and over again and expecting different results” can apply to the ways we have approached architecture and implementation.For references, please see “The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing”.www.ZachmanInternational.com. 2003.
