Zachmanフレームワーク
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.
The kinds of models or architectural descriptive representations are made explicit at the intersections of the rows and columns. An intersection is referred to as a cell. Because a cell is created by the intersection of a perspective and a focus, each is distinctive and unique. Since each cell is distinctive and unique, the contents of the cell are normalized and explicit per the perspective's focus.
The cell descriptions in the table itself uses general language for a specific set of targets. Below the focus of each cell in this particular Zachman Framework is explained:
(Why) Goal List – primary high level organization goals
(How) Process List – list of all known processes
(What) Material List – list of all known organizational entities
(Who) Organizational Unit & Role List – list of all organization units, sub-units, and identified roles
(Where) Geographical Locations List – locations important to organization; can be large and small
(When) Event List – list of triggers and cycles important to organization
(Why) Goal Relationship Model – identifies hierarchy of goals that support primary goals
(How) Process Model – provides process descriptions, input processes, output processes
(What) Entity Relationship Model – identifies and describes the organizational materials and their relationships
(Who) Organizational Unit & Role Relationship Model – identifies enterprise roles and units and the relationships between them
(Where) Locations Model – identifies enterprise locations and the relationships between them
(When) Event Model – identifies and describes events and cycles related by time
(Why) Rules Diagram – identifies and describes rules that apply constraints to processes and entities without regard to physical or technical implementation
(How) Process Diagram – identifies and describes process transitions expressed as verb-noun phrases without regard to physical or technical implementation
(What) Data Model Diagram – identifies and describes entities and their relationships without regard to physical or technical implementation
(Who) Role Relationship Diagram – identifies and describes roles and their relations to other roles by types of deliverables without regard to physical or technical implementation
(Where) Locations Diagram – identifies and describes locations used to access, manipulate, and transfer entities and processes without regard to physical or technical implementation
(When) Event Diagram – identifies and describes events related to each other in sequence, cycles occur within and between events, without regard to physical or technical implementation
(Why) Rules Specification – expressed in a formal language; consists of rule name and structured logic to specify and test rule state
(How) Process Function Specification – expressed in a technology specific language, hierarchical process elements are related by process calls
(What) Data Entity Specification – expressed in a technology specific format; each entity is defined by name, description, and attributes; shows relationships
(Who) Role Specification – expresses roles performing work and workflow components at the work product detailed specification level
(Where) Location Specification – expresses the physical infrastructure components and their connections
(When) Event Specification – expresses transformations of event states of interest to the enterprise
Detailed Representation
Eventually the cells with the detailed representation give Rules detail for (Why); Process detail for (How); Data detail for (What); Role detail for (Who); Location detail for (Where); and Event detail for (When).
There is a sixth row in the current Zachman framework, but it is not used for enterprise architecture — while the enterprise is described by rows one to six, enterprise architecture uses only rows one to five, thus only five rows are shown here.
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.
The framework comes with a set of rules:
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 organization.
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 objects 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.
One of the strengths of the Zachman Framework is that it explicitly shows a comprehensive set of views that can be addressed by enterprise architecture. 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.
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. Whereas 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 and When columns. However, there is no escaping the Why column's importance as it provides the business drivers for all the other columns.
Since the 1990s the Zachman Framework has been widely used as a means of providing structure for Information Engineering-style enterprise modeling. The Zachman Framework can be applied both in commercial companies and in government agencies. Within a government organization the framework can be applied to an entire agency at an abstract level, or it can be applied to various departments, offices, programs, subunits and even to basic operational entities.
Zachman Framework is applied in customized frameworks such as the TEAF, built around the similar frameworks, the TEAF matrix.
Other sources:
The TEAF matrix is called a customization sample, see , p. 22
Zachman Framework is also used as a framework to describe standards, for example standards for healthcare and healthcare information system. Each cell of the framework contains such a series of standards for healthcare and healthcare information system.
Another application of the Zachman Framework is as reference model for other enterprise architectures, see for example these four:
Other examples:
Analysis of the Rational Unified Process as a Process,
How the Model-driven architecture (MDA) models used in software development map to the Zachman Framework.
Mapping the IEC 62264 models onto the Zachman framework for analysing products information traceability.
Mapping the TOGAF Architecture Development Method (e.g. the methodology) to the Zachman Framework.
Less obvious are the ways the original Zachman framework has stimulated the development of other enterprise architecture frameworks, such as in the NIST Enterprise Architecture Model, the C4ISR AE, the DOE AE, and the DoDAF:
The Federal Enterprise Architecture Framework (FEAF) is based on the Zachman Framework but only addresses the first three columns of Zachman, using slightly different names, and focuses in the top of the three rows. (see )
The Zachman Framework methodology has for example been used by the United States Department of Veterans Affairs (VA) to develop and maintain its One-VA Enterprise Architecture in 2001. This methodology required them to define all aspects of the VA enterprise from a business process, data, technical, location, personnel, and requirements perspective. The next step in implementing the Zachman methodology has been to define all functions related to each business process and identify associated data elements. Once identified, duplication of function and inconsistency in data definition can be identified. The hard job then followed to de-conflict the data definitions and resolve duplicative implementations of the same business function.
The Department of Veterans Affairs at the beginning of the 21st century planned to implement an enterprise architecture fully based on the Zachman Framework.
The Zachman Framework was used as a reference model to initiate enterprise architecture planning in 2001.
Somewhere in between the VA Zachman Framework Portal was constructed.
This VA Zachman Framework Portal is still in use as a reference model for example in the determination of EA information collected from various business and project source documents.
Now somewhere in the past this "A Tutorial on the Zachman Architecture Framework".
Eventually an enterprise architecture repository was created at the macro level by the Zachman framework and at a cell level by the meta-model outlined below.
This diagram has been incorporated within the VA-EA to provide a symbolic representation of the metamodel that VA used, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of Commercial EA Repository Software. The One-VA EA repository was developed using an object oriented database within the Caliber-RM Software Product. Caliber-RM is intended to be used as a software configuration management tool; not as an EA repository.