Editing Zachman Framework (section)

== 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.<ref name="VA01">VA Enterprise Architecture Innovation Team (2001). [http://www.usa-federal-forms.com/va/3-pdf-forms_pubs/www.va.gov/oirm/architecture/EA/strategy/VAEAVersion-10-01.pdf ''Enterprise Architecture: Strategy, Governance, & Implementation''] report Department of Veterans Affairs, August, 2001.</ref>

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.<ref>{{usurped|1=[https://web.archive.org/web/20070628003649/http://inmongif.com/_fileCabinet/gifzach.pdf The government information factory and the Zachman Framework]}} by W. H. Inmon, 2003. p. 4. Accessed July 14, 2009.</ref>

=== 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.<ref name="CIOC99">The Chief Information Officers Council (1999). [http://www.cio.gov/documents/fedarch1.pdf Federal Enterprise Architecture Framework Version 1.1]. September 1999</ref>

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.<ref name="CIOC99"/>
[[File:Simplification Zachman Enterprise Framework.jpg|thumb|420px|The Veterans Affairs Zachman Framework with an explanation of its rows.<ref name="VA02Pre">US Department of Veterans Affairs (2002) [http://www.va.gov/oirm/architecture/EA/theory/tutorial.ppt A Tutorial on the Zachman Architecture Framework]. Accessed 06 Dec 2008.</ref><ref>[[Bill Inmon]] called this image "A simple example of The Zachman Framework" in the article 
[http://www.b-eye-network.in/print/1962 John Zachman - One of the Best Architects I Know] Originally published 17 November 2005.</ref>]]
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|commercial-off-the-shelf (COTS)]], [[Government off-the-shelf|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.<ref name="CIOC99"/> 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:<ref name="VA01"/>
# Inventory Sets – What
# Process Flows – How
# Distribution Networks – Where
# Responsibility Assignments – Who
# Timing Cycles – When
# 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.<ref name="VA01"/>

=== 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.<ref>{{cite web|last1=Zachman|first1=John A.|url=http://www.zachman.com|title=Official Home of The Zachman Framework™  |work=Zachman International|access-date=14 February 2015}}</ref>

The cell descriptions are taken directly from version 3.0 of the Zachman Framework. 
;Executive Perspective
# (What) Inventory Identification 
# (How) Process Identification 
# (Where) Distribution Identification 
# (Who) Responsibility Identification 
# (When) Timing Identification 
# (Why) Motivation Identification

;Business Management Perspective
# (What) Inventory Definition 
# (How) Process Definition 
# (Where) Distribution Definition 
# (Who) Responsibility Definition 
# (When) Timing Definition 
# (Why) Motivation Definition

;Architect Perspective
# (What) Inventory Representation
# (How) Process Representation 
# (Where) Distribution Representation
# (Who) Responsibility Representation
# (When) Timing Representation 
# (Why) Motivation Representation

;Engineer Perspective
# (What) Inventory Specification 
# (How) Process Specification
# (Where) Distribution Specification 
# (Who) Responsibility Specification 
# (When) Timing Specification 
# (Why) Motivation Specification

;Technician Perspective
# (What) Inventory Configuration 
# (How) Process Configuration 
# (Where) Distribution Configuration 
# (Who) Responsibility Configuration 
# (When) Timing Configuration 
# (Why) Motivation Configuration

;Enterprise Perspective
# (What) Inventory Instantiations 
# (How) Process Instantiations 
# (Where) Distribution Instantiations 
# (Who) Responsibility Instantiations 
# (When) Timing Instantiations 
# (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.<ref name="CIOC99"/>

=== Framework set of rules ===
[[File:Example of Zachman Framework Rules.JPG|thumb|420px|Example of Zachman Framework Rules.]]

The framework comes with a set of rules:<ref>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]</ref>
* ''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 object]]s 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 [[view model|views]] that can be addressed by enterprise architecture.<ref name="GASLSJ03"/> 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.