Zachman Framework


The Zachman Framework is an enterprise ontology and is a fundamental structure for Enterprise Architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: Identification, Definition, Representation, Specification, Configuration and Instantiation.
The Zachman Framework is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes.; rather, it is an ontology whereby a schema for organizing architectural artifacts is used to take into account both who the artifact targets and what particular issue is being addressed.
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.

Overview

The title "Zachman Framework" refers to The Zachman Framework for Enterprise Architecture with version 3.0 being the most current. The Zachman Framework has evolved in its thirty-year history to include:
In other sources the Zachman Framework is introduced as a framework, originated by and named after John Zachman, represented in numerous ways, see image. This framework is explained as, for example:
Beside the frameworks developed by John Zachman, numerous extensions and/or applications have been developed, which are also sometimes called Zachman Frameworks, however they generally tend to be graphical overlays of the actual framework itself.
The Zachman Framework summarizes a collection of perspectives involved in enterprise architecture. These perspectives are represented in a two-dimensional matrix that defines along the rows the type of stakeholders and with the columns the aspects of the architecture. The framework does not define a methodology for an architecture. Rather, the matrix is a template that must be filled in by the goals/rules, processes, material, roles, locations, and events specifically required by the organization. Further modeling by mapping between columns in the framework identifies gaps in the documented state of the organization.
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. When done by IT the lower level of focus is on information technology, however it can apply equally to physical material and the associated physical processes, roles, locations etc. related to those items.

History

In the 1980s John Zachman had been involved at IBM in the development of business system planning, a method for analyzing, defining and designing an information architecture of organizations. In 1982 Zachman had already concluded that these analyses could reach far beyond automating systems design and managing data into the realms of strategic business planning and management science in general. It may be employed in the areas of enterprise architecture, data-driven systems design, data classification criteria, and more.

"Information Systems Architecture" framework

In the 1987 article "A Framework for Information Systems Architecture" 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 involves at least three perspectives: raw material or data, function of processes, and location or networks.
The Information Systems Architecture is designed to be a classification schema for organizing architecture models. It provides a synoptic view of the models needed for enterprise architecture. Information Systems Architecture does not define in detail what the models should contain, it does not enforce the modeling language used for each model, and it does not propose a method for creating these models.

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 the 1997 paper "Concepts of the Framework for Enterprise Architecture" Zachman said that the framework should be referred to as a "Framework for Enterprise Architecture", and should have from the beginning. In the early 1980s however, according to Zachman, 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".
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:

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. The Zachman Framework provides the thirty-six necessary categories for completely describing anything; especially complex things like manufactured goods, constructed structures, and enterprises. The framework provides six different transformations of an abstract idea 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 of the Zachman Framework categorizes the rows as follows:
In summary, each perspective focuses attention on the same fundamental questions, then answers those questions from that viewpoint, creating different descriptive representations, which translate from higher to lower perspectives. The basic model for the focus remains constant. The basic model of each column is uniquely defined, yet related across and down the matrix. In addition, the six categories of enterprise architecture components, and the underlying interrogatives that they answer, form the columns of the Zachman Framework and these are:
  1. Inventory Sets — What
  2. Process Flows — How
  3. Distribution Networks — Where
  4. Responsibility Assignments — Who
  5. Timing Cycles — When
  6. Motivation Intentions — Why
In Zachman's opinion, the single factor that makes his framework unique is that each element on either axis of the matrix is explicitly distinguishable from all the other elements on that axis. The representations in each cell of the matrix are not merely successive levels of increasing detail, but actually are different representations — different in context, meaning, motivation, and use. Because each of the elements on either axis is explicitly different from the others, it is possible to define precisely what belongs in each cell.

Models of cells

The Zachman Framework typically is depicted as a bounded 6 x 6 "matrix" with the Communication Interrogatives as Columns and the Reification Transformations as Rows. The framework classifications are repressed by the Cells, that is, the intersection between the Interrogatives and the Transformations.
The cell descriptions are taken directly from version 3.0 of the Zachman Framework.
;Executive Perspective
  1. Inventory Identification
  2. Process Identification
  3. Distribution Identification
  4. Responsibility Identification
  5. Timing Identification
  6. Motivation Identification
;Business Management Perspective
  1. Inventory Definition
  2. Process Definition
  3. Distribution Definition
  4. Responsibility Definition
  5. Timing Definition
  6. Motivation Definition
;Architect Perspective
  1. Inventory Representation
  2. Process Representation
  3. Distribution Representation
  4. Responsibility Representation
  5. Timing Representation
  6. Motivation Representation
;Engineer Perspective
  1. Inventory Specification
  2. Process Specification
  3. Distribution Specification
  4. Responsibility Specification
  5. Timing Specification
  6. Motivation Specification
;Technician Perspective
  1. Inventory Configuration
  2. Process Configuration
  3. Distribution Configuration
  4. Responsibility Configuration
  5. Timing Configuration
  6. Motivation Configuration
;Enterprise Perspective
  1. Inventory Instantiations
  2. Process Instantiations
  3. Distribution Instantiations
  4. Responsibility Instantiations
  5. Timing Instantiations
  6. Motivation Instantiations
Since the product development 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 takes place within each cell. If a cell is not made explicit, it is implicit. 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.

Framework set of rules

The framework comes with a set of rules:
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. Some feel that following this model completely can lead to too much emphasis on documentation, as artifacts would be needed for every one of the thirty cells in the framework. Zachman, however, indicates that only the facts needed to solve the problem under analysis need be populated.
John Zachman clearly states in his documentation, presentations, and seminars that, as framework, there is flexibility in what depth and breadth of detail is required for each cell of the matrix based upon the importance to a given organization. An automaker whose business goals may necessitate an inventory and process-driven focus, could find it beneficial to focus their documentation efforts on What and How columns. By contrast, a travel agent company, whose business is more concerned with people and event-timing, could find it beneficial to focus their documentation efforts on Who, When, and Where columns. However, there is no escaping the Why column's importance as it provides the business drivers for all the other columns.

Applications and influences

Since the 1990s the Zachman Framework has been widely used as a means of providing structure for information technology engineering-style enterprise modeling. 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.
Other sources:
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:
Other examples:
Less obvious are the ways the original Zachman framework has stimulated the development of other enterprise architecture frameworks, such as in the NIST Enterprise Architecture Model, the C4ISR AE, the DOE AE, and the DoDAF:
The Zachman Framework methodology has for example been used by the United States Department of Veterans Affairs 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,.
The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework.

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.
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 which is a de facto standard across the Information Industry;
  2. The diagram emphasizes the importance of the often-neglected Zachman Row-Six. Representations in Mr. 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

While the Zachman Framework is widely discussed, its practical value has been questioned:
This criticism suggests that the Zachman Framework can hardly reflect actual best practice in EA.