What is Zachman Framework?

The Zachman framework originated in the famous Information System architecture paper ("A Framework for Information Systems Architecture"), completed by Mr. John Zachman in 1987, and has been developed to date. In this paper, Mr. Zachman the various elements related to information system architecture design from two dimensions to the following tables:

(Image source: Visual Paradigm's Zachman Framework tool)

Each row in the table represents the perspective used by a stakeholder involved in the construction of the information system, including:

• Scope Contexts: Contains a list of the environmental contexts in which the entire information system description is located, constraints originating from within and from outside, and other relevant components to be considered in the description of the information system under other perspectives.
• Business Concepts: A conceptual view of the end product that reflects the usage characteristics of the final product, that is, how the user prepares to use the final product. Stakeholders who have this perspective include customers or users of the final product.
• System Logic: The logical view of the final product reflects the nature and logic constraints of the final product. Stakeholders with this perspective include engineers, architects, and intermediaries who can associate expected income with existing physical, technical implementations.
• Technology Physics: reflects the physical constraints of existing technologies during product build. Stakeholders who have this perspective include the manufacturing engineer, the general contractor, and the organization or personnel with the technical capabilities required to produce the final product.
• Component Assemblies: Detailed descriptions of the decomposition of complex objects for production purposes, which play an important role in the transition from design media to final product media. For example, a product specification that relates the technical constraints described in the technical model to the vendor for the provided product.
• Operations Classes: Not in the 1987 paper ("A Framework for Information Systems Architecture") , the contents of this trip are not within the scope of the schema description, but in order to make the schema Zachman framework more complete, the line is eventually added. The content of this line represents the final product, which is the embodiment of the architecture in objective reality. For example, for an information system architecture, the content of this trip is the final output of the information system, and, for the enterprise architecture, this line represents the running enterprise itself. In short, the content of the first five elements is the description of the objective object, and the last line of content is the objective object itself.

Each column in the table represents an aspect of the information system. In Mr Zachman's view, it is sufficient to describe any thing as a clear explanation of it in a few basic ways, and the nature of human natural language has proved this conclusion for thousands of of years. These include:

• What (Data): A material composition that represents an objective object, that is, a BOM. For the enterprise, this part of the content is composed of things model (Thing models, it is referred to as the constituent model rather than the data model because different rows represent different perspectives, and only the third line where the designer is in the real information-based sense of the "data Model" is used here. Make up the object "to refer to all of the perspectives described in this column."
• How (Features): used to represent functionality and conversion behavior. For the enterprise, this part of the content is the process or function model.
• Network (where, where): used to indicate the location of the components and the unicom relationship between them. For enterprises, this part of the content is logistics or network models.
• Where (Responsible Unit): Describes who should do what, such as user manuals and instructions. For enterprises, this part of the content is the human model or workflow model.
• When (Timeframe): used to describe the time that things occur and the relative temporal relationships between different things, such as life cycles and time series diagrams. For the enterprise, this part of the content is time or dynamic model.
• Why (Cause/Reason/Intent): Used to represent final results and meaning. For enterprises, this part of the content is the motivation model.

Cells that intersect each row and column represent a specific description of an aspect of the information system from each stakeholder perspective. We can find that the framework itself is not complicated by the above description of the contents of the Zachman framework, but we should also follow the following rules of use in the actual application process:

• You cannot add new rows or columns to this frame. In the Zachman framework, the six-line perspective in the framework and the six-column description form the most basic meta language of the system description, that is, the description of its architecture for the purpose of building the system can be done from six perspectives and can be viewed in six aspects (whatWhat), How to work (how), where (Where), who is responsible (WHO), when (when), and why the motivation (Why) is answered, This architecture description is complete and is thus sufficient to be the foundation of system complexity management and change management.
• The contents of each column conform to a generic model. Because each column represents one aspect of the schema described, each description in the same column should essentially conform to a highly abstract Metamodel:
• The data column (What) should follow: things--relationships--things.
• The function column (how) should follow: process-input/output-process.
• The network column (Where) should conform to: node--connection--node.
• The "Person" column (WHO) should comply with: personnel-work-personnel.
• The time column should comply with: event-cycle-time. In which, "event" refers to a point of time, and "cycle" represents a period of time interval.
• The reason column (Why) should follow: The result-the way-results. where the "result" represents the target state, and "mode" is used to indicate the behavior that is used to achieve the target State.
• The model in each table cell should be specific to the generic model used in its column. Although the schema descriptions in each column follow the same model, as mentioned in the previous rule, because each row represents a different perspective for the description of the terminology, syntax, and constraints that are applied, for each specific cell, The schema description should also be based on the generic metamodel used by the column and is constrained by its line view.
• The verbosity of a schema description in a table cell is independent of the row in which it is located. It's easy to have an illusion that is, in the same column. The verbosity of the architecture description has a tendency to be more and more detailed from top to bottom, because the more it appears to be on the above line, the less the perspective it represents is concerned with the implementation details of the final product, so the architecture description does not need to be too detailed. Conversely, the lower line requires a higher degree of detail. From an implementation point of view, this concern is not unreasonable, but in terms of the objectives of the framework described, the trend of increasing the degree of detail from top to bottom is debatable. Because each row in the frame represents a different perspective, it does not mean that all perspectives focus on the implementation of the final product, but because each perspective has a different focus, the difference in detail is problematic only from the point of view of implementing the details. For example, the first line of planners focuses on the context in which the final product is located, as a result, the details of the description in this perspective should be based on the requirements of stakeholders with this perspective, and the following lines are not comparable in terms of the level of detail because of the different concerns. From this we can see that the architectural descriptions that are not peers are independent but interconnected, and that they are transforming relationships rather than evolving relationships,
• There is no meta conceptual element that can be shared among different table cells. Because each row or column in a table represents a certain perspective or basic meta language, the schema descriptions in each of their table cells should also be unique, so schema descriptions between different table cells should not appear to share meta concept elements.
• Do not directly contact different cells in a diagonal direction, which can only increase communication barriers. Each cell table is directly associated with a peer or a cell table located on and under it in the same column, thus minimizing the difficulty of communication and change management.
• Do not change the header name of the row or column. In the Zachman framework, the modification of the header name or meaning of a row or column can have a detrimental effect on the entire logical framework, as its logical framework is already complete. Note here that in the list of Zachman frames shown in Figure 3, its row headers and list headers contain two names, for example, the header of the first row has the range and planner two names, and the first column has the name "data" and "What (What)". The two names series (the names indicated in bold large fonts and the names in italics) represent the two uses of the Zachman framework:
• General scenario: In this scenario, the Zachman framework has a higher versatility, such as building buildings, airplanes, etc. Each of these headers will take the name indicated by a small italic font.
• Enterprise-specific scenarios: In this scenario, the target of the Zachman framework rests on the particular concept of "enterprise", where each header takes the name indicated by a bold large font.
• It should be noted that, regardless of the type of usage scenario mentioned above, these header names cannot be changed because of the actual situation, according to the rules used in the Zachman framework.
• Zachman Framework logic is universal and iterative. Although this framework has a reputation in the area of enterprise architecture, but this does not mean that he can only be used in this field, in fact for the Zachman framework, he does not focus on a specific thing, whether it is tangible things, such as housing, aircraft, or abstract conceptual entities, such as enterprises, Can be the object of his description, and therefore at this point it is universal, and because of this universality, the contents of each cell can also be described as an infinite iteration of the framework.

To sum up, the Zachman framework considers that an architectural description of objective things (which can be tangible entities such as houses or airplanes, or intangible conceptual objects such as enterprises) should include two dimensions, in which a dimension represents the six perspectives that should be used to describe the schema. The other dimension represents the six aspects of the architectural description that need to be answered. These two dimensions are orthogonal intersections, thus forming 36 intersection points, each of which represents a specific architectural artifact of the schema description. For example, both planners and designers need to describe the system's data, functions, etc. when describing a system, but for a specific aspect, such as data, different roles have different understandings. For business owners, data refers to business entities such as customers, products, and their relationships, and for the designer who executes the system design, the data refers to the information fragment of the complete informatization. In addition to these obvious features, the Zachman Framework also implies the following three points:

• Each architectural artifact can exist only in one table cell. That is, each architectural artifact's definition must be clear, and if an architecture artifact might appear in two or more table cells, it would indicate a problem with the contents of the schema artifact.
• Only when a role provides sufficient architectural artifacts for a particular aspect of the system does it mean that the corresponding table unit is complete, and that all table cells in the table are populated to indicate that a schema is complete.
• The contents of each column in the table must be interrelated. For example, the data defined by the business owner must be mapped in the designer's database design, and the definition of the data in each database can be traced back to the data definition in a business.

The Zachman frame is essentially a classification method to describe the enterprise architecture, which can provide the following help to solve the problems faced by the development of enterprise Informatization (System complexity management, the uncoordinated development of business and information Technology):

• The description and classification of enterprise architecture content are given, which can be decomposed and described by complex system.
• Ensure that every concern for each stakeholder is taken care of.
• Improve each architecture product to fit the target audience's concerns.
• Ensure that business requirements can be mapped to technical implementations, and that each technology implementation can be traced back to the business requirements.
• Strengthen the communication and communication between the business personnel and the information technicians, and reduce the unnecessary internal friction caused by the lack of communication.

Nevertheless, some scholars do not see Zachman as a framework (for example, the author of the Comparison of the top Four Enterprise architecture methodologies), Rather, it is just a taxonomy of content that is described in enterprise architecture. This view is based on reason, or because the framework cannot be answered in the following ways:

• While this framework describes what the enterprise architecture should contain, it does not provide a description of how the architecture development process is created.
• Under this framework enterprise architecture content is like a static picture, and enterprise architecture should be changed with the development of enterprises, so how to continuously evolve the process of governance of enterprise architecture is one of his lack of content.
• This framework does not provide a criterion for understanding whether an enterprise architecture organized in this manner is a good architecture, meaning that the framework lacks a maturity framework.

References

• Wikipedia: Zachman Framework