In the early ‘80’s, there was little interest in the idea of Enterprise Engineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of architecture was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resulted in the “Framework for Information Systems Architecture” (later referred to as The Zachman Framework). Although from the outset, it was clear that it should have been referred to as the “Framework for Enterprise Architecture,” that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, world-wide focus on Enterprise Engineering.

The Framework for Enterprise Architecture (or Zachman Framework) as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems, manual systems as well as automated systems. It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g. buildings or airplanes, etc.)

The Framework graphic in its most simplistic form depicts the design artifacts that constitute the intersection between the perspectives represented in the design process, that is, OWNER, DESIGNER and BUILDER; and the product abstractions, that is, WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the components are relative to one another, WHO (operating instructions) is doing what work, WHEN (timing diagrams) do things happen and WHY (engineering design objectives) do things happen. Empirically, in the older disciplines, some other artifacts were observable that were being used for scoping and for implementation purposes. These additional perspectives are labeled PLANNER and IMPLEMENTER and are included in the Framework graphic that is commonly exhibited.

In the more recent Framework Graphics, the end result, in the case of Enterprises, THE Enterprise itself, is also included to complete the classification structure of the descriptive representations (the “Design Artifacts”) as well as the end result (THE Enterprise).

The Framework as a classification structure, in its most generic form appears below:

A fully populated version of The Framework Graphic, Version 3.0 of 2011 is depicted below as Figure 2. This version of The Framework is the product of 30 or more years of research and experience finding words and graphic concepts to represent and convey the classification logic as precisely as possible.2

The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the “Product Definition” design artifacts. This has enabled enormous increases in product sophistication and the ability to manage high rates of product change over time. Similarly, disciplined production and management of “Enterprise Definition” (i.e. the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increases in Enterprise sophistication and accommodation of high rates of Enterprise change over time.

The Framework is a generic classification scheme for design artifacts, that is, descriptive representations of any complex object. The utility of such a classification scheme is to enable focused concentration on selected aspects of an object without losing a sense of the contextual, or holistic, perspective. In designing and building complex objects, there are simply too many details and relationships to consider simultaneously. However, at the same time, isolating sub-sets or components and making design decisions out of context results in sub-optimization with all its attendant costs and dissipation of energy (entropy). Restoration of integrity or retrofitting the sub-optimized components of the resultant object, such that they might approximate the purpose for which the object was originally intended, may well be financially prohibitive if not logically impossible.

This is the condition in which many Enterprises find themselves today after about fifty years of building automated systems, out-of-context. They have a large inventory of current systems, built out-of-context, not integrated, not supporting the Enterprise, that are consuming enormous amounts of resource for maintenance and are far and away too costly to replace. As a matter of fact, the inventory of existing systems has come to be referred to as “the legacy,” a kind-of albatross, a penalty to be paid for the mistakes of the past.

A balance between the holistic, contextual view and the pragmatic, implementation view can be facilitated by a Framework that has the characteristics of any good classification scheme, that is, it allows for abstractions intended to:

• simplify for understanding and communication, and
• clearly focus on independent variables (primitives, individual Framework Cells) for analytical purposes, but at the same time,
• maintain a disciplined awareness of contextual (integrative) relationships of the Enterprise as a whole that are significant to preserve the integrity of the object thereby enabling
• the creation of an infinite variety of implementation composites derived from normalized, Enterprise-engineered primitives, as required to perform the work of the Enterprise.

It makes little difference whether the object is physical, like an airplane or a building or a computer, or conceptual, like an Enterprise. The challenges are the same. How do you design and build it piece-by-piece such that it achieves its purpose without dissipating its value, raising its operating costs and inhibiting (or prohibiting) change by optimizing the pieces and sub-optimizing the object.

Although the Framework for Enterprise Architecture (or The Zachman Framework) is an application of Framework concepts to Enterprises, the Framework itself is generic. It is a comprehensive, logical structure for descriptive representations (i.e. models, or design artifacts) of any complex object and is neutral with regard to the processes or tools used for producing the descriptions.

Like any good classification system, the Framework is “clean,” “normalized,” one fact in one place. There are no mixtures, “apples and oranges” in the structure. The classification is holistic, complete and it is stable. The same classification on both axes has been employed by humanity for thousands of years. It is not going to change. For this reason, the Framework, as applied to Enterprises, is helpful for sorting out very complex, Enterprise “engineering” choices and issues that are significant both to general management and to technology management. 

In summary, the Framework is:

1. SIMPLE - it is easy to understand ... not technical, purely logical. In its most elemental form, it is five perspectives: Owner, Designer, Builder bounded by Scope (or, Strategist) and Detail (or, Implementor) plus the instantiation, the Enterprise itself ... and six abstractions: What (Things), How (Process), Where (Location), Who (Responsibility), When (Timing) and Why (Motivation). Anybody (technical or non-technical) can understand it.
2. COMPREHENSIVE - it addresses the Enterprise in its entirety. Any issues can be mapped against it to understand their primitive (or elemental) composition within the context of the Enterprise as a whole.
3. a LANGUAGE - it helps you think about complex concepts and communicate them precisely with few, non-technical words.
4. a PLANNING TOOL - it helps you make better choices as you are never making choices in a vacuum. You can position issues in the context of the Enterprise and see a total range of alternatives.
5. a PROBLEM-SOLVING TOOL - it enables you to work with abstractions, to simplify, to isolate simple, single variables without losing sense of the complexity of the Enterprise as a whole.
6. NEUTRAL - it is defined totally independently of tools or methodologies and therefore any tool or any methodology can be mapped against it to understand their implicit trade-offs and degree of completion ... that is, what they are doing, and what they are NOT doing.
7. the RAW MATERIAL FOR ENTERPRISE ENGINEERING – the primitive models, when operationalized for an Enterprise, are the design artifacts required for Enterprise Engineering just like the drawings, functional specs, bills-of-material, etc., etc. are the design artifacts required to engineer any physical object.

The Framework for Enterprise Architecture is not “the answer.” It is a tool ... a tool for thinking. If it is employed with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the complexities and dynamics of the Information Age Enterprise.

If the models as specified by the Framework were operationalized for a given Enterprise, engineering design objectives like alignment (quality), integration, flexibility, interoperability, reusability, etc. could be an operating reality employed to accommodate complexity and optimize the Enterprise. The models, if retained and maintained, would serve as a baseline for managing change. These are the characteristics of architecture for anything.

Architecture is not one thing. It is a set of things, in fact, a set of 30 descriptive representations relevant for describing a complex object such that it can be created (that is, engineered, optimized so it meets its design objectives) and relevant for changing (that is, improving the object over time). This is true for Enterprises just as it is true for buildings, airplanes, automobiles, bridges, super computers, battleships, semi-conductor chips or any other complex object.

TO GET YOUR OWN, PRINTABLE COPY OF THE ZACHMAN FRAMEWORK™ PDF, JUST CREATE AN ACCOUNT BY CLICKING "LOG IN" AT THE TOP OF THIS PAGE.

ALSO CHECK OUT: John Zachman's Concise Definition of the Zachman Framework™

Endnotes

1. The original article was written in 1996 and has not been materially changed except to provide updated graphics and minor editorial changes to accommodate the updated graphics. Top
2. The current version of the Framework Graphic can be accessed and Printed at zachman.com. I do not expect this version of the graphic to be modified appreciably, if at all, for the foreseeable future. Top

References

1. "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298.
2. "Extending and Formalizing the Framework for Information Systems Architecture." J.F. Sowa and J. A. Zachman. IBM Systems Journal, vol. 31, no. 3, 1992. IBM Publication G321-5488. .

If you need to Permission to republish The Zachman Framework™ graphic image, please see our Copyrights & Permissions FAQ.