Zachman Framework
The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.
[1] The Zachman Framework is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes;[2] rather, it is an ontology whereby a schema for organizing architectural artifacts (in other words, design documents, specifications, and models) is used to take 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 perspectives are represented in a two-dimensional matrix that defines along the rows the type of stakeholders and with the columns the aspects of the architecture.
Rather, the matrix is a template that must be filled in by the goals/rules, processes, material, roles, locations, and events specifically required by the organization.
[citation needed] In the 1980s John Zachman had been involved at IBM in the development of business system planning (BSP), a method for analyzing, defining and designing an information architecture of organizations.
It may be employed in the (in that time considered more esoteric) areas of enterprise architecture, data-driven systems design, data classification criteria, and more.
He saw a similar approach and concluded that architectures exist on many levels and involves at least three perspectives: raw material or data, function of processes, and location or networks.
The Who, When and Why columns were brought into public view, the notion of the four levels of metaframeworks and a depiction of integration associations across the perspectives were all outlined in the paper.
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).
[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] 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.
[24] 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.
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.
[12] 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.
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.
Since the 1990s the Zachman Framework has been widely used as a means of providing structure for information technology engineering-style enterprise modeling.
The next step in implementing the methodology has been to define all functions related to each business process and identify associated data elements.
This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to information technology investment management.
