Enterprise Architecture Introduction and Framework Rules 

Framework Introduction
Zachman's framework for information systems architecture - first proposed in 1987 and later extended in 1992 - is a widely used approach for developing and/or documenting an enterprise-wide information systems architecture. Zachman based his framework on practices in traditional architecture and engineering. This resulted in an approach which on the vertical axis provides multiple perspectives of the overall architecture and on the horizontal axis a classification of the various artifacts of the architecture.
The purpose of the framework is to provide a basic structure which supports the organization, access, integration, interpretation, development, management, and changing of a set of architectural representations of the organizations information systems. Such objects or descriptions of architectural representations are usually referred to as Artifacts.
The framework, then, can contain global plans as well as technical details, lists and charts as well as natural language statements. Any appropriate approach, standard, role, method, technique, or tool may be placed in it. In fact, the framework can be viewed as a tool to organize any form of meta-data for the enterprise.
Framework Rules
- Dimension Importance - The columns have no order of priority or sequence, and the order of columns in the framework is arbitrary. (However, the left-to-right order presented above is so commonly used as to be a convention. By keeping this order of columns, it makes the framework easier to read and reference.
- Dimension Simplicity - Each column has a simple, basic model used to describe a portion of the enterprise and its information systems architecture. However, these models are not independent: rather they are interdependent and interact continuously. A change in one column often affects one or more other columns.
- Dimension Uniqueness - The basic model of each column must be unique. By having unique models, each artifact of the enterprise can be unambiguously classified and subsequently retrieved.
- Perspective Uniqueness - Each row presents a distinct, unique perspective, associated with a participant (or more usually a group of participants) in information systems planning, development, and usage.
- Cell Uniqueness - If each dimension is unique and each perspective is unique, then each cell must also be unique. Consequently cell content cannot be found in more than one cell. For example, a business entity can only be found at the intersection of Enterprise Model and What. A data entity can only be found at the intersection of System Model and What.
- Dimension Necessity - All six dimensions are needed to fully represent each perspective. In other words, the composite or integration of all cell models in one row constitutes a complete model from the perspective of that row.
- Logic Recursiveness - The framework is recursive with respect to versions (that is, alternative systems descriptions - such as existing and planned - may be kept) and decomposition (that is, the cells in the framework can and may be presented at various levels of detail/granularity).
Adapted from: Sowa, J.F. & J.A. Zachman, 1992, and Inmon, W.H, J.A. Zachman, & J.G. Geiger, 1997.
Further explanation of the framework components:
Overview & Rules - Columns - Rows - Products - Goals - Tools - Architecture Development Teams