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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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 Packaged Services

a.63

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

a.64

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

a.6

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

a.65

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

a.66

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

a.67

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

a.68

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

a.69

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

a.70

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

a.71

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

a.72

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

a.73

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

a.74

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

a.7

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

a.75

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

a.76

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

a.77

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

a.78

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

a.79

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

a.80

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

a.81

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

a.82

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

a.83

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

a.84

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

a.8

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

a.85

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

a.86

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

a.87

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

a.88

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

a.89

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

a.90

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

a.91

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

a.92

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

a.9

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

ABB

• 3. Definitions
  • 3.9 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Absolute Protection

absolute protection

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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)

accessible

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles
      • Principle 12: Data is Accessible

access transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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)

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Achieving Interoperability

acknowledgements

• Frontmatter
  • Acknowledgements

ACL

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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.7 Recommended Architecture Views to be Developed
    • 35.7.8 Developing an Acquirer View

Acquirer view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.8 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
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review Consolidated Requirements Across Related Business Functions
• 20. Applying the ADM 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 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels
    • 22.6.2 SOA Activities at Different Levels
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned Architectures
    • 40.2.1 Activities within the Preliminary Phase

activity model

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

actor

• 3. Definitions
  • 3.2 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Actor/Role Matrix

Actor/Role matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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 and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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.11 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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

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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.5 Security Services Allocation
    • 35.7.5 Developing a Communications Engineering View
      • Allocation of Services to Components

amp

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan

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
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.4 Provide Analysis for Architecture Change Management
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders
      • 24.3.1.1 Sample Stakeholder Analysis
• 27. Gap Analysis

analyzing

• 26. Business Scenarios and Business Goals
  • 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

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

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s)
• 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.6 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.3 Application
  • 3.4 Application Architecture
  • 3.5 Application Platform
  • 3.6 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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.4 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Communication Diagram

application component

• 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/Data

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Application/Data Matrix

Application/Data matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Application/Data Matrix

Application/Function

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application/Function Matrix

Application/Function matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application/Function Matrix

Application Interaction matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Interaction Matrix

application logic

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Five-Tier

Application Migration diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Migration Diagram

Application/Organization

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application/Organization Matrix

Application/Organization matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application/Organization Matrix

Application Platform

• 3. Definitions
  • 3.5 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.6 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 5: Common Use 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 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

Application/Technology

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Application/Technology Matrix

Application/Technology matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Application/Technology Matrix

Application Use-Case diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Use-Case Diagram

applied

• 4. Release Notes
  • 4.1.1 Changes Applied in this Edition

applying

• 19. Applying Iteration to the ADM
• 20. Applying the ADM across the Architecture Landscape
• 23. Architecture Principles
  • 23.5 Applying Architecture Principles
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned Architectures

applying the ADM

• 20. Applying the ADM across the Architecture Landscape

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
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

• 19. Applying Iteration to the ADM
  • 19.4 Approaches to Architecture Development
• 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 Statement of Architecture Work; Secure Approval
• 41. Architecture Repository
  • 41.7 External Repositories
    • 41.7.3 Architecture Board Approvals

architect

• 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.7 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
• 18. Introduction
  • 18.3 Using TOGAF with Different Architectural Styles
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase

architectural artifact

• 35. Architectural Artifacts

architectural artifact, concepts

• 35. Architectural Artifacts
  • 35.1 Basic Concepts

architectural style

• 3. Definitions
  • 3.7 Architectural Style
• 18. Introduction
  • 18.3 Using TOGAF with Different Architectural Styles

architecture

• 1. Introduction
  • 1.2 Executive Overview
    • 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.4 Application Architecture
  • 3.8 Architecture
  • 3.9 Architecture Building Block (ABB)
  • 3.10 Architecture Continuum
  • 3.11 Architecture Development Method (ADM)
  • 3.12 Architecture Domain
  • 3.13 Architecture Framework
  • 3.14 Architecture Governance
  • 3.15 Architecture Landscape
  • 3.16 Architecture Principles
  • 3.17 Architecture Vision
  • 3.22 Business Architecture
  • 3.27 Capability Architecture
  • 3.32 Data Architecture
  • 3.36 Foundation Architecture
  • 3.62 Segment Architecture
  • 3.64 Service Oriented Architecture (SOA)
  • 3.65 Solution Architecture
  • 3.70 Strategic Architecture
  • 3.71 Target Architecture
  • 3.72 Taxonomy of Architecture Views
  • 3.73 Technology Architecture
  • 3.74 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.4 Architecture Domains

architecture artifacts

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase

Architecture Board

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

architecture building block

• 3. Definitions
  • 3.9 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
  • 2.8 Establishing and Maintaining an Enterprise Architecture Capability
• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
• 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 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 Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.10 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 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

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
  • 19.4 Approaches to Architecture Development
• 42. Tools for Architecture Development

Architecture Development Method

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

architecture development, techniques

• 18. Introduction
  • 18.2 Techniques for Architecture Development

architecture domain

• 3. Definitions
  • 3.12 Architecture Domain
• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Architecture Domains

architecture domains, security

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

architecture engagement

• 19. Applying Iteration to the ADM
  • 19.3 Classes of Architecture Engagement

Architecture Forum

• 1. Introduction

Architecture Framework

• 3. Definitions
  • 3.13 Architecture Framework

architecture governance

• 3. Definitions
  • 3.14 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.15 Architecture Landscape
• 20. Applying the ADM across the Architecture Landscape
  • 20.2 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 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.16 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 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.4 Architecture Repository
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.5 Architecture Repository
• 41. Architecture Repository
  • 41.1 Overview

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
• 20. Applying the ADM across the Architecture Landscape
  • 20.4 Developing Architectures at Different Levels
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase C: Information Systems Architectures
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Common Systems Architectures
      • Industry Architectures
      • Organization-Specific Architectures
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned Architectures

architecture, scoping

• 5. Introduction
  • 5.5 Scoping the Architecture

Architecture Skills Framework

• 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

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.3 Patterns and Views
• 35. Architectural Artifacts

Architecture Vision

• 3. Definitions
  • 3.17 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 and Business Goals
  • 26.7 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

artifact

• 2. Core Concepts
  • 2.5 Deliverables, Artifacts, and Building Blocks
• 3. Definitions
  • 3.18 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • SOA-Specific Phase C Artifacts
      • SOA-Specific Phase D Artifacts
      • SOA-Specific Phase E Artifacts
• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.2 Core Architecture Artifacts
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase

ARTS

• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.2 Approach
    • 10.2.2 Architecture Repository

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.5 Preliminary Phase
    • Define the required security capability as part of Architecture Capability
  • 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 and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

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
• 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

• 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
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
    • Identify mitigating security measures, where justified by risk assessment
• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment & Deduction Matrix
  • 28.5 Business Value Assessment Technique
• 30. Business Transformation Readiness Assessment
• 31. Risk Management
  • 31.4 Initial Risk Assessment
  • 31.5 Risk Mitigation and Residual Risk Assessment
  • 31.6 Conduct Residual Risk Assessment
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.10 Capability Assessment
    • 36.2.13 Compliance Assessment
    • 36.2.18 Requirements Impact Assessment
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Compliance Assessments

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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles
      • Principle 10: Data is an Asset

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 Work Package

assigned

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

assumptions

• 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

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 Vehicle

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
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase B: Business Architecture

background

• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
• 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.69 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.19 Baseline
• 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 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 first

• 19. Applying Iteration to the ADM
  • 19.4 Approaches to Architecture Development

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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed

benefit

• 1. Introduction
  • 1.2 Executive Overview
    • Who would benefit from using TOGAF?
• 4. Release Notes
  • 4.2 The Benefits of TOGAF 9
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 2: Maximize Benefit to the Enterprise
• 26. Business Scenarios and Business Goals
  • 26.2 Benefits of Business Scenarios
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
      • Benefits Diagram

between

• 19. Applying Iteration to the ADM
  • 19.5 Iteration Considerations
    • 19.5.1 Iteration between ADM Cycles
• 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.9 Architecture Building Block (ABB)
  • 3.21 Building Block
  • 3.66 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

• 41. Architecture Repository
  • 41.7 External Repositories
    • 41.7.3 Architecture Board Approvals
• 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

boundaryless

• 3. Definitions
  • 3.20 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.20 Boundaryless Information Flow

BPMN

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

breadth

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Breadth
• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise
• 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

breadth, enterprise

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.1 Breadth

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.9 Architecture Building Block (ABB)
  • 3.21 Building Block
  • 3.66 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.21 Building Block
• 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

bus

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus

business

• 3. Definitions
  • 3.22 Business Architecture
  • 3.23 Business Function
  • 3.24 Business Governance
  • 3.25 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.22 Business Architecture
• 8. Phase B: Business Architecture

Business Architecture view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View

Business Continuity Plan

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

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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Footprint Diagram

business function

• 3. Definitions
  • 3.23 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.24 Business Governance

Business Interaction matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Interaction Matrix

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

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.2 Phase A: Architecture Vision
      • 22.7.2.1 Stakeholders, Concerns, and Business Requirements
• 26. Business Scenarios and Business Goals

business scenarios

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.3 Resources
      • 17.2.3.1 Business Scenarios
• 26. Business Scenarios and Business Goals
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.8 Architecture Vision

business scenarios, descriptions

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

business scenarios, models

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

business scenarios, workshops

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

business service

• 3. Definitions
  • 3.25 Business Service
• 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Service/Function Catalog

Business Service/Information diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Use-Case Diagram

by

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Scope the enterprise organizations impacted by the security architecture
  • 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
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase

c

• 9. Phase C: Information Systems Architectures
• 10. Phase C: Information Systems Architectures - Data Architecture
• 11. Phase C: Information Systems Architectures - Application Architecture
• 21. Security Architecture and the ADM
  • 21.8 Phase C: Information Systems Architectures
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase C: Information Systems Architectures
      • SOA-Specific Phase C Artifacts

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?"

candidate

• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Candidate Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Candidate Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Candidate Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Candidate Roadmap Components

capabilities

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.4 Evaluate Business 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.26 Capability
  • 3.27 Capability Architecture
  • 3.28 Capability Increment
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define the required security capability as part of Architecture Capability
• 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.27 Capability Architecture
• 20. Applying the ADM across the Architecture Landscape
  • 20.2 Architecture Landscape
• 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.28 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

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.6 Architectural Artifacts by ADM Phase
    • 35.6.1 Preliminary Phase
      • Principles Catalog
    • 35.6.3 Phase B: Business Architecture
      • Organization/Actor Catalog
      • Driver/Goal/Objective Catalog
      • Role Catalog
      • Business Service/Function Catalog
      • Location Catalog
      • Process/Event/Control/Product Catalog
      • Contract/Measure Catalog
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Data Component Catalog
    • 35.6.5 Phase C: Application Architecture
      • Application Portfolio Catalog
      • Interface Catalog
    • 35.6.6 Phase D: Technology Architecture
      • Technology Standards Catalog
      • Technology Portfolio Catalog
    • 35.6.8 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 Architectural Artifacts by ADM Phase

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 and Business Goals
  • 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

Center of Excellence

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

centers

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

certification

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

chain

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • 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

• 4. Release Notes
  • 4.1.1 Changes Applied in this Edition
• 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
• 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

checking

• 26. Business Scenarios and Business Goals
  • 26.7 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

classes

• 19. Applying Iteration to the ADM
  • 19.3 Classes of Architecture Engagement

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.2 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.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Client/Server Model

client/server model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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.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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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

CoE

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus

common

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 5: Common Use Applications
    • 23.6.2 Data Principles
      • Principle 14: Common Vocabulary and Data Definitions
• 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

• 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.29 Communications and Stakeholder Management
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Communication Diagram
    • 35.6.6 Phase D: Technology Architecture
      • Communications Engineering Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • Communications Infrastructure
      • Communications Models
      • Communications Framework

Communications Engineering diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Communications Engineering Diagram

Communications Engineering view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View

communications framework

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • Communications Framework

Communications Infrastructure

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • 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.29 Communications and Stakeholder Management

communications model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • Communications Models

communications network

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.3 Basic Concepts
      • 35.7.2.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

complete

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned

compliance

• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.4 Perform Enterprise Architecture Compliance Reviews
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 7: Compliance with Law
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.13 Compliance Assessment
• 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 Candidate Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Candidate Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Candidate Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Candidate 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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Data Component Catalog
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • 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.63 Physical Application Component
  • A.64 Physical Data Component
  • A.65 Physical Technology Component
  • A.86 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 and Business Goals
  • 26.7 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Conceptual Data Diagram
• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure

Conceptual Data diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Conceptual Data Diagram

concerns

• 3. Definitions
  • 3.30 Concerns
• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.2 Phase A: Architecture Vision
      • 22.7.2.1 Stakeholders, Concerns, and Business Requirements
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
• 35. Architectural Artifacts
  • 35.1 Basic Concepts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.1 Stakeholders and Concerns
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.1 Stakeholders and Concerns
    • 35.7.3 Developing a Software Engineering View
      • 35.7.3.1 Stakeholders and Concerns
    • 35.7.4 Developing a System Engineering View
      • 35.7.4.1 Stakeholders and Concerns
    • 35.7.5 Developing a Communications Engineering View
      • 35.7.5.1 Stakeholders and Concerns
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.1 Stakeholders and Concerns
    • 35.7.7 Developing an Enterprise Manageability View
      • 35.7.7.1 Stakeholders and Concerns
    • 35.7.8 Developing an Acquirer View
      • 35.7.8.1 Stakeholders and Concerns

conclusion

• 19. Applying Iteration to the ADM
  • 19.6 Conclusions
• 30. Business Transformation Readiness Assessment
  • 30.7 Conclusion
• 35. Architectural Artifacts
  • 35.5 Conclusions
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 35.7.3.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.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
• 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 the Implementation and Migration Plan
    • 14.4.5 Confirm Architecture Roadmap and Update Architecture Definition Document
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
• 21. Security Architecture and the ADM
  • 21.7 Phase B: Business Architecture
    • Reassess and confirm Architecture Vision decisions

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
• 19. Applying Iteration to the ADM
  • 19.5 Iteration 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

consolidated

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review Consolidated Requirements Across Related Business Functions
• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, & 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.31 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

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
• 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 entities

• 34. Content Metamodel
  • 34.5 Content Metamodel Entities

content metamodel, extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions

content metamodel, vision and concepts

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

contents

• 26. Business Scenarios and Business Goals
  • 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 Tailor TOGAF and, if any, Other Selected 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.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
      • 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 4: Business Continuity

continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.10 Architecture Continuum
  • 3.35 Enterprise Continuum
  • 3.67 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

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.2 Architecture Contract
• 47. Architecture Board
  • 47.4 Operation of the Architecture Board
    • 47.4.3 Agenda
      • Contract Documentation Management
• 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
• A. Glossary of Supplementary Definitions
  • A.17 Contract

Contract/Measure

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Contract/Measure Catalog

Contract/Measure catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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
• 49. Architecture Contracts

contributions

• 26. Business Scenarios and Business Goals
  • 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 20: Control Technical Diversity
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus
    • 35.7.4 Developing a System Engineering View
      • 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
• 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

corporate governance

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

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?
• 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

• 26. Business Scenarios and Business Goals
  • 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.3 Resources
      • 17.2.3.2 Requirements Tools
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles
      • Principle 16: Technology Independence
• 26. Business Scenarios and Business Goals
  • 26.2 Benefits of Business Scenarios
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Achieving Interoperability
    • 35.7.8 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.11 Create the Architecture Roadmap & Implementation and Migration Plan
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned 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

creating

• 7. Phase A: Architecture Vision
  • 7.2 Approach
    • 7.2.2 Creating the Architecture Vision
• 26. Business Scenarios and Business Goals
  • 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

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

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 Complete the Architecture Development Cycle and Document Lessons Learned
• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
  • 19.5 Iteration Considerations
    • 19.5.1 Iteration between ADM Cycles
    • 19.5.2 Iteration within an ADM Cycle
• 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

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
• 21. Security Architecture and the ADM
  • 21.9 Phase D: Technology Architecture
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase D: Technology Architecture
      • SOA-Specific Phase D Artifacts

DAI

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Five-Tier
      • One Possible Instantiation of a DAI
      • DAIs Enable Flexibility

data

• 3. Definitions
  • 3.32 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Five-Tier

data access tier

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Some Uses of a Data Access Tier

data administration

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Administration

Data Architecture

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

database

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Administration

database management system

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

database services

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.2 Developing the View

database system

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Dictionary/Directory Systems
• A. Glossary of Supplementary Definitions
  • A.20 Data Dictionary

data directory

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Dictionary/Directory Systems

Data Dissemination diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Dissemination Diagram

data element

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

data encapsulation

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Three-Tier

data encryption

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Business Function Matrix

Data Entity/Data Component catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Data-Intensive versus Information-Intensive Software Systems

data-intensive software

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Security

Data Security diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Security Diagram

data standardization

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Management Systems

DBMS, flat files

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

DBMS, hierarchical model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

DBMS, network model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

DBMS, object-oriented model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

DBMS, relational model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

DBMSs

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Distributed DBMSs
      • Distributed Heterogeneous DBMSs

DD/DS

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Dictionary/Directory Systems

DDL

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Management Systems
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Functional Decomposition Diagram
      • Organization Decomposition Diagram
    • 35.6.6 Phase D: Technology Architecture
      • Platform Decomposition Diagram
• A. Glossary of Supplementary Definitions
  • A.35 Functional Decomposition

decrease

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

deduction

• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment & 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 Candidate Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Candidate Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Candidate Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Candidate Roadmap Components
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
    • Define the required security capability as part of Architecture Capability
  • 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 Architecture Roadmap and Update Architecture Definition Document
• 22. Using TOGAF to Define & Govern SOAs
  • 22.3 SOA 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles
      • Principle 14: Common Vocabulary and Data 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.33 Deliverable
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.4 Tailor Engagement Deliverables
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions

dependencies

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.6 Refine and Validate Dependencies
• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix

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

depth

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.2 Depth
• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise
• 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

depth, enterprise

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.2 Depth

derivation

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

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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels
    • 22.6.1 Level of Detail of Implementation Specification
• 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

• 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

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
• 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 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

developed

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed

developing

• 8. Phase B: Business Architecture
  • 8.2 Approach
    • 8.2.2 Developing the Baseline Description
• 20. Applying the ADM across the Architecture Landscape
  • 20.4 Developing Architectures at Different Levels
• 23. Architecture Principles
  • 23.4 Developing Architecture Principles
• 26. Business Scenarios and Business Goals
  • 26.7 Developing Business Scenarios
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.2 Developing the View

development

• 2. Core Concepts
  • 2.4 Architecture Development Method
• 3. Definitions
  • 3.11 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
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned
• 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
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Requirements Development
• 18. Introduction
  • 18.2 Techniques for Architecture Development
• 19. Applying Iteration to the ADM
  • 19.4 Approaches to 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Value Chain Diagram
      • Solution Concept Diagram
    • 35.6.3 Phase B: Business Architecture
      • 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.6.4 Phase C: Data Architecture
      • Conceptual Data Diagram
      • Logical Data Diagram
      • Data Dissemination Diagram
      • Data Security Diagram
      • Data Migration Diagram
      • Data Lifecycle Diagram
    • 35.6.5 Phase C: Application Architecture
      • Application Communication Diagram
      • Application and User Location Diagram
      • Application Use-Case Diagram
      • Enterprise Manageability Diagram
      • Process/Application Realization Diagram
      • Software Engineering Diagram
      • Application Migration Diagram
      • Software Distribution Diagram
    • 35.6.6 Phase D: Technology Architecture
      • Environments and Locations Diagram
      • Platform Decomposition Diagram
      • Processing Diagram
      • Networked Computing/Hardware Diagram
      • Communications Engineering Diagram
    • 35.6.7 Phase E: Opportunities and Solutions
      • Project Context Diagram
      • Benefits Diagram

dictionary

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

Dictionary/Directory

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Data Dictionary/Directory Systems

different

• 18. Introduction
  • 18.3 Using TOGAF with Different Architectural Styles
• 20. Applying the ADM across the Architecture Landscape
  • 20.4 Developing Architectures at Different Levels
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels
    • 22.6.2 SOA Activities at Different Levels

dimensions

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

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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Dissemination Diagram

distributed

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Distributed Object Management Model
    • 35.7.6 Developing a Data Flow View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Distributed DBMSs

distributed object management model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Distributed Object Management Model

distribution

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Software Distribution Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

diversity

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 20: Control Technical Diversity

DML

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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
• 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 Architecture Roadmap and Update Architecture Definition Document
    • 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned
• 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
    • Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
    • Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
  • 21.7 Phase B: Business Architecture
    • Identify and document interconnecting systems beyond project control
    • Identify and document the ownership of assets
    • 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
  • 21.8 Phase C: Information Systems Architectures
    • Determine and document the sensitivity or classification level of information stored/created/used
    • Identify and document custody of assets
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.3 Architecture Definition Document
• Frontmatter
  • Preface
    • This Document

documentation

• 26. Business Scenarios and Business Goals
  • 26.8 Business Scenario Documentation
    • 26.8.1 Textual Documentation

documenting

• 26. Business Scenarios and Business Goals
  • 26.7 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

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.12 Architecture Domain
• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.4 Architecture Domains
• 21. Security Architecture and the ADM
  • 21.3 Guidance on Security for the Architecture Domains
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Information Domains
• A. Glossary of Supplementary Definitions
  • A.40 Information Domain

downloads

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

DRDA

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • One Possible Instantiation of a DAI

driver

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

Driver/Goal/Objective

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Driver/Goal/Objective Catalog

Driver/Goal/Objective catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase E: Opportunities and Solutions
      • SOA-Specific Phase E Artifacts
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
• 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 Work Package
• 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 and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

EAP

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

Ease-of-Use

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles
      • Principle 17: Ease-of-Use

e-Business

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

edition

• 4. Release Notes
  • 4.1.1 Changes Applied in this Edition

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 and Business Goals
  • 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 and Business Goals
  • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • DAIs Enable Flexibility

enablement

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

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
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.1 Architecture Continuum
      • Industry Architectures

engagement

• 19. Applying Iteration to the ADM
  • 19.3 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Software Engineering Diagram
    • 35.6.6 Phase D: Technology Architecture
      • Communications Engineering Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
    • 35.7.4 Developing a System Engineering View
    • 35.7.5 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?
    • 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.34 Enterprise
  • 3.35 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
• 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
• 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
  • 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 across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Scope the enterprise organizations impacted by the security architecture
• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Enterprise Architecture and SOA
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 2: Maximize Benefit to the Enterprise
• 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Enterprise Manageability Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
    • 35.7.7 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 The Enterprise Continuum and the ADM
  • 39.6 The 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?

Enterprise Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.35 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 Manageability diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Enterprise Manageability Diagram

Enterprise Manageability view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.7 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 Repository

• 41. Architecture Repository
  • 41.1 Overview
  • 41.6 The Enterprise Repository

Enterprise Resource Planning system

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

Enterprise Security view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 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
  • 34.5 Content Metamodel Entities
• 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.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Business Function Matrix

Entity/Data

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Data Component Catalog

environment

• 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 and Business Goals
  • 26.7 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Environments and Locations Diagram

environment management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity

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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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
• 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 Vehicle

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

event

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Event Diagram
• A. Glossary of Supplementary Definitions
  • A.32 Event

Event diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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)

everybody's

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 3: Information Management is Everybody's Business

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

• 28. Migration Planning Techniques
  • 28.4 Transition Architecture State Evolution Table

example

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
• 26. Business Scenarios and Business Goals
  • 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
• 51. Architecture Maturity Models
  • 51.3 US DoC ACMM Framework
    • 51.3.3 Example: Enterprise Architecture Process Maturity Levels

excellence

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

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

• 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
• 41. Architecture Repository
  • 41.7 External Repositories
    • 41.7.1 External Reference Models
    • 41.7.2 External Standards

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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase F: Migration Planning
• 46. Establishing an Architecture Capability
  • 46.8 Phase F: Migration Planning

factor

• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment & 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

features

• 22. Using TOGAF to Define & Govern SOAs
  • 22.4 SOA Features

Federal Enterprise Architecture Business Reference Model

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

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 management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity

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

Fitness-for-Purpose

• 26. Business Scenarios and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Five-Tier

flexibility

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • DAIs Enable Flexibility

flow

• 3. Definitions
  • 3.20 Boundaryless Information Flow
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Process Flow Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 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

• 19. Applying Iteration to the ADM
  • 19.6 Conclusions
    • 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.7 Recommended Architecture Views to be Developed
    • 35.7.8 Developing an Acquirer View
      • Footnotes
• 37. Building Blocks
  • 37.3 Building Blocks and the ADM
    • 37.3.2 Building Block Specification Process in the ADM
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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 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.36 Foundation Architecture
• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.2 The ADM and the Foundation Architecture
• 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.36 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.13 Architecture Framework
  • 3.37 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 the Implementation and Migration Plan
• 33. Introduction
  • 33.3 Content Framework and the TOGAF ADM
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • Communications Framework
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.21 Tailored Architecture Framework
• 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
    • 50.2.2 Architecture Governance Framework - Organizational Structure

framework(s

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s)

frontmatter

• Frontmatter

full

• 34. Content Metamodel
  • 34.3 Content Metamodel in Detail
    • 34.3.3 Full Content Metamodel
• 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.23 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
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core Metamodel Entities
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 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

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Functional Decomposition Diagram
• A. Glossary of Supplementary Definitions
  • A.35 Functional Decomposition

functional decomposition

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

Functional Decomposition diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Functional Decomposition Diagram

functions

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review Consolidated Requirements Across Related Business 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase G: Implementation Governance
• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)
• 46. Establishing an Architecture Capability
  • 46.9 Phase G: Implementation Governance

gap

• 3. Definitions
  • 3.38 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
• 27. Gap Analysis

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

• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix

gateway

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Distributed Heterogeneous DBMSs

gathering

• 26. Business Scenarios and Business Goals
  • 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 and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.1 General Guidelines
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.1 General Guidelines
• 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 Implementation and Migration Plan

generic

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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 and Business Goals
  • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Goal/Objective/Service Diagram

Goal/Objective/Service diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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 and Business Goals
  • 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?

GOTS

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles
      • Principle 16: Technology Independence

govern

• 22. Using TOGAF to Define & Govern SOAs

governance

• 3. Definitions
  • 3.14 Architecture Governance
  • 3.24 Business Governance
  • 3.39 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.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.2 Governance and Support Strategy
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase G: Implementation Governance
• 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 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
• Frontmatter
  • About 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
• 26. Business Scenarios and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.1 General Guidelines
  • 26.9 Guidelines on Goals and Objectives
• 35. Architectural Artifacts
  • 35.2 Developing Views in the ADM
    • 35.2.1 General Guidelines
• 48. Architecture Compliance
  • 48.6 Architecture Compliance Review Guidelines
• A. Glossary of Supplementary Definitions
  • A.37 Guideline

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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase H: Architecture Change Management
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Distributed Heterogeneous DBMSs

hierarchic

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Master/Slave and Hierarchic Models

hierarchic model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Master/Slave and Hierarchic Models

High-Level

• 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

human

• 26. Business Scenarios and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Achieving Interoperability

IDEF

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

identification

• 31. Risk Management
  • 31.3 Risk 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.10 Identify Transition Architectures
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.2 Identify Deployment Resources and Skills
• 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
    • Identify and document interconnecting systems beyond project control
    • Identify and document the ownership of assets
    • Identify the criticality of the availability and correct operation of the overall service
  • 21.8 Phase C: Information Systems Architectures
    • Identify safe default actions and failure states
    • Identify and evaluate applicable recognized guidelines and standards
    • Identify and document custody of assets
    • Identify the criticality of the availability and correct operation of each function
    • Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
    • Identify lifespan of information used as defined by business needs and regulatory requirements
    • Identify actions/events that warrant logging for later review or triggering forensic processes
    • Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
    • Identify potential/likely avenues of attack
  • 21.9 Phase D: Technology Architecture
    • Identify and evaluate applicable recognized guidelines and standards
    • Identify methods to regulate consumption of resources
    • Identify the trust (clearance) level of:
    • Identify minimal privileges required for any entity to achieve a technical or business objective
    • Identify mitigating security measures, where justified by risk assessment
  • 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
  • 21.11 Phase F: Migration Planning
    • Identify correct secure installation parameters, initial conditions, and configurations
• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders

identifying

• 26. Business Scenarios and Business Goals
  • 26.7 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

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus

IEEE 1003.0

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

if

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s)
• 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 and Business Goals
  • 26.7 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
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Scope the enterprise organizations impacted by the security architecture

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.5 Preliminary Phase
    • Implement security architecture tools
  • 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

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.2 Determine Business Constraints for Implementation
    • 13.4.8 Formulate Implementation and Migration Strategy
    • 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
    • 14.4.6 Generate the Implementation and Migration Plan
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation

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 and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.1 Importance of Goals
    • 26.9.2 Importance of SMART Objectives

improve

• 26. Business Scenarios and Business Goals
  • 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

in

• 2. Core Concepts
  • 2.2 What is Architecture in the Context of TOGAF?
• 4. Release Notes
  • 4.1.1 Changes Applied in this Edition

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

• 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 and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Increase Vendor Independence

increment

• 3. Definitions
  • 3.28 Capability Increment

incremental change

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

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

independence

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.3 Application Principles
      • Principle 16: Technology Independence
• 26. Business Scenarios and Business Goals
  • 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.20 Boundaryless Information Flow
  • 3.40 Information
  • 3.41 Information Technology (IT)
  • 3.69 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
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Data-Intensive versus Information-Intensive Software Systems

information-intensive software

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

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

information technology

• 3. Definitions
  • 3.41 Information Technology (IT)

infrastructure

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.5 Infrastructure Consolidation Extensions
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus
    • 35.7.5 Developing a Communications Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Infrastructure Bus

infrastructure consolidation extensions

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

inheritance

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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
• 40. Architecture Partitioning
  • 40.3 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)

intellectual

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 9: Protection of Intellectual Property

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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Interaction Matrix
    • 35.6.5 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 the 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.6 Application Platform Interface (API)
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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.92 User Interface Service

Interface catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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

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.42 Interoperability
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 21: Interoperability
• 26. Business Scenarios and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Interoperability
• 29. Interoperability Requirements
  • 29.2 Defining Interoperability
  • 29.4 Refining Interoperability
  • 29.5 Determining Interoperability Requirements
  • 29.6 Reconciling 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

• 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)

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 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 3: Information Management is Everybody's Business
    • 23.6.2 Data Principles
      • Principle 10: Data is an Asset
      • Principle 11: Data is Shared
      • Principle 12: Data is Accessible
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Database Models

ISO

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

ISO/IEC 42010:2007

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

isolation

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Strict Isolation

issues

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.3 Key Issues
    • 35.7.3 Developing a Software Engineering View
      • 35.7.3.2 Key Issues
    • 35.7.4 Developing a System Engineering View
      • 35.7.4.2 Key Issues
    • 35.7.5 Developing a Communications Engineering View
      • 35.7.5.2 Key Issues
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.3 Key Issues
    • 35.7.7 Developing an Enterprise Manageability View
      • 35.7.7.3 Key Issues
    • 35.7.8 Developing an Acquirer View
      • 35.7.8.3 Key Issues
• 42. Tools for Architecture Development
  • 42.2 Issues in Tool Standardization

IT

• 3. Definitions
  • 3.41 Information Technology (IT)
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.5 Implement Business and IT Operations
• 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 8: IT Responsibility
• 26. Business Scenarios and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Effectiveness of IT Organization
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.4 IT Governance
      • 50.1.4.1 An IT Controls Framework - COBIT

iteration

• 19. Applying Iteration to the ADM
  • 19.2 Iteration Cycles
  • 19.5 Iteration Considerations
    • 19.5.1 Iteration between ADM Cycles
    • 19.5.2 Iteration within an ADM Cycle

iteration cycles

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

iteration of the ADM

• 19. Applying Iteration to the ADM

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

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
      • Principle 16: Technology Independence

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.3 Key Issues
    • 35.7.3 Developing a Software Engineering View
      • 35.7.3.2 Key Issues
    • 35.7.4 Developing a System Engineering View
      • 35.7.4.2 Key Issues
    • 35.7.5 Developing a Communications Engineering View
      • 35.7.5.2 Key Issues
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.3 Key Issues
    • 35.7.7 Developing an Enterprise Manageability View
      • 35.7.7.3 Key Issues
    • 35.7.8 Developing an Acquirer View
      • 35.7.8.3 Key Issues
• 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

• 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
• A. Glossary of Supplementary Definitions
  • A.47 Key Performance Indicator (KPI)

landscape

• 3. Definitions
  • 3.15 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
• 20. Applying the ADM across the Architecture Landscape
  • 20.2 Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

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

law

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 7: Compliance with Law

LCS

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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 Complete the Architecture Development Cycle and 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 Complete the Architecture Development Cycle and 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
• 20. Applying the ADM across the Architecture Landscape
  • 20.4 Developing Architectures at Different Levels
• 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:
• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels
    • 22.6.1 Level of Detail of Implementation Specification
    • 22.6.2 SOA Activities 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

• 26. Business Scenarios and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Reduce Lifecycle Costs
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Product Lifecycle Diagram
    • 35.6.4 Phase C: Data Architecture
      • Data Lifecycle Diagram
• 41. Architecture Repository
  • 41.4 Standards Information Base
    • 41.4.3 Standards Lifecycle
• 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

local subscriber environment

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.3 Basic Concepts

location

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Location Catalog
    • 35.6.5 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Location Catalog

Location diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Environments and Locations Diagram

locations

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.43 Logical
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Logical Data Diagram
• 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 Data diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.4 Phase C: Data Architecture
      • Logical Data Diagram

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

• 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

making

• 26. Business Scenarios and Business Goals
  • 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 and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Manageability
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Enterprise Manageability Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.7 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.29 Communications and Stakeholder Management
  • 3.52 Performance 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 the Implementation and Migration Plan
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.2 Enterprise Architecture Change Management Process
  • 16.4 Steps
    • 16.4.4 Provide Analysis for Architecture Change 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)

map

• 24. Stakeholder Management
  • 24.4 Template Stakeholder Map
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Stakeholder Map Matrix

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

marketing

• 30. Business Transformation Readiness Assessment
  • 30.6 Marketing the Implementation Plan

Master/Slave

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Master/Slave and Hierarchic Models

master/slave model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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 Architectural Artifacts by ADM Phase

matrix

• 28. Migration Planning Techniques
  • 28.1 Implementation Factor Assessment & Deduction Matrix
  • 28.2 Consolidated Gaps, Solutions, & 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.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Stakeholder Map Matrix
    • 35.6.3 Phase B: Business Architecture
      • Business Interaction Matrix
      • Actor/Role Matrix
    • 35.6.4 Phase C: Data Architecture
      • Data Entity/Business Function Matrix
      • Application/Data Matrix
    • 35.6.5 Phase C: Application Architecture
      • Application/Organization Matrix
      • Role/Application Matrix
      • Application/Function Matrix
      • Application Interaction Matrix
    • 35.6.6 Phase D: Technology Architecture
      • Application/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
• 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

maximize

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 2: Maximize Benefit to the Enterprise

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

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 and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.44 Metadata

metamodel

• 3. Definitions
  • 3.45 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.11 Architecture Development Method (ADM)
  • 3.46 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.47 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 Implementation and Migration Strategy
    • 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
    • 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
    • 14.4.6 Generate the Implementation and Migration Plan

Migration Planning

• 14. Phase F: Migration Planning
• 30. Business Transformation Readiness Assessment
  • 30.5 Readiness and Migration Planning

migration transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

• 3. Definitions
  • 3.48 Model
  • 3.49 Modeling
  • 3.57 Reference Model (RM)
• 26. Business Scenarios and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Client/Server Model
      • Peer-to-Peer Model
      • Distributed Object Management Model
    • 35.7.5 Developing a Communications Engineering View
      • 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.49 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
• 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 and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
  • 26.8 Business Scenario Documentation
    • 26.8.2 Business Scenario Models
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Master/Slave and Hierarchic Models
    • 35.7.5 Developing a Communications Engineering View
      • Communications Models
    • 35.7.6 Developing a Data Flow View
      • Database Models
• 41. Architecture Repository
  • 41.7 External Repositories
    • 41.7.1 External Reference Models
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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 and Business Goals
  • 26.7 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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.84 System and Network Management Service

networked

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Networked Computing/Hardware Diagram

Networked Computing/Hardware diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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

object

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Distributed Object Management Model

objective

• 3. Definitions
  • 3.50 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 and Business Goals
  • 26.7 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

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

obtain

• 21. Security Architecture and the ADM
  • 21.6 Phase A: Architecture Vision
    • Obtain management support for security measures

ODBC

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • One Possible Instantiation of a DAI

OLA

• 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.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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
• 34. Content Metamodel
  • 34.2 Content Metamodel Vision and Concepts
    • 34.2.1 Core Content Metamodel Concepts
      • Core and Extension Content
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Distributed Object Management Model

one

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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

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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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 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

• 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 and Business Goals
  • 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase E: Opportunities and Solutions
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
• 46. Establishing an Architecture Capability
  • 46.7 Phase E: Opportunities & Solutions

Opportunities & Solutions

• 13. Phase E: Opportunities & Solutions

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.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization
• 26. Business Scenarios and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Effectiveness of IT Organization
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Organization Decomposition Diagram
• 39. Enterprise Continuum
  • 39.6 The Enterprise Continuum and Your Organization

Organization/Actor

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Organization/Actor Catalog

Organization/Actor catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Organization/Actor Catalog

organizational

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.2 Organizational Context
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.16 Organizational Model for Enterprise Architecture
• 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Organization Decomposition Diagram

organizations

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.1 Scope the Enterprise Organizations Impacted
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Scope the enterprise organizations impacted by the security architecture

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

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

organizing

• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

orientation

• 3. Definitions
  • 3.63 Service Orientation
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 6: Service Orientation

oriented

• 3. Definitions
  • 3.64 Service Oriented Architecture (SOA)

OSI

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • 35.7.5.2 Key Issues
      • The OSI Reference Model

OSI Reference Model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • 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
• 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 and Business Goals
  • 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 across the Architecture Landscape
  • 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.77 Work Package
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Work Package

packaged

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

packaged services

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

packages

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages

paradigm

• 32. Capability-Based Planning
  • 32.2 Capability-Based Planning Paradigm

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
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define the required security capability as part of Architecture Capability
• 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

partition

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

partitioned

• 40. Architecture Partitioning
  • 40.2 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

partitions

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.3 Partitions and Centers of Excellence

partners

• 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.51 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.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

Peer-to-Peer

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • Peer-to-Peer Model

peer-to-peer model

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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.52 Performance Management
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets
• 26. Business Scenarios and Business Goals
  • 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.52 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.3 Time Period
• A. Glossary of Supplementary Definitions
  • A.87 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

• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.3 Governance and Personnel Scenarios

perspective

• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.2 Nature of Governance
      • 50.1.2.1 Governance: A Generic 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
• 14. Phase F: Migration Planning
• 15. Phase G: Implementation Governance
• 16. Phase H: Architecture Change Management
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
  • 21.6 Phase A: Architecture Vision
  • 21.7 Phase B: Business Architecture
  • 21.8 Phase C: Information Systems Architectures
  • 21.9 Phase D: Technology Architecture
  • 21.10 Phase E: Opportunities & Solutions
  • 21.11 Phase F: Migration Planning
  • 21.12 Phase G: Implementation Governance
  • 21.13 Phase H: Architecture Change Management
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
    • 22.7.2 Phase A: Architecture Vision
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase B: Business Architecture
      • Phase C: Information Systems Architectures
      • SOA-Specific Phase C Artifacts
      • Phase D: Technology Architecture
      • SOA-Specific Phase D Artifacts
      • Phase E: Opportunities and Solutions
      • SOA-Specific Phase E Artifacts
      • Phase F: Migration Planning
      • Phase G: Implementation Governance
      • Phase H: Architecture Change Management
• 31. Risk Management
  • 31.7 Risk Monitoring and Governance (Phase G)
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.1 Preliminary Phase
    • 35.6.2 Phase A: Architecture Vision
    • 35.6.3 Phase B: Business Architecture
    • 35.6.4 Phase C: Data Architecture
    • 35.6.5 Phase C: Application Architecture
    • 35.6.6 Phase D: Technology Architecture
    • 35.6.7 Phase E: Opportunities and Solutions

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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D

physical

• 3. Definitions
  • 3.53 Physical
• A. Glossary of Supplementary Definitions
  • A.63 Physical Application Component
  • A.64 Physical Data Component
  • A.65 Physical Technology Component

physical application component

• A. Glossary of Supplementary Definitions
  • A.63 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.64 Physical Data Component

physical technology component

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

place

• 26. Business Scenarios and Business Goals
  • 26.7 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.11 Create the Architecture Roadmap & Implementation and Migration Plan
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
    • 14.4.6 Generate the Implementation and Migration Plan
• 30. Business Transformation Readiness Assessment
  • 30.6 Marketing the Implementation Plan
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.12 Communications Plan
    • 36.2.14 Implementation and Migration Plan

planning

• 6. Preliminary Phase
  • 6.2 Approach
    • 6.2.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
• 14. Phase F: Migration Planning
• 21. Security Architecture and the ADM
  • 21.11 Phase F: Migration Planning
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase F: Migration Planning
• 28. Migration Planning Techniques
• 30. Business Transformation Readiness Assessment
  • 30.5 Readiness and Migration Planning
• 32. Capability-Based Planning
  • 32.2 Capability-Based Planning Paradigm
  • 32.3 Concept of Capability-Based Planning

plans

• 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.5 Application Platform
  • 3.6 Application Platform Interface (API)
  • 3.54 Platform
  • 3.55 Platform Service
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Platform Decomposition Diagram

platform service

• 3. Definitions
  • 3.55 Platform Service
• 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

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

policy

• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Define and document applicable regulatory and security policy requirements
• 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 and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve Portability and Scalability
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Portability
• 43. Foundation Architecture: Technical Reference Model
  • 43.2 High-Level Breakdown
    • 43.2.2 Portability and Interoperability
• A. Glossary of Supplementary Definitions
  • A.66 Portability

portfolio

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Application Portfolio Catalog
    • 35.6.6 Phase D: Technology Architecture
      • Technology Portfolio Catalog
• A. Glossary of Supplementary Definitions
  • A.67 Portfolio

portfolio management

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

positions

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

possible

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

• 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

• 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.1 Preliminary Phase
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned Architectures
    • 40.2.1 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

primary

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 1: Primary of Principles

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.68 PRINCE2

principle

• 3. Definitions
  • 3.16 Architecture Principles
  • 3.56 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.1 Principle of Service-Orientation
• 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.6 Architectural Artifacts by ADM Phase
    • 35.6.1 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

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 and Business Goals
  • 26.7 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 and Business Goals
  • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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.69 Process

Process/Application

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Process/Application Realization Diagram

Process/Application Realization diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Process/Application Realization Diagram

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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Process/Event/Control/Product Catalog

Process/Event/Control/Product catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Process/Event/Control/Product Catalog

Process Flow diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Process Flow Diagram

processing

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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 status

• 5. Introduction
  • 5.4 Architecture Governance

process tailoring

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Tailor TOGAF and, if any, Other Selected 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Product Lifecycle Diagram
• A. Glossary of Supplementary Definitions
  • A.70 Product

productivity

• 26. Business Scenarios and Business Goals
  • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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.71 Profile

profiling

• A. Glossary of Supplementary Definitions
  • A.72 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.73 Program

project

• 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.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
• 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
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
      • Project Context Diagram
• 52. Architecture Skills Framework
  • 52.5 Enterprise Architecture Role and Skill Definitions
    • 52.5.4 Program or Project Management Skills
  • 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
• A. Glossary of Supplementary Definitions
  • A.74 Project

Project Context diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
      • 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

• 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

prompt

• 1. Introduction
  • 1.2 Executive Overview
    • What specifically would prompt me to develop an enterprise architecture?

property

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 9: Protection of Intellectual Property

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

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 9: Protection of Intellectual Property
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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

• 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.17 Request for Architecture Work
      • Purpose
    • 36.2.18 Requirements Impact Assessment
      • Purpose
    • 36.2.20 Statement of Architecture Work
      • Purpose
    • 36.2.21 Tailored Architecture Framework
      • 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

• 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

• 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.80 Service Quality

quality management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity

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 and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area

ranking

• 26. Business Scenarios and Business Goals
  • 26.7 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

RDBMS

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Process/Application 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

recency

• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

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

recommended

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed

reconcile

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements

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 and Business Goals
  • 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.57 Reference Model (RM)
• 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.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • The OSI Reference Model
• 41. Architecture Repository
  • 41.3 Reference Library
  • 41.7 External Repositories
    • 41.7.1 External Reference Models
• 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.57 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 and Business Goals
  • 26.7 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

related

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.4 Review Consolidated Requirements Across Related Business Functions

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.6 The 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.4 Security Generic Architecture View

release

• 4. Release Notes

release notes

• 4. Release Notes

relocation transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

replication transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

reporting

• 50. Architecture Governance
  • 50.2 Architecture Governance Framework
    • 50.2.1 Architecture Governance Framework - Conceptual Structure
      • Monitoring and Reporting

repositories

• 41. Architecture Repository
  • 41.7 External Repositories

repository

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.58 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.4 Architecture Repository
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View
      • Repository
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.5 Architecture Repository
• 41. Architecture Repository
  • 41.6 The Enterprise Repository
    • 41.6.1 Requirements Repository
    • 41.6.2 Solutions 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.5 Preliminary Phase
    • Define the required security capability as part of Architecture Capability
  • 21.9 Phase D: Technology Architecture
    • Identify minimal privileges required for any entity to achieve a technical or business objective
• 26. Business Scenarios and Business Goals
  • 26.7 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

requirement

• 3. Definitions
  • 3.59 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.59 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 Consolidated Requirements Across Related Business Functions
    • 13.4.5 Consolidate and Reconcile Interoperability Requirements
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets
• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.2 Requirements Development
    • 17.2.3 Resources
      • 17.2.3.2 Requirements Tools

Requirements-Based

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 18: Requirements-Based Change

Requirements catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.8 Requirements Management
      • Requirements Catalog

Requirements Impact Assessment

• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.18 Requirements Impact Assessment

Requirements Repository

• 41. Architecture Repository
  • 41.6 The Enterprise Repository
    • 41.6.1 Requirements Repository

requirements tools

• 17. ADM Architecture Requirements Management
  • 17.2 Approach
    • 17.2.3 Resources
      • 17.2.3.2 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

• 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 Vehicle
• 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

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.3 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

responsibilities

• 26. Business Scenarios and Business Goals
  • 26.7 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

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 8: IT Responsibility
• 50. Architecture Governance
  • 50.1 Introduction
    • 50.1.5 Architecture Governance: Overview
      • 50.1.5.2 Architecture Governance as a Board-Level Responsibility

responsive

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 19: Responsive Change Management

results

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

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Modularity and Re-Use
• 39. Enterprise Continuum
  • 39.2 Enterprise Continuum and Architecture 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.3 Review and Consolidate Gap Analysis Results from Phases B to D
    • 13.4.4 Review Consolidated Requirements Across Related Business Functions
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.6 Perform Post-Implementation Review and Close the Implementation
• 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.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
• 48. Architecture Compliance
  • 48.4 Architecture Compliance Review Process
  • 48.5 Architecture Compliance Review Checklists
  • 48.6 Architecture Compliance Review Guidelines

reviewers

• Frontmatter
  • Participants
    • Architecture Forum Technical Reviewers

reviewing

• 26. Business Scenarios and Business Goals
  • 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.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
• 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 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
• 26. Business Scenarios and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Reduce Risk
• 31. Risk Management
  • 31.2 Risk Classification
  • 31.3 Risk Identification
  • 31.4 Initial Risk Assessment
  • 31.5 Risk Mitigation and Residual Risk Assessment
  • 31.6 Conduct Residual Risk Assessment
  • 31.7 Risk Monitoring and Governance (Phase G)

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.75 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.57 Reference Model (RM)

RM-ODP

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

roadmap

• 3. Definitions
  • 3.60 Roadmap
• 8. Phase B: Business Architecture
  • 8.4 Steps
    • 8.4.5 Define Candidate Roadmap Components
• 10. Phase C: Information Systems Architectures - Data Architecture
  • 10.4 Steps
    • 10.4.5 Define Candidate Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Candidate Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Candidate Roadmap Components
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Architecture Roadmap and Update Architecture Definition Document
• 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 Candidate Roadmap Components
• 11. Phase C: Information Systems Architectures - Application Architecture
  • 11.4 Steps
    • 11.4.5 Define Candidate Roadmap Components
• 12. Phase D: Technology Architecture
  • 12.4 Steps
    • 12.4.5 Define Candidate Roadmap Components

role

• 3. Definitions
  • 3.61 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.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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/Application

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Role/Application Matrix

Role/Application matrix

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Role/Application Matrix

Role catalog

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Role Catalog

roles

• 26. Business Scenarios and Business Goals
  • 26.7 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

RosettaNet

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

SA-CMM

• 51. Architecture Maturity Models
  • 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

sample

• 24. Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders
      • 24.3.1.1 Sample Stakeholder Analysis

SANS Institute

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 9: Protection of Intellectual Property

SBB

• 3. Definitions
  • 3.66 Solution Building Block (SBB)
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.1 Background
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.8 Developing an Acquirer View
      • 35.7.8.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 and Business Goals
  • 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.76 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.3 Resources
      • 17.2.3.1 Business Scenarios
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.3 Terminology
      • 25.1.3.4 Patterns and Business Scenarios
• 26. Business Scenarios and Business Goals
  • 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 Developing Business Scenarios
  • 26.8 Business Scenario Documentation
    • 26.8.2 Business Scenario Models

schedule

• 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
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Scope the enterprise organizations impacted by the security architecture
• 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

scoping

• 5. Introduction
  • 5.5 Scoping the Architecture

scoping the architecture

• 5. Introduction
  • 5.5 Scoping the Architecture

scripts

• 26. Business Scenarios and Business Goals
  • 26.7 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.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

secure

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop 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
    • Scope the enterprise organizations impacted by the security architecture
    • Define and document applicable regulatory and security policy requirements
    • Define the required security capability as part of Architecture Capability
    • Implement security architecture tools
    • 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Network Services

security context

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Operating System Services

security management

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • System Security Management Services

security mechanisms

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.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.62 Segment Architecture

Segment Architecture

• 3. Definitions
  • 3.62 Segment Architecture
• 20. Applying the ADM across the Architecture Landscape
  • 20.2 Architecture Landscape
• 41. Architecture Repository
  • 41.2 Architecture Landscape

SEI

• 51. Architecture Maturity Models
  • 51.2 Background

select

• 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

selected

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s)

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.89 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.78 Server

service

• 3. Definitions
  • 3.25 Business Service
  • 3.55 Platform Service
  • 3.63 Service Orientation
  • 3.64 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 6: Service Orientation
• 43. Foundation Architecture: Technical Reference Model
  • 43.4 Application Platform - Taxonomy
    • 43.4.2 Application Platform Service Categories
    • 43.4.3 Application Platform Service Qualities
      • 43.4.3.2 Taxonomy of Service Qualities

Service/Function

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Service/Function Catalog

Service/Information

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • 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 management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity

Service Management Repository

• 41. Architecture Repository
  • 41.1 Overview

service orientation

• 3. Definitions
  • 3.63 Service Orientation

service-orientation

• 22. Using TOGAF to Define & Govern SOAs
  • 22.5 Enterprise Architecture and SOA
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.1 Principle of Service-Orientation

Service Oriented Architecture

• 3. Definitions
  • 3.64 Service Oriented Architecture (SOA)

Service-Oriented Architecture

• 22. Using TOGAF to Define & Govern SOAs

service qualities

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

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

• 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.5 Security Services Allocation
      • Operating System Services
      • Network Services
      • System Security Management Services
    • 35.7.5 Developing a Communications Engineering View
      • Allocation of Services to Components
• 43. Foundation Architecture: Technical Reference Model
  • 43.3 TRM in Detail
    • 43.3.4 Application Platform
      • 43.3.4.3 Interfaces Between Services
  • 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.1 Data Interchange Services
    • 43.5.2 Data Management Services
    • 43.5.3 Graphics and Imaging Services
    • 43.5.4 International Operation Services
    • 43.5.5 Location and Directory Services
    • 43.5.6 Network Services
    • 43.5.7 Operating System Services
    • 43.5.8 Software Engineering Services
    • 43.5.9 Transaction Processing Services
    • 43.5.10 User Interface Services
    • 43.5.11 Security Services
    • 43.5.12 System and Network Management Services
    • 43.5.13 Object-Oriented Provision of Services
• 44. Integrated Information Infrastructure Reference Model
  • 44.3 Detailed Taxonomy
    • 44.3.4 Application Platform
      • 44.3.4.1 Software Engineering Services
      • 44.3.4.2 Security Services
      • 44.3.4.3 Location and Directory Services
      • 44.3.4.4 Human Interaction Services
      • 44.3.4.5 Data Interchange Services
      • 44.3.4.6 Data Management Services
      • 44.3.4.7 Additional Operating System Services
• 48. Architecture Compliance
  • 48.5 Architecture Compliance Review Checklists
    • 48.5.2 Software Services and Middleware Checklist
    • 48.5.4 Information Management Checklists
      • 48.5.4.5 Common Services
• A. Glossary of Supplementary Definitions
  • A.62 Packaged Services

services extensions

• 34. Content Metamodel
  • 34.4 Content Metamodel Extensions
    • 34.4.2 Services Extensions

services, network

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Network Services

services, operating system

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Operating System Services

services, system security management

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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

shared

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles
      • Principle 11: Data is Shared

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.69 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

size

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

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

• 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • System Security Management Services

SMART

• 26. Business Scenarios and Business Goals
  • 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.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • The OSI Reference Model

SOA

• 3. Definitions
  • 3.64 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 SOA Definition
  • 22.4 SOA Features
  • 22.5 Enterprise Architecture and SOA
  • 22.6 SOA and Levels
    • 22.6.2 SOA Activities at Different Levels

SOA levels

• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels

SOAs

• 22. Using TOGAF to Define & Govern SOAs

SOA-Specific

• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • SOA-Specific Phase C Artifacts
      • SOA-Specific Phase D Artifacts
      • SOA-Specific Phase E Artifacts

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.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Software Engineering Diagram
      • Software Distribution Diagram
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Modularity and Re-Use
      • Data-Intensive versus Information-Intensive Software Systems
      • Software Tiers

Software Distribution diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 Phase C: Application Architecture
      • Software Distribution Diagram

Software Engineering diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View

software modularity

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Modularity and Re-Use

software portability

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Portability

software re-use

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Modularity and Re-Use

software tiers

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Tiers

solution

• 3. Definitions
  • 3.65 Solution Architecture
  • 3.66 Solution Building Block (SBB)
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • 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.65 Solution Architecture

solution building block

• 3. Definitions
  • 3.66 Solution Building Block (SBB)
• 37. Building Blocks
  • 37.2 Introduction to Building Blocks
    • 37.2.4 Solution Building Blocks

Solution Concept diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Solution Concept Diagram

solutions

• 3. Definitions
  • 3.67 Solutions Continuum
• 13. Phase E: Opportunities & Solutions
• 15. Phase G: Implementation Governance
  • 15.4 Steps
    • 15.4.3 Guide Development of Solutions Deployment
• 21. Security Architecture and the ADM
  • 21.10 Phase E: Opportunities & Solutions
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.3 Architecture Development: Phases B, C, and D
      • Phase E: Opportunities and Solutions
• 28. Migration Planning Techniques
  • 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix
• 29. Interoperability Requirements
  • 29.6 Reconciling Interoperability Requirements with Potential Solutions
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.7 Phase E: Opportunities and Solutions
• 39. Enterprise Continuum
  • 39.4 Enterprise Continuum in Detail
    • 39.4.2 Solutions Continuum
      • Foundation Solutions
      • Common Systems Solutions
      • Industry Solutions
      • Organization-Specific Solutions

Solutions Continuum

• 2. Core Concepts
  • 2.6 Enterprise Continuum
• 3. Definitions
  • 3.67 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

Solutions Repository

• 41. Architecture Repository
  • 41.6 The Enterprise Repository
    • 41.6.2 Solutions Repository

some

• 25. Architecture Patterns
  • 25.4 Some Pattern Resources
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

• 22. Using TOGAF to Define & Govern SOAs
  • 22.6 SOA and Levels
    • 22.6.1 Level of Detail of Implementation Specification
• 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
• A. Glossary of Supplementary Definitions
  • A.58 Open Specifications

SQL

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.29 Communications and Stakeholder Management
  • 3.68 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.2 Phase A: Architecture Vision
      • 22.7.2.1 Stakeholders, Concerns, and Business Requirements
• 24. Stakeholder Management
  • 24.2 Approach to Stakeholder Management
  • 24.3 Steps in the Stakeholder Management Process
    • 24.3.1 Identify Stakeholders
      • 24.3.1.1 Sample Stakeholder Analysis
    • 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.29 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.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Stakeholder Map Matrix

stakeholders

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.2 Identify Stakeholders, Concerns, and Business Requirements
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.2 Phase A: Architecture Vision
      • 22.7.2.1 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.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.1 Stakeholders and Concerns
    • 35.7.2 Developing an Enterprise Security View
      • 35.7.2.1 Stakeholders and Concerns
    • 35.7.3 Developing a Software Engineering View
      • 35.7.3.1 Stakeholders and Concerns
    • 35.7.4 Developing a System Engineering View
      • 35.7.4.1 Stakeholders and Concerns
    • 35.7.5 Developing a Communications Engineering View
      • 35.7.5.1 Stakeholders and Concerns
    • 35.7.6 Developing a Data Flow View
      • 35.7.6.1 Stakeholders and Concerns
    • 35.7.7 Developing an Enterprise Manageability View
      • 35.7.7.1 Stakeholders and Concerns
    • 35.7.8 Developing an Acquirer View
      • 35.7.8.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.69 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Technology Standards Catalog
• 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 Information Base

• 2. Core Concepts
  • 2.7 Architecture Repository
• 3. Definitions
  • 3.69 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

• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise
• 28. Migration Planning Techniques
  • 28.4 Transition Architecture State Evolution Table

statement

• 7. Phase A: Architecture Vision
  • 7.4 Steps
    • 7.4.11 Develop 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
      • Principle 13: Data Trustee

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.70 Strategic Architecture

Strategic Architecture

• 3. Definitions
  • 3.70 Strategic Architecture
• 20. Applying the ADM across the Architecture Landscape
  • 20.2 Architecture Landscape
• 41. Architecture Repository
  • 41.2 Architecture Landscape

strategy

• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.8 Formulate Implementation and Migration Strategy
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.2 Governance and Support 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Strict Isolation

strict isolation

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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
• 33. Introduction
  • 33.4 Structure of Part IV
• 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.7 Architectural Style
• 4. Release Notes
  • 4.1 What's New in TOGAF 9?
    • Explicit Consideration of Architectural Styles, Including SOA and Security Architecture
• 18. Introduction
  • 18.3 Using TOGAF with Different Architectural Styles

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 and Business Goals
  • 26.7 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.8 Summary
• 26. Business Scenarios and Business Goals
  • 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.82 Supplier Management

supplier management

• 2. Core Concepts
  • 2.9 Establishing the Architecture Capability as an Operational Entity
• A. Glossary of Supplementary Definitions
  • A.82 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
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA
    • 22.7.1 Preliminary Phase
      • 22.7.1.2 Governance and Support Strategy

supporting

• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques

SW-CMM

• 51. Architecture Maturity Models
  • 51.4 Capability Maturity Models Integration (CMMI)
    • 51.4.1 Introduction

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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • Operating System Services
      • System Security Management Services
    • 35.7.4 Developing a System Engineering View
• 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.83 System
  • A.84 System and Network Management Service
  • A.85 System Stakeholder

system and network management service

• A. Glossary of Supplementary Definitions
  • A.84 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 Engineering view

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View

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

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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • System Security Management Services

system stakeholder

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

table

• 28. Migration Planning Techniques
  • 28.3 Architecture Definition Increments Table
  • 28.4 Transition 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 Tailor TOGAF and, if any, Other Selected 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.71 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.71 Target Architecture

Target Architecture Description

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Time Period

target first

• 19. Applying Iteration to the ADM
  • 19.4 Approaches to Architecture Development

targets

• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.5 Develop Change Requirements to Meet Performance Targets

taxonomy

• 3. Definitions
  • 3.72 Taxonomy of Architecture Views
• 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.72 Taxonomy of Architecture Views

TCP/IP

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View
      • The OSI Reference Model

team

• 6. Preliminary Phase
  • 6.4 Steps
    • 6.4.3 Define and Establish Enterprise Architecture Team and Organization

technical

• 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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.4 Technology Principles
      • Principle 20: Control Technical Diversity
• 26. Business Scenarios and Business Goals
  • 26.7 Developing Business Scenarios
    • 26.7.2 Questions to Ask for Each Area
      • Identifying the Business & Technical Environment, and Documenting in Models
• 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

• 43. Foundation Architecture: Technical Reference Model

technique

• 5. Introduction
  • 5.1 ADM Overview
    • 5.1.3 ADM and Supporting Guidelines and Techniques
• 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.41 Information Technology (IT)
  • 3.73 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.73 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

• 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.86 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • 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.6 Architectural Artifacts by ADM Phase
    • 35.6.6 Phase D: Technology Architecture
      • Technology Standards Catalog

TeleManagement Forum

• 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

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 Tailor TOGAF and, if any, Other Selected 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 and Business Goals
  • 26.8 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 and Business Goals
  • 26.7 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

• 4. Release Notes
  • 4.1.1 Changes Applied in this Edition
• 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

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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Software Tiers
      • Some Uses of a Data Access Tier

time

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Time Period
• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise
• A. Glossary of Supplementary Definitions
  • A.87 Time Period

time period

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Time Period
• A. Glossary of Supplementary Definitions
  • A.87 Time Period

time period, enterprise

• 5. Introduction
  • 5.5 Scoping the Architecture

timing

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
• 48. Architecture Compliance
  • 48.3 Architecture Compliance Reviews
    • 48.3.2 Timing

TMF

• 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

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 The Enterprise Continuum and the ADM

TOGAF TRM

• 12. Phase D: Technology Architecture
  • 12.2 Approach
    • 12.2.1 Architecture Repository
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View
      • 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.3 Resources
      • 17.2.3.2 Requirements Tools
• 21. Security Architecture and the ADM
  • 21.5 Preliminary Phase
    • Implement security architecture 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

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.88 Transaction
  • A.89 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.89 Transaction Sequence

transaction transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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
• 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.74 Transition Architecture
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.10 Identify Transition Architectures
• 28. Migration Planning Techniques
  • 28.4 Transition Architecture State Evolution Table

Transition Architecture

• 3. Definitions
  • 3.74 Transition Architecture

Transition Architecture Description

• 5. Introduction
  • 5.5 Scoping the Architecture
    • 5.5.3 Time Period

Transition Planning

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

transparency

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Distribution

treasury

• 25. Architecture Patterns
  • 25.2 US Treasury Architecture Development Guidance (TADG)

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

• 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
      • Principle 13: Data Trustee

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-Tier

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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

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

• 20. Applying the ADM across the Architecture Landscape
  • 20.3 Organizing the Architecture Landscape to Understand the State of the Enterprise

up

• 47. Architecture Board
  • 47.3 Setting Up the Architecture Board

update

• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.5 Confirm Architecture Roadmap and Update Architecture Definition Document

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
• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.1 Business Principles
      • Principle 5: Common Use Applications
• 25. Architecture Patterns
  • 25.1 Introduction
    • 25.1.4 Architecture Patterns in Use

Use-Case

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.3 Phase B: Business Architecture
      • Business Use-Case Diagram
    • 35.6.5 Phase C: Application Architecture
      • Application Use-Case Diagram
• A. Glossary of Supplementary Definitions
  • A.90 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 and Business Goals
  • 26.9 Guidelines on Goals and Objectives
    • 26.9.3 Categories of Goals and Objectives
      • Goal: Improve User Productivity
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.5 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.91 User
  • A.92 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.92 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • 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
• 18. Introduction
  • 18.3 Using TOGAF with Different Architectural Styles
• 22. Using TOGAF to Define & Govern SOAs
  • 22.7 Using TOGAF for SOA

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

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 Work Package
• 16. Phase H: Architecture Change Management
  • 16.4 Steps
    • 16.4.1 Establish Value Realization Process
• 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
• 28. Migration Planning Techniques
  • 28.5 Business Value Assessment Technique
• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • Value Chain Diagram

Value Chain diagram

• 35. Architectural Artifacts
  • 35.6 Architectural Artifacts by ADM Phase
    • 35.6.2 Phase A: Architecture Vision
      • 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 Vehicle

vendor

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

versus

• 16. Phase H: Architecture Change Management
  • 16.2 Approach
    • 16.2.3 Guidelines for Maintenance versus Architecture Redesign
• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Data-Intensive versus Information-Intensive Software Systems

view

• 3. Definitions
  • 3.75 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.7 Recommended Architecture Views to be Developed
    • 35.7.1 Developing a Business Architecture View
      • 35.7.1.2 Developing the View

view, Acquirer

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.8 Developing an Acquirer View

view, Communications Engineering

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.5 Developing a Communications Engineering View

view, Data Flow

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.6 Developing a Data Flow View

view, Enterprise Manageability

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.7 Developing an Enterprise Manageability View

view, Enterprise Security

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View

viewpoint

• 3. Definitions
  • 3.76 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.72 Taxonomy of Architecture Views
  • 3.75 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.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View

view, System Engineering

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.4 Developing a System Engineering View

VII

• 45. Introduction
  • 45.2 Structure of Part VII

vision

• 3. Definitions
  • 3.17 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

vocabulary

• 23. Architecture Principles
  • 23.6 Example Set of Architecture Principles
    • 23.6.2 Data Principles
      • Principle 14: Common Vocabulary and Data Definitions

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 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
• 19. Applying Iteration to the ADM
  • 19.5 Iteration Considerations
    • 19.5.2 Iteration within an ADM Cycle
• 40. Architecture Partitioning
  • 40.2 Applying Classification to Create Partitioned Architectures
    • 40.2.1 Activities within the Preliminary Phase
• 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.77 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 Statement of Architecture Work; Secure Approval
• 13. Phase E: Opportunities & Solutions
  • 13.4 Steps
    • 13.4.9 Identify and Group Major Work Packages
• 14. Phase F: Migration Planning
  • 14.4 Steps
    • 14.4.2 Assign a Business Value to Each Work Package
• 36. Architecture Deliverables
  • 36.2 Deliverable Descriptions
    • 36.2.17 Request for Architecture Work
    • 36.2.20 Statement of Architecture Work
• 49. Architecture Contracts
  • 49.2 Contents
    • 49.2.1 Statement of Architecture Work

work package

• 3. Definitions
  • 3.77 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.7 Recommended Architecture Views to be Developed
    • 35.7.2 Developing an Enterprise Security View
      • 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?"

XML

• 35. Architectural Artifacts
  • 35.7 Recommended Architecture Views to be Developed
    • 35.7.3 Developing a Software Engineering View
      • Achieving Interoperability

your

• 39. Enterprise Continuum
  • 39.6 The Enterprise Continuum and Your Organization
    • 39.6.2 Your Enterprise

Zachman Framework

• 5. Introduction
  • 5.3 Adapting the ADM