[Link] [Link] David C.
Hay
Published: June 1, 1997 Strategy - The planning of an organization's overall systems development effort. Analysis - The detailed definition of requirements for a particular area of the business. Design - The specific application of technology to the requirements defined during analysis. Construction - The actual construction of the system. Documentation - Preparation of the user manuals, reference manuals, etc. to describe the system. Transition - The implementation of the system, so as to make it part of the infrastructure of the organization. Production - The ongoing monitoring of the system to ensure that it continues to meet the needs of the organization. John Zachman's "Framework" is diagrammed in Figure 1. The rows represent the points of view of different players in the systems development process, while columns represent different aspects of the process. The players are: 1. Scope (Ballpark view): Definition of the enterprise's direction and business purpose. This is an industry view, concerned with the things that define the nature and purpose of the business. This is necessary to establish the context for any system development effort. 2. Model of the business (Owner's view): This defines -- in business terms -- the nature of the business, including its structure, functions, organization, and so forth. 3. Model of the information system (Architect's view): This defines the business described in step 2, but in more rigorous information terms. Where row two described business functions, for example, as perceived by the people performing them, row three describes them specifically as transformations of data. Where row two described all the things of interest to the enterprise, row three describes those things about which the organization wishes to collect and maintain information, and begins to describe that information. 4. Technology model (Designer's view): This describes how technology may be used to address the information processing needs identified in the previous rows. Here relational databases are chosen over network ones (or vice versa), kinds of languages are selected and program structures are defined, user interfaces are described, and so forth. 5. Detailed representations (Builder's view): This is a view of the program listings, database specifications, networks, and so forth that constitute a particular system. These are all expressed in terms of particular languages. 6. Functioning system: Finally, a system is implemented and made part of an -
[Link] 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.[26] 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:[24] 1. 2. 3. 4. 5. 6. The data description What The function description How The Network description Where The people description Who The time description When The motivation description Why
In Zachmans 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