Methodologies and Technologies for Rapid Enterprise Architecture Delivery


| Home | Courses | Certification | Projects | Papers | Contact Us |



TEN Archive

Contact Us




Printable PDF Version

Background, Description and Utility

by John A. Zachman, President, Zachman International
© Copyright 1993-1997 Zachman International, Inc. All Rights Reserved.


John Zachman - "Concepts of Framework for Enterprise Architecture"


In the early ‘80’s, there was little interest in the idea of Enterprise Reengineering 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." Although from the outset, it was clear that it should have been referred to as a "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 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. 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.)

The Framework graphic in its most simplistic form depicts the design artifacts that constitute the intersection between the roles 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. Empirically, in the older disciplines, some other "artifacts" were observable that were being used for scoping and for implementation purposes. These roles are somewhat arbitrarily labeled PLANNER and SUB-CONTRACTOR and are included in the Framework graphic that is commonly exhibited. The Framework, as it is applied to an Enterprise, depicting Enterprise design artifacts (models,) using Enterprise terminology appears below in Figure 1.

Figure 1: The First Three Columns of the Zachman Framework

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.

 From the very inception of the Framework, some other product abstractions were known to exist because it was obvious that in addition to WHAT, HOW and WHERE, a complete description would necessarily have to include the remaining primitive interrogatives: WHO, WHEN and WHY. These three additional interrogatives would be manifest as three additional columns of models that, in the case of Enterprises, would depict: WHO does what work, WHEN do things happen and WHY are various choices made. The state of the art in terms of modeling formalisms, as well as the inclination to devote energy to produce these additional artifacts is still somewhat limited, certainly in the case of Enterprises. Because experience in modeling is so limited, the examples of models for the cells in the "other three columns" are much more hypothetical and much less empirical. However hypothetical they may be, the remaining three columns of models appear below in Figure 2.

Figure 2: The Other Three Columns of the Zachman Framework

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 single variables and making design decisions out of context results in sub-optimization with all its attendant costs and dissipation of energy. 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.

 This is the condition in which many Enterprises find themselves 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:

  1. simplify for understanding and communication, and
  2. clearly focus on independent variables for analytical purposes, but at the same time,
  3. maintain a disciplined awareness of contextual relationships that are significant to preserve the integrity of the object.

 It makes little difference whether the object is physical, like an airplane, 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 and raising its cost by optimizing the pieces, sub-optimizing the object.

Although the Framework for Enterprise Architecture 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. For this reason, the Framework, as applied to Enterprises, is helpful for sorting out very complex, technology and methodology 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 three perspectives: Owner, Designer, Builder ... and three abstractions: Material, Function, Geometry. 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 where they fit 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 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 ... that is, what they are doing, and what they are NOT doing.

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.


1. "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.

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. 1-800-879-2755.

The Author

John Zachman is the author of the "Framework for Information Systems Architecture", which has received broad acceptance throughout the world as an integrative framework for managing change in Enterprises and in the systems that support them. He is not only known for this work, but also for his early contributions to Business Systems Planning, IBM's widely used information planning methodology in the 1970s, as well as Intensive Planning, the basis for IBM's executive, team planning techniques.

Mr Zachman has focused on planning and information strategies, and on architecture, since 1970 and has written many articles on these subjects. He travels nationally and internationally, teaching and consulting, and has facilitated innumerable executive team planning sessions. He is a popular conference speaker known for motivating messages on information issues. He has spoken to thousands of information professionals and business managers on every continent.

John Zachman is a member of the International Advisory Board of the Data Administration Management Association, DAMA International; a member of the International Information Resource Management Advisory Council of Smithsonian Institution in Washington DC; and of the Board of Directors of the Repository/Architecture/Development Users Group.

John A. Zachman
Zachman International
2222 Foothill Blvd. Suite 337
La Cañada, Ca. 91011
Int'l Phone: +1-818-244-3763

Int'l Fax: +1-818-244-3763

Back to Contents.




| Home | Courses | Certification | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.