Zachman Framework
A fundamental question that people always seem to ask about enterprise modeling, and modeling in general, is how do various approaches such as enterprise business modeling, enterprise architectural modeling, and design modeling for a single project all relate to one another. The
Zachman Framework (ZF), created in the 1980s by John Zachman, describes a good approach to addressing this very question. The ZF, depicted in Figure 1, describes a collection of perspectives pertinent to enterprise modeling. The rows of the framework represent the views of different types of stakeholders and the columns represent different aspects or views of your architecture. Traditionally, within a column the models are evolved/translated to reflect the views of the stakeholders for
each row and within a single row should be consistent with one another. In this article I show how the Enterprise Unified ProcessTM
(EUP) extends the Rational Unified Process (RUP) with the ZF.
Figure 1 The Zachman Framework.
Figure 2 The rows of the Zachman Framework.
| # | Row | Description / Function |
| 1. | Scope {Contextual} Planner | Defines your organisation’s direction and purpose, defining the boundaries of your enterprise architecture efforts. |
| 2. | Enterprise Model {Conceptual} Business Owner | Defines in business terms the nature of your organisation, including its structure, processes, and organisation. |
| 3. | System Model {logical} Designer | Defines the enterprise in more rigorous terms than row 2, basically taking the model to a greater level of detail. This row was originally called “information system designer’s view” in the original version of the ZF. |
| 4. | Technology Model {physical} Implementer | Defines how technology will be applied to address the needs defined by the previous rows above. |
| 5. | Detail Reepresentation {out-of-context} Subcontractor | Defines the detailed design, taking implementation language, database storage, and middleware considerations into account. |
| 6. | Functioning System | These are the actual working systems within your organisation. |
Figure 3 The columns of the Zachman Framework.
| # | Column | Description / Function |
| 1. | What (Data / Structure) | Focus is on the entities/object/components of significance, and the relationships between them, within your organisation. This column was originally called Data in the original version of the framework. |
| 2. | How (Function / Activities) | Focus is on what your organisation does to support itself and its customers. This column was originally called Function in the original version of the framework. |
| 3. | Where (Locations) | Focus is on the geographical distribution of your organisation’s activities. This column was originally called Network in the original version of the framework. |
| 4. | Who (People) | Focus is on who is involved in the business of your organisation. |
| 5. | When (Time) | Focus is on the effects that time, such as planning and events, has on your organisation. |
| 6. | Why (Motivation) | Focus is on the translation of business goals, strategies, and constraints into specific implementations. |
The ZF has several strengths:
- It has been well accepted within the data community who considers it the defacto standard for enterprise architecture.
- The ZF defines the perspectives that your enterprise models should encompass, the implication being that you can apply its guidance within a process such as the EUP.
- The ZF explicitly communicates that enterprise modeling has several stakeholders, not just enterprise architects and developers, whom you should involve in your modeling efforts.
However, the ZF suffers from several weaknesses:
It can lead to a documentation-heavy approach (although this does not have to be the case). There are 36 cells in Figure 1, each of which could be supported by one or more models.
It can lead to a process-heavy approach to development – you can instantly see the opportunity to define a collection of rigorous processes to support the ZF.
The ZF isn’t well accepted within the development community and few developers even seem to have even heard about it.
The ZF seems to promote a top-down approach to development. When people first read about the ZF, they tend to think that it implies a top-down approach where you start with the models in row 1, then work on row 2 models, and so on. This doesn’t have to be the case, you can in fact start in any cell and then iterate from there.
The ZF appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community).
-> Abstract Technology's Offshore Development Center
-> Abstract Technology software development process
-> Abstract Technology free pilot trial
