Zachman Framework
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
No issues specified. Please specify issues, or remove this template. |
 | This article's use of external links may not follow Wikipedia's policies or guidelines. |
The Zachman Framework is a framework for enterprise architecture which provides a formal and highly structured way of defining an enterprise. It uses a two dimensional classification model based around the 6 basic communication interrogatives (What, How, Where, Who, When, and Why) intersecting 6 distinct model types which relate to stakeholder groups (Visionary, Owner, Designer, Builder, Implementer and Worker) to give an holistic view of the enterprise which is being modeled.
Characteristics
Often used as part of a systems architecture or enterprise level technology review exercise it is popular within IT architecture departments but has little hold of either the developer or user communities. The enterprise architecture can readily evaluate an organization's software architecture.
The strong points are the complete coverage gained by touching each of the cells on the schema. The weak point is that this approach generates a lot of documentation, due to its completeness, which can be difficult to digest and sometimes of questionable utility.
Originally conceived by John Zachman at IBM in the 1980s the framework is now a de facto world standard for expressing the basic elements of an Enterprise Architecture. Originally the full technical name is Zachman Framework for Information Systems Architecture and was changed in the early 90's to The Zachman Framework for Enterprise Architecture.
Each artifact in a classification (cell) of the schema must be aligned with the cells immediately above and below it. All the cells in each row also must be integrated with each other. However, cells will not be aligned diagonally.
The Zachman Schema
| Order | Layer | What (Data) | How (Function) | Where (Network) | Who (People) | When (Time) | Why (Motivation) |
| 1 | Scope Context Boundary
|
List of things important to the business | List of processes the business performs | List of locations in which the business operates | List of organizations important to the business | List of events significant to the business | List of business goals/strategies |
| 2 | Business Model Concepts
|
e.g., Semantic or Entity-relationship Model | e.g., Business Process Model | e.g., Business Logistics System | e.g., Work Flow Model | e.g., Master Schedule | e.g., Business Plan |
| 3 | System Model Logic
|
e.g., Logical Data Model | e.g., Application Architecture | e.g., Distributed System Architecture | e.g., Human Interface Architecture | e.g., Processing Structure | e.g., Business Rule Model |
| 4 | Technology Model Physics
|
e.g., Physical Data Model | e.g., System Design | e.g., Technology Architecture | e.g., Presentation Architecture | e.g., Control Structure | e.g., Rule Design |
| 5 | Component Configuration
|
e.g., Data Definition | e.g., Program | e.g., Network Architecture | e.g., Security Architecture | e.g., Timing Definition | e.g., Rule Specification |
| 6 | Functioning Enterprise Instances
|
e.g., Data | e.g., Function | e.g., Network | e.g., Organization | e.g., Schedule | e.g., Strategy |
Advantages and disadvantages
The columns conflate question with ingredient. In practice, one can ask how every question (why, what, how…) is related to every ingredient (data, function…). The questions are by no means as objective as they appear; one person’s how is another person’s what is another person’s why.
The rows conflate perspective with idealisation, allowing for the definition of each perspective (enterprise, system and technology) at each level of abstraction (high level, medium level and excruciating detail).
The perspectives are more clearly understood by considering the specific properties of the artifacts in the row and carefully ensuring that the concepts (non computational model) are clearly separated from the system of logic representing the concepts (platform-independent model) and from the physics specification of the technology to be applied (vendor neutral models) from the component configurations required to become the instance containers of the functioning enterprise operated by the (knowledge, assembly, office or management) workers.