Zachman framework
From Wikipedia, the free encyclopedia
The Zachman Framework is a well established taxonomy often used in Information Technology departments by the teams responsible for developing and documenting an Enterprise Architecture.[1] The taxonomy is used for organizing architectural "artifacts" that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed. These artifacts may include design documents, specifications, and models.[2]
Originally conceived by John Zachman at IBM in the 1980s, the Framework is often referenced as a standard taxonomy for expressing the basic elements of enterprise architecture.[3] The Zachman Framework has been recognized by the U.S. Federal Government as having "... received worldwide acceptance as an integrated framework for managing change in enterprises and the systems that support them." [4]
John Zachman describes his work as follows:
The Framework, as it applies to enterprises, is a logical structure for identifying and organizing the descriptive representations (models) that are important in the management of enterprises and to the development of the systems, both automated and manual, that comprise them.[5]
According to Zachman, this taxonomy 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 in the process of designing and producing complex physical products (e.g. buildings or airplanes). It uses a two dimensional classification model based on the six basic interrogatives (What, How, Where, Who, When, and Why) intersecting six distinct perspectives, which relate to stakeholder groups (Planner, Owner, Designer, Builder, Implementer and Worker). The intersecting cells of the Framework correspond to models which, if documented, can provide a holistic view of the enterprise.[6]
Contents |
[edit] Use of the Zachman Framework
Marc Lankhorst, in his book Enterprise Architecture At Work,[7] describes the advantages and disadvantages of using this taxonomy for developing an Enterprise Architecture.
The advantage of the Zachman framework is that it is easy to understand, it addresses the enterprise as a whole, it is defined independently of tools or methodologies, and any issues can be mapped against it to understand where they fit. An important drawback is the large number of cells, which is an obstacle for the practical applicability of the framework. Also the relations between the cells are not that well specified. Notwithstanding these drawbacks, Zachman is to be credited with providing the first comprehensive framework for enterprise architecture, and his work is still widely used.
John Zachman described how to use his framework in a presentation to the Data Management Association of Puget Sound (April 2007) as follows:
The Framework does not prescribe anything about which models you have to build before you can deliver an implementation. Only YOU (or your methodology)determines which models (or "slivers" of models) you are actually going to build (or NOT build) over the process of developing systems. On the other hand, the Framework, by definition, identifies the total, comprehensive set of models relevant for describing the entire Enterprise. Therefore, the Framework is a convenient analytical tool to help you determine how you will feel if you (or your methodology) are NOT going to produce all the models ... or if you are going to do something that will INHIBIT integrated accumulation of the comprehensive set of models in the long term while you are satisfying current demand in the short term.[8]
[edit] Characteristics
The Zachman Framework has been compared with the Periodic Table. In the same way that atoms in the the Periodic Table of Chemical Elements are identified as the building blocks of matter, the cells in the Zachman Framework are identified as the building blocks of enterprises.[6]
The columns of the framework, which have no order of importance, represent unique abstractions of the enterprise in order to reduce the complexity of any single model that is built. The cell models are described as "primitive models," in that in each there is only a single variable. "Composite models," which are comprised of two or more variables, are needed in the design of solutions to satisfy business requirements. John Zachman maintains that primitive models are necessary for reusability and for engineering commonality across an enterprise, and that only primitive models can be considered to be elements of architecture.[6]
Each cell model in each column constrains the content of the cell below it. This ensures alignment between the intentions of enterprise owners, as represented by Row 2 of the framework, and with whatever is implemented to build the enterprise, as represented by Row 5 of the framework.
The granularity of detail in the Zachman Framework is a property of any individual cell regardless of any row. Depending on the requirement, planning or implementation, a cell model may have relatively little detail or an excruciating level of detail.[9]
The Zachman framework can be used at many different levels of an organization. For example, a framework used at the enterprise level could provide artifacts for the entire enterprise. A separate framework could be created at the level of a single division within the enterprise.[10]
[edit] The Zachman Schema
There are several versions of the diagram depicting the Zachman Framework for Enterprise Architecture. The diagram used in this article has been adapted from an official version that includes details about the cell models and which is made available by Zachman International. [11]
[edit] Framework rules
Adapted from: Sowa, J.F. & J.A. Zachman, 1992, and Inmon, W.H, J.A. Zachman, & J.G. Geiger, 1997.[12]
Rule 1: Do not add rows or columns to the Framework
The structure of the Framework as it has been designed identifies all possible primitive representations relevant to describing an enterprise. Adding rows or columns would introduce redundancies or discontinuities.
Rule 2: Each column has a simple generic model
The simple generic model for each column is the variable represented by the column as related to itself, e.g., the generic model for Column 1 is Thing - Relationship - Thing.
Rule 3: Each cell model specializes its column's generic model
The design of any cell model starts with its generic, columnar model and then adjusted according to the semantic constraints of the row it is in.
Rule 4: No meta concept can be classified into more than one cell
Each cell is unique. There is no redundancy.
Rule 5: Do not create diagonal relationships between cells
People in the different perspectives - Owner, Designer, Builder - often use the same terms to express different concepts. Creating diagonal relationships leads to semantic discord and misinterpretation.
Rule 6: Do not change the names of the rows and columns
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 generic, recursive
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.
[edit] The Zachman Framework and Enterprise Architecture
The Zachman Framework does not prescribe how any cell model is to be created, including any notation or level of detail. This is left to organizations to determine, based on the methodologies they have adopted.[9]
Organizations that adopt the Zachman Framework approach to enterprise architecture for engineering their enterprises require a methodology for carrying out the following functions:[13]
a. Build primitive models
b. Store primitive models
c. Manage (enforce) primitive models
d. Change primitive models
e. Assemble composite models from primitive models (for implementations)
[edit] References
- ^ The Open Group Architecture Framework
- ^ A Comparison of the Top Four Enterprise Architecture Methodologies, Roger Sessions, Microsoft Developer Network Architecture Center,
- ^ The Open Group Architecture Framework
- ^ Federal Enterprise Architecture Framework
- ^ " A Framework for Information Systems Architecture", John A. Zachman, IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298.
- ^ a b c Interview with John Zachman, by Roger Sessions, Editor-in-Chief, Perspectives of the International Association of Software Architects
- ^ Enterprise Architecture At Work: Modeling Communications and Analysis, by Marc Lankhorst, Springer, 2005, page 24-25
- ^ 'Enterprise Physics 101, a Framework for Enterprise Architecture,' Presented by John Zachman to the DRMA of Puget Sound, April 2007, [1]
- ^ a b John Zachman Enterprise Physics 101 Presentation, undated, posted by the Data Management Association (www.dama.org)
- ^ How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework, by Jaap Schekkerman, Trafford, 2006
- ^ Zachman International
- ^ University of Omaha
- ^ John Zachman Straight from the Shoulder Presentation, undated, posted by the Data Management Association (www.dama.org)
[edit] See Also
Service-Oriented Modeling Framework (SOMF)


