thumb|360px|The Zachman Framework of enterprise architecture

<!-- Deleted image removed: thumb|right|Zachman Framework V3.0. Used with Permission from the Author -->The Zachman Framework is a structured tool used in enterprise architecture to organize and understand complex business systems. It acts as an ontology, providing a clear and formal way to describe an enterprise through a two-dimensional grid. This grid combines two key perspectives: the basic questions of What, How, When, Who, Where, and Why, and the process of turning abstract ideas into concrete realities, known as reification. These reification stages include identification, definition, representation, specification, configuration, and instantiation. While influential in shaping enterprise architecture, the framework is often considered theoretical, with limited direct adoption in fast-paced industries like technology, where agile methods are preferred.

Unlike a methodology, the Zachman Framework does not prescribe specific steps or processes for gathering or using information.

The framework is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated several times since, with version 3.0 being the most current.

Overview

The Zachman Framework has evolved in its thirty-year history to include:

  • The initial framework, named A Framework for Information Systems Architecture, by John Zachman published in a 1987 article in the IBM Systems journal.
  • The Zachman Framework for Enterprise Architecture, an update of the 1987 original in the 1990s extended and renamed.
  • One of the later versions of the Zachman Framework, offered by Zachman International as industry standard.

thumb|320px|Collage of Zachman Frameworks as presented in several books on Enterprise Architecture from 1997 to 2005.

In other sources, this framework is explained as, for example:

  • a framework to organize and analyze data,
  • a framework for enterprise architecture.
  • a classification system, or classification scheme.
  • a matrix, often in a 6x6 matrix format
  • a two-dimensional model or an analytic model.
  • a two-dimensional schema, used to organize the detailed representations of the enterprise.

In addition to John Zachman's original frameworks, various extensions and applications have emerged, often referred to as Zachman Frameworks, though they typically serve as graphical overlays atop the core framework.

The Zachman Framework organizes key perspectives of enterprise architecture into a two-dimensional matrix. The rows represent different stakeholder types, while the columns outline various architectural aspects. It does not provide a specific methodology for architecture development. Instead, the matrix serves as a template to be populated with the organization's unique goals, rules, processes, materials, roles, locations, and events. Mapping relationships between columns helps identify gaps in the organization's documented state.

The framework is a logical structure for classifying and organizing the descriptive representations of an enterprise. It is significant to both the management of the enterprise, and the actors involved in the development of enterprise systems. While there is no order of priority for the columns of the Framework, the top-down order of the rows is significant to the alignment of business concepts and the actual physical enterprise. The level of detail in the Framework is a function of each cell (and not the rows). When done by IT the lower level of focus is on information technology, however it can apply equally to physical material (ball valves, piping, transformers, fuse boxes for example) and the associated physical processes, roles, locations etc. related to those items.

History

In the 1980s, John Zachman contributed to IBM's development of Business System Planning (BSP), a method for analyzing, defining, and designing organizational information architectures. By 1982, Zachman recognized that such analyses extended beyond automating systems design and data management, impacting strategic business planning and management science broadly. The approach could also apply to emerging fields like enterprise architecture, data-driven system design, and data classification methodologies. Zachman noted that the term "architecture" was used loosely by information systems professionals, and meant different things to planners, designers, programmers, communication specialists, and others. In searching for an objective, independent basis upon which to develop a framework for information systems architecture, Zachman looked at the field of classical architecture, and a variety of complex engineering projects in industry. He saw a similar approach and concluded that architectures exist on many levels and involve at least three perspectives: raw material or data, function or processes, and location or networks.

Extension and formalization

In the 1992 article "Extending and Formalizing the Framework for Information Systems Architecture" John F. Sowa and John Zachman present the framework and its recent extensions and show how it can be formalized in the notation of conceptual graphs. Also in 1992:

Later during the 1990s,

In 2008, Zachman Enterprise introduced the Zachman Framework: The Official Concise Definition as a new Zachman Framework standard.

Extended and modified frameworks

Since the 1990s several extended frameworks have been proposed, such as:

  • Matthew & McGee (1990) extended the three initial perspectives "what", "how" and "where", to event (the "when"), reason (the "why") and organization (the "who").
  • Vladan Jovanovic et al. (2006) presents a Zachman Cube, an extended of the Zachman Framework into a multidimensional Zachman's Cube.

Topics

Concept

The basic idea behind the Zachman Framework is that the same complex thing or item can be described for different purposes in different ways using different types of descriptions (e.g., textual, graphical). The Zachman Framework provides the thirty-six necessary categories for completely describing anything; especially complex things like manufactured goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises (i.e., the organization and all of its goals, people, and technologies). The framework provides six different transformations of an abstract idea (not increasing in detail, but transforming) from six different perspectives.

It allows different people to look at the same thing from different perspectives. This creates a holistic view of the environment, an important capability illustrated in the figure.

Views of rows

Each row represents a total view of the solution from a particular perspective. An upper row or perspective does not necessarily have a more comprehensive understanding of the whole than a lower perspective. Each row represents a distinct, unique perspective; however, the deliverables from each perspective must provide sufficient detail to define the solution at the level of perspective and must translate to the next lower row explicitly.

Each perspective must take into account the requirements of the other perspectives and the restraint those perspectives impose. The constraints of each perspective are additive. For example, the constraints of higher rows affect the rows below. The constraints of lower rows can, but do not necessarily affect the higher rows. Understanding the requirements and constraints necessitates communication of knowledge and understanding from perspective to perspective. The Framework points the vertical direction for that communication between perspectives.]]

The current version (3) of the Zachman Framework categorizes the rows as follows:

  • Executive Perspective (Scope Contents) – The first architectural sketch is a "bubble chart" or Venn diagram, which depicts in gross terms the size, shape, partial relationships, and basic purpose of the final structure. It corresponds to an executive summary for a planner or investor who wants an overview or estimate of the scope of the system, what it would cost, and how it would relate to the general environment in which it will operate.
  • Business Management Perspective (Business Concepts) – Next are the architect's drawings that depict the final building from the perspective of the owner, who will have to live with it in the daily routines of business. They correspond to the enterprise (business) models, which constitute the designs of the business and show the business entities and processes and how they relate.
  • Architect Perspective (System Logic) – The architect's plans are the translation of the drawings into detail requirements representations from the designer's perspective. They correspond to the system model designed by a systems analyst who must determine the data elements, logical process flows, and functions that represent business entities and processes.
  • Engineer Perspective (Technology Physics) – The contractor must redraw the architect's plans to represent the builder's perspective, with sufficient detail to understand the constraints of tools, technology, and materials. The builder's plans correspond to the technology models, which must adapt the information systems model to the details of the programming languages, input/output (I/O) devices, or other required supporting technology.
  • Technician Perspective (Tool Components) – Subcontractors work from shop plans that specify the details of parts or subsections. These correspond to the detailed specifications that are given to programmers who code individual modules without being concerned with the overall context or structure of the system. Alternatively, they could represent the detailed requirements for various commercial-off-the-shelf (COTS), government off-the-shelf (GOTS), or components of modular systems software being procured and implemented rather than built.
  • Enterprise Perspective or (Operations Instances)

Focus of columns

In summary, each perspective focuses attention on the same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations (i.e., models), which translate from higher to lower perspectives. The basic model for the focus (or product abstraction) remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix.

The cell descriptions are taken directly from version 3.0 of the Zachman Framework.

;Executive Perspective

  1. (What) Inventory Identification
  2. (How) Process Identification
  3. (Where) Distribution Identification
  4. (Who) Responsibility Identification
  5. (When) Timing Identification
  6. (Why) Motivation Identification

;Business Management Perspective

  1. (What) Inventory Definition
  2. (How) Process Definition
  3. (Where) Distribution Definition
  4. (Who) Responsibility Definition
  5. (When) Timing Definition
  6. (Why) Motivation Definition

;Architect Perspective

  1. (What) Inventory Representation
  2. (How) Process Representation
  3. (Where) Distribution Representation
  4. (Who) Responsibility Representation
  5. (When) Timing Representation
  6. (Why) Motivation Representation

;Engineer Perspective

  1. (What) Inventory Specification
  2. (How) Process Specification
  3. (Where) Distribution Specification
  4. (Who) Responsibility Specification
  5. (When) Timing Specification
  6. (Why) Motivation Specification

;Technician Perspective

  1. (What) Inventory Configuration
  2. (How) Process Configuration
  3. (Where) Distribution Configuration
  4. (Who) Responsibility Configuration
  5. (When) Timing Configuration
  6. (Why) Motivation Configuration

;Enterprise Perspective

  1. (What) Inventory Instantiations
  2. (How) Process Instantiations
  3. (Where) Distribution Instantiations
  4. (Who) Responsibility Instantiations
  5. (When) Timing Instantiations
  6. (Why) Motivation Instantiations

Since the product development (i.e., architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a question from a perspective, typically, the models or descriptions are higher-level depictions or the surface answers of the cell. The refined models or designs supporting that answer are the detailed descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place within each cell. If a cell is not made explicit (defined), it is implicit (undefined). If it is implicit, the risk of making assumptions about these cells exists. If the assumptions are valid, then time and money are saved. If, however, the assumptions are invalid, it is likely to increase costs and exceed the schedule for implementation.

  • Rule 1 The columns have no order : The columns are interchangeable but cannot be reduced or created
  • Rule 2 Each column has a simple generic model : Every column can have its own meta-model
  • Rule 3 The basic model of each column must be unique : The basic model of each column, the relationship objects and the structure of it is unique. Each relationship object is interdependent but the representation objective is unique.
  • Rule 4 Each row describes a distinct, unique perspective : Each row describes the view of a particular business group and is unique to it. All rows are usually present in most hierarchical organizations.
  • Rule 5 Each cell is unique : The combination of 2,3 & 4 must produce unique cells where each cell represents a particular case. Example: A2 represents business outputs as they represent what are to be eventually constructed.
  • Rule 6 The composite or integration of all cell models in one row constitutes a complete model from the perspective of that row : For the same reason as for not adding rows and columns, changing the names may change the fundamental logical structure of the Framework.
  • Rule 7 The logic is recursive : The logic is relational between two instances of the same entity.

The framework is generic in that it can be used to classify the descriptive representations of any physical object as well as conceptual objects such as enterprises. It is also recursive in that it can be used to analyze the architectural composition of itself. Although the framework will carry the relation from one column to the other, it is still a fundamentally structural representation of the enterprise and not a flow representation.

Flexibility in level of detail

One of the strengths of the Zachman Framework is that it explicitly shows a comprehensive set of views that can be addressed by enterprise architecture. The Zachman Framework can be applied both in commercial companies and in government agencies. Within a government organization the framework can be applied to an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities.

Customization

Zachman Framework is applied in customized frameworks such as the TEAF, built around the similar frameworks, the TEAF matrix.

<gallery class="center">

File:TEAF Matrix of Views and Perspectives.svg|TEAF Matrix of Views and Perspectives.

File:Framework for EA Direction, Description, and Accomplishment Overview.jpg|Framework for EA Direction, Description, and Accomplishment Overview.

File:TEAF Products.jpg|TEAF Products.

File:TEAF Work Products for EA Direction, Description, and Accomplishment.jpg|TEAF Work Products for EA Direction, Description, and Accomplishment.

</gallery>

Standards based on the Zachman Framework

Zachman Framework is also used as a framework to describe standards, for example standards for healthcare and healthcare information system. Each cell of the framework contains such a series of standards for healthcare and healthcare information system.

Mapping other frameworks

Another application of the Zachman Framework is as reference model for other enterprise architectures, see for example these four:

<gallery class="center">

File:EAP mapped to the Zachman Framework.jpg|EAP mapped to the Zachman Framework, 1999

File:DOD C4ISR Architecture Framework Products Mapped.jpg|Mapping the C4ISR, 1999

File:DoD Products Map to the Zachman Framework Cells.jpg|DoD Products Map to the Zachman Framework Cells, 2003.

File:DoDAF Support to the Builder.jpg|Mapping a part of the DoDAF, 2007.

</gallery>

Other examples:

  • Analysis of the Rational Unified Process as a Process,
  • How the Model-driven architecture (MDA) models used in software development map to the Zachman Framework.
  • Mapping the IEC 62264 models onto the Zachman framework for analysing products information traceability.
  • Mapping the TOGAF Architecture Development Method (e.g. the methodology) to the Zachman Framework.

Example: One-VA Enterprise Architecture

The Zachman Framework methodology has for example been used by the United States Department of Veterans Affairs (VA) to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required defining all aspects of the VA enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing the methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified and resolved.

<gallery class="center">

File:Integrated Process Flow for VA IT Projects.jpg|Integrated Process Flow for VA IT Projects (2001)

File:VA Zachman Framework Portal.jpg|VA Zachman Framework Portal

File:VA EA Repository Introduction.jpg|VA EA Repository Introduction (2008)

File:A Tutorial on the Zachman Architecture Framework.jpg|A Tutorial on the Zachman Architecture Framework

</gallery>

The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework.

  • The Zachman Framework was used as a reference model to initiate enterprise architecture planning in 2001.
  • Somewhere in between the VA Zachman Framework Portal was constructed.
  • This VA Zachman Framework Portal is still in use as a reference model for example in the determination of EA information collected from various business and project source documents.

Eventually, an enterprise architecture repository was created at the macro level by the Zachman framework and at a cell level by the meta-model outlined below.

thumb|600px|center|VA EA Meta-Model Cell Details Enlarged.

This diagram has been incorporated within the VA-EA to provide a symbolic representation of the metamodel it used, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of Commercial EA Repository Software. It was developed using an object oriented database within the Caliber-RM Software Product. Caliber-RM is intended to be used as a software configuration management tool; not as an EA repository.

However, this tool permitted defining entities and relationships and for defining properties upon both entities and relationships, which made it sufficient for building an EA repository, considering the technology available in early 2003. The personal motivation in selecting this tool was that none of the commercial repository tools then available provided a true Zachman Framework representation, and were highly proprietary, making it difficult to incorporate components from other vendors or from open source.

This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to information technology investment management.

  1. Progressing through the rows from top to bottom, one can trace-out the systems development life cycle (SDLC) which is a de facto standard across the Information Industry;
  2. The diagram emphasizes the importance of the often-neglected Zachman Row-Six (the Integrated, Operational Enterprise View). Representations in Zuech's interpretation of Zachman row-six consist, largely, of measurable service improvements and cost savings/avoidance that result from the business process and technology innovations that were developed across rows two through five.

Row-six provides measured return on investment for Individual Projects and, potentially, for the entire investment portfolio. Without row-six the Framework only identifies sunk-cost, but the row-six ROI permits it to measure benefits and to be used in a continuous improvement process, capturing best practices and applying them back through row-two.

Criticism

EA practitioner Stanley Gaver argues that "the analogy to classical architecture first made by John Zachman is faulty and incomplete". There are no detailed examples demonstrating the successful practical application of the framework; in 2004 John Zachman admitted that the framework is theoretical and has never been fully implemented: "If you ask who is successfully implementing the whole framework, the answer is nobody that we know of yet".

See also

  • Conceptual schema
  • Data model
  • Enterprise Architecture framework
  • Enterprise Architecture Planning
  • FDIC Enterprise Architecture Framework
  • Five Ws
  • View model

Notes

References

  • The Zachman Framework: The Official Concise Definition by John A. Zachman at Zachman International, 2009.
  • The Zachman Framework Evolution : overview of the evolution of the Zachman Framework by John P. Zachman at Zachman International, April 2009.
  • UML, RUP, and the Zachman Framework: Better together, by Vitalie Temnenco, IBM, 15 Nov 2006.