INDEX

a.10

• A. Glossary of Supplementary Definitions
  • A.10 COBIT

a.11

• A. Glossary of Supplementary Definitions
  • A.11 Communications Network

a.12

• A. Glossary of Supplementary Definitions
  • A.12 Communications Node

a.13

• A. Glossary of Supplementary Definitions
  • A.13 Communications System

a.14

• A. Glossary of Supplementary Definitions
  • A.14 Composite Application

a.1

• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)

a.15

• A. Glossary of Supplementary Definitions
  • A.15 Configuration Management

a.16

• A. Glossary of Supplementary Definitions
  • A.16 Connectivity Service

a.17

• A. Glossary of Supplementary Definitions
  • A.17 Contract

a.18

• A. Glossary of Supplementary Definitions
  • A.18 Control

a.19

• A. Glossary of Supplementary Definitions
  • A.19 CxO

a.20

• A. Glossary of Supplementary Definitions
  • A.20 Data Dictionary

a.21

• A. Glossary of Supplementary Definitions
  • A.21 Data Element

a.22

• A. Glossary of Supplementary Definitions
  • A.22 Data Entity

a.23

• A. Glossary of Supplementary Definitions
  • A.23 Data Interchange Service

a.24

• A. Glossary of Supplementary Definitions
  • A.24 Data Management Service

a.2

• A. Glossary of Supplementary Definitions
  • A.2 Ada

a.25

• A. Glossary of Supplementary Definitions
  • A.25 Database

a.26

• A. Glossary of Supplementary Definitions
  • A.26 Database Management System

a.27

• A. Glossary of Supplementary Definitions
  • A.27 Directory Service

a.28

• A. Glossary of Supplementary Definitions
  • A.28 Distributed Database

a.29

• A. Glossary of Supplementary Definitions
  • A.29 Driver

a.30

• A. Glossary of Supplementary Definitions
  • A.30 End User

a.31

• A. Glossary of Supplementary Definitions
  • A.31 Enterprise Resource Planning (ERP) System

a.32

• A. Glossary of Supplementary Definitions
  • A.32 Event

a.33

• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)

a.34

• A. Glossary of Supplementary Definitions
  • A.34 FORTRAN

a.3

• A. Glossary of Supplementary Definitions
  • A.3 Application Component

a.35

• A. Glossary of Supplementary Definitions
  • A.35 Functional Decomposition

a.36

• A. Glossary of Supplementary Definitions
  • A.36 Goal

a.37

• A. Glossary of Supplementary Definitions
  • A.37 Guideline

a.38

• A. Glossary of Supplementary Definitions
  • A.38 Hardware

a.39

• A. Glossary of Supplementary Definitions
  • A.39 Human Computer Interface (HCI)

a.40

• A. Glossary of Supplementary Definitions
  • A.40 Information Domain

a.41

• A. Glossary of Supplementary Definitions
  • A.41 Information System (IS)

a.42

• A. Glossary of Supplementary Definitions
  • A.42 Information System Service

a.43

• A. Glossary of Supplementary Definitions
  • A.43 Interaction

a.44

• A. Glossary of Supplementary Definitions
  • A.44 Interaction Model

a.4

• A. Glossary of Supplementary Definitions
  • A.4 Application Software

a.45

• A. Glossary of Supplementary Definitions
  • A.45 Interface

a.46

• A. Glossary of Supplementary Definitions
  • A.46 ITIL

a.47

• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

a.48

• A. Glossary of Supplementary Definitions
  • A.48 Lifecycle

a.49

• A. Glossary of Supplementary Definitions
  • A.49 Location

a.50

• A. Glossary of Supplementary Definitions
  • A.50 Logical Application Component

a.51

• A. Glossary of Supplementary Definitions
  • A.51 Logical Data Component

a.52

• A. Glossary of Supplementary Definitions
  • A.52 Logical Technology Component

a.53

• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)

a.54

• A. Glossary of Supplementary Definitions
  • A.54 Matrix

a.5

• A. Glossary of Supplementary Definitions
  • A.5 Availability

a.55

• A. Glossary of Supplementary Definitions
  • A.55 Measure

a.56

• A. Glossary of Supplementary Definitions
  • A.56 Metaview

a.57

• A. Glossary of Supplementary Definitions
  • A.57 Multimedia Service

a.58

• A. Glossary of Supplementary Definitions
  • A.58 Open Specifications

a.59

• A. Glossary of Supplementary Definitions
  • A.59 Open System

A5 interoperability

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability

a.60

• A. Glossary of Supplementary Definitions
  • A.60 Operational Governance

a.61

• A. Glossary of Supplementary Definitions
  • A.61 Operating System Service

a.62

• A. Glossary of Supplementary Definitions
  • A.62 Organization Unit

a.63

• A. Glossary of Supplementary Definitions
  • A.63 Packaged Services

a.64

• A. Glossary of Supplementary Definitions
  • A.64 Physical Application Component

a.6

• A. Glossary of Supplementary Definitions
  • A.6 Batch Processing

a.65

• A. Glossary of Supplementary Definitions
  • A.65 Physical Data Component

a.66

• A. Glossary of Supplementary Definitions
  • A.66 Physical Technology Component

a.67

• A. Glossary of Supplementary Definitions
  • A.67 Portability

a.68

• A. Glossary of Supplementary Definitions
  • A.68 Portfolio

a.69

• A. Glossary of Supplementary Definitions
  • A.69 PRINCE2

a.70

• A. Glossary of Supplementary Definitions
  • A.70 Process

a.71

• A. Glossary of Supplementary Definitions
  • A.71 Product

a.72

• A. Glossary of Supplementary Definitions
  • A.72 Profile

a.73

• A. Glossary of Supplementary Definitions
  • A.73 Profiling

a.74

• A. Glossary of Supplementary Definitions
  • A.74 Program

a.7

• A. Glossary of Supplementary Definitions
  • A.7 Business System

a.75

• A. Glossary of Supplementary Definitions
  • A.75 Project

a.76

• A. Glossary of Supplementary Definitions
  • A.76 Risk Management

a.77

• A. Glossary of Supplementary Definitions
  • A.77 Scalability

a.78

• A. Glossary of Supplementary Definitions
  • A.78 Security

a.79

• A. Glossary of Supplementary Definitions
  • A.79 Server

a.80

• A. Glossary of Supplementary Definitions
  • A.80 Service

a.81

• A. Glossary of Supplementary Definitions
  • A.81 Service Quality

a.82

• A. Glossary of Supplementary Definitions
  • A.82 SMART

a.83

• A. Glossary of Supplementary Definitions
  • A.83 Supplier Management

a.84

• A. Glossary of Supplementary Definitions
  • A.84 System

a.8

• A. Glossary of Supplementary Definitions
  • A.8 Catalog

a.85

• A. Glossary of Supplementary Definitions
  • A.85 System and Network Management Service

a.86

• A. Glossary of Supplementary Definitions
  • A.86 System Stakeholder

a.87

• A. Glossary of Supplementary Definitions
  • A.87 Technology Component

a.88

• A. Glossary of Supplementary Definitions
  • A.88 Time Period

a.89

• A. Glossary of Supplementary Definitions
  • A.89 Transaction

a.90

• A. Glossary of Supplementary Definitions
  • A.90 Transaction Sequence

a.91

• A. Glossary of Supplementary Definitions
  • A.91 Use-Case

a.92

• A. Glossary of Supplementary Definitions
  • A.92 User

a.93

• A. Glossary of Supplementary Definitions
  • A.93 User Interface Service

a.9

• A. Glossary of Supplementary Definitions
  • A.9 Client

ABB

• 3. Definitions
  • 3.10 Architecture Building Block (ABB)
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.1 Architecture Building Blocks
• 37. Building Blocks
  • 37.1 Overview
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks

abbreviations

• B. Abbreviations

about

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
• Frontmatter
  • About The Open Group

absolute

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.3 Absolute Protection

absolute protection

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.3 Absolute Protection

abstraction

• 3. Definitions
  • 3.1 Abstraction

AC

• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)

acceptable

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures

acceptance

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

access

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.4 Some Uses of a Data Access Tier
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.6 Access Method
• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)

access control

• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)

access transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

accuracy

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
• 40. Architecture Partitioning
  • 40.3 Characteristics of Architectures

achieve

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective

achieving

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability

acknowledgements

• Frontmatter
  • Acknowledgements

ACL

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.2 Developing the View

ACMM

• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.2 Elements of the ACMM

acquirer

• 35. Architectural Artifacts
  • 35.22 Developing an Acquirer View

Acquirer view

• 35. Architectural Artifacts
  • 35.22 Developing an Acquirer View

across

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.6 Resolve Impacts Across the Architecture Landscape
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.6 Resolve Impacts Across the Architecture Landscape
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.6 Resolve Impacts Across the Architecture Landscape
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.6 Resolve Impacts Across the Architecture Landscape

actions

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states
• 30. Business Transformation Readiness Assessment
  • 30.4 Assess Readiness Factors
    • 30.4.3 Readiness Factor Risks & Actions
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Actions Assigned

actions/events

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

activate

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.7 Activate the Process to Implement Change

Active Standard

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle

Active Store

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Industry Architectures

activities

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 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

activity

• 3. Definitions
  • 3.2 Activity

activity model

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

actor

• 3. Definitions
  • 3.3 Actor
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities

Actor/Role

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Actor/Role Matrix

Actor/Role matrix

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Actor/Role Matrix

actors

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model

Ada

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models
• A. Glossary of Supplementary Definitions
  • A.2 Ada

adapting

• 5. Introduction
  • 5.3 Adapting the ADM
• 18. Introduction
  • 18.1 Guidelines for Adapting the ADM Process

additional

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Additional ADM Detail
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.7 Additional Operating System Services

address

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine approaches to address identified risks:

addressing

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks

adherence

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

ADM

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 3. Definitions
  • 3.12 Architecture Development Method (ADM)
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Additional ADM Detail
• 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

ADM guidelines and techniques

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques
• 18. Introduction

administration

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.3 Data Administration
      • Database Administration
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Operations, Administration, and Management (OA&M) Utilities

ADM iteration

• 19. Applying Iteration to the ADM

ADM, requirements management

• 17. ADM Architecture Requirements Management

adopting

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise

agenda

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda

aggregation

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.7 Content Aggregation and Integration

align

• 14. Phase F: Migration Planning
  • 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.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

alignment

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess alignment or conflict of identified security policies with business goals

all

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

allocation

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • Allocation of Services to Components

amp

• 13. Phase E: Opportunities & Solutions
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

analysis

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.4 Perform Gap Analysis
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.4 Perform Gap Analysis
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.4 Perform Gap Analysis
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.4 Perform Gap Analysis
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

analyze

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.2 Analyze the Work Packages with Respect to Business Transformation

analyzing

• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.3 Analyzing

and/or

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

ANSI X.12

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository

anticipated

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

any

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Any Other Business (AOB)

AOB

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Any Other Business (AOB)

API

• 3. Definitions
  • 3.7 Application Platform Interface (API)

applicable

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements
  • 21.8 Phase C: Information Systems Architectures
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.6 COTS (where applicable)

application

• 3. Definitions
  • 3.4 Application
  • 3.5 Application Architecture
  • 3.6 Application Platform
  • 3.7 Application Platform Interface (API)
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks
    • 11.4.2 Develop Baseline Application Architecture Description
    • 11.4.3 Develop Target Application Architecture Description
    • 11.4.8 Finalize the Application Architecture

Application and User Location diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application and User Location Diagram

Application Architecture

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
• 3. Definitions
  • 3.5 Application Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture

application building blocks

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks

Application Communication diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Communication Diagram

application component

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• A. Glossary of Supplementary Definitions
  • A.3 Application Component

Application Interaction matrix

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Interaction Matrix

application logic

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Five-Tier

Application Migration diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Migration Diagram

Application Platform

• 3. Definitions
  • 3.6 Application Platform
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
• 44. Integrated Information Infrastructure Reference Model
  • 44.2 High-Level View
    • 44.2.3 Components of the High-Level III-RM
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform

application platform interface

• 3. Definitions
  • 3.7 Application Platform Interface (API)
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
  • 43.3 TRM in Detail
    • 43.3.6 Application Platform Interface

Application Platform, service qualities

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.3 Application Platform Service Qualities

Application Platform, taxonomy

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy

application portability

• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.2 Portability and Interoperability

Application Portfolio catalog

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Portfolio Catalog

application principles, examples

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles

applications

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
      • 43.3.3.1 Business Applications
      • 43.3.3.2 Infrastructure Applications
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 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

application services

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

Application Software

• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
• A. Glossary of Supplementary Definitions
  • A.4 Application Software

Applications Standards

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

applying

• 19. Applying Iteration to the ADM
• 20. Applying the ADM at Different Enterprise Levels
• 23. Architecture Principles
  • 23.5 Applying Architecture Principles
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures

applying the ADM

• 20. Applying the ADM at Different Enterprise Levels

approach

• 6. Preliminary Phase
  • 6.2 Approach
• 7. Phase A: Architecture Vision
  • 7.2 Approach
• 8. Phase B: Business Architecture
  • 8.2 Approach
• 9. Phase C: Information Systems Architectures
  • 9.2 Approach
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
• 12. Phase D: Technology Architecture
  • 12.2 Approach
• 13. Phase E: Opportunities & Solutions
  • 13.2 Approach
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
      • 13.4.8.2 Determine an Implementation Approach
• 14. Phase F: Migration Planning
  • 14.2 Approach
• 15. Phase G: Implementation Governance
  • 15.2 Approach
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.3 Determine Stakeholder Management Approach
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.1 Development Approach
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.3 Applications Checklists
      • 48.5.3.3 Application Integration Approach
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.3 Method-Driven Approach to Execution

approaches

• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine approaches to address identified risks:

appropriate

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document appropriate security forensic processes
  • 21.10 Phase E: Opportunities & Solutions
    • Identify new code/resources/assets that are appropriate for re-use

approval

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval

architect

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify a security architect or security architecture team
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect

architecting

• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.3 Contract between Architecting Function and Business Users

architects

• 52. Architecture Skills Framework
  • 52.3 Goals/Rationale
    • 52.3.1 Certification of Enterprise Architects

architectural

• 3. Definitions
  • 3.8 Architectural Style
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.3 Architectural Inputs
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.3 Architectural Inputs
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.3 Architectural Inputs
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.3 Architectural Inputs
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.3 Architectural Inputs
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.3 Architectural Inputs
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.3 Architectural Inputs
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.3 Architectural Inputs
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.3 Architectural Inputs
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.3 Architectural Inputs
• 16. Phase H: Architecture Change Management
  • 16.3 Inputs
    • 16.3.3 Architectural Inputs
• 35. Architectural Artifacts

architectural artifact

• 35. Architectural Artifacts

architectural artifact, concepts

• 35. Architectural Artifacts
  • 35.1 Basic Concepts

architectural style

• 3. Definitions
  • 3.8 Architectural Style

architecture

• 1. Introduction
  • 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?
• 2. Core Concepts
  • 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.7 Architecture Repository
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.5 Application Architecture
  • 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.22 Baseline Architecture
  • 3.25 Business Architecture
  • 3.31 Capability Architecture
  • 3.36 Data Architecture
  • 3.42 Foundation Architecture
  • 3.72 Segment Architecture
  • 3.75 Service Oriented Architecture (SOA)
  • 3.77 Solution Architecture
  • 3.82 Strategic Architecture
  • 3.83 Target Architecture
  • 3.84 Taxonomy of Architecture Views
  • 3.86 Technology Architecture
  • 3.87 Transition Architecture
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part II: Architecture Development Method
• 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.2 Architecture Development Cycle
  • 5.4 Architecture Governance
  • 5.5 Scoping the Architecture
    • 5.5.2 Architecture Domains

Architecture Board

• 5. Introduction
  • 5.4 Architecture Governance
• 47. Architecture Board

architecture building block

• 3. Definitions
  • 3.10 Architecture Building Block (ABB)
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks

Architecture/Business

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation

Architecture Capability

• 2. Core Concepts
  • 2.7 Architecture Repository
• 41. Architecture Repository
  • 41.1 Overview
• 46. Establishing an Architecture Capability

Architecture Capability Framework

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 45. Introduction

architecture change management

• 16. Phase H: Architecture Change Management

architecture characteristics

• 40. Architecture Partitioning
  • 40.3 Characteristics of Architectures

Architecture Compliance

• 48. Architecture Compliance
  • 48.2 Terminology: The Meaning of Architecture Compliance

Architecture Compliance, checklists

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists

Architecture Compliance, guidelines

• 48. Architecture Compliance
  • 48.6 Architecture Compliance Review Guidelines

Architecture Compliance, review

• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews

Architecture Compliance, review process

• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
    • 48.4.1 Overview

Architecture Content Framework

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 33. Introduction

Architecture Context

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles

Architecture Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.11 Architecture Continuum
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.2 Patterns and the Architecture Continuum
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum

Architecture Contract

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.2 Architecture Contract
• 49. Architecture Contracts

architecture, definition

• 2. Core Concepts
  • 2.2 What is Architecture in the Context of TOGAF?

Architecture Definition

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles

Architecture Definition Document

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.3 Architecture Definition Document

architecture deliverables

• 36. Architecture Deliverables

architecture description

• 35. Architectural Artifacts
  • 35.1 Basic Concepts

architecture development

• 42. Tools for Architecture Development

Architecture Development Method

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 3. Definitions
  • 3.12 Architecture Development Method (ADM)
• 5. Introduction

architecture development, techniques

• 18. Introduction
  • 18.2 Techniques for Architecture Development

architecture domain

• 3. Definitions
  • 3.13 Architecture Domain
• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.2 Architecture Domains

architecture domains, security

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

architecture engagement

• 20. Applying the ADM at Different Enterprise Levels
  • 20.2 Classes of Architecture Engagement

Architecture Forum

• 1. Introduction

Architecture Framework

• 3. Definitions
  • 3.14 Architecture Framework

architecture governance

• 3. Definitions
  • 3.15 Architecture Governance
• 5. Introduction
  • 5.4 Architecture Governance
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.4 Principles
• 15. Phase G: Implementation Governance
  • 15.2 Approach
• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
• 47. Architecture Board
  • 47.1 Role
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.1 Architecture Governance Characteristics

Architecture Governance Framework

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise
  • 50.2 Architecture Governance Framework

Architecture Governance Framework, structure

• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • 50.2.1.1 Key Concepts

architecture governance, implementation

• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice

architecture integration

• 5. Introduction
  • 5.6 Architecture Integration

Architecture Landscape

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.16 Architecture Landscape
• 41. Architecture Repository
  • 41.1 Overview
  • 41.2 Architecture Landscape

Architecture Metamodel

• 2. Core Concepts
  • 2.7 Architecture Repository
• 41. Architecture Repository
  • 41.1 Overview

architecture modeling

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling

architecture models

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process

architecture partition

• 5. Introduction
  • 5.5 Scoping the Architecture

architecture partitioning

• 40. Architecture Partitioning

architecture pattern

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.1 Architecture Patterns and Design Patterns

architecture pattern, content

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.2 Content of a Pattern

architecture principles

• 3. Definitions
  • 3.17 Architecture Principles
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.4 Principles
• 23. Architecture Principles
  • 23.1 Introduction

architecture principles, characteristics

• 23. Architecture Principles
  • 23.2 Characteristics of Architecture Principles

architecture principles, components

• 23. Architecture Principles
  • 23.3 Components of Architecture Principles

architecture principles, criteria

• 23. Architecture Principles
  • 23.4 Developing Architecture Principles
    • 23.4.1 Qualities of Principles

Architecture/Project

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.3 Determine Transition Architecture/Project Increment Timings

Architecture Report

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.9 Create Architecture Definition Document

Architecture Repository

• 2. Core Concepts
  • 2.7 Architecture Repository
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.2 Architecture Repository
• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.5 Architecture Repository
• 41. Architecture Repository

architecture requirements management

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management

Architecture Requirements Specification

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.6 Architecture Requirements Specification

Architecture Roadmap

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.7 Architecture Roadmap

architectures

• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.3 Create the Transition Architectures

architecture, scoping

• 5. Introduction
  • 5.5 Scoping the Architecture

Architecture Skills Framework

• 51. Architecture Maturity Models
  • 51.2 Background
• 52. Architecture Skills Framework

Architecture Skills Framework, proficiency levels

• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.4 Proficiency Levels

Architecture Skills Framework, skills

• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.3 Categories of Skills

architecture view

• 3. Definitions
  • 3.18 Architecture View
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.3 Patterns and Views
• 35. Architectural Artifacts

architecture viewpoints, taxonomy

• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

Architecture Vision

• 3. Definitions
  • 3.19 Architecture Vision
• 5. Introduction
  • 5.3 Adapting the ADM
• 7. Phase A: Architecture Vision
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.8 Architecture Vision

are

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
  • 21.10 Phase E: Opportunities & Solutions
    • Identify new code/resources/assets that are appropriate for re-use

area

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.2 Key Areas

arising

• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Complexities Arising from SOA

artifact

• 2. Core Concepts
  • 2.5 Deliverables, Artifacts, and Building Blocks
• 3. Definitions
  • 3.20 Artifact
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.2 Core Architecture Artifacts
• 35. Architectural Artifacts

ARTS

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.2 Architecture Repository
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process

as

• 1. Introduction
  • 1.2 Executive Overview
    • Why do I need TOGAF as a framework for enterprise architecture?
• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.2 Architecture Governance as a Board-Level Responsibility

ask

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

aspects

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.2 Examine Business Transformation Aspects
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

assess

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.5 Assess Readiness for Business Transformation
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 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.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.1 Assess the IT Requirements from a Functional Perspective
    • 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
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.4 Assess Best Delivery Vehicle
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
    • Assess alignment or conflict of identified security policies with business goals
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems
• 30. Business Transformation Readiness Assessment
  • 30.4 Assess Readiness Factors

assessment

• 13. Phase E: Opportunities & Solutions
  • 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.2 Determine Business Constraints for Implementation
      • 13.4.2.2 Review the Enterprise Architecture Maturity Assessment
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 14.4.2.4 Determine Continuous Business Value Assessment Technique
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
      • 14.4.4.2 Validate the Risk Assessment

asset

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

asset protection

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

assets

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
    • Identify and document the ownership of assets
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document custody of assets

assign

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 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

assigned

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Actions Assigned

associated

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.2 Determine Issues Associated with Functional Integration

assumptions

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify first-order assumptions and boundary conditions
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.5 Identifying Building Block Requirements and Constraints
      • 37.4.5.1 Assumptions of Required Technical Functionality

assurance

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

attack

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify potential/likely avenues of attack

attributes

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
• 34. Content Metamodel
  • 34.6 Content Metamodel Attributes

audience

• Frontmatter
  • Preface
    • Intended Audience

audit

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

audit information

• 5. Introduction
  • 5.4 Architecture Governance

authentication

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

authorization

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

availability

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function
• A. Glossary of Supplementary Definitions
  • A.5 Availability

Availability/Delivery

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles

available

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use

avenues

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify potential/likely avenues of attack

awareness

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

b

• 8. Phase B: Business Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

background

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.3 Background to the Example
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.1 Background
• 51. Architecture Maturity Models
  • 51.2 Background

base

• 3. Definitions
  • 3.81 Standards Information Base (SIB)
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part IV: Resource Base
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

baseline

• 3. Definitions
  • 3.21 Baseline
  • 3.22 Baseline Architecture
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.2 Developing the Baseline Description
  • 8.4 Steps
    • 8.4.2 Develop Baseline Business Architecture Description
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.2 Develop Baseline Data Architecture Description
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.2 Develop Baseline Application Architecture Description
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.2 Develop Baseline Technology Architecture Description
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)

Baseline Application Architecture Description

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.2 Develop Baseline Application Architecture Description

Baseline Architecture

• 3. Definitions
  • 3.22 Baseline Architecture

Baseline Data Architecture Description

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.2 Develop Baseline Data Architecture Description

Baseline Description

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.2 Developing the Baseline Description

Baseline Technology Architecture Description

• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.2 Develop Baseline Technology Architecture Description

basic

• 5. Introduction
  • 5.2 Architecture Development Cycle
    • 5.2.2 Basic Structure
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.1 Basic Principles
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.1 Basic Principles
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts

basis

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.2 Basis of an Internal Architecture Practice

batch

• A. Glossary of Supplementary Definitions
  • A.6 Batch Processing

batch processing

• A. Glossary of Supplementary Definitions
  • A.6 Batch Processing

be

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.6 Identify Types of Requirement to be Collected
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.5 Identify Types of Requirement to be Collected
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.5 Identify Types of Requirement to be Collected
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.5 Identify Types of Requirement to be Collected
• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

benefit

• 1. Introduction
  • 1.2 Executive Overview
    • Who would benefit from using TOGAF?
• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 26. Business Scenarios
  • 26.2 Benefits of Business Scenarios
• 35. Architectural Artifacts
  • 35.13 Viewpoints in Phase E
    • Benefits Diagram
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.3 Operational Benefits
• 52. Architecture Skills Framework
  • 52.3 Goals/Rationale
    • 52.3.2 Specific Benefits

Benefits diagram

• 35. Architectural Artifacts
  • 35.13 Viewpoints in Phase E
    • Benefits Diagram

best

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.4 Assess Best Delivery Vehicle

between

• 39. Enterprise Continuum
  • 39.5 Relationship between the Enterprise Continuum and TOGAF ADM
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.3 Interfaces Between Services
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.2 Contract between Architecture Design and Development Partners
    • 49.2.3 Contract between Architecting Function and Business Users

beyond

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify and document interconnecting systems beyond project control
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control

block

• 2. Core Concepts
  • 2.5 Deliverables, Artifacts, and Building Blocks
• 3. Definitions
  • 3.10 Architecture Building Block (ABB)
  • 3.24 Building Block
  • 3.78 Solution Building Block (SBB)
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.2 Identify Required Catalogs of Data Building Blocks
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.1 Architecture Building Blocks
    • 36.2.19 Solution Building Blocks
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks
    • 37.2.4 Solution Building Blocks

board

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board
    • 47.3.2 Size of the Board
    • 47.3.3 Board Structure

Board-Level

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.2 Architecture Governance as a Board-Level Responsibility

both

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

boundaries

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts

boundary

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify first-order assumptions and boundary conditions

boundaryless

• 3. Definitions
  • 3.23 Boundaryless Information Flow
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.1 Problem Space: The Need for Boundaryless Information Flow

Boundaryless Information Flow

• 3. Definitions
  • 3.23 Boundaryless Information Flow

BPMN

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

breadth

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

breakdown

• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown

brokerage

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.2 Brokerage Applications

brokerage applications

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.2 Brokerage Applications

BTEP

• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)

BTEP, Readiness Rating Scheme

• 30. Business Transformation Readiness Assessment
  • 30.4 Assess Readiness Factors
    • 30.4.2 Readiness Factor Rating

building

• 2. Core Concepts
  • 2.5 Deliverables, Artifacts, and Building Blocks
• 3. Definitions
  • 3.10 Architecture Building Block (ABB)
  • 3.24 Building Block
  • 3.78 Solution Building Block (SBB)
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.2 Identify Required Catalogs of Data Building Blocks
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.1 Architecture Building Blocks
    • 36.2.19 Solution Building Blocks
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks
    • 37.2.4 Solution Building Blocks

building block

• 3. Definitions
  • 3.24 Building Block

building block, re-use level

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.8 Building Block Re-Use Level

building blocks

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 37. Building Blocks
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.1 Platform Concept

building blocks, characteristics

• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.2 Generic Characteristics

building blocks, design

• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.1 Basic Principles
      • 37.3.1.2 Building Block Design

building blocks, example

• 37. Building Blocks
  • 37.4 Building Blocks Example

bus

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus

business

• 3. Definitions
  • 3.25 Business Architecture
  • 3.26 Business Domain
  • 3.27 Business Function
  • 3.28 Business Governance
  • 3.29 Business Service
• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.3 Business Scenarios
  • 7.4 Steps
    • 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.7 Confirm and Elaborate Architecture Principles, including Business Principles
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks
    • 8.4.2 Develop Baseline Business Architecture Description
    • 8.4.3 Develop Target Business Architecture Description
    • 8.4.8 Finalize the Business Architecture

business applications

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
      • 43.3.3.1 Business Applications

Business Architecture

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
• 3. Definitions
  • 3.25 Business Architecture
• 8. Phase B: Business Architecture

Business Architecture view

• 35. Architectural Artifacts
  • 35.15 Developing a Business Architecture View

Business/Capability

• 14. Phase F: Migration Planning
  • 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

Business Continuity Plan

• 31. Risk Management
  • 31.5 Risk Mitigation and Residual Risk Assessment

business domain

• 3. Definitions
  • 3.26 Business Domain

business drivers

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.9 Business Principles, Business Goals, and Business Drivers

Business Footprint diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Footprint Diagram

business function

• 3. Definitions
  • 3.27 Business Function

business goals

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.9 Business Principles, Business Goals, and Business Drivers

business governance

• 3. Definitions
  • 3.28 Business Governance

Business Interaction matrix

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Interaction Matrix

Business-Led

• 22. Using TOGAF to Define & Govern SOAs
  • 22.3 Business-Led SOA Community

business-led SOA community

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

business modeling

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

business planning

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

business principles

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.4 Principles
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.9 Business Principles, Business Goals, and Business Drivers

business principles, examples

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles

business process model

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

Business Process Modeling Notation

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

business requirements

• 26. Business Scenarios

business scenarios

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.1 Business Scenarios
• 26. Business Scenarios
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.8 Architecture Vision

business scenarios, descriptions

• 26. Business Scenarios
  • 26.4 Contents of a Business Scenario

business scenarios, models

• 26. Business Scenarios
  • 26.4 Contents of a Business Scenario

business scenarios, workshops

• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.2 Gathering

business service

• 3. Definitions
  • 3.29 Business Service
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities

Business Service/Function catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Service/Function Catalog

Business Service/Information diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Service/Information Diagram

Business Standards

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

business system

• A. Glossary of Supplementary Definitions
  • A.7 Business System

Business Transformation Readiness Assessment

• 30. Business Transformation Readiness Assessment

Business Use-Case diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Use-Case Diagram

by

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.2 Confirm Business Value Delivered by the Increments
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Identify mitigating security measures, where justified by risk assessment
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

c

• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
  • 35.11 Viewpoints in the Phase C Application Architecture
• 46. Establishing an Architecture Capability
  • 46.4 Phase C: Information Systems Architecture - Data
  • 46.5 Phase C: Information Systems Architecture - Application

Calendar

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

can

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.7 Phase B: Business Architecture
    • Determine "what can go wrong?"
  • 21.8 Phase C: Information Systems Architectures
    • Determine "what can go wrong?"
  • 21.9 Phase D: Technology Architecture
    • Determine "what can go wrong?"
  • 21.10 Phase E: Opportunities & Solutions
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Determine "what can go wrong?"

capabilities

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.4 Evaluate Business Capabilities
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 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.6 Refine and Validate Dependencies
      • 13.4.6.5 Assess Foundation Dependencies and Interim Capabilities
• 32. Capability-Based Planning
  • 32.4 Capabilities in an Enterprise Architecture Context

capability

• 2. Core Concepts
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.30 Capability
  • 3.31 Capability Architecture
  • 3.32 Capability Increment
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.1 Identify Transition Architecture and Capability Increments
• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
    • 32.3.1 Capability Dimensions
    • 32.3.2 Capability Increments
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.10 Capability Assessment
• 46. Establishing an Architecture Capability
• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)

Capability Architecture

• 3. Definitions
  • 3.31 Capability Architecture
• 41. Architecture Repository
  • 41.2 Architecture Landscape

Capability Assessment

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.10 Capability Assessment
• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

Capability-Based

• 32. Capability-Based Planning
  • 32.2 Capability-Based Planning Paradigm
  • 32.3 Concept of Capability-Based Planning

capability-based planning

• 32. Capability-Based Planning

capability dimensions

• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
    • 32.3.1 Capability Dimensions

Capability Framework

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise

capability increment

• 3. Definitions
  • 3.32 Capability Increment
• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
    • 32.3.2 Capability Increments

Capability Maturity Model

• 51. Architecture Maturity Models
  • 51.1 Overview

Capacity/Scalability

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Tool Capacity/Scalability Constraints

capital

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.1 Determine Personnel and Infrastructure (Capital) Costs

cases

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

catalog

• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 35. Architectural Artifacts
  • 35.7 Viewpoints in the Preliminary Phase
    • Principles Catalog
  • 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
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Data Component Catalog
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Portfolio Catalog
    • Interface Catalog
  • 35.12 Viewpoints in Phase D
    • Technology Standards Catalog
    • Technology Portfolio Catalog
  • 35.14 Viewpoints for Requirements Management
    • Requirements Catalog
• A. Glossary of Supplementary Definitions
  • A.8 Catalog

catalog of application building blocks

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks

catalogs

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.2 Identify Required Catalogs of Data Building Blocks
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.2 Identify Required Catalogs of Application Building Blocks
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

catalogs, building blocks

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.3 Identify Required Catalogs of Business Building Blocks

Catalyst

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process

categories

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.3 Categories of Skills

categorization

• 2. Core Concepts
  • 2.11 TOGAF Document Categorization Model

certification

• 52. Architecture Skills Framework
  • 52.3 Goals/Rationale
    • 52.3.1 Certification of Enterprise Architects

chain

• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Value Chain Diagram

change

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Focus on Holistic Enterprise Change
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.1 Drivers for Change
    • 16.2.2 Enterprise Architecture Change Management Process
  • 16.4 Steps
    • 16.4.4 Provide Analysis for Architecture Change Management
    • 16.4.5 Develop Change Requirements to Meet Performance Targets
    • 16.4.7 Activate the Process to Implement Change

change management

• 16. Phase H: Architecture Change Management

change management process

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process

Change Request

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.11 Change Request

changes

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
      • Required Changes to the Metamodel
    • 34.4.2 Services Extensions
      • Required Changes to the Metamodel
    • 34.4.3 Process Modeling Extensions
      • Required Changes to the Metamodel
    • 34.4.4 Data Extensions
      • Required Changes to the Metamodel
    • 34.4.5 Infrastructure Consolidation Extensions
      • Required Changes to the Metamodel
    • 34.4.6 Motivation Extensions
      • Required Changes to the Metamodel

characteristics

• 23. Architecture Principles
  • 23.2 Characteristics of Architecture Principles
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.2 Generic Characteristics
    • 37.2.3 Architecture Building Blocks
      • 37.2.3.1 Characteristics
    • 37.2.4 Solution Building Blocks
      • 37.2.4.1 Characteristics
• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions
  • 40.3 Characteristics of Architectures
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.2 Nature of Governance
      • 50.1.2.2 Characteristics of Governance
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.1 Architecture Governance Characteristics
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect

characterization

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.2 Characterization in Terms of the Enterprise Continuum

charters

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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

checking

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Checking for Fitness-for-Purpose, and refining if necessary

checklist

• 48. Architecture Compliance
  • 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.4 Information Management Checklists
    • 48.5.5 Security Checklist
    • 48.5.6 System Management Checklist
    • 48.5.7 System Engineering/Overall Architecture Checklists
    • 48.5.8 System Engineering/Methods & Tools Checklist

class

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Class Diagram
    • Class Hierarchy Diagram

Class diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Class Diagram

classes

• 20. Applying the ADM at Different Enterprise Levels
  • 20.2 Classes of Architecture Engagement

Class Hierarchy diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Class Hierarchy Diagram

classification

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used
• 31. Risk Management
  • 31.2 Risk Classification
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

classify

• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.2 Classify Stakeholder Positions

class model

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

clearance

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify the trust (clearance) level of:

client

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.3 Client
• A. Glossary of Supplementary Definitions
  • A.9 Client

Client/Server

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.1 Client/Server Model

client/server model

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.1 Client/Server Model

close

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation

CMM

• 51. Architecture Maturity Models
  • 51.1 Overview

CMMI

• 36. Architecture Deliverables
  • 36.1 Introduction
• 51. Architecture Maturity Models
  • 51.2 Background
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

COBIT

• 5. Introduction
  • 5.4 Architecture Governance
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT
• A. Glossary of Supplementary Definitions
  • A.10 COBIT

COBIT framework

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.1 General

CODASYL

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

code

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

code/resources/assets

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Identify new code/resources/assets that are appropriate for re-use

collected

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.6 Identify Types of Requirement to be Collected
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.5 Identify Types of Requirement to be Collected
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.5 Identify Types of Requirement to be Collected
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.5 Identify Types of Requirement to be Collected

COM

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus

common

• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Common Systems Architectures
    • 39.4.2 Solutions Continuum
      • Common Systems Solutions
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.5 Common Services

common object services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

Common Systems Architectures

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Common Systems Architectures

Common Systems Solutions

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum
      • Common Systems Solutions

communicated

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

communication

• 3. Definitions
  • 3.33 Communications and Stakeholder Management
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Communication Diagram
  • 35.12 Viewpoints in Phase D
    • Communications Engineering Diagram
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • 35.19.2.1 Communications Infrastructure
      • 35.19.2.2 Communications Models
      • Communications Framework

Communications Engineering diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Communications Engineering Diagram

Communications Engineering view

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View

communications framework

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • Communications Framework

Communications Infrastructure

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • 35.19.2.1 Communications Infrastructure
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
  • 43.3 TRM in Detail
    • 43.3.5 Communications Infrastructure

Communications Infrastructure Interface

• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
  • 43.3 TRM in Detail
    • 43.3.7 Communications Infrastructure Interface

communications management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.33 Communications and Stakeholder Management

communications model

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • 35.19.2.2 Communications Models

communications network

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
    • 35.16.4 Security Generic Architecture View
• A. Glossary of Supplementary Definitions
  • A.11 Communications Network

communications node

• A. Glossary of Supplementary Definitions
  • A.12 Communications Node

Communications Plan

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.12 Communications Plan

communications system

• A. Glossary of Supplementary Definitions
  • A.13 Communications System

communities

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

community

• 22. Using TOGAF to Define & Govern SOAs
  • 22.3 Business-Led SOA Community

compatibility

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Organizational Compatibility Factors

complexities

• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Complexities Arising from SOA

compliance

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.13 Compliance Assessment
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Compliance Assessments
• 48. Architecture Compliance
  • 48.2 Terminology: The Meaning of Architecture Compliance
  • 48.3 Architecture Compliance Reviews
  • 48.4 Architecture Compliance Review Process
  • 48.5 Architecture Compliance Review Checklists
  • 48.6 Architecture Compliance Review Guidelines
    • 48.6.2 Conducting Architecture Compliance Reviews

Compliance Assessment

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.13 Compliance Assessment
• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

component

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Roadmap Components
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems
  • 21.12 Phase G: Implementation Governance
    • 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
• 23. Architecture Principles
  • 23.3 Components of Architecture Principles
• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Data Component Catalog
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • Allocation of Services to Components
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.2 TRM Components
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.2 Components of the Model
  • 44.2 High-Level View
    • 44.2.3 Components of the High-Level III-RM
• A. Glossary of Supplementary Definitions
  • A.3 Application Component
  • A.50 Logical Application Component
  • A.51 Logical Data Component
  • A.52 Logical Technology Component
  • A.64 Physical Application Component
  • A.65 Physical Data Component
  • A.66 Physical Technology Component
  • A.87 Technology Component

composite

• A. Glossary of Supplementary Definitions
  • A.14 Composite Application

composite application

• A. Glossary of Supplementary Definitions
  • A.14 Composite Application

computer

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Computer Actors and their Place in the Technology Model
• A. Glossary of Supplementary Definitions
  • A.39 Human Computer Interface (HCI)

Computing/Hardware

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Networked Computing/Hardware Diagram

concept

• 2. Core Concepts
• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept

conceptual

• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure

concerns

• 3. Definitions
  • 3.34 Concerns
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
  • 35.15 Developing a Business Architecture View
    • 35.15.1 Stakeholders and Concerns
  • 35.16 Developing an Enterprise Security View
    • 35.16.1 Stakeholders and Concerns
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
  • 35.18 Developing a System Engineering View
    • 35.18.1 Stakeholders and Concerns
  • 35.19 Developing a Communications Engineering View
    • 35.19.1 Stakeholders and Concerns
  • 35.20 Developing a Data Flow View
    • 35.20.1 Stakeholders and Concerns
  • 35.21 Developing an Enterprise Manageability View
    • 35.21.1 Stakeholders and Concerns
  • 35.22 Developing an Acquirer View
    • 35.22.1 Stakeholders and Concerns

conclusion

• 30. Business Transformation Readiness Assessment
  • 30.7 Conclusion
• 35. Architectural Artifacts
  • 35.5 Conclusions
  • 35.17 Developing a Software Engineering View
    • 35.17.3 Conclusion
• 51. Architecture Maturity Models
  • 51.5 Conclusions
• 52. Architecture Skills Framework
  • 52.7 Conclusions

conditions

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.1 Conditions of Use
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify first-order assumptions and boundary conditions
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations

conditions of use

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.1 Conditions of Use

conduct

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.7 Conduct Formal Stakeholder Review
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.7 Conduct Formal Stakeholder Review
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.7 Conduct Formal Stakeholder Review
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.7 Conduct Formal Stakeholder Review
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.4 Conduct Overall Architecture Updates
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
• 31. Risk Management
  • 31.6 Conduct Residual Risk Assessment

conducting

• 48. Architecture Compliance
  • 48.6 Architecture Compliance Review Guidelines
    • 48.6.2 Conducting Architecture Compliance Reviews

configurable

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

configuration

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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
• A. Glossary of Supplementary Definitions
  • A.15 Configuration Management

configuration management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• A. Glossary of Supplementary Definitions
  • A.15 Configuration Management

configurations

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations

confirm

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.2 Confirm Governance and Support Frameworks
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
    • 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.7 Confirm Readiness and Risk for Business Transformation
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
    • 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.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

conflict

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess alignment or conflict of identified security policies with business goals

connectivity

• A. Glossary of Supplementary Definitions
  • A.16 Connectivity Service

connectivity service

• A. Glossary of Supplementary Definitions
  • A.16 Connectivity Service

consideration

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.5 Financial Considerations

consistency

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Consistency of Output

consolidate

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
      • 13.4.5.1 Consolidate Interoperability Requirements

consolidated

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, and Dependencies Matrix

consolidation

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.5 Infrastructure Consolidation Extensions

constituents

• 39. Enterprise Continuum
  • 39.3 Constituents of the Enterprise Continuum

constraint

• 3. Definitions
  • 3.35 Constraint
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.5 Identifying Building Block Requirements and Constraints
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Tool Capacity/Scalability Constraints

construction

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Implementation and Construction Tools

consumer

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.3 Information Consumer Applications

consumption

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify methods to regulate consumption of resources

content

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Content Framework
• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.2 Content of a Pattern
  • 25.2 US Treasury Architecture Development Guidance (TADG)
    • 25.2.1 TADG Pattern Content
• 33. Introduction
  • 33.2 Content Metamodel
  • 33.3 Content Framework and the TOGAF ADM
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core and Extension Content

content framework

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Content Framework

content framework, and the TOGAF ADM

• 33. Introduction
  • 33.3 Content Framework and the TOGAF ADM

content metamodel

• 33. Introduction
  • 33.2 Content Metamodel
• 34. Content Metamodel

content metamodel attributes

• 34. Content Metamodel
  • 34.6 Content Metamodel Attributes

content metamodel, detail

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail

content metamodel, extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions

content metamodel objects

• 34. Content Metamodel
  • 34.5 Content Metamodel Objects

content metamodel, vision and concepts

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts

contents

• 26. Business Scenarios
  • 26.4 Contents of a Business Scenario
• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log
• 49. Architecture Contracts
  • 49.2 Contents

content tailoring

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)

context

• 2. Core Concepts
  • 2.2 What is Architecture in the Context of TOGAF?
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.2 Organizational Context
• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
• 32. Capability-Based Planning
  • 32.4 Capabilities in an Enterprise Architecture Context
• 35. Architectural Artifacts
  • 35.13 Viewpoints in Phase E
    • Project Context Diagram

continuity

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements
  • 21.11 Phase F: Migration Planning
    • Implement disaster recovery and business continuity plans or modifications

continuous

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 14.4.2.4 Determine Continuous Business Value Assessment Technique

continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.11 Architecture Continuum
  • 3.39 Enterprise Continuum
  • 3.79 Solutions Continuum
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part III: Enterprise Continuum
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.1 The ADM, Enterprise Continuum, and Architecture Repository
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.2 Patterns and the Architecture Continuum
• 39. Enterprise Continuum
  • 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
    • 39.4.2 Solutions Continuum

contract

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.2 Purpose of a Service Contract

Contract/Measure

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Contract/Measure Catalog

Contract/Measure catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Contract/Measure Catalog

contracts

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Contracts
• 49. Architecture Contracts

contributions

• 26. Business Scenarios
  • 26.5 Contributions to the Business Scenario

control

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify and document interconnecting systems beyond project control
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Business Control
• A. Glossary of Supplementary Definitions
  • A.1 Access Control (AC)
  • A.18 Control

copy

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Copy Management Utilities

CORBA

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model

core

• 2. Core Concepts
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core and Extension Content
      • Core Metamodel Entities

core architecture artifacts

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.2 Core Architecture Artifacts

core concepts

• 2. Core Concepts

core content metamodel

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.1 Core Content Metamodel

core content metamodel, concepts

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts

corporate

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.2 Assess Transition Capabilities of Corporate and Partner Organizations

corporate governance

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise

corporate policy

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards

correct

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations
  • 21.12 Phase G: Implementation Governance
    • 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

cost

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.2 How Much Does TOGAF Cost?
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

Cost/Benefit

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

costs

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Decrease Costs
      • Goal: Reduce Lifecycle Costs

COTS

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.3 Requirements Tools
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles
• 26. Business Scenarios
  • 26.2 Benefits of Business Scenarios
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability
  • 35.22 Developing an Acquirer View
• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.1 Basic Principles
      • 37.3.1.2 Building Block Design
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
      • 43.3.3.2 Infrastructure Applications
• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.1 Purpose
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.6 COTS (where applicable)

create

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.9 Create Architecture Definition Document
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.9 Create Architecture Definition Document
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.9 Create Architecture Definition Document
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.9 Create Architecture Definition Document
• 13. Phase E: Opportunities & Solutions
  • 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.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.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

create architecture models

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process

created

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.3 Update Previously Created Architecture Deliverables

creating

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.2 Creating the Architecture Vision
• 26. Business Scenarios
  • 26.3 Creating the Business Scenario

creation

• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.2 View Creation Process

criteria

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria

criticality

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function

current

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)

custody

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document custody of assets

customer

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • 37.4.6.1 Customer Information System Building Block Specification

CxO

• A. Glossary of Supplementary Definitions
  • A.19 CxO

cycle

• 5. Introduction
  • 5.2 Architecture Development Cycle
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.1 Confirm the Enterprise Architecture Evolution Cycle

d

• 12. Phase D: Technology Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

DAI

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Five-Tier
      • 35.17.2.5 One Possible Instantiation of a DAI
      • 35.17.2.6 DAIs Enable Flexibility

data

• 3. Definitions
  • 3.36 Data Architecture
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 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

data access interface

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Five-Tier

data access tier

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.4 Some Uses of a Data Access Tier

data administration

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.3 Data Administration

Data Architecture

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
• 3. Definitions
  • 3.36 Data Architecture
• 10. Phase C: Information Systems Architectures - Data Architecture

database

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.1 Database Management Systems
      • Database Models
      • Database Administration
• A. Glossary of Supplementary Definitions
  • A.25 Database
  • A.26 Database Management System
  • A.28 Distributed Database

database administration

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Administration

database management system

• A. Glossary of Supplementary Definitions
  • A.26 Database Management System

database services

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.2 Developing the View

database system

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.2 Developing the View

data building blocks

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.2 Identify Required Catalogs of Data Building Blocks

data dictionary

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.2 Data Dictionary/Directory Systems
• A. Glossary of Supplementary Definitions
  • A.20 Data Dictionary

data directory

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.2 Data Dictionary/Directory Systems

Data Dissemination diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Dissemination Diagram

data element

• A. Glossary of Supplementary Definitions
  • A.21 Data Element

data encapsulation

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Three-Tier

data encryption

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.4 Data Security

data entity

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• A. Glossary of Supplementary Definitions
  • A.22 Data Entity

Data Entity/Business Function matrix

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Business Function Matrix

Data Entity/Data Component catalog

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Data Component Catalog

data extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.4 Data Extensions

Data Flow view

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View

data governance

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.3 Data Governance

Data-Intensive

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems

data-intensive software

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems

data interchange services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.1 Data Interchange Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.5 Data Interchange Services
• A. Glossary of Supplementary Definitions
  • A.23 Data Interchange Service

Data Lifecycle diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Lifecycle Diagram

data management

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.1 Data Management
• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues

data management services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.2 Data Management Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.6 Data Management Services
• A. Glossary of Supplementary Definitions
  • A.24 Data Management Service

data migration

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.2 Data Migration

Data Migration diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Migration Diagram

data principles, examples

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles

data security

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.4 Data Security

Data Security diagram

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Security Diagram

data services

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

data standardization

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Three-Tier

Data Standards

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

DBMS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.1 Database Management Systems

DBMS, flat files

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

DBMS, hierarchical model

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

DBMS, network model

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

DBMS, object-oriented model

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

DBMS, relational model

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

DBMSs

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Distributed DBMSs
      • Distributed Heterogeneous DBMSs

DD/DS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.2 Data Dictionary/Directory Systems

DDL

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.1 Database Management Systems
      • 35.20.3.2 Data Dictionary/Directory Systems

deal

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?

Decision Log

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

decisions

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Reassess and confirm Architecture Vision decisions

decomposition

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Functional Decomposition Diagram
    • Organization Decomposition Diagram
  • 35.12 Viewpoints in Phase D
    • Platform Decomposition Diagram
• A. Glossary of Supplementary Definitions
  • A.35 Functional Decomposition

decrease

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Decrease Costs

deduction

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.1 Create an Implementation Factor Assessment and Deduction Matrix
• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment and Deduction Matrix

default

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states

define

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.6 Define Scope
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Roadmap Components
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• 22. Using TOGAF to Define & Govern SOAs

defined

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 3: Defined

defining

• 29. Interoperability Requirements
  • 29.2 Defining Interoperability

definition

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.9 Create Architecture Definition Document
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.9 Create Architecture Definition Document
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.9 Create Architecture Definition Document
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.9 Create Architecture Definition Document
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
• 19. Applying Iteration to the ADM
  • 19.3 Two Styles of Architecture Definition
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
• 28. Migration Planning Techniques
  • 28.3 Architecture Definition Increments Table
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.3 Architecture Definition Document
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.2 Data Definition

definitional

• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.1 Definitional Rigor

definitions

• 3. Definitions
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
• A. Glossary of Supplementary Definitions

Degrees of Interoperability

• 29. Interoperability Requirements
  • 29.4 Refining Interoperability

deliverable

• 2. Core Concepts
  • 2.5 Deliverables, Artifacts, and Building Blocks
• 3. Definitions
  • 3.37 Deliverable
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.3 Update Previously Created Architecture Deliverables
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.4 Tailor Engagement Deliverables
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions

delivered

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.2 Confirm Business Value Delivered by the Increments

delivery

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.4 Assess Best Delivery Vehicle

dependencies

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
    • 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

deploy

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.2 Deploy Monitoring Tools

deployed

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

deployment

• 15. Phase G: Implementation Governance
  • 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
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Deployment Tools

Deployment Repository

• 41. Architecture Repository
  • 41.1 Overview

Deprecated Standard

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle

depth

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

derivation

• 44. Integrated Information Infrastructure Reference Model
  • 44.2 High-Level View
    • 44.2.1 Derivation of the III-RM from the TRM

derive

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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

descriptions

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions

design

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine the relationship of the system under design with existing business disaster/continuity plans
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.1 Architecture Patterns and Design Patterns
• 37. Building Blocks
  • 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
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Design Modeling Tools
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.2 Contract between Architecture Design and Development Partners

design pattern

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.1 Architecture Patterns and Design Patterns

designs

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.1 Skills and Experience in Producing Designs

detail

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Additional ADM Detail
• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Vertical Scope/Level of Detail
• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail

detailed

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.3 Detailed Implementation and Migration Plan
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.1 Detailed III-RM Graphic

Detailed Design Repository

• 41. Architecture Repository
  • 41.1 Overview

details

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.5 Plan the Migration Details

determine

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.2 Determine Issues Associated with Functional Integration
    • 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
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 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
• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • 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
    • Determine and document appropriate security forensic processes
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
    • Determine "what can go wrong?"
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used
    • Determine the relationship of the system under design with existing business disaster/continuity plans
    • Determine approaches to address identified risks:
    • Determine "what can go wrong?"
  • 21.9 Phase D: Technology Architecture
    • Determine "what can go wrong?"
  • 21.10 Phase E: Opportunities & Solutions
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Determine "what can go wrong?"
  • 21.12 Phase G: Implementation Governance
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.3 Determine Stakeholder Management Approach
• 30. Business Transformation Readiness Assessment
  • 30.2 Determine Readiness Factors

Determine/Confirm

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes

determining

• 29. Interoperability Requirements
  • 29.5 Determining Interoperability Requirements

develop

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.8 Develop Architecture Vision
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.2 Develop Baseline Business Architecture Description
    • 8.4.3 Develop Target Business Architecture Description
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.2 Develop Baseline Data Architecture Description
    • 10.4.3 Develop Target Data Architecture Description
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.2 Develop Baseline Application Architecture Description
    • 11.4.3 Develop Target Application Architecture Description
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.2 Develop Baseline Technology Architecture Description
    • 12.4.3 Develop Target Technology Architecture Description
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets

Developer-Led

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

developer-led SOA community

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

developing

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.2 Developing the Baseline Description
• 20. Applying the ADM at Different Enterprise Levels
  • 20.3 Developing Architectures at Different Levels
• 23. Architecture Principles
  • 23.4 Developing Architecture Principles
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
  • 35.15 Developing a Business Architecture View
    • 35.15.2 Developing the View

development

• 2. Core Concepts
  • 2.4 Architecture Development Method
• 3. Definitions
  • 3.12 Architecture Development Method (ADM)
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part II: Architecture Development Method
• 5. Introduction
  • 5.2 Architecture Development Cycle
• 9. Phase C: Information Systems Architectures
  • 9.2 Approach
    • 9.2.1 Development
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
    • 15.4.3 Guide Development of Solutions Deployment
• 18. Introduction
  • 18.2 Techniques for Architecture Development
• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle
• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.1 Development Approach
• 42. Tools for Architecture Development
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.4 Future Developments
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • 44.3.3.1 Development Tools
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.2 Contract between Architecture Design and Development Partners
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 2: Under Development

development tools

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • 44.3.3.1 Development Tools

diagram

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.5 Identify Required Diagrams
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.4 Identify Required Diagrams
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.4 Identify Required Diagrams
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.4 Identify Required Diagrams
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints
  • 35.8 Viewpoints in Phase A
    • Value Chain Diagram
    • Solution Concept Diagram
  • 35.9 Viewpoints in Phase B
    • 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
    • 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 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
    • 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

dictionary

• A. Glossary of Supplementary Definitions
  • A.20 Data Dictionary

Dictionary/Directory

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.2 Data Dictionary/Directory Systems

different

• 20. Applying the ADM at Different Enterprise Levels
  • 20.3 Developing Architectures at Different Levels

dimensions

• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
    • 32.3.1 Capability Dimensions

direction

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
      • 13.4.8.1 Determine Overall Strategic Implementation Direction
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Architecture Strategy and Direction Documentation

directory

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.5 Location and Directory Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.3 Location and Directory Services
• A. Glossary of Supplementary Definitions
  • A.27 Directory Service

directory services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.5 Location and Directory Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.3 Location and Directory Services
• A. Glossary of Supplementary Definitions
  • A.27 Directory Service

disaster

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements
  • 21.11 Phase F: Migration Planning
    • Implement disaster recovery and business continuity plans or modifications

disaster/continuity

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine the relationship of the system under design with existing business disaster/continuity plans

disciplines

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

dispensation

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Dispensations
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Dispensation

dispute

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Dispute Resolution

dissemination

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Dissemination Diagram

distributed

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Distributed DBMSs
      • Distributed Heterogeneous DBMSs
• A. Glossary of Supplementary Definitions
  • A.28 Distributed Database

distributed database

• A. Glossary of Supplementary Definitions
  • A.28 Distributed Database

distributed DBMS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Distributed DBMSs

distributed object management model

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model

distribution

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Software Distribution Diagram
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

DML

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • 35.20.3.1 Database Management Systems

do

• 1. Introduction
  • 1.2 Executive Overview
    • Why do I need an enterprise architecture?
    • Why do I need TOGAF as a framework for enterprise architecture?

DoC

• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework

document

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 2. Core Concepts
  • 2.11 TOGAF Document Categorization Model
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.9 Create Architecture Definition Document
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.9 Create Architecture Definition Document
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.9 Create Architecture Definition Document
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.9 Create Architecture Definition Document
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.3 Document Lessons Learned

documentation

• 26. Business Scenarios
  • 26.8 Guidelines on Business Scenario Documentation
    • 26.8.1 Textual Documentation

document categorization model

• 2. Core Concepts
  • 2.11 TOGAF Document Categorization Model

documenting

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 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
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts

documents

• Frontmatter
  • Referenced Documents

DoDAF

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process

does

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.2 How Much Does TOGAF Cost?

domain

• 3. Definitions
  • 3.13 Architecture Domain
  • 3.26 Business Domain
• A. Glossary of Supplementary Definitions
  • A.40 Information Domain

domain, Application Architecture

• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

domain, Business Architecture

• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

domain, Data Architecture

• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

domains

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.2 Architecture Domains
• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.1 Information Domains

domain, Technology Architecture

• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

downloads

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.3 Downloads

DRDA

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI

driver

• A. Glossary of Supplementary Definitions
  • A.29 Driver

Driver/Goal/Objective

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Driver/Goal/Objective Catalog

Driver/Goal/Objective catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Driver/Goal/Objective Catalog

drivers

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.1 Drivers for Change
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.9 Business Principles, Business Goals, and Business Drivers
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers

drivers for change

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.1 Drivers for Change

e

• 13. Phase E: Opportunities & Solutions
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
• 35. Architectural Artifacts
  • 35.13 Viewpoints in Phase E
• 46. Establishing an Architecture Capability
  • 46.7 Phase E: Opportunities & Solutions

each

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

EAP

• 9. Phase C: Information Systems Architectures
  • 9.2 Approach
    • 9.2.1 Development

e-Business

• 25. Architecture Patterns
  • 25.3 IBM Patterns for e-Business

ebXML

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository

EEI

• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)

effective

• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.2 Elements of an Effective Architecture Governance Strategy

effectiveness

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Effectiveness of IT Organization

efficacy

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Management Efficacy

elaborate

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
    • 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles

element

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.2 Elements of an Effective Architecture Governance Strategy
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.2 Elements of the ACMM
• A. Glossary of Supplementary Definitions
  • A.21 Data Element

enable

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.6 DAIs Enable Flexibility

enablement

• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)

encourage

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use

end

• A. Glossary of Supplementary Definitions
  • A.30 End User

end user

• A. Glossary of Supplementary Definitions
  • A.30 End User

Energistics

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.2 Architecture Repository
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Industry Architectures

enforce

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards

engagement

• 20. Applying the ADM at Different Enterprise Levels
  • 20.2 Classes of Architecture Engagement
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.4 Tailor Engagement Deliverables

engineer

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks

engineering

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Software Engineering Diagram
  • 35.12 Viewpoints in Phase D
    • Communications Engineering Diagram
  • 35.17 Developing a Software Engineering View
  • 35.18 Developing a System Engineering View
  • 35.19 Developing a Communications Engineering View
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.8 Software Engineering Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.1 Software Engineering Services

Engineering/Methods

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.8 System Engineering/Methods & Tools Checklist

Engineering/Overall

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists

enhancement

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

ensure

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

enterprise

• 1. Introduction
  • 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?
    • Why do I need TOGAF as a framework for enterprise architecture?
• 2. Core Concepts
  • 2.6 Enterprise Continuum
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
• 3. Definitions
  • 3.38 Enterprise
  • 3.39 Enterprise Continuum
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise
  • 4.2 The Benefits of TOGAF 9
    • More Focus on Holistic Enterprise Change
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part III: Enterprise Continuum
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.1 The ADM, Enterprise Continuum, and Architecture Repository
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.1 Enterprise
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
  • 6.3 Inputs
    • 6.3.1 Reference Materials External to the Enterprise
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.1 Reference Materials External to the Enterprise
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.1 Reference Materials External to the Enterprise
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.1 Reference Materials External to the Enterprise
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.1 Reference Materials External to the Enterprise
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.1 Reference Materials External to the Enterprise
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.1 Reference Materials External to the Enterprise
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.1 Reference Materials External to the Enterprise
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.3 Assess Transition Capabilities of the Enterprise and IT Organization
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.2 Review the Enterprise Architecture Maturity Assessment
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.1 Reference Materials External to the Enterprise
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework
      • 14.4.1.6 Establish Plans for Enterprise Architecture Management
    • 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.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
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.1 Reference Materials External to the Enterprise
  • 15.4 Steps
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process
  • 16.3 Inputs
    • 16.3.1 Reference Materials External to the Enterprise
• 20. Applying the ADM at Different Enterprise Levels
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 How Enterprise Architecture Supports SOA
• 28. Migration Planning Techniques
  • 28.4 Enterprise Architecture State Evolution Table
• 29. Interoperability Requirements
  • 29.3 Enterprise Operating Model
• 32. Capability-Based Planning
  • 32.4 Capabilities in an Enterprise Architecture Context
• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.2 Views and Viewpoints in Enterprise Architecture
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Enterprise Manageability Diagram
  • 35.16 Developing an Enterprise Security View
  • 35.21 Developing an Enterprise Manageability View
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.16 Organizational Model for Enterprise Architecture
• 39. Enterprise Continuum
  • 39.2 Enterprise Continuum and Architecture Re-Use
  • 39.3 Constituents of the Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
  • 39.5 Relationship between the Enterprise Continuum and TOGAF ADM
  • 39.6 Enterprise Continuum and Your Organization
    • 39.6.2 Your Enterprise

enterprise architect

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.2 Characterization in Terms of the Enterprise Continuum

enterprise architect, key characteristics

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.1 Skills and Experience in Producing Designs

enterprise architect, role of

• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.1 Overview

enterprise architecture

• 1. Introduction
  • 1.2 Executive Overview
    • What is an enterprise? What is enterprise architecture?

enterprise architecture capability

• 2. Core Concepts
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability

Enterprise Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.39 Enterprise Continuum
• 38. Introduction
• 39. Enterprise Continuum
• 42. Tools for Architecture Development
  • 42.1 Overview

Enterprise Continuum and Tools

• 1. Introduction
  • 1.1 Structure of the TOGAF Document

enterprise focus

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus

Enterprise IT Repository

• 41. Architecture Repository
  • 41.1 Overview

Enterprise Manageability diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Enterprise Manageability Diagram

Enterprise Manageability view

• 35. Architectural Artifacts
  • 35.21 Developing an Enterprise Manageability View

enterprise operating model

• 29. Interoperability Requirements
  • 29.3 Enterprise Operating Model

enterprise portal

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure

enterprise principles

• 23. Architecture Principles
  • 23.1 Introduction

Enterprise Resource Planning system

• A. Glossary of Supplementary Definitions
  • A.31 Enterprise Resource Planning (ERP) System

enterprise scope

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus

Enterprise Security view

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View

entities

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • Map to Business Organization Entities and Policies
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.2 TRM Entities and Interfaces

entity

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective
• A. Glossary of Supplementary Definitions
  • A.22 Data Entity

Entity/Business

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Business Function Matrix

Entity/Data

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Data Component Catalog

environment

• 3. Definitions
  • 3.40 Environment Management
• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Environment Management
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.7 Legal Environment
• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)

environment/access

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

Environment diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Environments and Locations Diagram

environment management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.40 Environment Management

environment(s

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

environments

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Environments and Locations Diagram

ERP

• A. Glossary of Supplementary Definitions
  • A.31 Enterprise Resource Planning (ERP) System

establish

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
    • 6.4.4 Identify and Establish Architecture Principles
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.1 Establish the Architecture Project
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.6 Establish Plans for Enterprise Architecture Management
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.1 Establish Value Realization Process
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

establishing

• 2. Core Concepts
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 46. Establishing an Architecture Capability

estimate

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles

evaluate

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.4 Evaluate Business Capabilities
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources

evaluation

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines

evaluation criteria, tools

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines

event

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Event Diagram
• A. Glossary of Supplementary Definitions
  • A.32 Event

Event diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Event Diagram

events

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

evidence

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

evolution

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.1 Confirm the Enterprise Architecture Evolution Cycle

examine

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.2 Examine Business Transformation Aspects

example

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.2 Importance of SMART Objectives
      • Example of Making Objectives SMART
• 27. Gap Analysis
  • 27.3 Example
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
    • 35.1.1 Simple Example of a Viewpoint and View
  • 35.4 Views and Viewpoints
    • 35.4.1 Example of Views and Viewpoints
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.3 Background to the Example

execution

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.3 Method-Driven Approach to Execution

executive

• 1. Introduction
  • 1.2 Executive Overview

existing

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
    • Determine the relationship of the system under design with existing business disaster/continuity plans
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

experience

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.1 Skills and Experience in Producing Designs
      • 52.6.3.4 Full Project Scope Experience
      • 52.6.3.7 Skills and Experience in One or More Industries

explicit

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture

extended

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise

extending

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.2 Extending the TRM

extension

• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core and Extension Content
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
    • 34.4.2 Services Extensions
    • 34.4.3 Process Modeling Extensions
    • 34.4.4 Data Extensions
    • 34.4.5 Infrastructure Consolidation Extensions
    • 34.4.6 Motivation Extensions

extensive

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

external

• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.1 Reference Materials External to the Enterprise
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.1 Reference Materials External to the Enterprise
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.1 Reference Materials External to the Enterprise
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.1 Reference Materials External to the Enterprise
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.1 Reference Materials External to the Enterprise
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.1 Reference Materials External to the Enterprise
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.1 Reference Materials External to the Enterprise
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.1 Reference Materials External to the Enterprise
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.1 Reference Materials External to the Enterprise
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.1 Reference Materials External to the Enterprise
• 16. Phase H: Architecture Change Management
  • 16.3 Inputs
    • 16.3.1 Reference Materials External to the Enterprise
• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)

External Environment Interface

• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)

f

• 14. Phase F: Migration Planning
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.5 Activities within Phases A to F
• 46. Establishing an Architecture Capability
  • 46.8 Phase F: Migration Planning

factor

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.1 Create an Implementation Factor Assessment and Deduction Matrix
• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment and Deduction Matrix
• 30. Business Transformation Readiness Assessment
  • 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

failure

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states

failure transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

FEAF

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles

features

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Key Features and Functions

Federal Enterprise Architecture Business Reference Model

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

federated architecture

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus

few

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

finalize

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.8 Finalize the Business Architecture
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.8 Finalize the Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.8 Finalize the Application Architecture
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.8 Finalize the Technology Architecture

financial

• 3. Definitions
  • 3.41 Financial Management
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.5 Financial Considerations

financial management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.41 Financial Management

findings

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings

first-order

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify first-order assumptions and boundary conditions

Fitness-for-Purpose

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Checking for Fitness-for-Purpose, and refining if necessary

Five-Tier

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Five-Tier

flexibility

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.6 DAIs Enable Flexibility

flow

• 3. Definitions
  • 3.23 Boundaryless Information Flow
• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Process Flow Diagram
  • 35.20 Developing a Data Flow View
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.1 Problem Space: The Need for Boundaryless Information Flow

focus

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Focus on Holistic Enterprise Change

footnotes

• 1. Introduction
  • 1.2 Executive Overview
    • Footnotes
• 5. Introduction
  • 5.7 Summary
    • Footnotes
• 6. Preliminary Phase
  • 6.5 Outputs
    • Footnotes
• 17. ADM Architecture Requirements Management
  • 17.5 Outputs
    • Footnotes
• 29. Interoperability Requirements
  • 29.7 Summary
    • Footnotes
• 30. Business Transformation Readiness Assessment
  • 30.7 Conclusion
    • Footnotes
• 34. Content Metamodel
  • 34.7 Metamodel Relationships
    • Footnotes
• 35. Architectural Artifacts
  • 35.22 Developing an Acquirer View
    • 35.22.3 Key Issues
      • Footnotes
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.8 Building Block Re-Use Level
      • Footnotes
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.7 Content Aggregation and Integration
      • Footnotes
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.5 Qualities
      • Footnotes
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.2 Elements of an Effective Architecture Governance Strategy
      • Footnotes
• 51. Architecture Maturity Models
  • 51.5 Conclusions
    • Footnotes

footprint

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Footprint Diagram

forensic

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document appropriate security forensic processes
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

formal

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.7 Conduct Formal Stakeholder Review
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.7 Conduct Formal Stakeholder Review
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.7 Conduct Formal Stakeholder Review
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.7 Conduct Formal Stakeholder Review

formal stakeholder review

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.7 Conduct Formal Stakeholder Review
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.7 Conduct Formal Stakeholder Review
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.7 Conduct Formal Stakeholder Review
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.7 Conduct Formal Stakeholder Review

formulate

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy

FORTRAN

• A. Glossary of Supplementary Definitions
  • A.34 FORTRAN

forum

• Frontmatter
  • Participants
    • Architecture Forum Technical Reviewers
    • Architecture Forum Members

foundation

• 3. Definitions
  • 3.42 Foundation Architecture
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.2 The ADM and the Foundation Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.5 Assess Foundation Dependencies and Interim Capabilities
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Foundation Architecture
    • 39.4.2 Solutions Continuum
      • Foundation Solutions
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.1 Role of the TRM in the Foundation Architecture

Foundation Architecture

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 3. Definitions
  • 3.42 Foundation Architecture
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Foundation Architecture
• 43. Foundation Architecture: Technical Reference Model

Foundation Solutions

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum
      • Foundation Solutions

framework

• 1. Introduction
  • 1.2 Executive Overview
    • What is an architecture framework?
    • Why do I need TOGAF as a framework for enterprise architecture?
• 2. Core Concepts
  • 2.10 Using TOGAF with Other Frameworks
• 3. Definitions
  • 3.14 Architecture Framework
  • 3.43 Framework
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Content Framework
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.5 Management Frameworks
    • 6.2.6 Relating the Management Frameworks
  • 6.4 Steps
    • 6.4.2 Confirm Governance and Support Frameworks
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 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

framework(s

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)

frontmatter

• Frontmatter

full

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.3 Full Content Metamodel
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.3 Full Lifecycle Support
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.4 Full Project Scope Experience

full content metamodel

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.3 Full Content Metamodel

function

• 3. Definitions
  • 3.27 Business Function
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Business Function Matrix
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.3 Contract between Architecting Function and Business Users

functional

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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

functional decomposition

• A. Glossary of Supplementary Definitions
  • A.35 Functional Decomposition

Functional Decomposition diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Functional Decomposition Diagram

functionality

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.5 Identifying Building Block Requirements and Constraints
      • 37.4.5.1 Assumptions of Required Technical Functionality
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.1 Functionality

functions

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Key Features and Functions

future

• 21. Security Architecture and the ADM
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.4 Future Developments

g

• 15. Phase G: Implementation Governance
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.6 Activities within Phases G and H
• 46. Establishing an Architecture Capability
  • 46.9 Phase G: Implementation Governance

gap

• 3. Definitions
  • 3.44 Gap
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.4 Perform Gap Analysis
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.4 Perform Gap Analysis
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.4 Perform Gap Analysis
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.4 Perform Gap Analysis
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

gap analysis

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.4 Perform Gap Analysis
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.4 Perform Gap Analysis
• 27. Gap Analysis

gaps

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, and Dependencies Matrix

gateway

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Distributed Heterogeneous DBMSs

gathering

• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.2 Gathering

general

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.1 General
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.1 General
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.1 General
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.1 General Guidelines
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.1 General Guidelines
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.2 General Pointers
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.1 General
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.1 General
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.5 IT General Knowledge Skills

generate

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

generic

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.4 Security Generic Architecture View
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.2 Generic Characteristics
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.2 Nature of Governance
      • 50.1.2.1 Governance: A Generic Perspective
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.1 Generic Skills
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.1 Generic Role

global transaction

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.9 Transaction Processing Services

glossary

• A. Glossary of Supplementary Definitions

go

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine "what can go wrong?"
  • 21.8 Phase C: Information Systems Architectures
    • Determine "what can go wrong?"
  • 21.9 Phase D: Technology Architecture
    • Determine "what can go wrong?"
  • 21.10 Phase E: Opportunities & Solutions
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Determine "what can go wrong?"

goal

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 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
• A. Glossary of Supplementary Definitions
  • A.36 Goal

Goal/Objective/Service

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Goal/Objective/Service Diagram

Goal/Objective/Service diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Goal/Objective/Service Diagram

goals

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess alignment or conflict of identified security policies with business goals
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.1 Importance of Goals
    • 26.9.3 Categories of Goals and Objectives

Goals/Rationale

• 52. Architecture Skills Framework
  • 52.3 Goals/Rationale

goes

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"

gone

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"

good

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Is our security good?
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use

GOTS

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles

govern

• 22. Using TOGAF to Define & Govern SOAs

governance

• 3. Definitions
  • 3.15 Architecture Governance
  • 3.28 Business Governance
  • 3.45 Governance
• 5. Introduction
  • 5.4 Architecture Governance
• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.2 Confirm Governance and Support Frameworks
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.3 Data Governance
• 15. Phase G: Implementation Governance
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.6 Manage Governance Process
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.15 Implementation Governance Model
• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

governance, characteristics

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.2 Nature of Governance
      • 50.1.2.2 Characteristics of Governance

governance contract

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract

governance extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions

Governance Log

• 2. Core Concepts
  • 2.7 Architecture Repository
• 41. Architecture Repository
  • 41.1 Overview
  • 41.5 Governance Log

Governance Log, contents of

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

granularity

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts

graphic

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.3 Graphics and Imaging Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.2 High-Level View
    • 44.2.2 High-Level III-RM Graphic
  • 44.3 Detailed Taxonomy
    • 44.3.1 Detailed III-RM Graphic

graphics services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.3 Graphics and Imaging Services

greater

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • Greater Usability

group

• 4. Release Notes
  • 4.6 Why Join The Open Group?
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.2 Group Portfolios and Projects into Increments
• Frontmatter
  • About The Open Group
    • The Open Group

guidance

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise
• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)

guide

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.3 Guide Development of Solutions Deployment

guideline

• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign
• 18. Introduction
  • 18.1 Guidelines for Adapting the ADM Process
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.1 General Guidelines

guidelines, for adapting the ADM

• 18. Introduction
  • 18.1 Guidelines for Adapting the ADM Process

h

• 16. Phase H: Architecture Change Management
• 21. Security Architecture and the ADM
  • 21.13 Phase H: Architecture Change Management
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.6 Activities within Phases G and H
• 46. Establishing an Architecture Capability
  • 46.10 Phase H: Architecture Change Management

hardware

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.1 Hardware and Operating System Checklist
• A. Glossary of Supplementary Definitions
  • A.38 Hardware

has

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"

HCI

• A. Glossary of Supplementary Definitions
  • A.39 Human Computer Interface (HCI)

heterogeneous

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Distributed Heterogeneous DBMSs

hierarchic

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.2 Master/Slave and Hierarchic Models

hierarchic model

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.2 Master/Slave and Hierarchic Models

hierarchy

• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.2 Using a Hierarchy of ADM Processes
• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Class Hierarchy Diagram

High-Level

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
• 44. Integrated Information Infrastructure Reference Model
  • 44.2 High-Level View
    • 44.2.2 High-Level III-RM Graphic
    • 44.2.3 Components of the High-Level III-RM

Hillside Group

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources

holistic

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Focus on Holistic Enterprise Change

hosting

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.4 Hosting, Data Types, and Sharing

how

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.2 How Much Does TOGAF Cost?
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 How Enterprise Architecture Supports SOA

human

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Human Actors and their Place in the Business Model
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.4 Human Interaction Services
• A. Glossary of Supplementary Definitions
  • A.39 Human Computer Interface (HCI)

human computer interface

• A. Glossary of Supplementary Definitions
  • A.39 Human Computer Interface (HCI)

human interaction services

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.4 Human Interaction Services

i

• 1. Introduction
  • 1.2 Executive Overview
    • Why do I need an enterprise architecture?
    • Why do I need TOGAF as a framework for enterprise architecture?
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part I: Introduction

IBM

• 25. Architecture Patterns
  • 25.3 IBM Patterns for e-Business

IBM patterns web site

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.4 Architecture Patterns in Use
  • 25.3 IBM Patterns for e-Business

ICAM

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

ICD

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability

IDEF

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

identification

• 31. Risk Management
  • 31.3 Risk Identification
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.7 Opportunity Identification

identified

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess alignment or conflict of identified security policies with business goals
  • 21.8 Phase C: Information Systems Architectures
    • Determine approaches to address identified risks:
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks

identify

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.4 Identify and Establish Architecture Principles
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.1 Identify Major Work Packages

identifying

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 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
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.4 Identifying Building Block Scope
    • 37.4.5 Identifying Building Block Requirements and Constraints

idiom

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.1 Architecture Patterns and Design Patterns

IDL

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus

IEEE 1003.0

• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.3 Other TRMs

if

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Checking for Fitness-for-Purpose, and refining if necessary

II

• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part II: Architecture Development Method

III

• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part III: Enterprise Continuum

III-RM

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Common Systems Architectures
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 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

III-RM graphic

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.2 Components of the Model

III-RM, taxonomy

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy

imaging

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.3 Graphics and Imaging Services

imaging services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.3 Graphics and Imaging Services

impact

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.18 Requirements Impact Assessment

impacted

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted

impacts

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.6 Resolve Impacts Across the Architecture Landscape
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.6 Resolve Impacts Across the Architecture Landscape
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.6 Resolve Impacts Across the Architecture Landscape
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.6 Resolve Impacts Across the Architecture Landscape

implement

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.6 Implement Architecture Tools
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.5 Implement Business and IT Operations
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.7 Activate the Process to Implement Change
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Implement disaster recovery and business continuity plans or modifications
  • 21.12 Phase G: Implementation Governance
    • 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

implementation

• 9. Phase C: Information Systems Architectures
  • 9.2 Approach
    • 9.2.2 Implementation
• 13. Phase E: Opportunities & Solutions
  • 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.2 Determine Business Constraints for Implementation
    • 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

Implementation and Migration Plan

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.14 Implementation and Migration Plan

implementation governance

• 15. Phase G: Implementation Governance

Implementation Governance Model

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.15 Implementation Governance Model

importance

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.1 Importance of Goals
    • 26.9.2 Importance of SMART Objectives

improve

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Business Process Performance
      • Goal: Improve Business Operations
      • Goal: Improve Management Efficacy
      • Goal: Improve Effectiveness of IT Organization
      • Goal: Improve User Productivity
      • Goal: Improve Portability and Scalability
      • Goal: Improve Interoperability
      • Goal: Improve Security
      • Goal: Improve Manageability

IMS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

in

• 2. Core Concepts
  • 2.2 What is Architecture in the Context of TOGAF?
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.4 Architecture Patterns in Use
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model
• 32. Capability-Based Planning
  • 32.4 Capabilities in an Enterprise Architecture Context
• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
  • 35.4 Views and Viewpoints
    • 35.4.2 Views and Viewpoints in Enterprise Architecture
  • 35.7 Viewpoints in the Preliminary Phase
  • 35.8 Viewpoints in Phase A
  • 35.9 Viewpoints in Phase B
  • 35.10 Viewpoints in the Phase C Data Architecture
  • 35.11 Viewpoints in the Phase C Application Architecture
  • 35.12 Viewpoints in Phase D
  • 35.13 Viewpoints in Phase E
• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.1 Basic Principles
      • 37.3.1.1 Building Blocks in Architecture Design
    • 37.3.2 Building Block Specification Process in the ADM
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
• 42. Tools for Architecture Development
  • 42.2 Issues in Tool Standardization
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.1 Role of the TRM in the Foundation Architecture
  • 43.3 TRM in Detail
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 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.7 Skills and Experience in One or More Industries

including

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles

inconvenience

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures

incorporate

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.4 Incorporate Project Schedules
• 21. Security Architecture and the ADM
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

increase

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Increase Vendor Independence

increment

• 3. Definitions
  • 3.32 Capability Increment
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.3 Determine Transition Architecture/Project Increment Timings

incremental change

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process

increments

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 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.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.2 Confirm Business Value Delivered by the Increments
• 28. Migration Planning Techniques
  • 28.3 Architecture Definition Increments Table
• 32. Capability-Based Planning
  • 32.3 Concept of Capability-Based Planning
    • 32.3.2 Capability Increments

Increments/Phases

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document

independence

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Increase Vendor Independence

indicator

• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

industries

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.7 Skills and Experience in One or More Industries

industry

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Industry Architectures
    • 39.4.2 Solutions Continuum
      • Industry Solutions

Industry Architectures

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Industry Architectures

Industry Solutions

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum
      • Industry Solutions

information

• 3. Definitions
  • 3.23 Boundaryless Information Flow
  • 3.46 Information
  • 3.47 Information Technology (IT)
  • 3.81 Standards Information Base (SIB)
• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.2 Assess Information Dependencies
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used
    • Identify lifespan of information used as defined by business needs and regulatory requirements

information consumer applications

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.3 Information Consumer Applications

information domains

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.1 Information Domains
• A. Glossary of Supplementary Definitions
  • A.40 Information Domain

information exchange matrix

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

Information-Intensive

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems

information-intensive software

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems

information provider applications

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.1 Information Provider Applications

information system

• A. Glossary of Supplementary Definitions
  • A.41 Information System (IS)

Information Systems Architecture

• 9. Phase C: Information Systems Architectures

information system service

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF
• A. Glossary of Supplementary Definitions
  • A.42 Information System Service

information technology

• 3. Definitions
  • 3.47 Information Technology (IT)

infrastructure

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.1 Determine Personnel and Infrastructure (Capital) Costs
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.5 Infrastructure Consolidation Extensions
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • 35.19.2.1 Communications Infrastructure
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
      • 43.3.3.2 Infrastructure Applications
    • 43.3.5 Communications Infrastructure
    • 43.3.7 Communications Infrastructure Interface
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications

infrastructure applications

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.3 Application Software
      • 43.3.3.2 Infrastructure Applications

infrastructure bus

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.8 Infrastructure Bus

infrastructure consolidation extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.5 Infrastructure Consolidation Extensions

infrastructure services

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

inheritance

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use

initial

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations
• 31. Risk Management
  • 31.4 Initial Risk Assessment
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 1: Initial

initial risk assessment

• 31. Risk Management
  • 31.4 Initial Risk Assessment

inputs

• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.2 Non-Architectural Inputs
    • 6.3.3 Architectural Inputs

installation

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations

instantiation

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI

integrated

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure

integrated information infrastructure

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure

integration

• 5. Introduction
  • 5.6 Architecture Integration
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.2 Determine Issues Associated with Functional Integration
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.7 Content Aggregation and Integration
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.3 Applications Checklists
      • 48.5.3.3 Application Integration Approach
• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)

intended

• Frontmatter
  • Preface
    • Intended Audience

interact

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process

interaction

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Interaction Matrix
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application Interaction Matrix
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.4 Human Interaction Services
• A. Glossary of Supplementary Definitions
  • A.43 Interaction
  • A.44 Interaction Model

interaction model

• A. Glossary of Supplementary Definitions
  • A.44 Interaction Model

interactions

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan

interchange

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.1 Data Interchange Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.5 Data Interchange Services
• A. Glossary of Supplementary Definitions
  • A.23 Data Interchange Service

interconnecting

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify and document interconnecting systems beyond project control
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control

interface

• 3. Definitions
  • 3.7 Application Platform Interface (API)
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Interface Catalog
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.6 Application Platform Interface
    • 43.3.7 Communications Infrastructure Interface
  • 43.5 Detailed Platform Taxonomy
    • 43.5.10 User Interface Services
• A. Glossary of Supplementary Definitions
  • A.33 External Environment Interface (EEI)
  • A.39 Human Computer Interface (HCI)
  • A.45 Interface
  • A.93 User Interface Service

Interface catalog

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Interface Catalog

interfaces

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.2 TRM Entities and Interfaces
    • 43.3.4 Application Platform
      • 43.3.4.3 Interfaces Between Services

interim

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.5 Assess Foundation Dependencies and Interim Capabilities

internal

• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.2 Basis of an Internal Architecture Practice

international

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.4 International Operation Services

international operation services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.4 International Operation Services

interoperability

• 3. Definitions
  • 3.48 Interoperability
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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

interoperability, categories

• 29. Interoperability Requirements
  • 29.2 Defining Interoperability

interoperability, refining

• 29. Interoperability Requirements
  • 29.4 Refining Interoperability

interoperability, requirements

• 29. Interoperability Requirements

interoperable

• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description

into

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.2 Group Portfolios and Projects into Increments
• 21. Security Architecture and the ADM
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

Intuitiveness/Ease-of-Use

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Intuitiveness/Ease-of-Use Factors

investment

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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

IPD-CMM

• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

is

• 1. Introduction
  • 1.2 Executive Overview
    • What is an enterprise? What is enterprise architecture?
    • What is an architecture framework?
• 2. Core Concepts
  • 2.1 What is TOGAF?
  • 2.2 What is Architecture in the Context of TOGAF?
• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Is our security good?
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
• A. Glossary of Supplementary Definitions
  • A.41 Information System (IS)

ISACF

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT

ISAM

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

ISO

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

ISO/IEC 42010:2007

• 2. Core Concepts
  • 2.2 What is Architecture in the Context of TOGAF?

isolation

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.2 Strict Isolation

issues

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.2 Determine Issues Associated with Functional Integration
• 35. Architectural Artifacts
  • 35.15 Developing a Business Architecture View
    • 35.15.3 Key Issues
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
  • 35.21 Developing an Enterprise Manageability View
    • 35.21.3 Key Issues
  • 35.22 Developing an Acquirer View
    • 35.22.3 Key Issues
• 42. Tools for Architecture Development
  • 42.2 Issues in Tool Standardization

IT

• 3. Definitions
  • 3.47 Information Technology (IT)
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.3 Assess Transition Capabilities of the Enterprise and IT Organization
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.1 Assess the IT Requirements from a Functional Perspective

iteration

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
  • 19.4 Mapping TOGAF Phases to Iteration Cycles

iteration cycles

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles

iteration of the ADM

• 19. Applying Iteration to the ADM

iterations

• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.1 Using Iterations within a Single ADM Cycle

IT governance

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise
    • 50.1.4 IT Governance

IT Governance Institute

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT

ITIL

• 5. Introduction
  • 5.4 Architecture Governance
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process
• A. Glossary of Supplementary Definitions
  • A.46 ITIL

IT principles

• 23. Architecture Principles
  • 23.1 Introduction

its

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.12 Phase G: Implementation Governance
    • 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

IV

• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part IV: Resource Base
• 33. Introduction
  • 33.4 Structure of Part IV

Java

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles

join

• 4. Release Notes
  • 4.6 Why Join The Open Group?

justified

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
  • 21.9 Phase D: Technology Architecture
    • Identify mitigating security measures, where justified by risk assessment

JVM

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Three-Tier

key

• 5. Introduction
  • 5.2 Architecture Development Cycle
    • 5.2.1 Key Points
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
• 35. Architectural Artifacts
  • 35.15 Developing a Business Architecture View
    • 35.15.3 Key Issues
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
  • 35.21 Developing an Enterprise Manageability View
    • 35.21.3 Key Issues
  • 35.22 Developing an Acquirer View
    • 35.22.3 Key Issues
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Key Features and Functions
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
• 50. 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
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.2 Key Areas
  • 50.3 Architecture Governance in Practice
    • 50.3.1 Architecture Governance - Key Success Factors
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

Key Performance Indicator

• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

keywords

• Frontmatter
  • Preface
    • Keywords

kind

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?

knowledge

• 3. Definitions
  • 3.49 Knowledge
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.5 IT General Knowledge Skills

KPI

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs
• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

landscape

• 3. Definitions
  • 3.16 Architecture Landscape
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.6 Resolve Impacts Across the Architecture Landscape
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.6 Resolve Impacts Across the Architecture Landscape
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.6 Resolve Impacts Across the Architecture Landscape
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.6 Resolve Impacts Across the Architecture Landscape
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.1 Partitioning the Architecture Landscape to Understand the State of the Enterprise
• 41. Architecture Repository
  • 41.2 Architecture Landscape

language

• 35. Architectural Artifacts
  • 35.3 Views, Tools, and Languages
  • 35.4 Views and Viewpoints
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description

later

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

LCS

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.4 Security Generic Architecture View

leadership

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.5 Leadership

learned

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.3 Document Lessons Learned

legal

• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.7 Legal Environment

legitimate

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process

lessons

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.3 Document Lessons Learned

lessons learned process

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.1 Drivers for Change

level

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used
  • 21.9 Phase D: Technology Architecture
    • Identify the trust (clearance) level of:
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.8 Building Block Re-Use Level
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 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

level of abstraction

• 40. Architecture Partitioning
  • 40.3 Characteristics of Architectures

level of detail

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Vertical Scope/Level of Detail

levels

• 20. Applying the ADM at Different Enterprise Levels
  • 20.3 Developing Architectures at Different Levels

leveraged

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems

libraries

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Libraries

library

• 41. Architecture Repository
  • 41.3 Reference Library

lifecycle

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Lifecycle Management
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Reduce Lifecycle Costs
• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Product Lifecycle Diagram
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Lifecycle Diagram
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.3 Full Lifecycle Support
• A. Glossary of Supplementary Definitions
  • A.48 Lifecycle

lifespan

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements

Line-of-Business

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.3 Review Corporate Line-of-Business Strategic Plans

local subscriber environment

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts

location

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Location Catalog
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application and User Location Diagram
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.5 Location and Directory Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.3 Location and Directory Services
• A. Glossary of Supplementary Definitions
  • A.49 Location

Location catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Location Catalog

Location diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Environments and Locations Diagram

locations

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Environments and Locations Diagram

location services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.5 Location and Directory Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.3 Location and Directory Services

location transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

log

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

logged

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

logging

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

logical

• 3. Definitions
  • 3.50 Logical
• A. Glossary of Supplementary Definitions
  • A.50 Logical Application Component
  • A.51 Logical Data Component
  • A.52 Logical Technology Component

logical application component

• A. Glossary of Supplementary Definitions
  • A.50 Logical Application Component

logical data component

• A. Glossary of Supplementary Definitions
  • A.51 Logical Data Component

logical technology component

• A. Glossary of Supplementary Definitions
  • A.52 Logical Technology Component

loss/impact

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

maintaining

• 2. Core Concepts
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability

maintenance

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.2 Determine Operations and Maintenance Costs
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign

major

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.1 Identify Major Work Packages

making

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.2 Importance of SMART Objectives
      • Example of Making Objectives SMART

manage

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.3 Manage Risks
    • 16.4.6 Manage Governance Process

manageability

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Manageability
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Enterprise Manageability Diagram
  • 35.21 Developing an Enterprise Manageability View
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.8 Qualities

managed

• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 4: Managed

management

• 3. Definitions
  • 3.33 Communications and Stakeholder Management
  • 3.40 Environment Management
  • 3.41 Financial Management
  • 3.60 Performance Management
  • 3.65 Quality Management
  • 3.69 Resource Management
  • 3.73 Service Management
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.5 Management Frameworks
    • 6.2.6 Relating the Management Frameworks
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.1 Data Management
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 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

management frameworks

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

management utilities

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications

manager

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Quality of Service Manager Utilities

managing

• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)

Managing Successful Programs

• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)

mandated

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • Mandated Building Blocks

map

• 24. Stakeholder Management
  • 24.4 Template Stakeholder Map
• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Stakeholder Map Matrix
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • Map to Business Organization Entities and Policies

mapping

• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
  • 4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1
• 19. Applying Iteration to the ADM
  • 19.4 Mapping TOGAF Phases to Iteration Cycles

marketing

• 30. Business Transformation Readiness Assessment
  • 30.6 Marketing the Implementation Plan

Master/Slave

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.2 Master/Slave and Hierarchic Models

master/slave model

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.2 Master/Slave and Hierarchic Models

materials

• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.1 Reference Materials External to the Enterprise
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.1 Reference Materials External to the Enterprise
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.1 Reference Materials External to the Enterprise
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.1 Reference Materials External to the Enterprise
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.1 Reference Materials External to the Enterprise
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.1 Reference Materials External to the Enterprise
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.1 Reference Materials External to the Enterprise
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.1 Reference Materials External to the Enterprise
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.1 Reference Materials External to the Enterprise
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.1 Reference Materials External to the Enterprise
• 16. Phase H: Architecture Change Management
  • 16.3 Inputs
    • 16.3.1 Reference Materials External to the Enterprise

matrices

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.4 Identify Required Matrices
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.3 Identify Required Matrices
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.3 Identify Required Matrices
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.3 Identify Required Matrices
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints

matrix

• 13. Phase E: Opportunities & Solutions
  • 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.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.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment and Deduction Matrix
  • 28.2 Consolidated Gaps, Solutions, and Dependencies Matrix
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Catalog, Matrix, and Diagram Concept
• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Stakeholder Map Matrix
  • 35.9 Viewpoints in Phase B
    • Business Interaction Matrix
    • Actor/Role Matrix
  • 35.10 Viewpoints in the Phase C Data Architecture
    • Data Entity/Business Function Matrix
    • System/Data Matrix
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System/Organization Matrix
    • Role/System Matrix
    • System/Function Matrix
    • Application Interaction Matrix
  • 35.12 Viewpoints in Phase D
    • System/Technology Matrix
• A. Glossary of Supplementary Definitions
  • A.54 Matrix

maturity

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.2 Review the Enterprise Architecture Maturity Assessment
• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
  • 51.4 Capability Maturity Models Integration (CMMI)

maturity model

• 30. Business Transformation Readiness Assessment
  • 30.3 Present Readiness Factors
• 51. Architecture Maturity Models

MDA

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools

me

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?

meaning

• 48. Architecture Compliance
  • 48.2 Terminology: The Meaning of Architecture Compliance

measure

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
• A. Glossary of Supplementary Definitions
  • A.55 Measure

measured

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

measurement

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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

measures

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Identify mitigating security measures, where justified by risk assessment
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks
  • 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
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts

mediator

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability

meet

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets

meeting

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Minutes of Previous Meeting
      • Schedule of Meetings

members

• Frontmatter
  • Participants
    • Architecture Forum Members

metadata

• 3. Definitions
  • 3.51 Metadata
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Metadata

metamodel

• 3. Definitions
  • 3.52 Metamodel
• 33. Introduction
  • 33.2 Content Metamodel
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities

metamodel relationships

• 34. Content Metamodel
  • 34.7 Metamodel Relationships

metaview

• A. Glossary of Supplementary Definitions
  • A.56 Metaview

method

• 2. Core Concepts
  • 2.4 Architecture Development Method
• 3. Definitions
  • 3.12 Architecture Development Method (ADM)
  • 3.53 Method
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part II: Architecture Development Method
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.6 Access Method
• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.2 SCAMPI Method

Method-Driven

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.3 Method-Driven Approach to Execution

methodology

• 3. Definitions
  • 3.54 Methodology

methods

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify methods to regulate consumption of resources
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.2 Business Skills & Methods

middleware

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.2 Software Services and Middleware Checklist

migration

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.1 Key Considerations for Data Architecture
      • 10.2.1.2 Data Migration
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
• 14. Phase F: Migration Planning
  • 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.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

Migration Planning

• 14. Phase F: Migration Planning
• 30. Business Transformation Readiness Assessment
  • 30.5 Readiness and Migration Planning

migration transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

milestones

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle

minimal

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective

minutes

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Minutes of Previous Meeting

mitigating

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify mitigating security measures, where justified by risk assessment

mitigation

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks
• 31. Risk Management
  • 31.5 Risk Mitigation and Residual Risk Assessment

model

• 2. Core Concepts
  • 2.11 TOGAF Document Categorization Model
• 3. Definitions
  • 3.55 Model
  • 3.56 Modeling
  • 3.66 Reference Model (RM)
  • 3.85 Technical Reference Model (TRM)
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model
• 29. Interoperability Requirements
  • 29.3 Enterprise Operating Model
• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.1 Client/Server Model
      • 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.2 Key Issues
      • The OSI Reference Model
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.15 Implementation Governance Model
    • 36.2.16 Organizational Model for Enterprise Architecture
• 43. Foundation Architecture: Technical Reference Model
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.2 Components of the Model

Model Driven Architecture

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools

modeling

• 3. Definitions
  • 3.56 Modeling
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.3 Process Modeling Extensions
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Business Modeling Tools
      • Design Modeling Tools
      • Data Modeling Tools

models

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
  • 26.8 Guidelines on Business Scenario Documentation
    • 26.8.2 Business Scenario Models
• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.2 Master/Slave and Hierarchic Models
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • 35.19.2.2 Communications Models
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use
• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)

modifications

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Implement disaster recovery and business continuity plans or modifications

modular

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Modular Structure

modularity

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use

monitoring

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.2 Deploy Monitoring Tools
• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Monitoring and Reporting

more

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Focus on Holistic Enterprise Change
    • More Consistency of Output
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.7 Skills and Experience in One or More Industries

motivation

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.6 Motivation Extensions

motivation extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.6 Motivation Extensions

MSP

• 36. Architecture Deliverables
  • 36.1 Introduction
• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)

much

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.2 How Much Does TOGAF Cost?
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

multimedia

• A. Glossary of Supplementary Definitions
  • A.57 Multimedia Service

multimedia service

• A. Glossary of Supplementary Definitions
  • A.57 Multimedia Service

must

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

nature

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.2 Nature of Governance

necessary

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle
  • 21.12 Phase G: Implementation Governance
    • 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
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Checking for Fitness-for-Purpose, and refining if necessary

need

• 1. Introduction
  • 1.2 Executive Overview
    • Why do I need an enterprise architecture?
    • Why do I need TOGAF as a framework for enterprise architecture?
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements
• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 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
• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework

network

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.2 Network Services
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.6 Network Services
    • 43.5.12 System and Network Management Services
• A. Glossary of Supplementary Definitions
  • A.11 Communications Network
  • A.85 System and Network Management Service

networked

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Networked Computing/Hardware Diagram

Networked Computing/Hardware diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Networked Computing/Hardware Diagram

network management services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.12 System and Network Management Services

network services

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.2 Network Services
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.6 Network Services

new

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Identify new code/resources/assets that are appropriate for re-use
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems

node

• A. Glossary of Supplementary Definitions
  • A.12 Communications Node

node connectivity diagram

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

Non-Architectural

• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.2 Non-Architectural Inputs
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.2 Non-Architectural Inputs
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.2 Non-Architectural Inputs
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.2 Non-Architectural Inputs
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.2 Non-Architectural Inputs
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.2 Non-Architectural Inputs
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.2 Non-Architectural Inputs
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.2 Non-Architectural Inputs
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.2 Non-Architectural Inputs
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.2 Non-Architectural Inputs
• 16. Phase H: Architecture Change Management
  • 16.3 Inputs
    • 16.3.2 Non-Architectural Inputs

none

• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 0: None

non-privileged

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

non-repudiation

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

notes

• 4. Release Notes

nothing

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

OA&M

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Operations, Administration, and Management (OA&M) Utilities

OAG

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

OASIS

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository

object

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model

objective

• 3. Definitions
  • 3.57 Objective
• 6. Preliminary Phase
  • 6.1 Objectives
• 7. Phase A: Architecture Vision
  • 7.1 Objectives
• 8. Phase B: Business Architecture
  • 8.1 Objectives
• 9. Phase C: Information Systems Architectures
  • 9.1 Objectives
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.1 Objectives
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.1 Objectives
• 12. Phase D: Technology Architecture
  • 12.1 Objectives
• 13. Phase E: Opportunities & Solutions
  • 13.1 Objectives
• 14. Phase F: Migration Planning
  • 14.1 Objectives
• 15. Phase G: Implementation Governance
  • 15.1 Objectives
• 16. Phase H: Architecture Change Management
  • 16.1 Objectives
• 17. ADM Architecture Requirements Management
  • 17.1 Objectives
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)
    • Identify minimal privileges required for any entity to achieve a technical or business objective
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying and Documenting Objectives
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.2 Importance of SMART Objectives
      • Example of Making Objectives SMART

object management

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

Object Management Group

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process

Object-Oriented

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

object-oriented services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

objects

• 34. Content Metamodel
  • 34.5 Content Metamodel Objects

Obsolete Standard

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle

obtain

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures

ODBC

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI

OLA

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Compliance Assessments
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Compliance

OLE

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model

OMG

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process

one

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines
      • 52.6.3.7 Skills and Experience in One or More Industries

ongoing

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

OODBMS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

open

• 4. Release Notes
  • 4.6 Why Join The Open Group?
• A. Glossary of Supplementary Definitions
  • A.58 Open Specifications
  • A.59 Open System
• Frontmatter
  • About The Open Group
    • The Open Group

open specifications

• A. Glossary of Supplementary Definitions
  • A.58 Open Specifications

open system

• A. Glossary of Supplementary Definitions
  • A.59 Open System

operating

• 29. Interoperability Requirements
  • 29.3 Enterprise Operating Model
• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.7 Operating System Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.7 Additional Operating System Services
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.1 Hardware and Operating System Checklist
• A. Glossary of Supplementary Definitions
  • A.61 Operating System Service

operating system services

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.7 Operating System Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.7 Additional Operating System Services
• A. Glossary of Supplementary Definitions
  • A.61 Operating System Service

operation

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
  • 21.8 Phase C: Information Systems Architectures
    • Identify the criticality of the availability and correct operation of each function
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.4 International Operation Services
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board

operational

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.3 Operational Benefits
• A. Glossary of Supplementary Definitions
  • A.60 Operational Governance

operational contract

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract

operational governance

• A. Glossary of Supplementary Definitions
  • A.60 Operational Governance

operational-level agreement

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Compliance Assessments
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Compliance

operations

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.5 Align Implementation and Migration Plan with the Operations Management Framework
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.2 Determine Operations and Maintenance Costs
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.5 Implement Business and IT Operations
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Business Operations
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Operations, Administration, and Management (OA&M) Utilities

operations management

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

operators

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

opportunities

• 13. Phase E: Opportunities & Solutions
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
• 46. Establishing an Architecture Capability
  • 46.7 Phase E: Opportunities & Solutions

Opportunities & Solutions

• 13. Phase E: Opportunities & Solutions

opportunity

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.7 Opportunity Identification

opportunity identification

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.7 Opportunity Identification

optimizing

• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 5: Optimizing

ORB

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.4 Distributed Object Management Model
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

ORB services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services

organization

• 3. Definitions
  • 3.58 Organization
• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.3 Assess Transition Capabilities of the Enterprise and IT Organization
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Effectiveness of IT Organization
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Organization Decomposition Diagram
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • Map to Business Organization Entities and Policies
• 39. Enterprise Continuum
  • 39.6 Enterprise Continuum and Your Organization
• A. Glossary of Supplementary Definitions
  • A.62 Organization Unit

Organization/Actor

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Organization/Actor Catalog

Organization/Actor catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Organization/Actor Catalog

organizational

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.2 Organizational Context
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.16 Organizational Model for Enterprise Architecture
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Organizational Compatibility Factors
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.2 Architecture Governance Framework - Organizational Structure

Organizational Model

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.16 Organizational Model for Enterprise Architecture

Organization Decomposition diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Organization Decomposition Diagram

organizations

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.2 Assess Transition Capabilities of Corporate and Partner Organizations

Organization-Specific

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Organization-Specific Architectures
    • 39.4.2 Solutions Continuum
      • Organization-Specific Solutions

Organization-Specific Architectures

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Organization-Specific Architectures

Organization-Specific Solutions

• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum
      • Organization-Specific Solutions

organization unit

• A. Glossary of Supplementary Definitions
  • A.62 Organization Unit

orientation

• 3. Definitions
  • 3.74 Service Orientation

oriented

• 3. Definitions
  • 3.75 Service Oriented Architecture (SOA)

OSI

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • The OSI Reference Model

OSI Reference Model

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • The OSI Reference Model

our

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Is our security good?

output

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • More Consistency of Output
• 6. Preliminary Phase
  • 6.5 Outputs
• 7. Phase A: Architecture Vision
  • 7.5 Outputs
• 8. Phase B: Business Architecture
  • 8.5 Outputs
• 9. Phase C: Information Systems Architectures
  • 9.5 Outputs
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.5 Outputs
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.5 Outputs
• 12. Phase D: Technology Architecture
  • 12.5 Outputs
• 13. Phase E: Opportunities & Solutions
  • 13.5 Outputs
• 14. Phase F: Migration Planning
  • 14.5 Outputs
• 15. Phase G: Implementation Governance
  • 15.5 Outputs
• 16. Phase H: Architecture Change Management
  • 16.5 Outputs
• 17. ADM Architecture Requirements Management
  • 17.5 Outputs
• 21. Security Architecture and the ADM
  • 21.5.2 Security Outputs

  • 21.6.2 Security Outputs

  • 21.7.2 Security Outputs

  • 21.8.2 Security Outputs

  • 21.9.2 Security Outputs

outside

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

overall

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
      • 13.4.8.1 Determine Overall Strategic Implementation Direction
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.4 Conduct Overall Architecture Updates
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.1 Overall Process

overview

• 1. Introduction
  • 1.2 Executive Overview
• 5. Introduction
  • 5.1 ADM Overview
• 19. Applying Iteration to the ADM
  • 19.1 Overview
• 20. Applying the ADM at Different Enterprise Levels
  • 20.1 Overview
• 21. Security Architecture and the ADM
  • 21.1 Overview
• 22. Using TOGAF to Define & Govern SOAs
  • 22.1 Overview
• 29. Interoperability Requirements
  • 29.1 Overview
• 32. Capability-Based Planning
  • 32.1 Overview
• 33. Introduction
  • 33.1 Overview
• 34. Content Metamodel
  • 34.1 Overview
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.2 Overview of the Content Metamodel
• 35. Architectural Artifacts
  • 35.3 Views, Tools, and Languages
    • 35.3.1 Overview
• 37. Building Blocks
  • 37.1 Overview
  • 37.2 Introduction to Building Blocks
    • 37.2.1 Overview
• 39. Enterprise Continuum
  • 39.1 Overview
• 40. Architecture Partitioning
  • 40.1 Overview
• 41. Architecture Repository
  • 41.1 Overview
  • 41.3 Reference Library
    • 41.3.1 Overview
  • 41.4 Standards Information Base
    • 41.4.1 Overview
  • 41.5 Governance Log
    • 41.5.1 Overview
• 42. Tools for Architecture Development
  • 42.1 Overview
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.1 Overview
• 45. Introduction
  • 45.1 Overview
• 46. Establishing an Architecture Capability
  • 46.1 Overview
• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
    • 48.4.1 Overview
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.5 Architecture Governance: Overview
  • 50.2 Architecture Governance Framework
    • 50.2.2 Architecture Governance Framework - Organizational Structure
      • 50.2.2.1 Overview
• 51. Architecture Maturity Models
  • 51.1 Overview
  • 51.3 US DoC ACMM Framework
    • 51.3.1 Overview
• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.1 Overview

ownership

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify and document the ownership of assets

package

• 3. Definitions
  • 3.90 Work Package

packaged

• A. Glossary of Supplementary Definitions
  • A.63 Packaged Services

packaged services

• A. Glossary of Supplementary Definitions
  • A.63 Packaged Services

packages

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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

paradigm

• 32. Capability-Based Planning
  • 32.2 Capability-Based Planning Paradigm

parameters

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations

part

• 4. Release Notes
  • 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
• 33. Introduction
  • 33.4 Structure of Part IV
• 38. Introduction
  • 38.2 Structure of Part V
• 45. Introduction
  • 45.2 Structure of Part VII

participants

• Frontmatter
  • Participants

partitioned

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures

partitioning

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise
• 40. Architecture Partitioning
  • 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

partner

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 13.4.1.2 Assess Transition Capabilities of Corporate and Partner Organizations
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.2 Contract between Architecture Design and Development Partners

parts

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.3 Relationship to Other parts of TOGAF

pattern

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.2 Content of a Pattern
  • 25.2 US Treasury Architecture Development Guidance (TADG)
    • 25.2.1 TADG Pattern Content
  • 25.4 Some Pattern Resources

pattern resources

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources

patterns

• 3. Definitions
  • 3.59 Patterns
• 25. Architecture Patterns
  • 25.1 Introduction
    • 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.2 TADG Architecture Patterns
  • 25.3 IBM Patterns for e-Business

patterns-discussion FAQ

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources

patterns home page

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources

P-CMM

• 51. Architecture Maturity Models
  • 51.2 Background
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

Peer-to-Peer

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.3 Peer-to-Peer Model

peer-to-peer model

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.3 Peer-to-Peer Model

perform

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.4 Perform Gap Analysis
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.4 Perform Gap Analysis
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.4 Perform Gap Analysis
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.4 Perform Gap Analysis
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation

performance

• 3. Definitions
  • 3.60 Performance Management
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets
• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Business Process Performance
• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

performance management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.60 Performance Management

performance measurement

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

period

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Time Period
• A. Glossary of Supplementary Definitions
  • A.88 Time Period

personal

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.6 Personal and Professional Skills

personnel

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.1 Determine Personnel and Infrastructure (Capital) Costs
• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.3 Governance and Personnel Scenarios

perspective

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.1 Assess the IT Requirements from a Functional Perspective

phase

• 6. Preliminary Phase
• 7. Phase A: Architecture Vision
• 8. Phase B: Business Architecture
• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
• 12. Phase D: Technology Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

Phase A

• 7. Phase A: Architecture Vision

Phase B

• 8. Phase B: Business Architecture

Phase C

• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture

Phase D

• 12. Phase D: Technology Architecture

Phase E

• 13. Phase E: Opportunities & Solutions

Phase F

• 14. Phase F: Migration Planning

Phase G

• 15. Phase G: Implementation Governance

Phase H

• 16. Phase H: Architecture Change Management

phases

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
• 19. Applying Iteration to the ADM
  • 19.4 Mapping TOGAF Phases to Iteration Cycles
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.5 Activities within Phases A to F
    • 40.4.6 Activities within Phases G and H

physical

• 3. Definitions
  • 3.61 Physical
• A. Glossary of Supplementary Definitions
  • A.64 Physical Application Component
  • A.65 Physical Data Component
  • A.66 Physical Technology Component

physical application component

• A. Glossary of Supplementary Definitions
  • A.64 Physical Application Component

physical/business/regulatory

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

physical data component

• A. Glossary of Supplementary Definitions
  • A.65 Physical Data Component

physical technology component

• A. Glossary of Supplementary Definitions
  • A.66 Physical Technology Component

place

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model

plan

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.1 Review Corporate Strategic Plan
• 14. Phase F: Migration Planning
  • 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.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

planning

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
• 14. Phase F: Migration Planning
  • 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.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework

plans

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.3 Review Corporate Line-of-Business Strategic Plans
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.6 Establish Plans for Enterprise Architecture Management
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine the relationship of the system under design with existing business disaster/continuity plans
  • 21.11 Phase F: Migration Planning
    • Implement disaster recovery and business continuity plans or modifications

plans/requirements

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements

platform

• 3. Definitions
  • 3.6 Application Platform
  • 3.7 Application Platform Interface (API)
  • 3.62 Platform
  • 3.63 Platform Services
• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Platform Decomposition Diagram
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.1 Platform Concept

Platform Decomposition diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Platform Decomposition Diagram

platform services

• 3. Definitions
  • 3.63 Platform Services
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities

platform taxonomy

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy

PMBOK

• 36. Architecture Deliverables
  • 36.1 Introduction

pointers

• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.2 General Pointers

points

• 5. Introduction
  • 5.2 Architecture Development Cycle
    • 5.2.1 Key Points

policies

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess alignment or conflict of identified security policies with business goals
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Policies
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • Map to Business Organization Entities and Policies

policy

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Policy Management and Take-On

policy/business

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control

politics

• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.2 Elements of an Effective Architecture Governance Strategy
      • 50.3.2.1 Architecture Governance and Corporate Politics

portability

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Portability and Scalability
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.3 Portability
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.2 Portability and Interoperability
• A. Glossary of Supplementary Definitions
  • A.67 Portability

portfolio

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.1 Create the Portfolio Charters

portfolio management

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

portfolios

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.2 Group Portfolios and Projects into Increments

positions

• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.2 Classify Stakeholder Positions

possible

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI

Post-Implementation

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation

postscript

• 12. Phase D: Technology Architecture
  • 12.6 Postscript

potential

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
      • 13.4.5.2 Reconcile Interoperability Requirements with Potential Solutions
• 29. Interoperability Requirements
  • 29.6 Reconciling Interoperability Requirements with Potential Solutions

potential/likely

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify potential/likely avenues of attack

practice

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.2 Basis of an Internal Architecture Practice

preface

• Frontmatter
  • Preface

preliminary

• 6. Preliminary Phase
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
• 35. Architectural Artifacts
  • 35.7 Viewpoints in the Preliminary Phase
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.4 Activities within the Preliminary Phase

Preliminary phase

• 6. Preliminary Phase

preparation

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.2 Preparation

present

• 30. Business Transformation Readiness Assessment
  • 30.3 Present Readiness Factors

previous

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Minutes of Previous Meeting

previously

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.3 Update Previously Created Architecture Deliverables

PRINCE2

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process
• 36. Architecture Deliverables
  • 36.1 Introduction
• A. Glossary of Supplementary Definitions
  • A.69 PRINCE2

principle

• 3. Definitions
  • 3.17 Architecture Principles
  • 3.64 Principle
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.4 Principles
  • 6.4 Steps
    • 6.4.4 Identify and Establish Architecture Principles
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.7 Confirm and Elaborate Architecture Principles, including Business Principles
• 23. Architecture Principles
  • 23.2 Characteristics of Architecture Principles
  • 23.3 Components of Architecture Principles
  • 23.4 Developing Architecture Principles
    • 23.4.1 Qualities of Principles

Principles catalog

• 35. Architectural Artifacts
  • 35.7 Viewpoints in the Preliminary Phase
    • Principles Catalog

priorities

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management

prioritize

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
      • 14.4.4.3 Prioritize the Projects

privileges

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective

problem

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying, Documenting, and Ranking the Problem
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.1 Problem Space: The Need for Boundaryless Information Flow

procedures

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

process

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.1 Determine Overall Modeling Process
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.1 Determine Overall Modeling Process
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process
  • 16.4 Steps
    • 16.4.1 Establish Value Realization Process
    • 16.4.6 Manage Governance Process
    • 16.4.7 Activate the Process to Implement Change
• 18. Introduction
  • 18.1 Guidelines for Adapting the ADM Process
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.1 Overall Process
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Business Process Performance
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.3 Process Modeling Extensions
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.2 View Creation Process
  • 35.9 Viewpoints in Phase B
    • Process Flow Diagram
• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.2 Building Block Specification Process in the ADM
• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
• A. Glossary of Supplementary Definitions
  • A.70 Process

processes

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned
      • 14.4.7.2 Confirm the Enterprise Architecture Management Processes
• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.2 Using a Hierarchy of ADM Processes
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
    • Determine and document appropriate security forensic processes
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • 50.2.1.2 Key Architecture Governance Processes

Process/Event/Control/Product

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Process/Event/Control/Product Catalog

Process/Event/Control/Product catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Process/Event/Control/Product Catalog

Process Flow diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Process Flow Diagram

processing

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Processing Diagram
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.9 Transaction Processing Services
• A. Glossary of Supplementary Definitions
  • A.6 Batch Processing

Processing diagram

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Processing Diagram

process modeling

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process

process modeling extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.3 Process Modeling Extensions

Processors/Servers/Clients

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.2 Processors/Servers/Clients

process services

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 Business- & Developer-Led SOA Communities

process status

• 5. Introduction
  • 5.4 Architecture Governance

Process/System

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Process/System Realization Diagram

Process/System Realization diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Process/System Realization Diagram

process tailoring

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)

produced

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

producing

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.1 Skills and Experience in Producing Designs

product

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Product Lifecycle Diagram
• A. Glossary of Supplementary Definitions
  • A.71 Product

productivity

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve User Productivity
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.3 Applications Checklists
      • 48.5.3.1 Infrastructure (Enterprise Productivity) Applications

Product Lifecycle diagram

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Product Lifecycle Diagram

Product Line Architecture

• 5. Introduction
  • 5.3 Adapting the ADM

product/service/process

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process

professional

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.6 Personal and Professional Skills

proficiency

• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.4 Proficiency Levels

profile

• A. Glossary of Supplementary Definitions
  • A.72 Profile

profiling

• A. Glossary of Supplementary Definitions
  • A.73 Profiling

program

• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.4 Program or Project Management Skills
• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)
  • A.74 Program

project

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.1 Establish the Architecture Project
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.2 Create the Project Charters

Project Context diagram

• 35. Architectural Artifacts
  • 35.13 Viewpoints in Phase E
    • Project Context Diagram

project management

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

Project Portfolio

• 41. Architecture Repository
  • 41.5 Governance Log
    • 41.5.2 Contents of the Governance Log

projects

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
      • 13.4.10.2 Group Portfolios and Projects into Increments
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 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.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.3 Prioritize the Projects

prompt

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?

propositions

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs

protect

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"

protection

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.3 Absolute Protection

provide

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.4 Provide Analysis for Architecture Change Management

provider

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.2 Business Applications
      • 44.3.2.1 Information Provider Applications

proving

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

provision

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
      • 43.4.2.1 Object-Oriented Provision of Services
  • 43.5 Detailed Platform Taxonomy
    • 43.5.13 Object-Oriented Provision of Services

purpose

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.2 Purpose of a Service Contract
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
      • Purpose
    • 34.4.2 Services Extensions
      • Purpose
    • 34.4.3 Process Modeling Extensions
      • Purpose
    • 34.4.4 Data Extensions
      • Purpose
    • 34.4.5 Infrastructure Consolidation Extensions
      • Purpose
    • 34.4.6 Motivation Extensions
      • Purpose
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.2 Architecture Contract
      • Purpose
    • 36.2.3 Architecture Definition Document
      • Purpose
    • 36.2.4 Architecture Principles
      • Purpose
    • 36.2.5 Architecture Repository
      • Purpose
    • 36.2.6 Architecture Requirements Specification
      • Purpose
    • 36.2.7 Architecture Roadmap
      • Purpose
    • 36.2.8 Architecture Vision
      • Purpose
    • 36.2.9 Business Principles, Business Goals, and Business Drivers
      • Purpose
    • 36.2.10 Capability Assessment
      • Purpose
    • 36.2.11 Change Request
      • Purpose
    • 36.2.12 Communications Plan
      • Purpose
    • 36.2.13 Compliance Assessment
      • Purpose
    • 36.2.14 Implementation and Migration Plan
      • Purpose
    • 36.2.15 Implementation Governance Model
      • Purpose
    • 36.2.16 Organizational Model for Enterprise Architecture
      • Purpose
    • 36.2.18 Requirements Impact Assessment
      • Purpose
    • 36.2.20 Statement of Architecture Work
      • Purpose
    • 36.2.21 Tailored Architecture Framework
      • Purpose
    • 36.2.22 Transition Architecture
      • Purpose
• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.1 Purpose

qualitative

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

qualities

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.1 Service Qualities and TOGAF
• 23. Architecture Principles
  • 23.4 Developing Architecture Principles
    • 23.4.1 Qualities of Principles
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.8 Qualities
  • 43.4 Application Platform - Taxonomy
    • 43.4.3 Application Platform Service Qualities
      • 43.4.3.2 Taxonomy of Service Qualities

quality

• 3. Definitions
  • 3.65 Quality Management
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Quality of Service Manager Utilities
• A. Glossary of Supplementary Definitions
  • A.81 Service Quality

quality management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.65 Quality Management

quantitative

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases

questions

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

RACI

• 22. Using TOGAF to Define & Govern SOAs
  • 22.10 Service Contract Template

ranking

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying, Documenting, and Ranking the Problem

rating

• 30. Business Transformation Readiness Assessment
  • 30.4 Assess Readiness Factors
    • 30.4.2 Readiness Factor Rating

rationalize

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.6 Rationalize and Consolidate Dependencies

RDBMS

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Database Models

REA

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

readiness

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.5 Assess Readiness for Business Transformation
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.7 Confirm Readiness and Risk for Business Transformation
• 30. Business Transformation Readiness Assessment
  • 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

readiness factors

• 30. Business Transformation Readiness Assessment
  • 30.2 Determine Readiness Factors

readiness planning

• 30. Business Transformation Readiness Assessment
  • 30.5 Readiness and Migration Planning

realization

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.1 Establish Value Realization Process
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Process/System Realization Diagram

re-architecting change

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process

reassess

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Reassess and confirm Architecture Vision decisions

recognized

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards

reconcile

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
      • 13.4.5.2 Reconcile Interoperability Requirements with Potential Solutions

reconciling

• 29. Interoperability Requirements
  • 29.6 Reconciling Interoperability Requirements with Potential Solutions

recovery

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document applicable disaster recovery or business continuity plans/requirements
  • 21.11 Phase F: Migration Planning
    • Implement disaster recovery and business continuity plans or modifications

Red Books

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.4 Architecture Patterns in Use
  • 25.3 IBM Patterns for e-Business

redesign

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign

reduce

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Reduce Risk
      • Goal: Reduce Lifecycle Costs

reference

• 3. Definitions
  • 3.66 Reference Model (RM)
  • 3.85 Technical Reference Model (TRM)
• 6. Preliminary Phase
  • 6.3 Inputs
    • 6.3.1 Reference Materials External to the Enterprise
• 7. Phase A: Architecture Vision
  • 7.3 Inputs
    • 7.3.1 Reference Materials External to the Enterprise
• 8. Phase B: Business Architecture
  • 8.3 Inputs
    • 8.3.1 Reference Materials External to the Enterprise
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
• 9. Phase C: Information Systems Architectures
  • 9.3 Inputs
    • 9.3.1 Reference Materials External to the Enterprise
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.3 Inputs
    • 10.3.1 Reference Materials External to the Enterprise
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.3 Inputs
    • 11.3.1 Reference Materials External to the Enterprise
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.3 Inputs
    • 12.3.1 Reference Materials External to the Enterprise
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
• 13. Phase E: Opportunities & Solutions
  • 13.3 Inputs
    • 13.3.1 Reference Materials External to the Enterprise
• 14. Phase F: Migration Planning
  • 14.3 Inputs
    • 14.3.1 Reference Materials External to the Enterprise
• 15. Phase G: Implementation Governance
  • 15.3 Inputs
    • 15.3.1 Reference Materials External to the Enterprise
• 16. Phase H: Architecture Change Management
  • 16.3 Inputs
    • 16.3.1 Reference Materials External to the Enterprise
• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • The OSI Reference Model
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use
• 41. Architecture Repository
  • 41.3 Reference Library
• 43. Foundation Architecture: Technical Reference Model
• 44. Integrated Information Infrastructure Reference Model

referenced

• Frontmatter
  • Referenced Documents

reference data

• 5. Introduction
  • 5.4 Architecture Governance

Reference Library

• 2. Core Concepts
  • 2.7 Architecture Repository
• 41. Architecture Repository
  • 41.1 Overview
  • 41.3 Reference Library

reference models

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 3. Definitions
  • 3.66 Reference Model (RM)
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools

references

• 21. Security Architecture and the ADM
  • 21.14 References

refine

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies

refining

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Checking for Fitness-for-Purpose, and refining if necessary
• 29. Interoperability Requirements
  • 29.4 Refining Interoperability

reflect

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

regarding

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control

regulate

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify methods to regulate consumption of resources

regulatory

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements

relating

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.6 Relating the Management Frameworks

relationship

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine the relationship of the system under design with existing business disaster/continuity plans
• 34. Content Metamodel
  • 34.7 Metamodel Relationships
• 39. Enterprise Continuum
  • 39.5 Relationship between the Enterprise Continuum and TOGAF ADM
  • 39.6 Enterprise Continuum and Your Organization
    • 39.6.1 Relationships
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.3 Relationship to Other parts of TOGAF
• 49. Architecture Contracts
  • 49.3 Relationship to Architecture Governance

relay system

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.4 Security Generic Architecture View

release

• 4. Release Notes

release notes

• 4. Release Notes

relocation transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

replication transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

reporting

• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Monitoring and Reporting

repository

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.67 Repository
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.1 The ADM, Enterprise Continuum, and Architecture Repository
• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.2 Architecture Repository
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository
• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository
• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View
    • 35.20.3 Key Issues
      • Repository
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.5 Architecture Repository
• 41. Architecture Repository

request

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.11 Change Request
    • 36.2.17 Request for Architecture Work

Request for Architecture Work

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.1 General
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.17 Request for Architecture Work

requests

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Requests for Change

required

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 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
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.1 Governance Extensions
      • Required Changes to the Metamodel
    • 34.4.2 Services Extensions
      • Required Changes to the Metamodel
    • 34.4.3 Process Modeling Extensions
      • Required Changes to the Metamodel
    • 34.4.4 Data Extensions
      • Required Changes to the Metamodel
    • 34.4.5 Infrastructure Consolidation Extensions
      • Required Changes to the Metamodel
    • 34.4.6 Motivation Extensions
      • Required Changes to the Metamodel
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.5 Identifying Building Block Requirements and Constraints
      • 37.4.5.1 Assumptions of Required Technical Functionality

requirement

• 3. Definitions
  • 3.68 Requirement
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.6 Identify Types of Requirement to be Collected
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.5 Identify Types of Requirement to be Collected
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.5 Identify Types of Requirement to be Collected
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.5 Identify Types of Requirement to be Collected

Requirement for Architecture Work

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.3 Requirements for Architecture Work

requirements

• 3. Definitions
  • 3.68 Requirement
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.3 Requirements for Architecture Work
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.5 Identify Types of Requirement to be Collected
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.5 Identify Types of Requirement to be Collected
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review IT Requirements from a Functional Perspective
      • 13.4.4.1 Assess the IT Requirements from a Functional Perspective

Requirements catalog

• 35. Architectural Artifacts
  • 35.14 Viewpoints for Requirements Management
    • Requirements Catalog

Requirements Impact Assessment

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.18 Requirements Impact Assessment

requirements tools

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.3 Requirements Tools

residual

• 31. Risk Management
  • 31.5 Risk Mitigation and Residual Risk Assessment
  • 31.6 Conduct Residual Risk Assessment

residual risk assessment

• 31. Risk Management
  • 31.6 Conduct Residual Risk Assessment

resolution

• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Dispute Resolution

resolve

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.6 Resolve Impacts Across the Architecture Landscape
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.6 Resolve Impacts Across the Architecture Landscape
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.6 Resolve Impacts Across the Architecture Landscape
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.6 Resolve Impacts Across the Architecture Landscape

resource

• 3. Definitions
  • 3.69 Resource Management
• 4. Release Notes
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
    • Part IV: Resource Base
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
• A. Glossary of Supplementary Definitions
  • A.31 Enterprise Resource Planning (ERP) System

Resource-Event-Agent

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

resource management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.69 Resource Management

resources

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.2 Identify Deployment Resources and Skills
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify methods to regulate consumption of resources
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources
• 25. Architecture Patterns
  • 25.4 Some Pattern Resources

respect

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.2 Analyze the Work Packages with Respect to Business Transformation

responsibilities

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts
• 47. Architecture Board
  • 47.2 Responsibilities

responsibility

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.2 Architecture Governance as a Board-Level Responsibility

results

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
      • 13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

return

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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

re-usable

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources

re-use

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use
    • Identify new code/resources/assets that are appropriate for re-use
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.8 Building Block Re-Use Level
• 39. Enterprise Continuum
  • 39.2 Enterprise Continuum and Architecture Re-Use
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.2 Partitioning Reference Models to Encourage Good Practice and Re-Use

review

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.7 Conduct Formal Stakeholder Review
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.7 Conduct Formal Stakeholder Review
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.7 Conduct Formal Stakeholder Review
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.7 Conduct Formal Stakeholder Review
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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.2 Review the Phase B, C, and D Gap Analysis Results

reviewers

• Frontmatter
  • Participants
    • Architecture Forum Technical Reviewers

reviewing

• 26. Business Scenarios
  • 26.3 Creating the Business Scenario
    • 26.3.4 Reviewing

reviews

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
  • 48.6 Architecture Compliance Review Guidelines
    • 48.6.2 Conducting Architecture Compliance Reviews

revisit

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control
  • 21.9 Phase D: Technology Architecture
    • Revisit assumptions regarding interconnecting systems beyond project control

rigor

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
    • 52.2.1 Definitional Rigor

risk

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.7 Confirm Readiness and Risk for Business Transformation
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 14.4.2.2 Assign Risk to the Projects and Project Increments
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
      • 14.4.4.2 Validate the Risk Assessment

risk assessment

• 31. Risk Management
  • 31.4 Initial Risk Assessment

risk classification

• 31. Risk Management
  • 31.2 Risk Classification

risk identification

• 31. Risk Management
  • 31.3 Risk Identification

risk management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
• 31. Risk Management
• A. Glossary of Supplementary Definitions
  • A.76 Risk Management

risk management, best practice

• 31. Risk Management
  • 31.4 Initial Risk Assessment

Risk Management Plan

• 31. Risk Management
  • 31.3 Risk Identification

risk monitoring

• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)

risks

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.3 Manage Risks
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine approaches to address identified risks:
  • 21.10 Phase E: Opportunities & Solutions
    • Engineer mitigation measures addressing identified risks
• 30. Business Transformation Readiness Assessment
  • 30.4 Assess Readiness Factors
    • 30.4.3 Readiness Factor Risks & Actions

RM

• 3. Definitions
  • 3.66 Reference Model (RM)

RM-ODP

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

roadmap

• 3. Definitions
  • 3.70 Roadmap
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Roadmap Components
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.7 Architecture Roadmap

roadmap components

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Roadmap Components

role

• 3. Definitions
  • 3.71 Role
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Role Catalog
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.1 Role of the TRM in the Foundation Architecture
• 47. Architecture Board
  • 47.1 Role
• 49. Architecture Contracts
  • 49.1 Role
• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
  • 52.5 Enterprise Architecture Role and Skill Definitions
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.1 Generic Role

Role catalog

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Role Catalog

roles

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts
• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
    • 48.4.2 Roles
• 52. Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.2 TOGAF Roles

Role/System

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Role/System Matrix

Role/System matrix

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Role/System Matrix

RosettaNet

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

SA-CMM

• 51. Architecture Maturity Models
  • 51.2 Background
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

safe

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states

safety-critical/mission-critical/non-critical

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical

said

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

SalesApp

• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling

SANS Institute

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles

SBB

• 3. Definitions
  • 3.78 Solution Building Block (SBB)
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
• 35. Architectural Artifacts
  • 35.22 Developing an Acquirer View
    • 35.22.2 Developing the View
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.19 Solution Building Blocks
• 37. Building Blocks
  • 37.1 Overview
  • 37.2 Introduction to Building Blocks
    • 37.2.4 Solution Building Blocks

scalability

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Portability and Scalability
• A. Glossary of Supplementary Definitions
  • A.77 Scalability

SCAMPI

• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.2 SCAMPI Method

scenario

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.3 Business Scenarios
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.1 Business Scenarios
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.4 Patterns and Business Scenarios
• 26. Business Scenarios
  • 26.2 Benefits of Business Scenarios
  • 26.3 Creating the Business Scenario
  • 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.8 Guidelines on Business Scenario Documentation
    • 26.8.2 Business Scenario Models

schedule

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.4 Incorporate Project Schedules
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Schedule of Meetings

scope

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.6 Define Scope
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.4 Identifying Building Block Scope
• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.4 Full Project Scope Experience

Scope/Focus

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Enterprise Scope/Focus

Scope/Level

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Vertical Scope/Level of Detail

scoping

• 5. Introduction
  • 5.5 Scoping the Architecture

scoping the architecture

• 5. Introduction
  • 5.5 Scoping the Architecture

scripts

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts

SE-CMM

• 51. Architecture Maturity Models
  • 51.2 Background
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

secure

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations

security

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 21. Security Architecture and the ADM
  • 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
    • 21.5.1 Security Inputs
    • 21.5.2 Security Outputs
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures
    • 21.6.1 Security Inputs
    • 21.6.2 Security Outputs
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures
    • Determine and document appropriate security forensic processes
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
    • Assess alignment or conflict of identified security policies with business goals
    • 21.7.1 Security Inputs
    • 21.7.2 Security Outputs
    • 21.8.1 Security Inputs
    • 21.8.2 Security Outputs
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
    • Identify mitigating security measures, where justified by risk assessment
    • 21.9.1 Security Inputs
    • 21.9.2 Security Outputs
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use
    • Evaluate tested and re-usable security software and security system resources
  • 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
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

security architecture

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 21. Security Architecture and the ADM

security, architecture domains

• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains

security association

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.2 Network Services

security context

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services

security management

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.3 System Security Management Services

security mechanisms

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.4 Security Generic Architecture View

Security/Protection

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.3 Security/Protection

security-related

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle

security-relevant

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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
  • 21.13 Phase H: Architecture Change Management
    • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

security services

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.4 Security Generic Architecture View
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.11 Security Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.2 Security Services

security services, allocation

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation

security-specific

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Assess and baseline current security-specific business processes (enhancement of existing objective)
  • 21.8 Phase C: Information Systems Architectures
    • Assess and baseline current security-specific architecture elements (enhancement of existing objective)
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)

segment

• 3. Definitions
  • 3.72 Segment Architecture

Segment Architecture

• 3. Definitions
  • 3.72 Segment Architecture
• 41. Architecture Repository
  • 41.2 Architecture Landscape

SEI

• 51. Architecture Maturity Models
  • 51.2 Background

select

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.6 Select Services

sensitivity

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used

sequence

• A. Glossary of Supplementary Definitions
  • A.90 Transaction Sequence

server

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.4 Application Server
      • 48.5.7.5 Data Server
• A. Glossary of Supplementary Definitions
  • A.79 Server

service

• 3. Definitions
  • 3.29 Business Service
  • 3.73 Service Management
  • 3.74 Service Orientation
  • 3.75 Service Oriented Architecture (SOA)
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.2 Identify Required Service Granularity Level, Boundaries, and Contracts
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify the criticality of the availability and correct operation of the overall service
• 22. Using TOGAF to Define & Govern SOAs
  • 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

service contract

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Contracts

service contract, content & structure

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract

service contract, guidelines for definition

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition

service contract, purpose of

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.2 Purpose of a Service Contract

service contract, template

• 22. Using TOGAF to Define & Govern SOAs
  • 22.10 Service Contract Template

Service/Function

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Service/Function Catalog

service governance considerations

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations

Service/Information

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Service/Information Diagram

service-level agreement

• 25. Architecture Patterns
  • 25.3 IBM Patterns for e-Business
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.5 Qualities
• 47. Architecture Board
  • 47.2 Responsibilities
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.3 Contract between Architecting Function and Business Users
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Compliance

service lifecycle management

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Lifecycle Management

service management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.73 Service Management

Service Management Repository

• 41. Architecture Repository
  • 41.1 Overview

service metadata

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Metadata

service modeling

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.2 Purpose of a Service Contract

service orientation

• 3. Definitions
  • 3.74 Service Orientation

Service Oriented Architecture

• 3. Definitions
  • 3.75 Service Oriented Architecture (SOA)
• 22. Using TOGAF to Define & Govern SOAs

service policies

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.3 Service Governance Considerations
      • Service Policies

service qualities

• A. Glossary of Supplementary Definitions
  • A.81 Service Quality

service qualities, and TOGAF

• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Guidelines for Service Contract Definition
    • 22.8.1 Service Qualities and TOGAF

service qualities, Application Platform

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.3 Application Platform Service Qualities

service qualities, TRM

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.3 Application Platform Service Qualities
      • 43.4.3.2 Taxonomy of Service Qualities

services

• 3. Definitions
  • 3.63 Platform Services
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.6 Select Services
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Identify existing security services available for re-use
• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.2 Services Extensions
• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security 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

services extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.2 Services Extensions

services, network

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.2 Network Services

services, operating system

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services

service sprawl

• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Complexities Arising from SOA

services, system security management

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.3 System Security Management Services

set

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles

setting

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board

sharing

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.4 Hosting, Data Types, and Sharing

SIB

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.81 Standards Information Base (SIB)
• 41. Architecture Repository
  • 41.1 Overview

sign-off

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle

simple

• 35. Architectural Artifacts
  • 35.1 Basic Concepts
    • 35.1.1 Simple Example of a Viewpoint and View

simplification change

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process

single

• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.1 Using Iterations within a Single ADM Cycle

size

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board
    • 47.3.2 Size of the Board

skill

• 3. Definitions
  • 3.76 Skill
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.2 Identify Deployment Resources and Skills
• 52. Architecture Skills Framework
  • 52.2 Need for an Enterprise Architecture Skills Framework
  • 52.4 Enterprise Architecture Role and Skill Categories
    • 52.4.3 Categories of Skills

SLA

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• 25. Architecture Patterns
  • 25.3 IBM Patterns for e-Business
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.5 Qualities
• 47. Architecture Board
  • 47.2 Responsibilities
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.3 Contract between Architecting Function and Business Users
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Compliance

SMAP

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.3 System Security Management Services

SMART

• 26. Business Scenarios
  • 26.1 Introduction
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.2 Importance of SMART Objectives
      • Example of Making Objectives SMART

SNA

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • The OSI Reference Model

SOA

• 3. Definitions
  • 3.75 Service Oriented Architecture (SOA)
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 22. Using TOGAF to Define & Govern SOAs
  • 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

SOA, and enterprise architecture

• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 How Enterprise Architecture Supports SOA

SOA, and TOGAF

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF

SOA, business-led community

• 22. Using TOGAF to Define & Govern SOAs
  • 22.3 Business-Led SOA Community

SOA, complexities from

• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Complexities Arising from SOA

SOAs

• 22. Using TOGAF to Define & Govern SOAs

software

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Software Engineering Diagram
    • Software Distribution Diagram
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems
      • 35.17.2.3 Software Tiers

Software Distribution diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Software Distribution Diagram

Software Engineering diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Software Engineering Diagram

software engineering services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.8 Software Engineering Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.1 Software Engineering Services

Software Engineering view

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View

software modularity

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use

software portability

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.3 Portability

software re-use

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
      • 35.17.1.2 Software Modularity and Re-Use

software tiers

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.3 Software Tiers

solution

• 3. Definitions
  • 3.77 Solution Architecture
  • 3.78 Solution Building Block (SBB)
• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Solution Concept Diagram
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.19 Solution Building Blocks
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.4 Solution Building Blocks
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
      • 44.1.4.2 Solution Space: The Need for Integrated Information Infrastructure

solution architect

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.2 Characterization in Terms of the Enterprise Continuum

Solution Architecture

• 3. Definitions
  • 3.77 Solution Architecture

solution building block

• 3. Definitions
  • 3.78 Solution Building Block (SBB)
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.4 Solution Building Blocks

solution characteristics

• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions

Solution Concept diagram

• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Solution Concept Diagram

solutions

• 3. Definitions
  • 3.79 Solutions Continuum
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
      • 13.4.5.2 Reconcile Interoperability Requirements with Potential Solutions

Solutions Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.79 Solutions Continuum
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.4 Solution Building Blocks
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum

some

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.4 Some Uses of a Data Access Tier

something

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"

space

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 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

specific

• 52. Architecture Skills Framework
  • 52.3 Goals/Rationale
    • 52.3.2 Specific Benefits

specifically

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?

specification

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.2 Volere Requirements Specification Template
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.6 Architecture Requirements Specification
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.3 Architecture Building Blocks
      • 37.2.3.2 Specification Content
    • 37.2.4 Solution Building Blocks
      • 37.2.4.2 Specification Content
  • 37.3 Building Blocks and the ADM
    • 37.3.2 Building Block Specification Process in the ADM
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • 37.4.6.1 Customer Information System Building Block Specification
• A. Glossary of Supplementary Definitions
  • A.58 Open Specifications

SQL

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.5 One Possible Instantiation of a DAI

stability

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

stakeholder

• 3. Definitions
  • 3.33 Communications and Stakeholder Management
  • 3.80 Stakeholder
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.7 Conduct Formal Stakeholder Review
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.7 Conduct Formal Stakeholder Review
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.7 Conduct Formal Stakeholder Review
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.7 Conduct Formal Stakeholder Review
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.2 Classify Stakeholder Positions
    • 24.3.3 Determine Stakeholder Management Approach

stakeholder management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• 3. Definitions
  • 3.33 Communications and Stakeholder Management
• 24. Stakeholder Management

Stakeholder Management, process steps

• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process

Stakeholder Map matrix

• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Stakeholder Map Matrix

stakeholders

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders
• 35. Architectural Artifacts
  • 35.15 Developing a Business Architecture View
    • 35.15.1 Stakeholders and Concerns
  • 35.16 Developing an Enterprise Security View
    • 35.16.1 Stakeholders and Concerns
  • 35.17 Developing a Software Engineering View
    • 35.17.1 Stakeholders and Concerns
  • 35.18 Developing a System Engineering View
    • 35.18.1 Stakeholders and Concerns
  • 35.19 Developing a Communications Engineering View
    • 35.19.1 Stakeholders and Concerns
  • 35.20 Developing a Data Flow View
    • 35.20.1 Stakeholders and Concerns
  • 35.21 Developing an Enterprise Manageability View
    • 35.21.1 Stakeholders and Concerns
  • 35.22 Developing an Acquirer View
    • 35.22.1 Stakeholders and Concerns

standard

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.2 Types of Standard

standardization

• 42. Tools for Architecture Development
  • 42.2 Issues in Tool Standardization

standards

• 3. Definitions
  • 3.81 Standards Information Base (SIB)
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify and evaluate applicable recognized guidelines and standards
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards
• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Technology Standards Catalog
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle
    • 41.4.4 Standards Classification within the Standards Information Base

standards, classification

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

standards, compliance with

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards

Standards Information Base

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.81 Standards Information Base (SIB)
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

standards, lifecycle

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle

standards, types of

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.2 Types of Standard

state

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
      • 14.4.6.2 Enterprise Architecture State Evolution
• 28. Migration Planning Techniques
  • 28.4 Enterprise Architecture State Evolution Table
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.1 Partitioning the Architecture Landscape to Understand the State of the Enterprise

statement

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.20 Statement of Architecture Work
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.1 Statement of Architecture Work

Statement of Architecture Work

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.2 Creating the Architecture Vision
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.20 Statement of Architecture Work
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.1 Statement of Architecture Work

states

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states

status

• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.5 Status of the III-RM

STEP Framework

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.4 Architecture Repository

steps

• 6. Preliminary Phase
  • 6.4 Steps
• 7. Phase A: Architecture Vision
  • 7.4 Steps
• 8. Phase B: Business Architecture
  • 8.4 Steps
• 9. Phase C: Information Systems Architectures
  • 9.4 Steps
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
• 12. Phase D: Technology Architecture
  • 12.4 Steps
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
• 14. Phase F: Migration Planning
  • 14.4 Steps
• 15. Phase G: Implementation Governance
  • 15.4 Steps
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
• 17. ADM Architecture Requirements Management
  • 17.4 Steps
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
• 27. Gap Analysis
  • 27.2 Suggested Steps
• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
    • 48.4.3 Steps

steward

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles

storage

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • Storage Management Utilities

stored/created/used

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used

strategic

• 3. Definitions
  • 3.82 Strategic Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
      • 13.4.2.1 Review Corporate Strategic Plan
      • 13.4.2.3 Review Corporate Line-of-Business Strategic Plans
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
      • 13.4.8.1 Determine Overall Strategic Implementation Direction

Strategic Architecture

• 3. Definitions
  • 3.82 Strategic Architecture
• 41. Architecture Repository
  • 41.2 Architecture Landscape

strategy

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate High-Level Implementation and Migration Strategy
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Architecture Strategy and Direction Documentation
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.2 Elements of an Effective Architecture Governance Strategy

strict

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.2 Strict Isolation

strict isolation

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.3 Basic Concepts
      • 35.16.3.2 Strict Isolation

structure

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Modular Structure
  • 4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
  • 4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1
• 5. Introduction
  • 5.2 Architecture Development Cycle
    • 5.2.2 Basic Structure
• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract
• 33. Introduction
  • 33.4 Structure of Part IV
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.2 Structure
• 38. Introduction
  • 38.2 Structure of Part V
• 45. Introduction
  • 45.2 Structure of Part VII
• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board
    • 47.3.3 Board Structure
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
    • 50.2.2 Architecture Governance Framework - Organizational Structure

structured analysis

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process

style

• 3. Definitions
  • 3.8 Architectural Style
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 19. Applying Iteration to the ADM
  • 19.3 Two Styles of Architecture Definition

subject matter

• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions
  • 40.3 Characteristics of Architectures

subsystems

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

success

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Documenting Roles, Responsibilities, Measures of Success, Required Scripts
• 50. Architecture Governance
  • 50.3 Architecture Governance in Practice
    • 50.3.1 Architecture Governance - Key Success Factors

successful

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
• A. Glossary of Supplementary Definitions
  • A.53 Managing Successful Programs (MSP)

suggested

• 27. Gap Analysis
  • 27.2 Suggested Steps

summary

• 5. Introduction
  • 5.7 Summary
• 26. Business Scenarios
  • 26.10 Summary
• 29. Interoperability Requirements
  • 29.7 Summary
• 31. Risk Management
  • 31.8 Summary
• 32. Capability-Based Planning
  • 32.5 Summary

supplementary

• A. Glossary of Supplementary Definitions

supplier

• A. Glossary of Supplementary Definitions
  • A.83 Supplier Management

supplier management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• A. Glossary of Supplementary Definitions
  • A.83 Supplier Management

support

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.2 Confirm Governance and Support Frameworks
• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.3 Full Lifecycle Support

supporting

• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques

supports

• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 How Enterprise Architecture Supports SOA

SW-CMM

• 51. Architecture Maturity Models
  • 51.2 Background
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

synchronization

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework

system

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment
  • 21.6 Phase A: Architecture Vision
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
  • 21.8 Phase C: Information Systems Architectures
    • 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
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources
  • 21.12 Phase G: Implementation Governance
    • 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
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System Use-Case Diagram
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.1 Operating System Services
      • 35.16.5.3 System Security Management Services
  • 35.18 Developing a System Engineering View
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.6 Architecture Modeling
      • 37.4.6.1 Customer Information System Building Block Specification
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.7 Operating System Services
    • 43.5.12 System and Network Management Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.7 Additional Operating System Services
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.1 Hardware and Operating System Checklist
    • 48.5.6 System Management Checklist
    • 48.5.7 System Engineering/Overall Architecture Checklists
    • 48.5.8 System Engineering/Methods & Tools Checklist
• A. Glossary of Supplementary Definitions
  • A.7 Business System
  • A.13 Communications System
  • A.26 Database Management System
  • A.31 Enterprise Resource Planning (ERP) System
  • A.41 Information System (IS)
  • A.42 Information System Service
  • A.59 Open System
  • A.61 Operating System Service
  • A.84 System
  • A.85 System and Network Management Service
  • A.86 System Stakeholder

system and network management service

• A. Glossary of Supplementary Definitions
  • A.85 System and Network Management Service

system architect

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.2 Characterization in Terms of the Enterprise Continuum

System/Data

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • System/Data Matrix

System/Data matrix

• 35. Architectural Artifacts
  • 35.10 Viewpoints in the Phase C Data Architecture
    • System/Data Matrix

System Engineering view

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View

System/Function

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System/Function Matrix

System/Function matrix

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System/Function Matrix

system management services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.12 System and Network Management Services

System/Organization

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System/Organization Matrix

System/Organization matrix

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System/Organization Matrix

systems

• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture

system(s

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed

systems

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Identify and document interconnecting systems beyond project control
  • 21.8 Phase C: Information Systems Architectures
    • Revisit assumptions regarding interconnecting systems beyond project control

system security management services

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.3 System Security Management Services

system stakeholder

• A. Glossary of Supplementary Definitions
  • A.86 System Stakeholder

System/Technology

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • System/Technology Matrix

System/Technology matrix

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • System/Technology Matrix

System Use-Case diagram

• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System Use-Case Diagram

table

• 28. Migration Planning Techniques
  • 28.3 Architecture Definition Increments Table
  • 28.4 Enterprise Architecture State Evolution Table

TADG

• 25. Architecture Patterns
  • 25.1 Introduction
    • 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

TAFIM

• 1. Introduction
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.3 Other TRMs

tailor

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.4 Tailor Engagement Deliverables

tailored

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.21 Tailored Architecture Framework

Tailored Architecture Framework

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.21 Tailored Architecture Framework

tailoring

• 48. Architecture Compliance
  • 48.6 Architecture Compliance Review Guidelines
    • 48.6.1 Tailoring the Checklists

Take-On

• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Policy Management and Take-On

target

• 3. Definitions
  • 3.83 Target Architecture
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.3 Develop Target Business Architecture Description
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.3 Develop Target Data Architecture Description
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.3 Develop Target Application Architecture Description
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.3 Develop Target Technology Architecture Description

Target Architecture

• 3. Definitions
  • 3.83 Target Architecture

Target Architecture Description

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Time Period

targets

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets

taxonomy

• 3. Definitions
  • 3.84 Taxonomy of Architecture Views
• 35. Architectural Artifacts
  • 35.6 Taxonomy of Architecture Viewpoints
• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.2 TRM Components
  • 43.4 Application Platform - Taxonomy
    • 43.4.1 Basic Principles
    • 43.4.3 Application Platform Service Qualities
      • 43.4.3.2 Taxonomy of Service Qualities

taxonomy of architecture views

• 3. Definitions
  • 3.84 Taxonomy of Architecture Views

TCP/IP

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View
    • 35.19.2 Key Issues
      • The OSI Reference Model

team

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Identify a security architect or security architecture team

technical

• 3. Definitions
  • 3.85 Technical Reference Model (TRM)
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective
• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.5 Identifying Building Block Requirements and Constraints
      • 37.4.5.1 Assumptions of Required Technical Functionality
• 43. Foundation Architecture: Technical Reference Model
• 44. Integrated Information Infrastructure Reference Model
  • 44.1 Basic Concepts
    • 44.1.4 Key Business and Technical Drivers
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.6 Technical IT Skills
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.3 Key Characteristics of an Enterprise Architect
      • 52.6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines
• Frontmatter
  • Participants
    • Architecture Forum Technical Reviewers

Technical Reference Model

• 3. Definitions
  • 3.85 Technical Reference Model (TRM)
• 43. Foundation Architecture: Technical Reference Model

technique

• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Project
      • 14.4.2.4 Determine Continuous Business Value Assessment Technique
• 18. Introduction
  • 18.2 Techniques for Architecture Development
• 28. Migration Planning Techniques
  • 28.5 Business Value Assessment Technique

technologies

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Assess and baseline current security-specific technologies (enhancement of existing objective)

technology

• 3. Definitions
  • 3.47 Information Technology (IT)
  • 3.86 Technology Architecture
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks
    • 12.4.2 Develop Baseline Technology Architecture Description
    • 12.4.3 Develop Target Technology Architecture Description
    • 12.4.8 Finalize the Technology Architecture

Technology Architecture

• 2. Core Concepts
  • 2.3 What Kind of Architecture Does TOGAF Deal With?
• 3. Definitions
  • 3.86 Technology Architecture
• 12. Phase D: Technology Architecture

technology building blocks

• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.2 Identify Required Catalogs of Technology Building Blocks

technology component

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 SOA and TOGAF
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• A. Glossary of Supplementary Definitions
  • A.87 Technology Component

technology governance

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise
    • 50.1.3 Technology Governance

Technology Portfolio catalog

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Technology Portfolio Catalog

technology principles, examples

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles

Technology Standards

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base

Technology Standards catalog

• 35. Architectural Artifacts
  • 35.12 Viewpoints in Phase D
    • Technology Standards Catalog

TeleManagement Forum

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository

template

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.2 Volere Requirements Specification Template
• 22. Using TOGAF to Define & Govern SOAs
  • 22.10 Service Contract Template
• 24. Stakeholder Management
  • 24.4 Template Stakeholder Map

terminology

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
• 48. Architecture Compliance
  • 48.2 Terminology: The Meaning of Architecture Compliance

terminology tailoring

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Select and Tailor Architecture Framework(s)

terms

• 52. Architecture Skills Framework
  • 52.6 Generic Role and Skills of the Enterprise Architect
    • 52.6.2 Characterization in Terms of the Enterprise Continuum

tested

• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
    • Evaluate tested and re-usable security software and security system resources

textual

• 26. Business Scenarios
  • 26.8 Guidelines on Business Scenario Documentation
    • 26.8.1 Textual Documentation

that

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes
  • 21.10 Phase E: Opportunities & Solutions
    • Identify new code/resources/assets that are appropriate for re-use
  • 21.12 Phase G: Implementation Governance
    • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

their

• 26. Business Scenarios
  • 26.7 Guidelines on Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying Human Actors and their Place in the Business Model
      • Identifying Computer Actors and their Place in the Technology Model

this

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Define necessary security-related management sign-off milestones of this architecture development cycle
• Frontmatter
  • Preface
    • This Document

though

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.3 Enforce Corporate Policy though Compliance with Standards

threats

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

Three-Tier

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Three-Tier

through

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

tier

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.3 Software Tiers
      • 35.17.2.4 Some Uses of a Data Access Tier

time

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Time Period
• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions
• A. Glossary of Supplementary Definitions
  • A.88 Time Period

Time-Lined

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

time period

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Time Period

Time-Spans

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
      • 14.4.5.1 Confirm Transition Architecture Time-Spans

timing

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.3 Determine Transition Architecture/Project Increment Timings

TMF

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.1 Determine Overall Modeling Process
• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository

TOGAF

• 1. Introduction
  • 1.1 Structure of the TOGAF Document
  • 1.2 Executive Overview
    • Why do I need TOGAF as a framework for enterprise architecture?
    • Who would benefit from using TOGAF?

TOGAF ADM

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
• 36. Architecture Deliverables
• 39. Enterprise Continuum
  • 39.5 Relationship between the Enterprise Continuum and TOGAF ADM

TOGAF TRM

• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository
• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View
    • 35.18.2 Key Issues
      • 35.18.2.1 Client/Server Model
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Foundation Architecture
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.1 Basic Principles

tool

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.6 Implement Architecture Tools
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.2 Deploy Monitoring Tools
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.3 Requirements Tools
• 35. Architectural Artifacts
  • 35.3 Views, Tools, and Languages
  • 35.4 Views and Viewpoints
    • 35.4.3 Need for a Common Language and Interoperable Tools for Architecture Description
• 42. Tools for Architecture Development
  • 42.2 Issues in Tool Standardization
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • Tool Capacity/Scalability Constraints
      • 42.3.1.2 Architecture of the Tool

trademarks

• Frontmatter
  • Trademarks

training

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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

transaction

• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.9 Transaction Processing Services
• A. Glossary of Supplementary Definitions
  • A.89 Transaction
  • A.90 Transaction Sequence

transaction processing services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.9 Transaction Processing Services

transaction sequence

• A. Glossary of Supplementary Definitions
  • A.90 Transaction Sequence

transaction transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

transformation

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.5 Assess Readiness for Business Transformation
    • 7.4.10 Identify the Business Transformation Risks and Mitigation Activities
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.7 Confirm Readiness and Risk for Business Transformation
    • 13.4.9 Identify and Group Major Work Packages
      • 13.4.9.2 Analyze the Work Packages with Respect to Business Transformation
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
      • 14.4.1.2 Examine Business Transformation Aspects
• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)

transformation readiness assessment

• 30. Business Transformation Readiness Assessment
  • 30.1 Introduction
    • 30.1.1 Business Transformation Enablement Program (BTEP)

transition

• 3. Definitions
  • 3.87 Transition Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.1 Determine/Confirm Key Corporate Change Attributes
      • 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.10 Identify Transition Architectures
      • 13.4.10.1 Identify Transition Architecture and Capability Increments

Transition Architecture

• 3. Definitions
  • 3.87 Transition Architecture
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.22 Transition Architecture

Transition Architecture Description

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Time Period

transition planning

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles

transparency

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.7 Distribution

treasury

• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)

Trial Standard

• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle

triggering

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

triggers

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board
    • 47.3.1 Triggers

TRM

• 3. Definitions
  • 3.85 Technical Reference Model (TRM)
• 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.3 TRM in Detail
    • 43.3.2 TRM Entities and Interfaces
    • 43.3.4 Application Platform
      • 43.3.4.2 Extending the TRM

TRM, detail

• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail

TRM graphic

• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.2 TRM Components
  • 43.4 Application Platform - Taxonomy
    • 43.4.1 Basic Principles

TRMs

• 43. Foundation Architecture: Technical Reference Model
  • 43.1 Concepts
    • 43.1.3 Other TRMs

trust

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify the trust (clearance) level of:

trustee

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles

trying

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"

two

• 19. Applying Iteration to the ADM
  • 19.3 Two Styles of Architecture Definition

Two-Tier

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • Two-Tier

types

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.6 Identify Types of Requirement to be Collected
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
      • 10.4.1.5 Identify Types of Requirement to be Collected
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
      • 11.4.1.5 Identify Types of Requirement to be Collected
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
      • 12.4.1.5 Identify Types of Requirement to be Collected
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.2 Types of Standard
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.4 Hosting, Data Types, and Sharing

UML

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

UN/CEFACT

• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.2 Approach
    • 11.2.1 Architecture Repository

under

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Determine the relationship of the system under design with existing business disaster/continuity plans
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels
      • Level 2: Under Development

understand

• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 40.4.1 Partitioning the Architecture Landscape to Understand the State of the Enterprise

unit

• A. Glossary of Supplementary Definitions
  • A.62 Organization Unit

up

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board

update

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create Portfolio and Project Charters and Update the Architectures
      • 13.4.11.4 Conduct Overall Architecture Updates

upon

• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
    • Assess the impact of new security measures upon other new components or existing leveraged systems

US

• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework

usability

• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
    • Greater Usability

US DoD

• 1. Introduction

use

• 4. Release Notes
  • 4.5 Using TOGAF
    • 4.5.1 Conditions of Use
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.4 Architecture Patterns in Use

Use-Case

• 35. Architectural Artifacts
  • 35.9 Viewpoints in Phase B
    • Business Use-Case Diagram
  • 35.11 Viewpoints in the Phase C Application Architecture
    • System Use-Case Diagram
• 37. Building Blocks
  • 37.4 Building Blocks Example
    • 37.4.4 Identifying Building Block Scope
• A. Glossary of Supplementary Definitions
  • A.91 Use-Case

use-case analysis

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
      • 8.4.1.1 Determine Overall Modeling Process

use-case model

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.3 Business Modeling

used

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify lifespan of information used as defined by business needs and regulatory requirements

useful

• 21. Security Architecture and the ADM
  • 21.4 ADM Architecture Requirements Management
    • Nothing useful can be said about a security measure outside the context of an application, or a system and its environment

user

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve User Productivity
• 35. Architectural Artifacts
  • 35.11 Viewpoints in the Phase C Application Architecture
    • Application and User Location Diagram
• 43. Foundation Architecture: Technical Reference Model
  • 43.5 Detailed Platform Taxonomy
    • 43.5.10 User Interface Services
• A. Glossary of Supplementary Definitions
  • A.30 End User
  • A.92 User
  • A.93 User Interface Service

user interface services

• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
  • 43.5 Detailed Platform Taxonomy
    • 43.5.10 User Interface Services
• A. Glossary of Supplementary Definitions
  • A.93 User Interface Service

users

• 21. Security Architecture and the ADM
  • 21.12 Phase G: Implementation Governance
    • 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
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.3 Contract between Architecting Function and Business Users

uses

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.4 Some Uses of a Data Access Tier

using

• 1. Introduction
  • 1.2 Executive Overview
    • Who would benefit from using TOGAF?
• 2. Core Concepts
  • 2.10 Using TOGAF with Other Frameworks
• 4. Release Notes
  • 4.5 Using TOGAF
• 20. Applying the ADM at Different Enterprise 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
• 22. Using TOGAF to Define & Govern SOAs

utilities

• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.3 Infrastructure Applications
      • 44.3.3.2 Management Utilities
      • Operations, Administration, and Management (OA&M) Utilities
      • Quality of Service Manager Utilities
      • Copy Management Utilities
      • Storage Management Utilities

utilizing

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures

v

• 38. Introduction
  • 38.2 Structure of Part V

validate

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
      • 14.4.4.2 Validate the Risk Assessment

validation

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

value

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.9 Define the Target Architecture Value Propositions and KPIs
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 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.3 Assign Business Value to the Projects and Project Increments
      • 14.4.2.4 Determine Continuous Business Value Assessment Technique

Value Chain diagram

• 35. Architectural Artifacts
  • 35.8 Viewpoints in Phase A
    • Value Chain Diagram

values

• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.4 Information Management Checklists
      • 48.5.4.1 Data Values

vehicle

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
      • 14.4.3.4 Assess Best Delivery Vehicle

vendor

• 26. Business Scenarios
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Increase Vendor Independence
• 42. Tools for Architecture Development
  • 42.3 Evaluation Criteria and Guidelines
    • 42.3.1 Tool Criteria
      • 42.3.1.6 Vendor Factors

versus

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign
• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.1 Data-Intensive versus Information-Intensive Software Systems

vertical

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Vertical Scope/Level of Detail

vertical scope

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Vertical Scope/Level of Detail

view

• 3. Definitions
  • 3.18 Architecture View
  • 3.88 View
• 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.2 View Creation Process
  • 35.15 Developing a Business Architecture View
    • 35.15.2 Developing the View

view, Acquirer

• 35. Architectural Artifacts
  • 35.22 Developing an Acquirer View

view, Communications Engineering

• 35. Architectural Artifacts
  • 35.19 Developing a Communications Engineering View

view, Data Flow

• 35. Architectural Artifacts
  • 35.20 Developing a Data Flow View

view, Enterprise Manageability

• 35. Architectural Artifacts
  • 35.21 Developing an Enterprise Manageability View

view, Enterprise Security

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View

viewpoint

• 3. Definitions
  • 3.89 Viewpoint
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.1 Select Reference Models, Viewpoints, and Tools
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.1 Select Reference Models, Viewpoints, and Tools
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.1 Select Reference Models, Viewpoints, and Tools
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.1 Select Reference Models, Viewpoints, and Tools
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
    • 35.1.1 Simple Example of a Viewpoint and View

viewpoints, examples

• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.1 Example of Views and Viewpoints

views

• 3. Definitions
  • 3.84 Taxonomy of Architecture Views
  • 3.88 View
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.3 Patterns and Views
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
  • 35.2 Developing Views in the ADM
  • 35.3 Views, Tools, and Languages
  • 35.4 Views and Viewpoints
    • 35.4.1 Example of Views and Viewpoints
    • 35.4.2 Views and Viewpoints in Enterprise Architecture

views, creation

• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.2 View Creation Process

views, examples

• 35. Architectural Artifacts
  • 35.4 Views and Viewpoints
    • 35.4.1 Example of Views and Viewpoints

views, guidelines

• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.1 General Guidelines

view, Software Engineering

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View

view, System Engineering

• 35. Architectural Artifacts
  • 35.18 Developing a System Engineering View

VII

• 45. Introduction
  • 45.2 Structure of Part VII

vision

• 3. Definitions
  • 3.19 Architecture Vision
• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.2 Creating the Architecture Vision
  • 7.4 Steps
    • 7.4.8 Develop Architecture Vision

volatility

• 40. Architecture Partitioning
  • 40.2 Characteristics of Solutions

volere

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Resources
      • 17.2.2.2 Volere Requirements Specification Template

warrant

• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
    • Identify actions/events that warrant logging for later review or triggering forensic processes

we

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"

what

• 1. Introduction
  • 1.2 Executive Overview
    • What is an enterprise? What is enterprise architecture?
    • What specifically would prompt me to develop an enterprise architecture?
    • What is an architecture framework?
• 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?
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
    • Determine "what can go wrong?"
  • 21.8 Phase C: Information Systems Architectures
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
    • Determine "what can go wrong?"
  • 21.9 Phase D: Technology Architecture
    • Determine "what can go wrong?"
  • 21.10 Phase E: Opportunities & Solutions
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Determine "what can go wrong?"
  • 21.12 Phase G: Implementation Governance
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"

what's

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?

where

• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify mitigating security measures, where justified by risk assessment
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.7 System Engineering/Overall Architecture Checklists
      • 48.5.7.6 COTS (where applicable)

which

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

who

• 1. Introduction
  • 1.2 Executive Overview
    • Who would benefit from using TOGAF?
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process

whom/how

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine whom/how much it is acceptable to inconvenience in utilizing security measures

why

• 1. Introduction
  • 1.2 Executive Overview
    • Why do I need an enterprise architecture?
    • Why do I need TOGAF as a framework for enterprise architecture?
• 4. Release Notes
  • 4.6 Why Join The Open Group?

will

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
  • 21.7 Phase B: Business Architecture
    • Determine who are the legitimate actors who will interact with the product/service/process
  • 21.9 Phase D: Technology Architecture
    • Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
  • 21.11 Phase F: Migration Planning
    • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

within

• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Extended Guidance on Adopting TOGAF within an Enterprise
• 20. Applying the ADM at Different Enterprise Levels
  • 20.4 ADM Cycle Approaches
    • 20.4.1 Using Iterations within a Single ADM Cycle
• 40. Architecture Partitioning
  • 40.4 Applying Classification to Create Partitioned Architectures
    • 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
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.4 Standards Classification within the Standards Information Base
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.1 Levels of Governance within the Enterprise

work

• 3. Definitions
  • 3.90 Work Package
• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.3 Requirements for Architecture Work
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 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

workflow

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
      • 13.4.6.3 Assess Workflow Dependencies

work package

• 3. Definitions
  • 3.90 Work Package

would

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?
    • Who would benefit from using TOGAF?

wrapping process

• 35. Architectural Artifacts
  • 35.16 Developing an Enterprise Security View
    • 35.16.5 Security Services Allocation
      • 35.16.5.2 Network Services

wrong

• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Determine the assets at risk if something goes wrong - "What are we trying to protect?"
    • Determine "what can go wrong?"
  • 21.8 Phase C: Information Systems Architectures
    • Determine "what can go wrong?"
  • 21.9 Phase D: Technology Architecture
    • Determine "what can go wrong?"
  • 21.10 Phase E: Opportunities & Solutions
    • Determine "what can go wrong?"
  • 21.11 Phase F: Migration Planning
    • Determine "what can go wrong?"
  • 21.12 Phase G: Implementation Governance
    • Determine "what has gone wrong?"
  • 21.13 Phase H: Architecture Change Management
    • Determine "what has gone wrong?"

WSDL definition

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract

XML

• 35. Architectural Artifacts
  • 35.17 Developing a Software Engineering View
    • 35.17.2 Key Issues
      • 35.17.2.2 Achieving Interoperability

XSD schema

• 22. Using TOGAF to Define & Govern SOAs
  • 22.9 Content and Structure of a Service Contract

your

• 39. Enterprise Continuum
  • 39.6 Enterprise Continuum and Your Organization
    • 39.6.2 Your Enterprise

Zachman Framework

• 5. Introduction
  • 5.3 Adapting the ADM