[¤1] Mapping the TOGAF ADM to the Zachman Framework   


[¤2] Mapping the TOGAF ADM to the Zachman Framework

[¤3] Introduction    The Zachman Framework     Mapping TOGAF to the Zachman Framework


[¤4] Introduction

[¤5] A number of architecture frameworks exist, each of which has its particular advantages and disadvantages, and relevance, for enterprise architecture. Several are discussed in Other Architectures and Frameworks.

[¤6] However, there is no accepted industry standard method for developing an enterprise architecture. The Open Group's goal with TOGAF is to work towards making the TOGAF Architecture Development Method just such an industry standard method, which can be used for developing the products associated with any recognized enterprise framework that the architect feels is appropriate for a particular architecture. The Open Group's vision for TOGAF is as a vehicle and repository for practical, experience-based information on how to go about the process of enterprise architecture, providing a generic method with which specific sets of deliverables, specific reference models, and other relevant architectural assets, can be integrated.

[¤7] To illustrate the concept, this section provides a mapping of the various Phases of the TOGAF ADM to the cells of the well known Zachman Framework.


[¤8] The Zachman Framework

[¤9] The Zachman Framework for Enterprise Architecture, sometimes simply referred to as "The Zachman Framework", has become a de facto standard for classifying the artifacts developed in enterprise architecture. It is a logical structure for classifying and organizing the design artifacts of an enterprise that are significant to its management. It draws on a classification scheme found in the more mature disciplines of Architecture/Construction and Engineering/Manufacturing, used for classifying and organizing the design artefacts relating to complex physical products such as a building or an aircraft. Zachman adopts this classification scheme to the design and construction of information systems.

[¤10] The Zachman Framework comprises a 6x6 matrix.

[¤11]

[¤12] The columns represent various aspects of the enterprise that can be described, or modeled; and the rows represent various viewpoints from which the aspects can be described. Thus each cell formed by the intersection of a column and a row represents an aspect of the enterprise modeled from a particular viewpoint. The architect selects and models the cells that are appropriate to the immediate purpose, with the ultimate objective of modeling all the cells.

[¤13] The six viewpoints are:

(c_greenslade) The Planner's or Scope Viewpoint
[¤14]
1. The Planner or Ballpark Viewpoint
[¤15] 2. The Owner's or Enterprise Model Viewpoint
[¤16] 3. The Designer's or Systems Model Viewpoint
[¤17] 4. The Builder's or Technology Model Viewpoint
[¤18] 5. The Subcontractor's or Detailed Representation Viewpoint
[¤19] 6. The Functioning Enterprise or Actual System Viewpoint

[¤20] The six aspects - and the interrogatives to which they correspond - are:

[¤21] 1. The Data aspect - What?
[¤22] 2. The Function aspect - How?
[¤23] 3. The Network aspect - Where?
[¤24] 4. The People aspect - Who?
[¤25] 5. The Time aspect  - When?
[¤26] 6. The Motivation aspect - Why?

[¤27] Although the Zachman Framework applies to enterprises, the Framework itself is generic. It is a comprehensive, logical structure for the descriptive representations (i.e. models, or design artefacts) of any complex object, and it does not prescribe or describe any particular method, representation technique, or automated tool.

[¤28] The strength of the framework is that it provides a way of thinking about an enterprise in an organized way, so that it can be described and analyzed. It also enables the individuals involved in producing enterprise information systems to focus on selected aspects of the system without losing sight of the overall enterprise context. In designing and building complex systems, such as enterprise systems, there are simply too many details and relationships to consider simultaneously. At the same time, isolating single variables and making design decisions out of context results in sub-optimization, with all the attendant costs and risks. The challenge is the same whether the system is physical, like an aircraft, or conceptual, like an enterprise system. How do you design and build it, piece by piece, and step by step, such that it achieves its purpose without losing its value and raising its cost by optimizing the pieces and sub-optimizing the overall?


[¤29] Mapping TOGAF to the Zachman Framework

[¤30] The scope of the four architecture domains of TOGAF aligns very well with the first four rows of the Zachman Framework, as shown in the following mapping of these domains:

[¤31] adm_zf.gif (16881 bytes)

[¤32] Several domains overlap in the above diagram: the earliest domain to address a cell has precedence in the coloring scheme.

[¤33] The mappings of the individual phases of the ADM are shown in detail below. 

[¤34] Preliminary Phase: Framework and Principles

(c_greenslade) Is it possible to put all the cell references into left to right, top to bottom order?
[¤35]
The outputs of this phase are:

(c_greenslade) Modify to include extra mapping of Architecture principles.
[¤42]
Iprelim_zf.gif (13489 bytes)

[¤43] Phase A: Architecture Vision

[¤44] The outputs of this phase are:

[¤64] a_vis_zf.gif (13306 bytes)

[¤65] Phase B: Business Architecture

[¤66] The outputs of this phase are:

(c_greenslade) Diagram and text need to be aligned. Scope/Data is on the diagram, but not in the text. System/Function is in the text, but not in the diagram.
[¤92]
wpe2.jpg (55921 bytes)

[¤93] Notes:

[¤98]  

[¤99] Phase C: Informations System Architectures: Data Architecture

[¤100] The outputs of this part of Phase C are:

[¤132]  

(c_greenslade) Modify to include extra mapping of Data principles.
[¤133]
wpe2.jpg (55921 bytes)

[¤134]  

[¤135] Phase C: Informations System Architectures: Applications Architecture

[¤136] The outputs of this part of Phase C are:

(c_greenslade) Modify to include extra mapping of application principles
[¤172]
wpe2.jpg (55921 bytes)

[¤173]  

[¤174] Phase D: Technology Architecture

[¤175] The outputs of Phase D are given below, first by relevant individual Step, and then as a composite for the whole phase.

[¤176] Step 1. Create a baseline description in the TOGAF format

[¤177] The outputs of this step are:

(c_greenslade) Modify to include extra mapping of technology architecture principles
[¤187]
4C1_ZF.gif (13471 bytes)

[¤188] Step 2. Consider different architecture reference models, viewpoints, and tools

[¤189] The outputs of this step are:

[¤204] d2_zf.gif (13127 bytes)

[¤205] Step 3. Create an architectural model of building blocks

[¤206] The outputs of this step are:

[¤220] 4C1_ZF.gif (13471 bytes)

[¤221] 4. Select the services portfolio required per building block

[¤222] The outputs of this step are:

[¤227] d4_zf.gif (13193 bytes)

[¤228] Step 8. Conduct a gap analysis

[¤229] The outputs of this step are:

[¤233] d8_zf.gif (13211 bytes)

[¤234] Composite Mapping for phase D

[¤235] wpe2.jpg (55921 bytes)

[¤236]  

[¤237] For more detailed information on the Zachman Framework, refer to any of John Zachman's publications, or the Zachman Institute for Framework Advancement (ZIFA).


[¤238] Copyright The Open Group, 2002