Zachman Framework – Vincent Cockrell

February 3, 2011

In 1987, J.A. Zachman contributed an article to the IBM Systems Journal titled “A Framework For Informations Systems Architecture”. In this article, Zachman described his method for managing the complexity of increasingly distributed informations systems. Zachman’s vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. (1)

The Zachman Framework summarizes the architecture of an enterprise from the perspective of the stakeholders. Zachman is represented in a two dimensional matrix in which the rows reflect the perspectives of six major stakeholders in the enterprise and the columns represent the six contextual dimensions.

The Framework is structured around the views of different users involved in planning, designing, building and maintaining an enterprise’s Information Systems:

  • Scope (Planner’s Perspective): The planner is concerned with the strategic aspects of the organization, thus addressing the context of its environment and scope.
  • Enterprise Model (Owner’s Perspective): The owner is interested in the business perspective of the organization, how it delivers and how it will be used.
  • System Model (Designer’s Perspective): The designer is concerned with the systems of the organization to ensure that they will, in fact, fulfill the owner’s expectations.
  • Technology Model (Builder’s Perspective): The builder is concerned with the technology used to support the systems and the business in the organization.
  • Detailed Representations (Subcontractor’s Perspective): This perspective addresses the builder’s specifications of system components to be subcontracted to third parties. (3)

While the rows describe the organization users’ views, the columns allow focusing on each dimension:

  • Data (What?): Each of the cells in this column addresses the information of the organization. Each of the above perspectives should have an understanding of enterprise’s data and how it is used.
  • Function (How?): The cells in the function column describe the process of translating the mission of the organization into the business and into successively more detailed definitions of its operations.
  • Network (Where?): This column is concerned with the geographical distribution of the organization’s activities and artifacts, and how they relate with each perspective of the organization.
  • People (Who?): This column describes who is related with each artifact of the organization, namely Business processes, information and IT. At higher level cells, the "who" refers to organizational units, whereas in lower cells it refers to system users and usernames.
  • Time (When?): This column describes how each artifact of the organizations relates to a timeline, in each perspective.
  • Motivation (Why?): This column is concerned with the translation of goals in each row into actions and objectives in lower rows. (3)

Weaknesses of the Zachman Framework:

  • It can lead to a documentation-heavy approach. There are 36 cells each of which could be supported by one or more models.
  • It can lead to a process-heavy approach to development.
  • It isn’t well accepted within the development community and few developers even seem to have even heard about it.
  • It 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.
  • It appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community). (4)

Strengths of the Zachman Framework:

  • The Zachman Framework is well accepted within the data community as the standard for enterprise architecture.
  • The Zachman Framework defines the perspectives that an enterprise model should encompass, the implication being that you can apply its guidance within a process such as the Enterprise Unified Process.
  • The Zachman Framework explicitly communicates that enterprise modeling has several stakeholders, not just enterprise architects and developers, whom you should involve in your modeling efforts. (4)

The Zachman Framework can be used analyze anything relative to its architectural composition. Zachman stated, “It doesn’t know what it is being used to analyze. Only the analyst knows the analytical target and establishes the boundaries of the analysis.” (2)

References:

  1. http://msdn.microsoft.com/en-us/library/bb466232.aspx
  2. Excerpted from The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing, Copyright, John A. Zachman, 2003.
  3. http://msdn.microsoft.com/en-us/library/aa480042.aspx

4. http://www.enterpriseunifiedprocess.com/essays/zachmanFramework.html

Advertisements

3 Responses to “Zachman Framework – Vincent Cockrell”

  1. I did my research and blog on TOGAF (The Open Group Architecture Framework). During my research, I have found that some feel that the Zachman Framework cripples the user by not only outlining the architecture but by implementing it. By implementing it, they feel Zachman limits the user to that one way of implementation. Since we read about TOGAF for class and you did your research on Zachman, how do you feel about that opinion?

  2. Symya Williams said

    Do you think the Zachman Framework is best for just IT or can it be/should it be used in other industries?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: