ADM and the Zachman Framework

ADM and the Zachman Framework

Introduction | The Zachman Framework | Mapping TOGAF to the Zachman Framework

---

This chapter provides a mapping of the TOGAF Architecture Development Method (ADM) to the Zachman Framework.

Introduction

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 .

However, there is no accepted industry standard method for developing an enterprise architecture. The Open Group goal with TOGAF is to work towards making the TOGAF ADM 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 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.

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.

The Zachman Framework

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.

The Zachman Framework comprises a 6x6 matrix.

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.

The six viewpoints are:

1. The Scope (Contextual) viewpoint - aimed at the planner
2. The Business Model (Conceptual) viewpoint - aimed at the owner
3. The System (Logical) viewpoint - aimed at the designer
4. The Technology (Physical) viewpoint - aimed at the builder
5. The Detailed Representations (Out-of-Context) viewpoint - aimed at the subcontractor
6. The Functioning Enterprise viewpoint

The six aspects - and the interrogatives to which they correspond - are:

1. The Data aspect - What?
2. The Function aspect - How?
3. The Network aspect - Where?
4. The People aspect - Who?
5. The Time aspect - When?
6. The Motivation aspect - Why?

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.

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?

Mapping TOGAF to the Zachman Framework

The scope of the four architecture domains of TOGAF align very well with the first four rows of the Zachman Framework, as shown in the following mapping of these domains.

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

The mappings of the individual phases of the ADM are shown in detail below.

Note:

In addition to the mappings to specific cells given below, the detailed representations and functioning enterprise viewpoints (the lowest two rows) of the Zachman Framework are also addressed and represented in TOGAF, through the Architecture Governance Framework (see Architecture Governance Framework), and through ADM deliverables such as the various Architecture Contracts (see Architecture Contracts). These ensure the validity and viability of the delivered solutions to meet the business needs.

Preliminary Phase: Framework and Principles

The outputs of this phase are:

• Framework Definition
  ZF: Business/Function (model of the architecture development process)
  [R2,C2]
• Architecture principles
  ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
  [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
• Restatement of, or reference to, business principles, business goals, and business drivers
  ZF: Composite of: Scope/Motivation, Business/Motivation
  [R1,C6; R2,C6]

Phase A: Architecture Vision

The outputs of this phase are:

• Approved Statement of Architecture Work, including in particular:
  • Scope and constraints
    ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time
    [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]

    Note:

    The Scope/Motivation cell is presumed to be addressed by strategic business planning activities outside the scope of the Architecture Vision.

  • Plan for the architecture work
• Refined statements of business principles, business goals, and strategic drivers
  ZF: Scope/Data, Scope/Motivation
  [R1,C1; R1,C6]
• Architecture principles (if not previously existing)
  ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
  [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
• Architecture Vision/Business Scenario, including:
  • Baseline Business Architecture, Version 0.1
    ZF: Business/Data, Business/Function, Business/Network, Business/People, Business/Time, Business/Motivation
    [R2,C2; R2,C2; R2,C3; R2,C4; R2,C5; R2,C6]
  • Baseline Technology Architecture, Version 0.1
    ZF: System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
    [R3,C2; R3,C2; R3,C3; R3,C4; R3,C5; R3,C6]
  • Target Business Architecture, Version 0.1
    ZF: Business/Data, Business/Function, Business/Network, Business/People, Business/Time, Business/Motivation
    [R2,C2; R2,C2; R2,C3; R2,C4; R2,C5; R2,C6]
  • Target Technology Architecture, Version 0.1
    ZF: System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
    [R3,C2; R3,C2; R3,C3; R3,C4; R3,C5; R3,C6]

Phase B: Business Architecture

The outputs of this phase are:

• Statement of Architecture Work (updated if necessary)
• Validated business principles, business goals, and strategic drivers
  ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time
  [R1,C1; R1,C2; R1,C3; R1,C4; R1,C5; R1,C6]
• Target Business Architecture, Version 1.0 (detailed)
  • Organization structure, identifying business locations and relating them to organizational units
    ZF: Scope/Network, Scope/People, Business/Network, Business/People
    [R1,C3; R1,C4; R2,C3; R2,C4]
  • Business goals and objectives, for each organizational unit
    ZF: Scope/Network, Scope/Time, Business/Network, Business/Time, Business/Motivation
    [R1,C3; R1,C5; R2,C3; R2,C5; R2,C6]

    Note:

    The Scope/Motivation cell is presumed to be addressed by strategic business planning activities outside the scope of the Business Architecture.

  • Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
    ZF: Scope/Function, Business/Function
    [R1,C2; R2,C2]
  • Business services - the services that each enterprise unit provides to its customers, both internally and externally
    ZF: Business/Function, System/Function
    [R2,C2; R3,C2]
  • Business processes, including measures and deliverables
    ZF: Business/Function, Business/Time
    [R2,C2; R2,C5]
  • Business roles, including development and modification of skills requirements
    ZF: Scope/People, Business/People
    [R1,C4; R2,C4]
  • Correlation of organization and functions; relate business functions to organizational units in the form of a matrix report
    ZF: Scope/Function, Scope/Network, Scope/People, Business/Function, Business/Network, Business/People
    [R1,C2; R1,C3; R1,C4; R2,C2; R2,C3; R2,C4]
• Baseline Business Architecture, Version 1.0 (detailed), if appropriate
• Views corresponding to the selected viewpoints addressing key stakeholder concerns
• Gap analysis results
• Technical requirements (drivers for the Technology Architecture work): identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (e.g., guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (e.g., expressed as primitives of the Zachman Framework)
  ZF: System/Motivation
  [R3,C6]
• Business Architecture Report
• Updated business requirements

Note:

The Business/Data cell is covered by the Data and Applications Architectures.

Phase C: Informations System Architectures: Data Architecture

The outputs of this part of Phase C are:

• Statement of Architecture Work (updated if necessary)
• Baseline Data Architecture, Version 1.0, if appropriate
• Validated principles, or new data principles (if generated here)
  ZF: Scope/Data, Scope/Network, Scope/People, Scope/Time
  [R1,C3; R1,C4; R1,C5]
• Target Data Architecture, Version 1.0:
  • Business data model
    ZF: Business/Data
    [R2,C1]
  • Logical data model
    ZF: System/Data
    [R3,C1]
  • Data management process models
    ZF: System/Function, System/People
    [R3,C2; R3,C3]
  • Data entity/business function matrix
    ZF: Composite of Business/People, System/Data, System/Function
    [R2,C4; R3,C1; R3,C2]
  • Data interoperability requirements
    ZF: Composite of System/Data, System/Function, System/Network, System/People
    [R3,C1; R3,C2; R3,C3; R3,C4]
• Viewpoints addressing key stakeholder concerns
• Views corresponding to the selected viewpoints; for example:
  • Data dissemination view
    ZF: Composite of System/Data, System/Function, System/Network, System/People
    [R3,C1; R3,C2; R3,C3; R3,C4]
  • Data lifecycle view
    ZF: Composite of System/Data, System/Function, System/Time
  • Data security view
    ZF: Composite of System/Function, System/Data, System/Network, System/People, System/Time
  • Data model management view
    ZF: Composite of Business/Data, System/Data, Business/Time, System/Time
• Gap analysis results
• Relevant technical requirements that will apply to this evolution of the architecture development cycle
  ZF: System/Motivation
• Data Architecture Report, summarizing what was done and the key findings
• Impact Analysis
• Updated business requirements, if appropriate

Phase C: Informations System Architectures: Applications Architecture

The outputs of this part of Phase C are:

• Statement of Architecture Work (updated if necessary)
• Baseline Applications Architecture, Version 1.0, if appropriate
• Validated application principles, or new application principles (if generated here)
  ZF: Scope/Function, Scope/Network, Scope/People, Scope/Time
• Target Applications Architecture, Version 1.0:
  • Process systems model
    ZF: System/Function
  • Systems/place model
    ZF: System/Network
  • People/systems model
    ZF: System/People
  • Systems/time model
    ZF: System/Time
  • Applications interoperability requirements
    ZF: Composite of System/Data, System/Function, System/Network, System/People, System/Time, System/Motivation
• Viewpoints addressing key stakeholder concerns
• Views corresponding to the selected viewpoints; for example:
  • Common applications services view
    ZF: Composite of System/Data, System/Function, System/Network, System/People, System/Time
  • Applications interoperability view
    ZF: Composite of System/Data, System/Function, System/Network, System/Time
  • Applications/information view
    ZF: Composite of System/Data, System/Function, System/Network, System/Time
  • Applications/user locations view
    ZF: Composite of System/Network, System/People
• Gap analysis results
  • Areas where the Business Architecture may need to change to cater for changes in the Applications Architecture
    ZF: Composite of Business/Data, Business/Function, Business/Network, Business/People, Business/Time
  • Identify any areas where the Data Architecture (if generated at this point) may need to change to cater for changes in the Applications Architecture
    ZF: Composite of Business/Data, Business/People, Business/Time
  • Identify any constraints on the Technology Architecture about to be designed
    ZF: System/Motivation
• Applications Architecture Report, summarizing what was done and the key findings
• Impact Analysis
• Updated business requirements, if appropriate

Phase D: Technology Architecture

The outputs of Phase D are given below, first by relevant individual step, and then as a composite for the whole phase.

Step 1: Create a Baseline Description in the TOGAF Format

The outputs of this step are:

• Technology Architecture principles (if not existing)
  ZF: Scope/Data, Scope/Function, Scope/Network, Scope/People, Scope/Time, Scope/Motivation
• Target Technology Architecture, Version 0.2:
  • Technology Architecture - Constraints
  • Technology Architecture - Architecture Principles
  • Technology Architecture - Requirements Traceability, key questions list
  • Technology Architecture - Requirements Traceability, criteria for selection of service portfolio
  • Technology Architecture Model, Version 0.1
    ZF: Technology/Function, Technology/Network

Step 2: Consider Different Architecture Reference Models, Viewpoints, and Tools

The outputs of this step are:

• Target Technology Architecture, Version 0.3
  • Technology Architecture - Architecture Viewpoints
    • Networked computing/hardware view
      ZF: System/Network, Technology/Network
    • Communications view
      ZF: Composite of: System/Network, System/People, Technology/Network, Technology/People
    • Processing view
      ZF: System/Data, System/Function, System/Network, System/People, System/Time, Technology/Data, Technology/Function, Technology/Network, Technology/People, Technology/Time
    • Cost view
      ZF: Technology/Motivation
    • Standards view
      ZF: Technology/Motivation
  • Technology Architecture - Constraints
    ZF: System/Motivation

Step 3: Create an Architectural Model of Building Blocks

The outputs of this step are:

• Target Technology Architecture, Version 0.4
  • Technology Architecture Model
    • Networked computing/hardware view
      ZF: Technology/Network, System/Network
    • Communications view
      ZF: Composite of: Technology/Network, Technology/People, System/Network, System/People
    • Processing view
      ZF: Technology/Network, Technology/Time, Technology/People, Technology/Data, Technology/Function, System/Network, System/Time, System/People, System/Data, System/Function
    • Cost view
      ZF: Technology/Motivation
    • Standards view
      ZF: Technology/Motivation
  • Technology Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 4: Select the Services Portfolio Required per Building Block

The outputs of this step are:

• Target Technology Architecture, Version 0.5
  • Technology Architecture - target services (a description of the service portfolios required also known as an Organization-Specific Framework)
    ZF: Technology/Network, Technology/Time, Technology/People, Technology/Data, Technology/Function, Technology/Motivation
  • Technology Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum

Step 8: Conduct a Gap Analysis

The outputs of this step are:

• Target Technology Architecture, Version 1.0:
  • Technology Architecture - gap report
    ZF: Composite of Technology/Data, Technology/ Function, Technology/Network, Technology/People, Technology/Time, Technology/Motivation

Composite Mapping for Phase D

IS353_Syllabus

I have read the Syllabus..There is no question or comment

About Me*_*

Hello ...

I am Mayy Tayeb Mohammed AlAmin ...

Study in Taibah University in Medina ...In the College of Computer Science and Engineering, Department of Computer Information Systems ..

Level V

mayy Al-Tayeb

Hi girls
Welcome to my Blog*_*
I wish the best for everyone