Zachman framework

The Zachman Framework is a classification structure often used in Information Technology departments by the teams responsible for developing and documenting an Enterprise Architecture. The Framework is used for organizing architectural "artifacts" in a way 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. [ [http://msdn2.microsoft.com/en-us/library/bb466232.aspx "A Comparison of the Top Four Enterprise Architecture Methodologies"] , Roger Sessions, Microsoft Developer Network Architecture Center, ] The Zachman Framework is one of the earliest Enterprise Architecture frameworks.

Overview

Originally conceived by John Zachman at IBM in the 1980s, the Framework is often referenced as a standard approach for expressing the basic elements of enterprise architecture. 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." [ [http://www.cio.gov/Documents/fedarch1.pdf Federal Enterprise Architecture Framework] ]

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. [ [http://www.research.ibm.com/journal/50th/applications/zachman.html" A Framework for Information Systems Architecture"] , John A. Zachman, "IBM Systems Journal", vol. 26, no. 3, 1987. IBM Publication G321-5298.]

The Zachman Framework is a schema - the intersection between two historical classifications that have been in use for literally thousands of years. The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas. The second is derived from reification, the transformation of an abstract idea into an instantiation that was initially postulated by ancient Greek philosophers and is labeled in the Framework: Identification, Definition, Representation, Specification, Configuration and Instantiation. ... More specifically, the Zachman Framework is an ontology - a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a "sliver," a solution, a project, an airplane, a building, a product, a profession of whatever of whatever). [ [http://zachmaninternational.com/index.php/ea-articles/26-articles/13-the-zachman-framework-a-concise-definition "John Zachman's Concise definition of the Zachman Framework"] , John A. Zachman, "Zachman International", 2008]

According to Zachman, this ontology 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. [http://www.scc.cc/voice/ArtRogerSessionsInterview4.pdf Interview with John Zachman] , by Roger Sessions, Editor-in-Chief, "Perspectives of the International Association of Software Architects"]

Use of the Zachman Framework

In the book "Enterprise Architecture At Work", ["Enterprise Architecture At Work: Modeling Communications and Analysis", by Marc Lankhorst et al., Springer, 2005, page 24-25] the advantages and disadvantages of using this taxonomy for developing an Enterprise Architecture are described.

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 deliveran implementation. Only YOU (or your methodology) determines which models (or "slivers" of models) youare 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 relevantfor describing the entire Enterprise. Therefore, the Framework is a convenient analytical tool to help youdetermine how you will feel if you (or your methodology) are NOT going to produce all the models ... or ifyou are going to do something that will INHIBIT integrated accumulation of the comprehensive set ofmodels in the long term while you are satisfying current demand in the short term. ['Enterprise Physics 101, a Framework for Enterprise Architecture,' Presented by John Zachman to the DRMA of Puget Sound, April 2007, [http://www.drma-seattle.org/DAMA-PS/200006-z1.pdf] ]

Characteristics

The Zachman Framework has been compared with the Periodic Table. In the same way that atoms in 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.

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.

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. [http://www.dama-mn.org/media/Zachman-Physics4.pdf John Zachman Enterprise Physics 101 Presentation] , undated, posted by the Data Management Association (www.dama.org) ]

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. ["How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework", by Jaap Schekkerman, Trafford, 2006]

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. [ [http://www.zachmaninternational.com/2/Zachman_Framework.asp Zachman International] ]

Framework rules

Adapted from: Sowa, J.F. & J.A. Zachman, 1992, and Inmon, W.H, J.A. Zachman, & J.G. Geiger, 1997. [ [http://www.isqa.unomaha.edu/vanvliet/arch/ISA/isa.htm University of Omaha] ]

:"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.

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.

Organizations that adopt the Zachman Framework approach to enterprise architecture for engineering their enterprises require a methodology for carrying out the following functions: [ [http://www.damauk.org/John%20Zachman%20-%20Straight%20from%20the%20Shoulder.pdf John Zachman Straight from the Shoulder Presentation] , undated, posted by the Data Management Association (www.dama.org) ]

: 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)

References