John A. Zachman is widely recognized for establishing the historical foundation for enterprise architecture. Although he is (and remains) a major influence on EA, most of his writings comprise only a few articles, a co-authored book, and several prefaces to other books. Instead, he has maintained his own organization and published on his web site [Zachman International] in the forms of blogs and other entries.

Zachman developed the first version of his framework in the mid-1980s and published it in the IBM Systems Journal [Zachman 1987] as “A framework of information systems architecture.” This effort was an extension of his work begun in 1984, when he developed the first three-column “Information System Architecture” inspired by work from Peter Chen and Charles Bachman. The 1987 publication still retained the three columns, as it represented only information systems. In 1992, Zachman expanded the concept to include rows for planner, owner, designer, builder, subcontractor, and the enterprise view. In 2008, and more recently in 2011, Zachman developed the framework to the most current iteration—a six-by-six matrix. The 2011 representation is a clarification involving a renaming of the rows in the framework ontology. On the vertical axis are rows representing six perspectives, and on the horizontal axis are six columns of interrogatives addressed by each of the respective perspectives.

The Zachman Framework as an Ontology

Zachman calls his framework an “ontology,” which he defines on his web site as “a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object.” The scope of the objects the framework can address is “an Enterprise, a department, a value chain, a ‘sliver,’ a solution, a project, an airplane, a building, a product, a profession or whatever.” Zachman states that his framework is not a methodology for creating the implementation (an instantiation) of the object. Instead, he says, the “Framework IS the ontology for describing the Enterprise. The Framework (ontology) is a STRUCTURE whereas a methodology is a PROCESS. A Structure is NOT a Process. A Structure establishes definition whereas a Process provides Transformation.”

The Zachman Framework is therefore a comprehensive and structured categorization scheme that enables the architect to discover, record, and categorize the real-world objects and abstractions that are involved within a transformation process. The word “ontology” is used to describe concepts and relationships. The two-dimensional ontology arises from the scheme of columns and rows that are used to label the category of a specific architecture object.

The Zachman Framework, as illustrated in Figure 21-1, is represented as a two-dimensional grid, where the columns represent interrogatives and the rows represent perspectives. The interrogatives are the six questions—What, How, Where, Who, When, and Why. These are used to describe with completeness any narrative as stated by philosophers and taught today in courses on journalism, like the opening lines of the Rudyard Kipling poem I Keep Six Honest Serving Men:

Figure 21-1   The Zachman Framework of the Enterprise Ontology (used with permission from Zachman International)

I keep six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

Figure 21-1 shows the most recent Zachman Framework 3.0 picture provided at the Zachman International web site.

As with any other narrative, an architecture narrative can be described by answering the six questions and tabulating the results of the corresponding questions.

Zachman realized that the question Why? may have different answers to different stakeholders. In other words, getting a consistent and reliable set of answers to the six interrogatives may not always be possible when you talk to many people who have their own ideas of what the answers are.

For example, when the question Why? is posed to the airport authority for RMN Airport, the following answers result:

• Develop the local economy around the airport.

• Develop a revenue-generation engine for the three municipalities surrounding the airport.

• Provide employment for the local citizenry.

But when the Why? question is posed to an airline that uses the airport as an origin or destination, the answers are different:

• Provide runways for safe landings and takeoffs.

• Provide terminal facilities for safety and comfort of passengers.

• Provide refueling and maintenance capabilities.

Though both stakeholders are talking about the same airport and the reasons why it is in existence, each of them has different concerns, issues, needs, and even language to catalog the architecture objects that they describe.

The problem of classifying architecture elements becomes more complex when architecture elements are used loosely in descriptions. Is USA a location (Where) or is it a role (Who)? Depending on the usage of the architecture element, we can resolve whether the term is used as a location or a role. Repository storage of USA may require two distinct elements: USA (geo-location) and USA (geo-political entity). The Zachman interrogatives force resolution of such ambiguities because a tabulation of Where? or Who? is required for the USA in this example.

Recognizing that each stakeholder group has different answers to the same question, often couched in their own terms, Zachman stipulated that there should be rows that correspond to the perspective of such diverse stakeholder groups. Thus, the perspectives correspond loosely to the viewpoint concepts found in other frameworks.

Reification

How then to systematically identify who these stakeholders are so that the row structures can be standardized? Zachman’s analysis initially looked at the stages through which a building is constructed, from the planning stage to the physical construction stage, and the role of the architect amid all of these stages. Later, he generalized the stages involved in any endeavor that involves converting concepts into implementations through a series of transformations using the general steps of problem-solving. This process is what he calls reification.

Zachman identified the following transformation steps in a logical sequence:

1. Identification is transformed into Definition.

2. Definition is transformed into Representation.

3. Representation is transformed into Specification.

4. Specification is transformed into Configuration.

5. Configuration is transformed into Implementation.

Each of the six reification stages is defined as follows:

• Identification   Identify the problem (Owner).

• Definition   Define the variables of the problem (Planner).

• Representation   Represent the variables and relationships (Architect).

• Specification   Specify the elements of the solution (Designer).

• Configuration   Specify the collection of elements and relationships to be implemented for the solution (Acquirer).

• Implementation   Implement the solution (Implementer).

These are abstractions that have more specific meaning when applied to a problem domain and a specific enterprise. We consider reification in the context of the problem of verifying the identity of the people at RMN Airport, establishing their entitlement to the services they might be requesting, and verifying their authorization to be in the area where they are currently located or attempting to enter.

• The CIO has identified the problem of the inability to identify anyone walking around in the airport—from airline employees, to airport concessionaires, to passengers, to service personnel, to airport administration staff, to TSA staff, to aircrew and others—and the potential consequences for disastrous events.

• The definition of the problem and the staging of solution capabilities are performed at the planning staff level. The needed capabilities and their scopes are laid out and allocated to specific projects.

• The representation of specific identification processes—data, roles, and events—and time periods is performed by the enterprise architect.

• The specification for acquiring these capabilities is performed by the design team.

• The configuration of multiple acquisitions and project oversight is performed by a program manager.

• The actual implementation is performed by contractors for specific projects and a systems integrator responsible for the needed interoperability across the projects.

The Perspectives

Zachman’s perspectives correspond to the stakeholders within the six reification steps described. It is important to note that the standard Zachman Framework perspectives are articulated based on an assumption of reification as the intent of the framework.

Here are the perspectives shown from top to bottom in Figure 21-1:

• Executive Perspective   Referred to as the Planner’s Perspective in earlier versions of the framework, provides the scope of the enterprise. This viewpoint represents the group that manages the business of the enterprise at the highest level, defines the scope of the project, and operates at a relatively high level of abstraction.

• Business Management Perspective   Referred to at the Owner’s Perspective in earlier versions of the framework, represents the viewpoint of the business area managers in the enterprise. Once the executive identifies the scope, the business area owner/manager gives more detail about business-specific aspects that provide materials to be used by the architect or designer of the enterprise in the next rows.

• Architect Perspective   Referred to as the Designer’s Perspective in earlier versions of the framework, is the viewpoint of those who represent the business in a disciplined manner and complete the strategic view of the enterprise. The architect also relates the business needs of the enterprise identified in the first two rows to the solution and technical viewpoints of the following two rows. The architect as designer provides the logical structure for data and architects the whole enterprise. Note that specific solutions are not identified at this level. These solutions are determined in the engineer’s or builder’s view in the following row.

• Engineer Perspective   Referred to as the Builder’s Perspective in earlier versions of the framework, provides the viewpoint of those who identify specific technology solutions to solve business problems identified in the previous perspectives. After the designers create the designs for the architecture, the builder implements the design and is responsible for providing solutions in the form of products, which may be commercial-off-the-shelf (COTS) or custom-built. This creates what Zachman refers to as the “enterprise physics.”

• Technician Perspective   Referred to as the Subcontractor’s Perspective in earlier versions of the framework, is the viewpoint of those hired or tasked with implementation of the solutions. It is here that the specific products are implemented according to the enterprise physics determined in the previous row.

• Enterprise Perspective   Referred to as the Functioning Enterprise in earlier versions of the framework, is the physical representation of the system itself.

The Interrogative Columns

Each of the perspectives has six different aspects depicted as columns. These are based on the classic six interrogatives: What, How, Where, Who, When, and Why. By addressing each of these questions for the respective rows, we have a complete understanding of the subject.

• What is the data column and addresses the understanding of the enterprise data.

• How is the function column describing the various processes entailed in dealing with data columns.

• Where is the network column describing the locations and logistics between entities.

• Who is the people or roles column characterizing those who participate in the organizational activities.

• When is the timing column describing when a function is to be performed.

• Why is the motivation column characterizing the end goals, constraints, rules, and regulations involved.

Classification Schema

The intersection of six interrogative columns with six perspective columns creates a matrix of thirty-six cells, as the intersection between the two classifications of interrogatives and the six stages of transformation or reification. According to Zachman, each cell is a single variable (distinct representation) containing only one type of enterprise component and the relationships with all other components of the same type in the enterprise. In Zachman’s terms, the 36 variables that contain values of architecture elements completely describe the ingredients of transformation within the reification process.

The Zachman Framework is considered to be an ontological or thought tool for organizing and classifying enterprise knowledge. It is methodologically independent of other frameworks (such as DoDAF, FEAF2, and TOGAF) and is an accompaniment to them. The usefulness of the Zachman Framework is in the systematic manner in which architecture elements can be cataloged and related. The Zachman Framework can be equally used to identify capabilities and performers in the DoDAF, to identify requirements in the TOGAF, or to identify processes, roles, and inputs and outputs in the FEAF2.

The power of reification is that it captures all the steps of a major transformation, from identification to implementation, and is therefore a powerful alignment tool to understand how the identification is mapped to the implementation. These types of alignments are required across the enterprise. For example, business strategy should map to operational processes, operational processes should map to information systems and automation, and information systems and automation should map to the infrastructure computing platforms and networks.

Primitives and Composites

Having standardized the rows and columns of his framework, Zachman set out to standardize (in an abstract manner) what types of architecture objects are represented within each of the 36 cells. He used an analogy to the periodic table of elements that codifies the chemical elements with symbols and a location within the table ordered by certain criteria. He called the architecture elements in the Zachman Framework cells “primitives” and reasoned that “composites” of architecture elements were similar to chemical molecular structures that comprise multiples of the same element or combinations of diverse elements described by a distinct formula. Just as the exact formula reflects constraints such as valency, relationships between architecture objects described in composites are also constrained by manmade rules, existential constraints or the laws of nature.

Each Zachman Framework cell therefore contains primitives analogous to the elements in the periodic table. These primitive elements are invariant structures that make up all enterprises. The combinations of elements or primitives into composites are “snapshot” structures that characterize a particular enterprise at a given moment in time. These are variant structures dependent on the context and nature of the technologies and business. The invariant primitives are characteristic independent variables defining the nature of any enterprise.

Table 21-1 describes the primitive elements or “models” within each cell of the matrix.

Table 21-1   Zachman Framework Primitives

In summary, in the Zachman Framework, row 1 deals with scope:

• The WHAT of row 1 are high-level data classes.

• The HOW is the high-level business process types.

• The WHERE is the location types.

• The WHO are the roles or responsibility types.

• The WHEN are the timing types.

• The WHY are the types of motivations.

Row 2 focuses on business models:

• The WHAT is the business data model.

• The HOW is the business process models.

• The WHERE is the location models.

• The WHO is the business role models.

• The WHEN is the business timing model.

• The WHY are the business ends and means.

Row 3 focuses on system models:

• The WHAT is system data models and data relationships.

• The HOW is logical representations of information systems and their relationships.

• The WHERE is logical representations of the distributed system location architecture.

• The WHO is logical representation systems roles and work products.

• The WHEN is logical system timing.

• The WHY are system ends and means.

Row 4 contains the technology models as physical models of solutions:

• The WHAT involves technology level data physical data models.

• The HOW is specifications of applications technology.

• The WHERE is specifications of network locations and connections.

• The WHO is specification of technology roles.

• The WHEN is the specification of technology timing.

• The WHY is technology ends and means.

Row 5 is the as-built and deployment of business components or tools:

• The WHAT is the tool data models.

• The HOW is coded program functions (tool transforms).

• The WHERE is tool locations and connections.

• The WHO is tool roles.

• The WHEN is tool timing definitions coded to sequence activities on particular platforms and technologies.

• The WHY are the tool ends and means.

Row 6 is the operational enterprise and affords evaluation. This is the functioning enterprise:

• The WHAT is data values stored in actual databases—the operational data entities and relationships.

• The HOW is the operational processes.

• The WHERE is the operational locations and connections.

• The WHO is the operational roles and work products.

• The WHEN involves operational timing definitions operating to sequence activities.

• The WHY are operational ends and means.

Rules for the Use of the Zachman Framework Ontology

To establish the effectiveness of the framework, Zachman defines several rules that need to be followed. Note that the term “model” is used more loosely here than in other frameworks such as DoDAF.

• Rows or columns are not to be added to the framework. WHO, WHAT, WHERE, WHY, and HOW are the only primitive interrogatives accepted. This provides a full comprehensive set for understanding a subject. All are required. Adding or removing any of these would result in either duplication or discontinuities. This rule specifies that the framework rows and columns cannot be modified.

• Each column contains a simple generic model. For example, the WHAT column focuses on data and relationships. These are single and independent aspects of the enterprise.

• Each cell model is specific to its column’s generic model. As each column has a simple and generic model, each cell provides information on the perspective specific to the row. Thus, each cell model is a specific version of the generic model for each column.

• No meta concept (such as the element type chemical symbol in the periodic table analogy) can be classified into more than one cell. Each row is unique, as is each column. Each cell is unique. Each meta concept is specific to the cell, and it is logical that none of the meta concepts can be classified into more than one cell.

• One must not create diagonal relationships between cells. A diagonal relationship relates a cell in one perspective to a cell in another. Each perspective defines its own semantics for its columns. Thus, creating diagonal relationships will lead to semantically incomplete communication. This can lead to significant misunderstandings and communication breakdowns.

• The names of the rows and columns should not be changed. Any change would not be acceptable as a corruption of the basic framework.

• The logic involved in the framework is generic and recursive. The framework can be applied equally appropriately to a parent enterprise as to smaller component enterprises within that parent enterprise. The framework is considered generic enough to classify descriptive representations of anything, and the framework is enough to analyze all aspects relative to the architectural composition of anything.

Summary

The Zachman Framework is a tool used for classifying artifacts and providing the logic for aligning information systems and business. It is a generic framework that works for all scopes and is intended as a resource for other frameworks such as DoDAF, TOGAF, and FEAF2. Although the Zachman Framework provides perspectives that reflect stakeholder viewpoints, it does not specify specific models or views. Rather, the framework cells focus on versions of generic models or primitives based on both a perspective and an interrogative. The Zachman Framework does not and was not intended to provide a methodology for a step-by-step process for creating an EA. Instead, it proffers a holistic view that gives a complete classification system of architecture elements and a structure to categorize architecture objects in a systematic manner that reflects the actual process of transformation.

Questions

1. What is the relationship of the first two rows of the framework to the bottom three rows, and the significance of the architect’s perspective?

2. Although Zachman changed the labels for the perspectives, what is the basis for the rule that the names now used should not be revised?

3. How are you able to distinguish between primitives and composites? Why are primitives invariant while composites are conditioned by business contexts and the current state of an enterprise?

4. How are you able to create a composite view of some entity out of a combination of enterprise primitives?

5. Why does the Zachman Framework use a two-dimensional ontology to categorize architecture objects?

6. What are some problems that do not fit into the reification category?

7. How would you organize the DoDAF Metamodel 2 (DM2) metamodel classes into the Zachman Framework?

8. How would you organize the requirements-gathering framework of TOGAF and the architecture objects of TOGAF’s metamodel into the Zachman Framework?

9. Can you identify the various perspectives of the Zachman Framework for your own enterprise?

References

Kipling, Rudyard. I Keep Six Honest Serving Men, from Just So Stories. Free Book Series, Gutenberg.org. Retrieved 12/13/2017 from www.gutenberg.org/ebooks/2781.

Zachman International. www.zachman.com.

Zachman, John A. 1987. “A framework for information systems architecture.” IBM Systems Journal, 26 (3).

Zachman, John A. 1993. Foreword to Enterprise Resource Planning, by Steven Spewak. New York: Wiley.

Zachman, John A. 2011. Foreword to FEAC Certified Enterprise Architect CEA Study Guide by Prakash Rao, et al. New York: McGraw-Hill.

Zachman, John A. 2016. “The Concise Definition of the Zachman Framework.” www.zachman.com/about-the-zachman-framework.

Zachman, John P. 2009. “The Zachman Framework Evolution.” Zachman International. www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution.