• 1. Introduction
  • 1.1 Structure of the TOGAF Document
  • 1.2 Executive Overview
    • What is an enterprise? What is enterprise architecture?
    • Why do I need an enterprise architecture?
    • What specifically would prompt me to develop an enterprise architecture?
    • What is an architecture framework?
    • Why do I need TOGAF as a framework for enterprise architecture?
    • Who would benefit from using TOGAF?
    • Footnotes
• 2. Core Concepts
  • 2.1 What is TOGAF?
  • 2.2 What is Architecture in the Context of TOGAF?
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
  • 2.4 Architecture Development Method
  • 2.5 Deliverables, Artifacts, and Building Blocks
  • 2.6 Enterprise Continuum
  • 2.7 Architecture Repository
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
  • 2.9 Establishing the Architecture Capability as an Operational Entity
  • 2.10 Using TOGAF with Other Frameworks
  • 2.11 TOGAF Document Categorization Model
• 3. Definitions
  • 3.1 Abstraction
  • 3.2 Activity
  • 3.3 Actor
  • 3.4 Application
  • 3.5 Application Architecture
  • 3.6 Application Platform
  • 3.7 Application Platform Interface (API)
  • 3.8 Architectural Style
  • 3.9 Architecture
  • 3.10 Architecture Building Block (ABB)
  • 3.11 Architecture Continuum
  • 3.12 Architecture Development Method (ADM)
  • 3.13 Architecture Domain
  • 3.14 Architecture Framework
  • 3.15 Architecture Governance
  • 3.16 Architecture Landscape
  • 3.17 Architecture Principles
  • 3.18 Architecture View
  • 3.19 Architecture Vision
  • 3.20 Artifact
  • 3.21 Baseline
  • 3.22 Baseline Architecture
  • 3.23 Boundaryless Information Flow
  • 3.24 Building Block
  • 3.25 Business Architecture
  • 3.26 Business Domain
  • 3.27 Business Function
  • 3.28 Business Governance
  • 3.29 Business Service
  • 3.30 Capability
  • 3.31 Capability Architecture
  • 3.32 Capability Increment
  • 3.33 Communications and Stakeholder Management
  • 3.34 Concerns
  • 3.35 Constraint
  • 3.36 Data Architecture
  • 3.37 Deliverable
  • 3.38 Enterprise
  • 3.39 Enterprise Continuum
  • 3.40 Environment Management
  • 3.41 Financial Management
  • 3.42 Foundation Architecture
  • 3.43 Framework
  • 3.44 Gap
  • 3.45 Governance
  • 3.46 Information
  • 3.47 Information Technology (IT)
  • 3.48 Interoperability
  • 3.49 Knowledge
  • 3.50 Logical
  • 3.51 Metadata
  • 3.52 Metamodel
  • 3.53 Method
  • 3.54 Methodology
  • 3.55 Model
  • 3.56 Modeling
  • 3.57 Objective
  • 3.58 Organization
  • 3.59 Patterns
  • 3.60 Performance Management
  • 3.61 Physical
  • 3.62 Platform
  • 3.63 Platform Services
  • 3.64 Principle
  • 3.65 Quality Management
  • 3.66 Reference Model (RM)
  • 3.67 Repository
  • 3.68 Requirement
  • 3.69 Resource Management
  • 3.70 Roadmap
  • 3.71 Role
  • 3.72 Segment Architecture
  • 3.73 Service Management
  • 3.74 Service Orientation
  • 3.75 Service Oriented Architecture (SOA)
  • 3.76 Skill
  • 3.77 Solution Architecture
  • 3.78 Solution Building Block (SBB)
  • 3.79 Solutions Continuum
  • 3.80 Stakeholder
  • 3.81 Standards Information Base (SIB)
  • 3.82 Strategic Architecture
  • 3.83 Target Architecture
  • 3.84 Taxonomy of Architecture Views
  • 3.85 Technical Reference Model (TRM)
  • 3.86 Technology Architecture
  • 3.87 Transition Architecture
  • 3.88 View
  • 3.89 Viewpoint
  • 3.90 Work Package
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Modular Structure
    • Content Framework
    • Extended Guidance on Adopting TOGAF within an Enterprise
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
    • Additional ADM Detail
  • 4.2 The Benefits of TOGAF 9
    • Greater Usability
    • More Focus on Holistic Enterprise Change
    • More Consistency of Output
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part I: Introduction
    • Part II: Architecture Development Method
    • Part III: Enterprise Continuum
    • Part IV: Resource Base
  • 4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1
  • 4.5 Using TOGAF
    • 4.5.1 Conditions of Use
    • 4.5.2 How Much Does TOGAF Cost?
    • 4.5.3 Downloads
  • 4.6 Why Join The Open Group?
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.1 The ADM, Enterprise Continuum, and Architecture Repository
    • 5.1.2 The ADM and the Foundation Architecture
    • 5.1.3 ADM and Supporting Guidelines and Techniques
  • 5.2 Architecture Development Cycle
    • 5.2.1 Key Points
    • 5.2.2 Basic Structure
  • 5.3 Adapting the ADM
  • 5.4 Architecture Governance
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus
    • 5.5.2 Architecture Domains
    • 5.5.3 Vertical Scope/Level of Detail
    • 5.5.4 Time Period
  • 5.6 Architecture Integration
  • 5.7 Summary
    • Footnotes
• 6. Preliminary Phase
  • 6.1 Objectives
  • 6.2 Approach
    • 6.2.1 Enterprise
    • 6.2.2 Organizational Context
    • 6.2.3 Requirements for Architecture Work
    • 6.2.4 Principles
    • 6.2.5 Management Frameworks
    • 6.2.6 Relating the Management Frameworks
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
  • 6.3 Inputs
    • 6.3.1 Reference Materials External to the Enterprise
    • 6.3.2 Non-Architectural Inputs
    • 6.3.3 Architectural Inputs
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted
    • 6.4.2 Confirm Governance and Support Frameworks
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
    • 6.4.4 Identify and Establish Architecture Principles
    • 6.4.5 Select and Tailor Architecture Framework(s)
    • 6.4.6 Implement Architecture Tools
  • 6.5 Outputs
    • Footnotes
• 7. Phase A: Architecture Vision
  • 7.1 Objectives
  • 7.2 Approach
    • 7.2.1 General
    • 7.2.2 Creating the Architecture Vision
    • 7.2.3 Business Scenarios
  • 7.3 Inputs
    • 7.3.1 Reference Materials External to the Enterprise
    • 7.3.2 Non-Architectural Inputs
    • 7.3.3 Architectural Inputs
  • 7.4 Steps
    • 7.4.1 Establish the Architecture Project
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
    • 7.4.4 Evaluate Business Capabilities
    • 7.4.5 Assess Readiness for Business Transformation
    • 7.4.6 Define Scope
    • 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles
    • 7.4.8 Develop Architecture Vision
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
  • 7.5 Outputs
• 8. Phase B: Business Architecture
  • 8.1 Objectives
  • 8.2 Approach
    • 8.2.1 General
    • 8.2.2 Developing the Baseline Description
    • 8.2.3 Business Modeling
    • 8.2.4 Architecture Repository
  • 8.3 Inputs
    • 8.3.1 Reference Materials External to the Enterprise
    • 8.3.2 Non-Architectural Inputs
    • 8.3.3 Architectural Inputs
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks
      • 8.4.1.4 Identify Required Matrices
      • 8.4.1.5 Identify Required Diagrams
      • 8.4.1.6 Identify Types of Requirement to be Collected
    • 8.4.2 Develop Baseline Business Architecture Description
    • 8.4.3 Develop Target Business Architecture Description
    • 8.4.4 Perform Gap Analysis
    • 8.4.5 Define Roadmap Components
    • 8.4.6 Resolve Impacts Across the Architecture Landscape
    • 8.4.7 Conduct Formal Stakeholder Review
    • 8.4.8 Finalize the Business Architecture
    • 8.4.9 Create Architecture Definition Document
  • 8.5 Outputs
• 9. Phase C: Information Systems Architectures
  • 9.1 Objectives
  • 9.2 Approach
    • 9.2.1 Development
    • 9.2.2 Implementation
  • 9.3 Inputs
    • 9.3.1 Reference Materials External to the Enterprise
    • 9.3.2 Non-Architectural Inputs
    • 9.3.3 Architectural Inputs
  • 9.4 Steps
  • 9.5 Outputs
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.1 Objectives
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.1 Data Management
      • 10.2.1.2 Data Migration
      • 10.2.1.3 Data Governance
    • 10.2.2 Architecture Repository
  • 10.3 Inputs
    • 10.3.1 Reference Materials External to the Enterprise
    • 10.3.2 Non-Architectural Inputs
    • 10.3.3 Architectural Inputs
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
      • 10.4.1.2 Identify Required Catalogs of Data Building Blocks
      • 10.4.1.3 Identify Required Matrices
      • 10.4.1.4 Identify Required Diagrams
      • 10.4.1.5 Identify Types of Requirement to be Collected
    • 10.4.2 Develop Baseline Data Architecture Description
    • 10.4.3 Develop Target Data Architecture Description
    • 10.4.4 Perform Gap Analysis
    • 10.4.5 Define Roadmap Components
    • 10.4.6 Resolve Impacts Across the Architecture Landscape
    • 10.4.7 Conduct Formal Stakeholder Review
    • 10.4.8 Finalize the Data Architecture
    • 10.4.9 Create Architecture Definition Document
  • 10.5 Outputs
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.1 Objectives
  • 11.2 Approach
    • 11.2.1 Architecture Repository
  • 11.3 Inputs
    • 11.3.1 Reference Materials External to the Enterprise
    • 11.3.2 Non-Architectural Inputs
    • 11.3.3 Architectural Inputs
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks
      • 11.4.1.3 Identify Required Matrices
      • 11.4.1.4 Identify Required Diagrams
      • 11.4.1.5 Identify Types of Requirement to be Collected
    • 11.4.2 Develop Baseline Application Architecture Description
    • 11.4.3 Develop Target Application Architecture Description
    • 11.4.4 Perform Gap Analysis
    • 11.4.5 Define Roadmap Components
    • 11.4.6 Resolve Impacts Across the Architecture Landscape
    • 11.4.7 Conduct Formal Stakeholder Review
    • 11.4.8 Finalize the Application Architecture
    • 11.4.9 Create Architecture Definition Document
  • 11.5 Outputs
• 12. Phase D: Technology Architecture
  • 12.1 Objectives
  • 12.2 Approach
    • 12.2.1 Architecture Repository
  • 12.3 Inputs
    • 12.3.1 Reference Materials External to the Enterprise
    • 12.3.2 Non-Architectural Inputs
    • 12.3.3 Architectural Inputs
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
      • 12.4.1.3 Identify Required Matrices
      • 12.4.1.4 Identify Required Diagrams
      • 12.4.1.5 Identify Types of Requirement to be Collected
      • 12.4.1.6 Select Services
    • 12.4.2 Develop Baseline Technology Architecture Description
    • 12.4.3 Develop Target Technology Architecture Description
    • 12.4.4 Perform Gap Analysis
    • 12.4.5 Define Roadmap Components
    • 12.4.6 Resolve Impacts Across the Architecture Landscape
    • 12.4.7 Conduct Formal Stakeholder Review
    • 12.4.8 Finalize the Technology Architecture
    • 12.4.9 Create Architecture Definition Document
  • 12.5 Outputs
  • 12.6 Postscript
• 13. Phase E: Opportunities & Solutions
  • 13.1 Objectives
  • 13.2 Approach
  • 13.3 Inputs
    • 13.3.1 Reference Materials External to the Enterprise
    • 13.3.2 Non-Architectural Inputs
    • 13.3.3 Architectural Inputs
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.1 Create an Implementation Factor Assessment and Deduction Matrix
      • 13.4.1.2 Assess Transition Capabilities of Corporate and Partner Organizations
      • 13.4.1.3 Assess Transition Capabilities of the Enterprise and IT Organization
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.1 Review Corporate Strategic Plan
      • 13.4.2.2 Review the Enterprise Architecture Maturity Assessment
      • 13.4.2.3 Review Corporate Line-of-Business Strategic Plans
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.1 Create a Consolidated Gaps, Solutions, and Dependencies Matrix
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results
      • 13.4.3.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.1 Assess the IT Requirements from a Functional Perspective
      • 13.4.4.2 Determine Issues Associated with Functional Integration
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
      • 13.4.5.1 Consolidate Interoperability Requirements
      • 13.4.5.2 Reconcile Interoperability Requirements with Potential Solutions
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.1 Assess Business Dependencies
      • 13.4.6.2 Assess Information Dependencies
      • 13.4.6.3 Assess Workflow Dependencies
      • 13.4.6.4 Assess IT Dependencies
      • 13.4.6.5 Assess Foundation Dependencies and Interim Capabilities
      • 13.4.6.6 Rationalize and Consolidate Dependencies
    • 13.4.7 Confirm Readiness and Risk for Business Transformation
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
      • 13.4.8.1 Determine Overall Strategic Implementation Direction
      • 13.4.8.2 Determine an Implementation Approach
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.1 Identify Major Work Packages
      • 13.4.9.2 Analyze the Work Packages with Respect to Business Transformation
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.1 Identify Transition Architecture and Capability Increments
      • 13.4.10.2 Group Portfolios and Projects into Increments
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.1 Create the Portfolio Charters
      • 13.4.11.2 Create the Project Charters
      • 13.4.11.3 Create the Transition Architectures
      • 13.4.11.4 Conduct Overall Architecture Updates
  • 13.5 Outputs
• 14. Phase F: Migration Planning
  • 14.1 Objectives
  • 14.2 Approach
  • 14.3 Inputs
    • 14.3.1 Reference Materials External to the Enterprise
    • 14.3.2 Non-Architectural Inputs
    • 14.3.3 Architectural Inputs
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.1 Align Implementation and Migration Plan with Business/Capability Planning
      • 14.4.1.2 Examine Business Transformation Aspects
      • 14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework
      • 14.4.1.4 Align Implementation and Migration Plan with the Project Management Framework
      • 14.4.1.5 Align Implementation and Migration Plan with the Operations Management Framework
      • 14.4.1.6 Establish Plans for Enterprise Architecture Management
    • 14.4.2 Assign a Business Value to Each Project
      • 14.4.2.1 Confirm Organizational Business Value, Return on Investment, and Performance Measurement Parameters
      • 14.4.2.2 Assign Risk to the Projects and Project Increments
      • 14.4.2.3 Assign Business Value to the Projects and Project Increments
      • 14.4.2.4 Determine Continuous Business Value Assessment Technique
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.1 Determine Personnel and Infrastructure (Capital) Costs
      • 14.4.3.2 Determine Operations and Maintenance Costs
      • 14.4.3.3 Determine Transition Architecture/Project Increment Timings
      • 14.4.3.4 Assess Best Delivery Vehicle
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
      • 14.4.4.1 Derive Cost Benefit Analysis for the Migration Projects
      • 14.4.4.2 Validate the Risk Assessment
      • 14.4.4.3 Prioritize the Projects
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.1 Confirm Transition Architecture Time-Spans
      • 14.4.5.2 Confirm Business Value Delivered by the Increments
      • 14.4.5.3 Update Previously Created Architecture Deliverables
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.1 Confirm Enterprise Architecture Evolution
      • 14.4.6.2 Enterprise Architecture State Evolution
      • 14.4.6.3 Detailed Implementation and Migration Plan
      • 14.4.6.4 Incorporate Project Schedules
      • 14.4.6.5 Plan the Migration Details
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.1 Confirm the Enterprise Architecture Evolution Cycle
      • 14.4.7.2 Confirm the Enterprise Architecture Management Processes
      • 14.4.7.3 Document Lessons Learned
  • 14.5 Outputs
• 15. Phase G: Implementation Governance
  • 15.1 Objectives
  • 15.2 Approach
  • 15.3 Inputs
    • 15.3.1 Reference Materials External to the Enterprise
    • 15.3.2 Non-Architectural Inputs
    • 15.3.3 Architectural Inputs
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
    • 15.4.2 Identify Deployment Resources and Skills
    • 15.4.3 Guide Development of Solutions Deployment
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
    • 15.4.5 Implement Business and IT Operations
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation
  • 15.5 Outputs
• 16. Phase H: Architecture Change Management
  • 16.1 Objectives
  • 16.2 Approach
    • 16.2.1 Drivers for Change
    • 16.2.2 Enterprise Architecture Change Management Process
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign
  • 16.3 Inputs
    • 16.3.1 Reference Materials External to the Enterprise
    • 16.3.2 Non-Architectural Inputs
    • 16.3.3 Architectural Inputs
  • 16.4 Steps
    • 16.4.1 Establish Value Realization Process
    • 16.4.2 Deploy Monitoring Tools
    • 16.4.3 Manage Risks
    • 16.4.4 Provide Analysis for Architecture Change Management
    • 16.4.5 Develop Change Requirements to Meet Performance Targets
    • 16.4.6 Manage Governance Process
    • 16.4.7 Activate the Process to Implement Change
  • 16.5 Outputs
• 17. ADM Architecture Requirements Management
  • 17.1 Objectives
  • 17.2 Approach
    • 17.2.1 General
    • 17.2.2 Resources
      • 17.2.2.1 Business Scenarios
      • 17.2.2.2 Volere Requirements Specification Template
      • 17.2.2.3 Requirements Tools
  • 17.3 Inputs
  • 17.4 Steps
  • 17.5 Outputs
    • Footnotes
• 18. Introduction
  • 18.1 Guidelines for Adapting the ADM Process
  • 18.2 Techniques for Architecture Development
• 19. Applying Iteration to the ADM
  • 19.1 Overview
  • 19.2 Iteration Cycles
  • 19.3 Two Styles of Architecture Definition
  • 19.4 Mapping TOGAF Phases to Iteration Cycles
• 20. Applying the ADM at Different Enterprise Levels
  • 20.1 Overview
  • 20.2 Classes of Architecture Engagement
  • 20.3 Developing Architectures at Different Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.1 Using Iterations within a Single ADM Cycle
    • 20.4.2 Using a Hierarchy of ADM Processes
• 21. Security Architecture and the ADM
  • 21.1 Overview
  • 21.2 Introduction
  • 21.3 Guidance on Security for the Architecture Domains
  • 21.4 ADM Architecture Requirements Management
    • Is our security good?
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
    • Identify a security architect or security architecture team
    • Identify first-order assumptions and boundary conditions
    • 21.5.1 Security Inputs
    • 21.5.2 Security Outputs
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures
    • Define necessary security-related management sign-off milestones of this architecture development cycle
    • Determine and document applicable disaster recovery or business continuity plans/requirements
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
    • 21.6.1 Security Inputs
    • 21.6.2 Security Outputs
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • Identify and document interconnecting systems beyond project control
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases
    • Identify and document the ownership of assets
    • Determine and document appropriate security forensic processes
    • Identify the criticality of the availability and correct operation of the overall service
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
    • Reassess and confirm Architecture Vision decisions
    • Assess alignment or conflict of identified security policies with business goals
    • Determine "what can go wrong?"
    • 21.7.1 Security Inputs
    • 21.7.2 Security Outputs
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
    • Identify safe default actions and failure states
    • Identify and evaluate applicable recognized guidelines and standards
    • Revisit assumptions regarding interconnecting systems beyond project control
    • Determine and document the sensitivity or classification level of information stored/created/used
    • Identify and document custody of assets
    • Identify the criticality of the availability and correct operation of each function
    • Determine the relationship of the system under design with existing business disaster/continuity plans
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
    • Identify lifespan of information used as defined by business needs and regulatory requirements
    • Determine approaches to address identified risks:
    • Identify actions/events that warrant logging for later review or triggering forensic processes
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
    • Identify potential/likely avenues of attack
    • Determine "what can go wrong?"
    • 21.8.1 Security Inputs
    • 21.8.2 Security Outputs
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)
    • Revisit assumptions regarding interconnecting systems beyond project control
    • Identify and evaluate applicable recognized guidelines and standards
    • Identify methods to regulate consumption of resources
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Identify the trust (clearance) level of:
    • Identify minimal privileges required for any entity to achieve a technical or business objective
    • Identify mitigating security measures, where justified by risk assessment
    • Determine "what can go wrong?"
    • 21.9.1 Security Inputs
    • 21.9.2 Security Outputs
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use
    • Engineer mitigation measures addressing identified risks
    • Evaluate tested and re-usable security software and security system resources
    • Identify new code/resources/assets that are appropriate for re-use
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Identify correct secure installation parameters, initial conditions, and configurations
    • Implement disaster recovery and business continuity plans or modifications
    • Determine "what can go wrong?"
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
    • Implement necessary training to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; ensure awareness training of all users and non-privileged operators of the system and/or its components
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
  • 21.14 References
• 22. Using TOGAF to Define & Govern SOAs
  • 22.1 Overview
  • 22.2 Introduction
  • 22.3 Business-Led SOA Community
  • 22.4 Business- & Developer-Led SOA Communities
  • 22.5 Complexities Arising from SOA
  • 22.6 How Enterprise Architecture Supports SOA
  • 22.7 SOA and TOGAF
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.1 Service Qualities and TOGAF
    • 22.8.2 Purpose of a Service Contract
    • 22.8.3 Service Governance Considerations
      • Service Contracts
      • Service Policies
      • Service Lifecycle Management
      • Service Metadata
  • 22.9 Content and Structure of a Service Contract
  • 22.10 Service Contract Template
• 23. Architecture Principles
  • 23.1 Introduction
  • 23.2 Characteristics of Architecture Principles
  • 23.3 Components of Architecture Principles
  • 23.4 Developing Architecture Principles
    • 23.4.1 Qualities of Principles
  • 23.5 Applying Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
    • 23.6.2 Data Principles
    • 23.6.3 Application Principles
    • 23.6.4 Technology Principles
• 24. Stakeholder Management
  • 24.1 Introduction
  • 24.2 Approach to Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders
    • 24.3.2 Classify Stakeholder Positions
    • 24.3.3 Determine Stakeholder Management Approach
    • 24.3.4 Tailor Engagement Deliverables
  • 24.4 Template Stakeholder Map
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
    • 25.1.2 Content of a Pattern
    • 25.1.3 Terminology
      • 25.1.3.1 Architecture Patterns and Design Patterns
      • 25.1.3.2 Patterns and the Architecture Continuum
      • 25.1.3.3 Patterns and Views
      • 25.1.3.4 Patterns and Business Scenarios
    • 25.1.4 Architecture Patterns in Use
  • 25.2 US Treasury Architecture Development Guidance (TADG)
    • 25.2.1 TADG Pattern Content
    • 25.2.2 TADG Architecture Patterns
  • 25.3 IBM Patterns for e-Business
  • 25.4 Some Pattern Resources
• 26. Business Scenarios
  • 26.1 Introduction
  • 26.2 Benefits of Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.1 Overall Process
    • 26.3.2 Gathering
    • 26.3.3 Analyzing
    • 26.3.4 Reviewing
  • 26.4 Contents of a Business Scenario
  • 26.5 Contributions to the Business Scenario
  • 26.6 Business Scenarios and the TOGAF ADM
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.1 General Guidelines
    • 26.7.2 Questions to Ask for Each Area
      • Identifying, Documenting, and Ranking the Problem
      • Identifying the Business & Technical Environment, and Documenting in Models
      • Identifying and Documenting Objectives
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts
      • Checking for Fitness-for-Purpose, and refining if necessary
  • 26.8 Guidelines on Business Scenario Documentation
    • 26.8.1 Textual Documentation
    • 26.8.2 Business Scenario Models
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.1 Importance of Goals
    • 26.9.2 Importance of SMART Objectives
      • Example of Making Objectives SMART
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Business Process Performance
      • Goal: Decrease Costs
      • Goal: Improve Business Operations
      • Goal: Improve Management Efficacy
      • Goal: Reduce Risk
      • Goal: Improve Effectiveness of IT Organization
      • Goal: Improve User Productivity
      • Goal: Improve Portability and Scalability
      • Goal: Improve Interoperability
      • Goal: Increase Vendor Independence
      • Goal: Reduce Lifecycle Costs
      • Goal: Improve Security
      • Goal: Improve Manageability
  • 26.10 Summary
• 27. Gap Analysis
  • 27.1 Introduction
  • 27.2 Suggested Steps
  • 27.3 Example
• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment and Deduction Matrix
  • 28.2 Consolidated Gaps, Solutions, and Dependencies Matrix
  • 28.3 Architecture Definition Increments Table
  • 28.4 Enterprise Architecture State Evolution Table
  • 28.5 Business Value Assessment Technique
• 29. Interoperability Requirements
  • 29.1 Overview
  • 29.2 Defining Interoperability
  • 29.3 Enterprise Operating Model
  • 29.4 Refining Interoperability
  • 29.5 Determining Interoperability Requirements
  • 29.6 Reconciling Interoperability Requirements with Potential Solutions
  • 29.7 Summary
    • Footnotes
• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)
  • 30.2 Determine Readiness Factors
  • 30.3 Present Readiness Factors
  • 30.4 Assess Readiness Factors
    • 30.4.1 Readiness Factor Vision
    • 30.4.2 Readiness Factor Rating
    • 30.4.3 Readiness Factor Risks & Actions
  • 30.5 Readiness and Migration Planning
  • 30.6 Marketing the Implementation Plan
  • 30.7 Conclusion
    • Footnotes
• 31. Risk Management
  • 31.1 Introduction
  • 31.2 Risk Classification
  • 31.3 Risk Identification
  • 31.4 Initial Risk Assessment
  • 31.5 Risk Mitigation and Residual Risk Assessment
  • 31.6 Conduct Residual Risk Assessment
  • 31.7 Risk Monitoring and Governance (Phase G)
  • 31.8 Summary
• 32. Capability-Based Planning
  • 32.1 Overview
  • 32.2 Capability-Based Planning Paradigm
  • 32.3 Concept of Capability-Based Planning
    • 32.3.1 Capability Dimensions
    • 32.3.2 Capability Increments
  • 32.4 Capabilities in an Enterprise Architecture Context
  • 32.5 Summary
• 33. Introduction
  • 33.1 Overview
  • 33.2 Content Metamodel
  • 33.3 Content Framework and the TOGAF ADM
  • 33.4 Structure of Part IV
• 34. Content Metamodel
  • 34.1 Overview
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core and Extension Content
      • Core Metamodel Entities
      • Catalog, Matrix, and Diagram Concept
    • 34.2.2 Overview of the Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.1 Core Content Metamodel
    • 34.3.2 Core Architecture Artifacts
    • 34.3.3 Full Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
      • Purpose
      • Required Changes to the Metamodel
    • 34.4.2 Services Extensions
      • Purpose
      • Required Changes to the Metamodel
    • 34.4.3 Process Modeling Extensions
      • Purpose
      • Required Changes to the Metamodel
    • 34.4.4 Data Extensions
      • Purpose
      • Required Changes to the Metamodel
    • 34.4.5 Infrastructure Consolidation Extensions
      • Purpose
      • Required Changes to the Metamodel
    • 34.4.6 Motivation Extensions
      • Purpose
      • Required Changes to the Metamodel
  • 34.5 Content Metamodel Objects
  • 34.6 Content Metamodel Attributes
  • 34.7 Metamodel Relationships
    • Footnotes
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
    • 35.1.1 Simple Example of a Viewpoint and View
  • 35.2 Developing Views in the ADM
    • 35.2.1 General Guidelines
    • 35.2.2 View Creation Process
  • 35.3 Views, Tools, and Languages
    • 35.3.1 Overview
  • 35.4 Views and Viewpoints
    • 35.4.1 Example of Views and Viewpoints
    • 35.4.2 Views and Viewpoints in Enterprise Architecture
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description
  • 35.5 Conclusions
  • 35.6 Taxonomy of Architecture Viewpoints
  • 35.7 Viewpoints in the Preliminary Phase
    • Principles Catalog
  • 35.8 Viewpoints in Phase A
    • Stakeholder Map Matrix
    • Value Chain Diagram
    • Solution Concept Diagram
  • 35.9 Viewpoints in Phase B
    • Organization/Actor Catalog
    • Driver/Goal/Objective Catalog
    • Role Catalog
    • Business Service/Function Catalog
    • Location Catalog
    • Process/Event/Control/Product Catalog
    • Contract/Measure Catalog
    • Business Interaction Matrix
    • Actor/Role Matrix
    • Business Footprint Diagram
    • Business Service/Information Diagram
    • Functional Decomposition Diagram
    • Product Lifecycle Diagram
    • Goal/Objective/Service Diagram
    • Business Use-Case Diagram
    • Organization Decomposition Diagram
    • Process Flow Diagram
    • Event Diagram
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Data Component Catalog
    • Data Entity/Business Function Matrix
    • System/Data Matrix
    • Class Diagram
    • Data Dissemination Diagram
    • Data Security Diagram
    • Class Hierarchy Diagram
    • Data Migration Diagram
    • Data Lifecycle Diagram
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Portfolio Catalog
    • Interface Catalog
    • System/Organization Matrix
    • Role/System Matrix
    • System/Function Matrix
    • Application Interaction Matrix
    • Application Communication Diagram
    • Application and User Location Diagram
    • System Use-Case Diagram
    • Enterprise Manageability Diagram
    • Process/System Realization Diagram
    • Software Engineering Diagram
    • Application Migration Diagram
    • Software Distribution Diagram
  • 35.12 Viewpoints in Phase D
    • Technology Standards Catalog
    • Technology Portfolio Catalog
    • System/Technology Matrix
    • Environments and Locations Diagram
    • Platform Decomposition Diagram
    • Processing Diagram
    • Networked Computing/Hardware Diagram
    • Communications Engineering Diagram
  • 35.13 Viewpoints in Phase E
    • Project Context Diagram
    • Benefits Diagram
  • 35.14 Viewpoints for Requirements Management
    • Requirements Catalog
  • 35.15 Developing a Business Architecture View
    • 35.15.1 Stakeholders and Concerns
    • 35.15.2 Developing the View
    • 35.15.3 Key Issues
  • 35.16 Developing an Enterprise Security View
    • 35.16.1 Stakeholders and Concerns
    • 35.16.2 Developing the View
    • 35.16.3 Basic Concepts
      • 35.16.3.1 Information Domains
      • 35.16.3.2 Strict Isolation
      • 35.16.3.3 Absolute Protection
    • 35.16.4 Security Generic Architecture View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services
      • 35.16.5.2 Network Services
      • 35.16.5.3 System Security Management Services
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.1 Development Approach
      • 35.17.1.2 Software Modularity and Re-Use
      • 35.17.1.3 Portability
      • 35.17.1.4 Migration and Interoperability
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems
      • 35.17.2.2 Achieving Interoperability
      • 35.17.2.3 Software Tiers
      • Two-Tier
      • Three-Tier
      • Five-Tier
      • 35.17.2.4 Some Uses of a Data Access Tier
      • 35.17.2.5 One Possible Instantiation of a DAI
      • 35.17.2.6 DAIs Enable Flexibility
      • 35.17.2.7 Distribution
      • 35.17.2.8 Infrastructure Bus
    • 35.17.3 Conclusion
  • 35.18 Developing a System Engineering View
    • 35.18.1 Stakeholders and Concerns
    • 35.18.2 Key Issues
      • 35.18.2.1 Client/Server Model
      • 35.18.2.2 Master/Slave and Hierarchic Models
      • 35.18.2.3 Peer-to-Peer Model
      • 35.18.2.4 Distributed Object Management Model
  • 35.19 Developing a Communications Engineering View
    • 35.19.1 Stakeholders and Concerns
    • 35.19.2 Key Issues
      • 35.19.2.1 Communications Infrastructure
      • 35.19.2.2 Communications Models
      • The OSI Reference Model
      • Communications Framework
      • Allocation of Services to Components
  • 35.20 Developing a Data Flow View
    • 35.20.1 Stakeholders and Concerns
    • 35.20.2 Developing the View
    • 35.20.3 Key Issues
      • 35.20.3.1 Database Management Systems
      • Database Models
      • Distributed DBMSs
      • Distributed Heterogeneous DBMSs
      • 35.20.3.2 Data Dictionary/Directory Systems
      • 35.20.3.3 Data Administration
      • Repository
      • Database Administration
      • 35.20.3.4 Data Security
  • 35.21 Developing an Enterprise Manageability View
    • 35.21.1 Stakeholders and Concerns
    • 35.21.2 Developing the View
    • 35.21.3 Key Issues
  • 35.22 Developing an Acquirer View
    • 35.22.1 Stakeholders and Concerns
    • 35.22.2 Developing the View
    • 35.22.3 Key Issues
      • Footnotes
• 36. Architecture Deliverables
  • 36.1 Introduction
  • 36.2 Deliverable Descriptions
    • 36.2.1 Architecture Building Blocks
    • 36.2.2 Architecture Contract
      • Purpose
      • Content
    • 36.2.3 Architecture Definition Document
      • Purpose
      • Content
    • 36.2.4 Architecture Principles
      • Purpose
      • Content
    • 36.2.5 Architecture Repository
      • Purpose
      • Content
    • 36.2.6 Architecture Requirements Specification
      • Purpose
      • Content
    • 36.2.7 Architecture Roadmap
      • Purpose
      • Content
    • 36.2.8 Architecture Vision
      • Purpose
      • Content
    • 36.2.9 Business Principles, Business Goals, and Business Drivers
      • Purpose
      • Content
    • 36.2.10 Capability Assessment
      • Purpose
      • Content
    • 36.2.11 Change Request
      • Purpose
      • Content
    • 36.2.12 Communications Plan
      • Purpose
      • Content
    • 36.2.13 Compliance Assessment
      • Purpose
      • Content
    • 36.2.14 Implementation and Migration Plan
      • Purpose
      • Content
    • 36.2.15 Implementation Governance Model
      • Purpose
      • Content
    • 36.2.16 Organizational Model for Enterprise Architecture
      • Purpose
      • Content
    • 36.2.17 Request for Architecture Work
    • 36.2.18 Requirements Impact Assessment
      • Purpose
      • Content
    • 36.2.19 Solution Building Blocks
    • 36.2.20 Statement of Architecture Work
      • Purpose
      • Content
    • 36.2.21 Tailored Architecture Framework
      • Purpose
      • Content
    • 36.2.22 Transition Architecture
      • Purpose
      • Content
• 37. Building Blocks
  • 37.1 Overview
  • 37.2 Introduction to Building Blocks
    • 37.2.1 Overview
    • 37.2.2 Generic Characteristics
    • 37.2.3 Architecture Building Blocks
      • 37.2.3.1 Characteristics
      • 37.2.3.2 Specification Content
    • 37.2.4 Solution Building Blocks
      • 37.2.4.1 Characteristics
      • 37.2.4.2 Specification Content
  • 37.3 Building Blocks and the ADM
    • 37.3.1 Basic Principles
      • 37.3.1.1 Building Blocks in Architecture Design
      • 37.3.1.2 Building Block Design
    • 37.3.2 Building Block Specification Process in the ADM
  • 37.4 Building Blocks Example
    • 37.4.1 Introduction
    • 37.4.2 Structure
    • 37.4.3 Background to the Example
    • 37.4.4 Identifying Building Block Scope
    • 37.4.5 Identifying Building Block Requirements and Constraints
      • 37.4.5.1 Assumptions of Required Technical Functionality
    • 37.4.6 Architecture Modeling
      • 37.4.6.1 Customer Information System Building Block Specification
      • Description
      • Mandated Building Blocks
      • Map to Business Organization Entities and Policies
    • 37.4.7 Opportunity Identification
    • 37.4.8 Building Block Re-Use Level
      • Footnotes
• 38. Introduction
  • 38.1 Introduction
  • 38.2 Structure of Part V
• 39. Enterprise Continuum
  • 39.1 Overview
  • 39.2 Enterprise Continuum and Architecture Re-Use
  • 39.3 Constituents of the Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Foundation Architecture
      • Common Systems Architectures
      • Industry Architectures
      • Organization-Specific Architectures
    • 39.4.2 Solutions Continuum
      • Foundation Solutions
      • Common Systems Solutions
      • Industry Solutions
      • Organization-Specific Solutions
  • 39.5 Relationship between the Enterprise Continuum and TOGAF ADM
  • 39.6 Enterprise Continuum and Your Organization
    • 39.6.1 Relationships
    • 39.6.2 Your Enterprise
• 40. Architecture Partitioning
  • 40.1 Overview
  • 40.2 Characteristics of Solutions
  • 40.3 Characteristics of Architectures
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.1 Partitioning the Architecture Landscape to Understand the State of the Enterprise
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards
    • 40.4.4 Activities within the Preliminary Phase
    • 40.4.5 Activities within Phases A to F
    • 40.4.6 Activities within Phases G and H
    • 40.4.7 Content Aggregation and Integration
      • Footnotes
• 41. Architecture Repository
  • 41.1 Overview
  • 41.2 Architecture Landscape
  • 41.3 Reference Library
    • 41.3.1 Overview
  • 41.4 Standards Information Base
    • 41.4.1 Overview
    • 41.4.2 Types of Standard
    • 41.4.3 Standards Lifecycle
    • 41.4.4 Standards Classification within the Standards Information Base
  • 41.5 Governance Log
    • 41.5.1 Overview
    • 41.5.2 Contents of the Governance Log
• 42. Tools for Architecture Development
  • 42.1 Overview
  • 42.2 Issues in Tool Standardization
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.1 Functionality
      • Key Features and Functions
      • Intuitiveness/Ease-of-Use Factors
      • Organizational Compatibility Factors
      • Tool Capacity/Scalability Constraints
      • 42.3.1.2 Architecture of the Tool
      • 42.3.1.3 Full Lifecycle Support
      • 42.3.1.4 Interoperability Factors
      • 42.3.1.5 Financial Considerations
      • 42.3.1.6 Vendor Factors
    • 42.3.2 General Pointers
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.1 Role of the TRM in the Foundation Architecture
    • 43.1.2 TRM Components
    • 43.1.3 Other TRMs
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
    • 43.2.2 Portability and Interoperability
  • 43.3 TRM in Detail
    • 43.3.1 Introduction
    • 43.3.2 TRM Entities and Interfaces
    • 43.3.3 Application Software
      • 43.3.3.1 Business Applications
      • 43.3.3.2 Infrastructure Applications
    • 43.3.4 Application Platform
      • 43.3.4.1 Platform Concept
      • 43.3.4.2 Extending the TRM
      • 43.3.4.3 Interfaces Between Services
      • 43.3.4.4 Future Developments
    • 43.3.5 Communications Infrastructure
    • 43.3.6 Application Platform Interface
    • 43.3.7 Communications Infrastructure Interface
    • 43.3.8 Qualities
  • 43.4 Application Platform - Taxonomy
    • 43.4.1 Basic Principles
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services
    • 43.4.3 Application Platform Service Qualities
      • 43.4.3.1 Principles
      • 43.4.3.2 Taxonomy of Service Qualities
  • 43.5 Detailed Platform Taxonomy
    • 43.5.1 Data Interchange Services
    • 43.5.2 Data Management Services
    • 43.5.3 Graphics and Imaging Services
    • 43.5.4 International Operation Services
    • 43.5.5 Location and Directory Services
    • 43.5.6 Network Services
    • 43.5.7 Operating System Services
    • 43.5.8 Software Engineering Services
    • 43.5.9 Transaction Processing Services
    • 43.5.10 User Interface Services
    • 43.5.11 Security Services
    • 43.5.12 System and Network Management Services
    • 43.5.13 Object-Oriented Provision of Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.1 Background
    • 44.1.2 Components of the Model
    • 44.1.3 Relationship to Other parts of TOGAF
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.1 Problem Space: The Need for Boundaryless Information Flow
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure
    • 44.1.5 Status of the III-RM
  • 44.2 High-Level View
    • 44.2.1 Derivation of the III-RM from the TRM
    • 44.2.2 High-Level III-RM Graphic
    • 44.2.3 Components of the High-Level III-RM
  • 44.3 Detailed Taxonomy
    • 44.3.1 Detailed III-RM Graphic
    • 44.3.2 Business Applications
      • 44.3.2.1 Information Provider Applications
      • 44.3.2.2 Brokerage Applications
      • 44.3.2.3 Information Consumer Applications
    • 44.3.3 Infrastructure Applications
      • 44.3.3.1 Development Tools
      • Business Modeling Tools
      • Design Modeling Tools
      • Implementation and Construction Tools
      • Data Modeling Tools
      • Deployment Tools
      • Libraries
      • 44.3.3.2 Management Utilities
      • Operations, Administration, and Management (OA&M) Utilities
      • Quality of Service Manager Utilities
      • Copy Management Utilities
      • Storage Management Utilities
    • 44.3.4 Application Platform
      • 44.3.4.1 Software Engineering Services
      • 44.3.4.2 Security Services
      • 44.3.4.3 Location and Directory Services
      • 44.3.4.4 Human Interaction Services
      • 44.3.4.5 Data Interchange Services
      • 44.3.4.6 Data Management Services
      • 44.3.4.7 Additional Operating System Services
    • 44.3.5 Qualities
      • Footnotes
• 45. Introduction
  • 45.1 Overview
  • 45.2 Structure of Part VII
• 46. Establishing an Architecture Capability
  • 46.1 Overview
  • 46.2 Phase A: Architecture Vision
  • 46.3 Phase B: Business Architecture
  • 46.4 Phase C: Information Systems Architecture - Data
  • 46.5 Phase C: Information Systems Architecture - Application
  • 46.6 Phase D: Technology Architecture
  • 46.7 Phase E: Opportunities & Solutions
  • 46.8 Phase F: Migration Planning
  • 46.9 Phase G: Implementation Governance
  • 46.10 Phase H: Architecture Change Management
  • 46.11 Requirements Management
• 47. Architecture Board
  • 47.1 Role
  • 47.2 Responsibilities
  • 47.3 Setting Up the Architecture Board
    • 47.3.1 Triggers
    • 47.3.2 Size of the Board
    • 47.3.3 Board Structure
  • 47.4 Operation of the Architecture Board
    • 47.4.1 General
    • 47.4.2 Preparation
    • 47.4.3 Agenda
      • Minutes of Previous Meeting
      • Requests for Change
      • Dispensations
      • Compliance Assessments
      • Dispute Resolution
      • Architecture Strategy and Direction Documentation
      • Actions Assigned
      • Contract Documentation Management
      • Any Other Business (AOB)
      • Schedule of Meetings
• 48. Architecture Compliance
  • 48.1 Introduction
  • 48.2 Terminology: The Meaning of Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.1 Purpose
    • 48.3.2 Timing
    • 48.3.3 Governance and Personnel Scenarios
  • 48.4 Architecture Compliance Review Process
    • 48.4.1 Overview
    • 48.4.2 Roles
    • 48.4.3 Steps
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.1 Hardware and Operating System Checklist
    • 48.5.2 Software Services and Middleware Checklist
    • 48.5.3 Applications Checklists
      • 48.5.3.1 Infrastructure (Enterprise Productivity) Applications
      • 48.5.3.2 Business Applications
      • 48.5.3.3 Application Integration Approach
    • 48.5.4 Information Management Checklists
      • 48.5.4.1 Data Values
      • 48.5.4.2 Data Definition
      • 48.5.4.3 Security/Protection
      • 48.5.4.4 Hosting, Data Types, and Sharing
      • 48.5.4.5 Common Services
      • 48.5.4.6 Access Method
    • 48.5.5 Security Checklist
    • 48.5.6 System Management Checklist
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.1 General
      • 48.5.7.2 Processors/Servers/Clients
      • 48.5.7.3 Client
      • 48.5.7.4 Application Server
      • 48.5.7.5 Data Server
      • 48.5.7.6 COTS (where applicable)
    • 48.5.8 System Engineering/Methods & Tools Checklist
  • 48.6 Architecture Compliance Review Guidelines
    • 48.6.1 Tailoring the Checklists
    • 48.6.2 Conducting Architecture Compliance Reviews
• 49. Architecture Contracts
  • 49.1 Role
  • 49.2 Contents
    • 49.2.1 Statement of Architecture Work
    • 49.2.2 Contract between Architecture Design and Development Partners
    • 49.2.3 Contract between Architecting Function and Business Users
  • 49.3 Relationship to Architecture Governance
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise
    • 50.1.2 Nature of Governance
      • 50.1.2.1 Governance: A Generic Perspective
      • 50.1.2.2 Characteristics of Governance
    • 50.1.3 Technology Governance
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.1 Architecture Governance Characteristics
      • 50.1.5.2 Architecture Governance as a Board-Level Responsibility
      • 50.1.5.3 TOGAF and Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • 50.2.1.1 Key Concepts
      • 50.2.1.2 Key Architecture Governance Processes
      • Policy Management and Take-On
      • Compliance
      • Dispensation
      • Monitoring and Reporting
      • Business Control
      • Environment Management
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.1 Overview
      • 50.2.2.2 Key Areas
      • 50.2.2.3 Operational Benefits
  • 50.3 Architecture Governance in Practice
    • 50.3.1 Architecture Governance - Key Success Factors
    • 50.3.2 Elements of an Effective Architecture Governance Strategy
      • 50.3.2.1 Architecture Governance and Corporate Politics
      • Footnotes
• 51. Architecture Maturity Models
  • 51.1 Overview
  • 51.2 Background
  • 51.3 US DoC ACMM Framework
    • 51.3.1 Overview
    • 51.3.2 Elements of the ACMM
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 0: None
      • Level 1: Initial
      • Level 2: Under Development
      • Level 3: Defined
      • Level 4: Managed
      • Level 5: Optimizing
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction
    • 51.4.2 SCAMPI Method
  • 51.5 Conclusions
    • Footnotes
• 52. Architecture Skills Framework
  • 52.1 Introduction
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.1 Definitional Rigor
    • 52.2.2 Basis of an Internal Architecture Practice
  • 52.3 Goals/Rationale
    • 52.3.1 Certification of Enterprise Architects
    • 52.3.2 Specific Benefits
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.1 Overview
    • 52.4.2 TOGAF Roles
    • 52.4.3 Categories of Skills
    • 52.4.4 Proficiency Levels
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.1 Generic Skills
    • 52.5.2 Business Skills & Methods
    • 52.5.3 Enterprise Architecture Skills
    • 52.5.4 Program or Project Management Skills
    • 52.5.5 IT General Knowledge Skills
    • 52.5.6 Technical IT Skills
    • 52.5.7 Legal Environment
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.1 Generic Role
    • 52.6.2 Characterization in Terms of the Enterprise Continuum
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.1 Skills and Experience in Producing Designs
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines
      • 52.6.3.3 Method-Driven Approach to Execution
      • 52.6.3.4 Full Project Scope Experience
      • 52.6.3.5 Leadership
      • 52.6.3.6 Personal and Professional Skills
      • 52.6.3.7 Skills and Experience in One or More Industries
  • 52.7 Conclusions
• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)
  • A.2 Ada
  • A.3 Application Component
  • A.4 Application Software
  • A.5 Availability
  • A.6 Batch Processing
  • A.7 Business System
  • A.8 Catalog
  • A.9 Client
  • A.10 COBIT
  • A.11 Communications Network
  • A.12 Communications Node
  • A.13 Communications System
  • A.14 Composite Application
  • A.15 Configuration Management
  • A.16 Connectivity Service
  • A.17 Contract
  • A.18 Control
  • A.19 CxO
  • A.20 Data Dictionary
  • A.21 Data Element
  • A.22 Data Entity
  • A.23 Data Interchange Service
  • A.24 Data Management Service
  • A.25 Database
  • A.26 Database Management System
  • A.27 Directory Service
  • A.28 Distributed Database
  • A.29 Driver
  • A.30 End User
  • A.31 Enterprise Resource Planning (ERP) System
  • A.32 Event
  • A.33 External Environment Interface (EEI)
  • A.34 FORTRAN
  • A.35 Functional Decomposition
  • A.36 Goal
  • A.37 Guideline
  • A.38 Hardware
  • A.39 Human Computer Interface (HCI)
  • A.40 Information Domain
  • A.41 Information System (IS)
  • A.42 Information System Service
  • A.43 Interaction
  • A.44 Interaction Model
  • A.45 Interface
  • A.46 ITIL
  • A.47 Key Performance Indicator (KPI)
  • A.48 Lifecycle
  • A.49 Location
  • A.50 Logical Application Component
  • A.51 Logical Data Component
  • A.52 Logical Technology Component
  • A.53 Managing Successful Programs (MSP)
  • A.54 Matrix
  • A.55 Measure
  • A.56 Metaview
  • A.57 Multimedia Service
  • A.58 Open Specifications
  • A.59 Open System
  • A.60 Operational Governance
  • A.61 Operating System Service
  • A.62 Organization Unit
  • A.63 Packaged Services
  • A.64 Physical Application Component
  • A.65 Physical Data Component
  • A.66 Physical Technology Component
  • A.67 Portability
  • A.68 Portfolio
  • A.69 PRINCE2
  • A.70 Process
  • A.71 Product
  • A.72 Profile
  • A.73 Profiling
  • A.74 Program
  • A.75 Project
  • A.76 Risk Management
  • A.77 Scalability
  • A.78 Security
  • A.79 Server
  • A.80 Service
  • A.81 Service Quality
  • A.82 SMART
  • A.83 Supplier Management
  • A.84 System
  • A.85 System and Network Management Service
  • A.86 System Stakeholder
  • A.87 Technology Component
  • A.88 Time Period
  • A.89 Transaction
  • A.90 Transaction Sequence
  • A.91 Use-Case
  • A.92 User
  • A.93 User Interface Service
• B. Abbreviations
• Frontmatter
  • Preface
    • This Document
    • Intended Audience
    • Keywords
  • About The Open Group
    • The Open Group
  • Participants
    • Architecture Forum Technical Reviewers
    • Architecture Forum Members
  • Trademarks
  • Acknowledgements
  • Referenced Documents
• INDEX

return to top of page

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part of the TOGAF document or go direct to a chapter within the document.
  
• Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or select Home to return to the welcome page.
  

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.