TOGAF 9

TOGAF 9

Get Started. It's Free
or sign up with your email address
TOGAF 9 by Mind Map: TOGAF 9

1. Publications

1.1. Part 1: Introduction

1.1.1. Definitions

1.1.1.1. TOGAF

1.1.1.1.1. Definition

1.1.1.1.2. Benefits of Adoption to TOGAF

1.1.1.1.3. Who would benefit from using TOGAF?

1.1.1.1.4. What Kind of Architecture Does TOGAF Deal With

1.1.1.2. Enterprise

1.1.1.2.1. “any collection of organizations that has a common set of goals”

1.1.1.3. Architecture

1.1.1.3.1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation

1.1.1.3.2. It defines the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

1.1.2. Why do we need Enterprise Architecture?

1.1.2.1. 1. Lower costs – development, maintenance, support

1.1.2.2. 2. Reduced complexity

1.1.2.3. 3. Reduced risk

1.1.2.4. 4. Simpler to add new systems

1.1.2.5. 5. Faster purchase and implementation

1.1.3. What is an Architecture Framework?

1.1.3.1. Def 1

1.1.3.1.1. A common vocabulary

1.1.3.1.2. A set of tools or building blocks

1.1.3.1.3. A set of recommended standards

1.1.3.1.4. A method for designing a target state of the enterprise

1.1.3.2. Def 2

1.1.3.2.1. An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures

1.1.3.2.2. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together

1.1.3.2.3. It should contain a set of tools and provide a common vocabulary

1.1.3.2.4. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

1.1.4. Core Concepts

1.1.4.1. Establishing the Architecture Capability as an Operational Entity, an enterprise architecture practice should establish capabilities in the following areas

1.1.4.1.1. Financial Management

1.1.4.1.2. Performance Management

1.1.4.1.3. Service Management

1.1.4.1.4. Risk Management

1.1.4.1.5. Resource Management

1.1.4.1.6. Communications and Stakeholder Management

1.1.4.1.7. Quality Management

1.1.4.1.8. Configuration Management

1.1.4.1.9. Supplier Management

1.1.4.1.10. Environment Management

1.2. Part 2: ADM

1.2.1. Intro

1.2.1.1. Overview

1.2.1.1.1. The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners.

1.2.1.1.2. It describes a method for developing and managing the lifecycle of an Enterprise Architecture, and forms the core of the TOGAF standard.

1.2.1.2. Architecture Development Cycle

1.2.1.2.1. A Preliminary Phase (only done once)

1.2.1.2.2. Eight phases (A-H) arranged in a cycle

1.2.1.2.3. All phases have inputs, steps and outputs

1.2.1.2.4. Outputs (deliverables) are in the form of documents, that get saved to the repository

1.2.1.2.5. ADM designed to be generic, to fit most enterprises, but can be modified or extended to meet a specific need

1.2.1.3. Scoping the Architecture

1.2.1.3.1. There are many reasons to constrain the scope of the architectural activity

1.2.1.3.2. Four dimensions are typically used in order to define and limit the scope

1.2.2. Architecture Development Cycle

1.2.2.1. The ADM is iterative, over the whole process, between phases and within phases

1.2.2.2. For each iteration of the ADM, a fresh decision must be taken as to

1.2.2.2.1. The breadth of coverage of the enterprise to be defined

1.2.2.2.2. The level of detail to be defined

1.2.2.2.3. The extent of the time period aimed at, including the number and extent of any intermediate time periods

1.2.2.2.4. The architectural assets to be leveraged, including:

1.2.2.3. These decisions should be based on a

1.2.2.3.1. Practical assessment of resource and competence availability,

1.2.2.3.2. The value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work.

1.2.2.4. As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

1.2.3. Phases

1.2.3.1. Preliminary Phase

1.2.3.1.1. Objectives

1.2.3.1.2. Approach

1.2.3.1.3. Steps

1.2.3.1.4. Output

1.2.3.2. Phase A: Architecture Vision

1.2.3.2.1. Objectives

1.2.3.2.2. Approach

1.2.3.2.3. Steps

1.2.3.2.4. Output

1.2.3.3. Phase B: Business Architecture

1.2.3.3.1. Summary

1.2.3.3.2. Inputs

1.2.3.3.3. Steps

1.2.3.3.4. Approach

1.2.3.3.5. Output

1.2.3.4. Phase C: Information Systems Architecture

1.2.3.4.1. Objectives

1.2.3.4.2. Steps

1.2.3.4.3. Approach

1.2.3.4.4. Information Systems Architecture

1.2.3.4.5. Data Architecture

1.2.3.4.6. Application Architecture

1.2.3.4.7. Outputs

1.2.3.5. Phase D: Technology Architecture

1.2.3.5.1. Objectives

1.2.3.5.2. Steps

1.2.3.5.3. Approach

1.2.3.5.4. Outputs

1.2.3.6. Phase E: Opportunities and Solutions

1.2.3.6.1. Intro

1.2.3.6.2. Objectives

1.2.3.6.3. Approach

1.2.3.6.4. Steps

1.2.3.6.5. Outputs

1.2.3.7. Phase F: Migration Planning

1.2.3.7.1. Intro

1.2.3.7.2. Objectives

1.2.3.7.3. Approach

1.2.3.7.4. Outputs

1.2.3.7.5. Steps

1.2.3.8. Phase H: Architecture Change Management

1.2.3.8.1. Objectives

1.2.3.8.2. Approach

1.2.3.8.3. Steps

1.2.3.8.4. Outputs

1.2.3.9. Requirements Management

1.2.3.9.1. Summary

1.2.3.9.2. Objectives

1.2.3.9.3. Approach

1.2.3.9.4. Steps

1.3. Part 3: ADM Guidelines and Techniques

1.3.1. 1. Applying Iteration to the ADM

1.3.1.1. Iteration Cycles

1.3.1.1.1. Architecture Capability Iteration

1.3.1.1.2. Architecture Development Iteration

1.3.1.1.3. Transition Planning Iteration

1.3.1.1.4. Architecture Governance Iteration

1.3.1.2. Classes of Architecture Engagement

1.3.1.2.1. Identification of Required Change

1.3.1.2.2. Definition of Change

1.3.1.2.3. Implementation of Change

1.3.1.3. Approaches to Architecture Development

1.3.1.3.1. Baseline First

1.3.1.3.2. Target First

1.3.2. 2. Applying the ADM at different Enterprise Levels

1.3.2.1. Strategic Architectures (executive level)

1.3.2.2. Segment Architectures (program or portfolio level)

1.3.2.3. Capability Architectures

1.3.3. 3. Security Architecture and the ADM

1.3.3.1. How to adapt the ADM for security

1.3.3.1.1. Preliminary Phase

1.3.3.1.2. Phase A

1.3.3.1.3. Phase B

1.3.3.1.4. Phase C

1.3.3.1.5. Phase D

1.3.3.1.6. Phase E

1.3.3.1.7. Phase F

1.3.3.1.8. Phase G

1.3.3.1.9. Phase H

1.3.3.2. Accepted areas of concern for the security architect

1.3.3.2.1. Authentication

1.3.3.2.2. Authorization

1.3.3.2.3. Audit

1.3.3.2.4. Assurance

1.3.3.2.5. Availability

1.3.3.2.6. Asset Protection

1.3.3.2.7. Administration

1.3.3.2.8. Risk Management

1.3.3.3. Typical security architecture artifacts

1.3.3.3.1. Business rules regarding handling of data/information assets

1.3.3.3.2. Written and published security policy

1.3.3.3.3. Codified data/information asset ownership and custody

1.3.3.3.4. Risk analysis documentation

1.3.3.3.5. Data classification policy documentation

1.3.4. 4. Using TOGAF to Define & Govern SOAs

1.3.4.1. A style of architecture that looks at all the functions of the system as services.

1.3.4.2. Services

1.3.4.2.1. Services: Self-contained Can call other services Is a black box to consumers of the service

1.3.4.2.2. Examples of Services:

1.3.4.3. Using TOGAF for SOA

1.3.4.3.1. Additional artifacts around services Content metamodel extensions

1.3.5. 5. Architecture Principles

1.3.5.1. Principle Components

1.3.5.1.1. Name

1.3.5.1.2. Statement

1.3.5.1.3. Rationale

1.3.5.1.4. Implications

1.3.5.2. Qualities

1.3.5.2.1. Understandable

1.3.5.2.2. Complete

1.3.5.2.3. Consistent

1.3.5.2.4. Stable

1.3.5.3. Two key domains inform the development and utilization of architecture:

1.3.5.3.1. Enterprise

1.3.5.3.2. Architecture

1.3.5.4. Example Set of Architecture Principles (BDAT)

1.3.5.4.1. Business Principles

1.3.5.4.2. Data Principles

1.3.5.4.3. Application Principles

1.3.5.4.4. Technology Principles

1.3.6. 6. Architecture Stakeholder Management

1.3.6.1. Stakeholder

1.3.6.1.1. Def.

1.3.6.1.2. examples

1.3.6.1.3. Sample Stakeholder Analysis

1.3.6.2. Technique

1.3.6.2.1. Identifying who they are in Phase A to identify key players, versus minor players

1.3.6.2.2. Classifying their positions

1.3.6.2.3. Determine stakeholder management approach

1.3.6.2.4. Tailor engagement deliverables

1.3.6.3. Approach to Stakeholder Management

1.3.6.3.1. View

1.3.6.3.2. Viewpoint

1.3.6.3.3. Concern

1.3.7. 7. Architecture Patterns

1.3.7.1. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in other

1.3.7.2. In TOGAF, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable solution to a problem.

1.3.7.3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.

1.3.8. 8. Business Scenarios

1.3.8.1. Introduction

1.3.8.1.1. Principally used in the

1.3.8.1.2. A business scenario describes:

1.3.8.1.3. A good Business Scenario

1.3.8.2. Benefits of Business Scenarios

1.3.8.2.1. A business scenario is essentially a complete description of a business problem, both in business and in architectural terms,

1.3.8.2.2. Without such a complete description to serve as context:

1.3.8.2.3. in communication with vendors.

1.3.8.3. Creating the Business Scenario

1.3.8.3.1. Overall Process

1.3.8.3.2. Phases

1.3.8.4. Contents of a Business Scenario

1.3.8.4.1. The documentation of a business scenario should contain all the important details about the scenario. It should capture, and sequence, the critical steps and interactions between actors that address the situation.

1.3.8.4.2. It should also declare all the relevant information about all actors, specifically: the different responsibilities of the actors; the key pre-conditions that have to be met prior to proper system functionality; and the technical requirements for the service to be of acceptable quality.

1.3.8.5. Contributions to the Business Scenario

1.3.8.6. Business Scenarios and the TOGAF ADM

1.3.8.6.1. Business scenarios figure most prominently in the initial phase of the Architecture Development Method (ADM), Architecture Vision, when they are used to define relevant business requirements, and to build consensus with business management and other stakeholders.

1.3.8.7. Developing Business Scenarios

1.3.8.8. Business Scenario Documentation

1.3.8.9. Guidelines on Goals and Objectives

1.3.9. 9. Gap Analysis

1.3.9.1. Business domain gaps:

1.3.9.1.1. People gaps (e.g., cross-training requirements)

1.3.9.1.2. Process gaps (e.g., process inefficiencies)

1.3.9.1.3. Tools gaps (e.g., duplicate or missing tool functionality)

1.3.9.1.4. Information gaps

1.3.9.1.5. Measurement gaps

1.3.9.1.6. Financial gaps

1.3.9.1.7. Facilities gaps (buildings, office space, etc.)

1.3.9.2. Data domain gaps:

1.3.9.2.1. Data not of sufficient currency

1.3.9.2.2. Data not located where it is needed

1.3.9.2.3. Not the data that is needed

1.3.9.2.4. Data not available when needed

1.3.9.2.5. Data not created

1.3.9.2.6. Data not consumed

1.3.9.2.7. Data relationship gaps

1.3.9.3. Applications impacted, eliminated, or created

1.3.9.4. Technologies impacted, eliminated, or created

1.3.10. 10. Migration Planning Techniques

1.3.10.1. Matries

1.3.10.1.1. 1. Implementation Factor Assessment & Deduction Matrix

1.3.10.1.2. 2. Consolidated Gaps, Solutions, & Dependencies Matrix

1.3.10.2. Tables

1.3.10.2.1. 3. Architecture Definition Increments Table

1.3.10.2.2. 4. Transition Architecture State Evolution Table

1.3.10.3. 5. Business Value Assessment Technique

1.3.10.3.1. A technique to assess business value is to draw up a matrix based on a value index dimension and a risk index dimension.

1.3.10.3.2. The value index should include criteria such as

1.3.10.3.3. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure.

1.3.10.3.4. Each criterion should be assigned an individual weight.

1.3.10.3.5. The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.

1.3.11. 11. Interoperability Requirements

1.3.11.1. Definitions

1.3.11.1.1. interoperability

1.3.11.2. Categories

1.3.11.2.1. Operational or Business Interoperability

1.3.11.2.2. Information Interoperability defines

1.3.11.2.3. Technical Interoperability

1.3.11.3. Enterprise Operating Model

1.3.11.4. Refining Interoperability

1.3.11.4.1. Implementing interoperability requires the creation, management, acceptance, and enforcement of realistic standards that are SMART

1.3.11.5. Determining Interoperability Requirements

1.3.11.6. Reconciling Interoperability Requirements with Potential Solutions

1.3.11.7. Summary

1.3.11.7.1. Defining interoperability in a clear unambiguous manner at several levels (business/service, information, and technical) is a useful architecture planning tool.

1.3.11.7.2. The notions of interoperability will become ever more important in the Service Oriented Architecture (SOA) environment where services will be shared internally and externally in ever more inter-dependent extended enterprises.

1.3.12. 12. Business Transformation Readiness Assessment

1.3.12.1. Introduction

1.3.12.1.1. Initial Business Transformation readiness assessment is carried out in Phase A of the TOGAF ADM

1.3.12.1.2. Understanding the readiness of the organization to accept change, identifying the issues, and then dealing with them in the Implementation and Migration Plans is key to successful architecture transformation in Phases E and F.

1.3.12.1.3. This will be a joint effort between corporate (especially human resources) staff, lines of business, and IT planners.

1.3.12.2. Recommended Activities

1.3.12.2.1. Determine the readiness factors that will impact the organization

1.3.12.2.2. Present the readiness factors using maturity models

1.3.12.2.3. Assess the readiness factors, including determination of readiness factor ratings

1.3.12.2.4. Assess the risks for each readiness factor and identify improvement actions to mitigate the risk

1.3.12.2.5. Work these actions into Phase E and F Implementation and Migration Plan

1.3.12.3. Business Transformation Enablement Program (BTEP)

1.3.12.3.1. The Canadian Government (BTEP) provides guidance on how to identify the business transformation-related issues.

1.3.12.4. Determine Readiness Factors

1.3.12.4.1. Vision

1.3.12.4.2. Desire, Willingness, and Resolve

1.3.12.4.3. Need

1.3.12.4.4. Business Case

1.3.12.4.5. Funding

1.3.12.4.6. Sponsorship and Leadership

1.3.12.4.7. Governance

1.3.12.4.8. Accountability

1.3.12.4.9. Workable Approach and Execution Model

1.3.12.4.10. IT Capacity to Execute

1.3.12.4.11. Enterprise Capacity to Execute

1.3.12.4.12. Enterprise Ability to Implement and Operate

1.3.12.5. Present Readiness Factors

1.3.12.5.1. Once the factors are determined, it is necessary to present them in such a way that the assessment is clear and the maximum value is derived from the participants.

1.3.12.5.2. One such presentation is through the use of maturity models that enable participants to:

1.3.12.5.3. example

1.3.12.6. Assess Readiness Factors

1.3.12.6.1. Readiness Factor Vision

1.3.12.6.2. Readiness Factor Rating

1.3.12.6.3. Readiness Factor Risks & Actions

1.3.12.7. Readiness and Migration Planning

1.3.12.7.1. The assessment exercise will provide a realistic assessment of the organization and will be a key input into the strategic migration planning that will be initiated in Phase E and completed in Phase F.

1.3.12.7.2. It is important to note whether the business transformation actions will be on the vision's critical path and, if so, determine how they will impact implementation.

1.3.12.8. Marketing the Implementation Plan

1.3.13. 13. Risk Management

1.3.13.1. Intro

1.3.13.1.1. Risk is pervasive in any enterprise architecture activity and present in all phases within the ADM.

1.3.13.1.2. There will always be risk with any architecture/business transformation effort. It is important to identify, classify, and mitigate these risks before starting so that they can be tracked throughout the transformation effort.

1.3.13.1.3. Mitigation is an ongoing effort and often the risk triggers may be outside the scope of the transformation planners (e.g., merger, acquisition) so planners must monitor the transformation context constantly.

1.3.13.1.4. Risk Levels

1.3.13.2. Risk Classification

1.3.13.2.1. Risk is pervasive in any enterprise architecture activity and is present in all phases within the Architecture Development Method (ADM). From a management perspective, it is useful to classify the risks so that the mitigation of the risks can be executed as expeditiously as possible.

1.3.13.2.2. Risks are normally classified as

1.3.13.3. Risk Identification

1.3.13.3.1. The maturity and transformation readiness assessments

1.3.13.3.2. Capability Maturity Models (CMMs)

1.3.13.3.3. Risk documentation

1.3.13.4. Initial Risk Assessment

1.3.13.4.1. Effect

1.3.13.4.2. Frequency

1.3.13.4.3. Combined

1.3.13.5. Risk Mitigation and Residual Risk Assessment

1.3.13.5.1. Risk mitigation refers to the identification, planning, and conduct of actions that will reduce the risk to an acceptable level.

1.3.13.5.2. The mitigation effort could be a simple monitoring and/or acceptance of the risk to a full-blown contingency plan calling for complete redundancy in a Business Continuity Plan (with all of the associated scope, cost, and time implications).

1.3.13.6. Conduct Residual Risk Assessment

1.3.13.6.1. Once the initial risk is mitigated, then the risk that remains is called the ‘‘residual risk’’. The key consideration is that the mitigating effort actually reduces the corporate impact and does not just move the risk to another similarly high quadrant.

1.3.13.7. Risk Monitoring and Governance (Phase G)

1.3.13.7.1. The residual risks have to be approved by the IT governance framework and potentially in corporate governance where business acceptance of the residual risks is required.

1.3.13.7.2. Once the residual risks have been accepted, then the execution of the mitigating actions has to be carefully monitored to ensure that the enterpr ise is dealing with residual rather than initial risk.

1.3.13.7.3. The risk identification and mitigation assessment worksheets are maintained as governance artifacts and are kept up-to-date in Phase G (Implementation Governance) where risk monitoring is conducted.

1.3.13.8. Initial Risk Assessment

1.3.13.8.1. Effect

1.3.13.8.2. Frequency

1.3.13.8.3. Combines (Effect+Frequency)

1.3.14. 14. Capability-Based Planning

1.3.14.1. Overview

1.3.14.1.1. Capability-Based Planning is a business planning technique that focuses on business outcomes.

1.3.14.1.2. Capability-based planning focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise.

1.3.14.1.3. It also copes well with the friction of co-ordinating projects across corporate functional domains that together enable the enterprise to achieve that capability

1.3.14.1.4. Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond is required and the same resources are involved in multiple capabilities.

1.3.14.2. Capability-Based Planning Paradigm

1.3.14.3. Concept of Capability-Based Planning

1.3.14.3.1. From an enterprise architecture and IT perspective, capability-based planning is a powerful mechanism to ensure that the strategic business plan drives the enterprise from a top-down approach. It is also adaptable with capability engineering to leverage emerging bottom-up innovations.

1.3.14.3.2. Capability Dimensions

1.3.14.3.3. Capability Increments

1.3.14.4. Capabilities in an Enterprise Architecture Context

1.3.14.5. Summary

1.3.14.6. Old

1.3.14.6.1. Intro

1.3.14.6.2. Concept of Capability-Based Planning

1.3.14.7. Links

1.4. Part 4: Architecture Content Framework

1.4.1. Intro.

1.4.1.1. This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables

1.4.1.2. Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc.

1.4.1.3. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented

1.4.2. Content Metamodel

1.4.2.1. 1. Overview

1.4.2.1.1. The content metamodel provides formal structure for these terms to ensure consistency within the ADM and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.

1.4.2.2. 2. Content Metamodel Vision and Concepts

1.4.2.2.1. 1. Core Content Metamodel Concepts

1.4.2.2.2. 2. Overview of the Content Metamodel

1.4.2.3. 3. Content Metamodel in Detail

1.4.2.3.1. Core Content Metamodel

1.4.2.3.2. Core Architecture Artifacts

1.4.2.3.3. Full Content Metamodel

1.4.2.4. 4. Content Metamodel Extensions

1.4.2.4.1. Governance Extensions

1.4.2.4.2. Services Extensions

1.4.2.4.3. Process Modeling Extensions

1.4.2.4.4. Data Extensions

1.4.2.4.5. Infrastructure Consolidation Extensions

1.4.2.4.6. Motivation Extensions

1.4.2.5. 5. Content Metamodel Entities

1.4.2.6. 6. Content Metamodel Attributes

1.4.2.7. 7. Metamodel Relationships

1.4.3. Architectural Artifacts

1.4.3.1. Classifications

1.4.3.1.1. Catalogs

1.4.3.1.2. Matrices

1.4.3.1.3. Diagrams

1.4.3.2. Artifacts

1.4.3.2.1. Preliminary Phase

1.4.3.2.2. Phase A, Architecture Vision

1.4.3.2.3. Phase B, Business Architecture

1.4.3.2.4. Phase C, Data Architecture

1.4.3.2.5. Phase C, Application Architecture

1.4.3.2.6. Phase D, Technology Architecture

1.4.3.2.7. Phase E. Opportunities & Solutions

1.4.3.2.8. Requirements Management

1.4.3.2.9. Others

1.4.4. Architecture Deliverables

1.4.4.1. 1. Architecture Building Blocks

1.4.4.1.1. characteristics:

1.4.4.1.2. contain the following, at a minimum

1.4.4.2. 2. Architecture Contract

1.4.4.2.1. Architecture Design and Development

1.4.4.2.2. Business Users' Architecture Contract

1.4.4.3. 3. Architecture Definition Document

1.4.4.3.1. is a companion to the Architecture Requirements Specification, with a complementary objective:

1.4.4.3.2. Def.

1.4.4.4. 4. Architecture Principles

1.4.4.5. 5. Architecture Repository

1.4.4.6. 6. Architecture Requirements Specification

1.4.4.6.1. provides

1.4.4.7. 7. Architecture Roadmap

1.4.4.7.1. Work package portfolio:

1.4.4.7.2. Implementation Factor Assessment and Deduction matrix, including:

1.4.4.7.3. Consolidated Gaps, Solutions, and Dependencies matrix, including:

1.4.4.7.4. Any Transition Architectures

1.4.4.7.5. Implementation recommendations:

1.4.4.8. 8. Architecture Vision

1.4.4.8.1. The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture.

1.4.4.8.2. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome.

1.4.4.8.3. Early agreement on the outcome enables the architects to focus on the detail necessary to validate feasibility.

1.4.4.8.4. Providing an Architecture Vision also supports stakeholder communication by providing a summary version of the full Architecture Definition.

1.4.4.9. 9. Business Principles, Business Goals, and Business Drivers

1.4.4.10. 10. Capability Assessment

1.4.4.10.1. Explanation

1.4.4.10.2. IT Capability Assessment

1.4.4.10.3. Architecture Maturity Assessment

1.4.4.10.4. Business Capability Assessment

1.4.4.11. 11. Communications Plan

1.4.4.11.1. Identification of stakeholders and grouping by communication requirements

1.4.4.11.2. Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and Critical Success Factors (CSFs)

1.4.4.11.3. Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.

1.4.4.11.4. Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location

1.4.4.12. 12. Compliance Assessment

1.4.4.12.1. Overview of project progress and status

1.4.4.12.2. Overview of project architecture/design

1.4.4.12.3. Completed architecture checklists:

1.4.4.13. 13. Implementation and Migration Plan

1.4.4.13.1. Implementation and Migration Strategy

1.4.4.13.2. Project and portfolio breakdown of implementation:

1.4.4.14. 14. Implementation Governance Model

1.4.4.14.1. Governance processes

1.4.4.14.2. Governance organization structure

1.4.4.14.3. Governance roles and responsibilities

1.4.4.14.4. Governance checkpoints and success/failure criteria

1.4.4.15. 15. Organizational Model for Enterprise Architecture

1.4.4.15.1. Scope of organizations impacted

1.4.4.15.2. Maturity assessment, gaps, and resolution approach

1.4.4.15.3. Roles and responsibilities for architecture team(s)

1.4.4.15.4. Constraints on architecture work

1.4.4.15.5. Budget requirements

1.4.4.15.6. Governance and support strategy

1.4.4.16. 16. Request for Architecture Work

1.4.4.16.1. Organization sponsors

1.4.4.16.2. Organization's mission statement

1.4.4.16.3. This is the request sent from the sponsoring organization (business sponsor) to the architecture group to request that architecture work be done.It is a high-level new project request.

1.4.4.16.4. Business goals (and changes)

1.4.4.16.5. Strategic plans of the business

1.4.4.16.6. Time limits

1.4.4.16.7. Changes in the business environment

1.4.4.17. 17. Change Request

1.4.4.18. 18. Requirements Impact Assessment

1.4.4.18.1. Reference to specific requirements

1.4.4.18.2. Stakeholder priority of the requirements to date

1.4.4.18.3. Phases to be revisited

1.4.4.18.4. Phase to lead on requirements prioritization

1.4.4.18.5. Results of phase investigations and revised priorities

1.4.4.18.6. Recommendations on management of requirements

1.4.4.18.7. Repository reference number

1.4.4.19. 19. Solution Building Blocks

1.4.4.19.1. Characteristics

1.4.4.19.2. Contents

1.4.4.20. 20. Statement of Architecture Work

1.4.4.20.1. Title

1.4.4.20.2. Architecture project request and background

1.4.4.20.3. Architecture project description and scope

1.4.4.20.4. Overview of Architecture Vision

1.4.4.20.5. Specific change of scope procedures

1.4.4.20.6. Roles, responsibilities, and deliverables

1.4.4.20.7. Acceptance criteria and procedures

1.4.4.20.8. Architecture project plan and schedule

1.4.4.20.9. Approvals

1.4.4.21. 21. Tailored Architecture Framework

1.4.4.21.1. Tailored architecture method

1.4.4.21.2. Tailored architecture content (deliverables and artifacts)

1.4.4.21.3. Configured and deployed tools

1.4.4.21.4. Interfaces with governance models and other frameworks

1.4.5. Building Blocks

1.4.5.1. Characteristics

1.4.5.1.1. is a package of functionality defined to meet the business needs across an organization.

1.4.5.1.2. has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

1.4.5.1.3. has a defined boundary and is generally recognizable as "a thing" by domain experts.

1.4.5.1.4. A building block may interoperate with other, inter-dependent, building blocks

1.4.5.2. A good building block has the following characteristics:

1.4.5.2.1. It considers implementation and usage, and evolves to exploit technology and standards.

1.4.5.2.2. It may be assembled from other building blocks.

1.4.5.2.3. It may be a subassembly of other building blocks.

1.4.5.2.4. Ideally a building block is re-usable and replaceable, and well specified

1.4.5.3. Architecture Building Blocks

1.4.5.3.1. Characteristics

1.4.5.4. Solution Building Blocks

1.4.5.4.1. Characteristics

1.4.5.4.2. The first occurence of Solution building blocks happen in Phase E

1.4.5.5. Building Block Specification Process in the ADM

1.4.5.5.1. The process of building block definition takes place gradually as the ADM is followed, mainly in Phases A, B, C, and D.

1.4.5.5.2. The major work in these steps consists of identifying the ABBs required to meet the business goals and objectives.

1.4.5.5.3. The selected set of ABBs is then refined in an iterative process to arrive at a set of SBBs which can either be bought off-the-shelf or custom developed.

1.4.5.5.4. It is an iterative process because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of products may affect the choice and the content of building blocks.

1.5. Part 5: Enterprise Continuum and Tools

1.5.1. Architecture Continuum

1.5.1.1. Foundation Architecture

1.5.1.2. Common Systems Architecture

1.5.1.3. Industry Architecture

1.5.1.4. Organization-Specific Architecture

1.5.2. Architecture Repository

1.5.2.1. Architecture

1.5.2.1.1. Metamodel

1.5.2.1.2. Capability

1.5.2.1.3. Landscape

1.5.2.2. SIB

1.5.2.3. Reference Library

1.5.2.4. Governance Log

1.5.3. Solutions Continuum

1.5.3.1. Foundation Solutions

1.5.3.2. Common Systems Solutions

1.5.3.3. Industry Solutions

1.5.3.4. Organization-Specific Solutions

1.5.4. Architecture Partitioning

1.5.4.1. Reasons

1.5.4.1.1. Two units within the same organization have conflicting architectures

1.5.4.1.2. Different teams need to work on different elements of the same architecture at the same time

1.5.4.1.3. Having a modular architecture supports the concept of re-usable building blocks

1.5.4.2. Architectural Landscape:

1.5.4.2.1. Strategic architecture (enterprise)

1.5.4.2.2. Segment architecture (group)

1.5.4.2.3. Capability architecture (project or portfolio)

1.5.4.3. Integration Risks:

1.5.4.3.1. If one project team has an “8” architecture maturity, and another has a “3”

1.5.4.3.2. Disjointed, fragmented architecture that cannot be integrated to form one overall architecture

1.5.4.4. What is needed:

1.5.4.4.1. Architecture standards across the organization

1.5.4.4.2. Enforced by proper architecture governance

1.5.4.4.3. Standard catalog of building blocks for project teams to choose from

1.5.4.5. Explanation

1.5.4.5.1. Architecture Partitioning is the practice of dividing up an enterprise architecture in a logical manner between two or more groups

1.5.4.5.2. There is no “one size fits all” way to partition an architecture, It’s highly customized to each organization structure and scenario

1.5.4.5.3. The enterprise continuum is a catalog of building blocks organized from highly-generic to organization-specific

1.5.4.5.4. Keeping metadata on each building block helps classify it for the purposes of partitioning:

1.5.4.5.5. Subject matter (breadth), time, maturity/volatility, depth

1.5.4.5.6. Architectures can be partitioned based on this criteria.

1.6. Part 6 TOGAF Reference Models

1.6.1. Foundation Architecture: TRM

1.6.1.1. Intro

1.6.1.1.1. The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built.

1.6.1.1.2. It's considered for use in this phase C. It focuses on the application-level components and services necessary to provide an integrated information infrastructure.

1.6.1.2. TRM

1.6.1.2.1. TRM in Detail

1.6.1.2.2. Provide a visual model, and core terminology for generic platform services

1.6.1.2.3. Provides a database of standards that can be used to define the particular services and other components of an organization-specific architecture that is derived from the TOGAF Foundation Architecture

1.6.1.3. SIB

1.6.2. Integrated Information Infrastructure Reference Model) III-RM

1.6.2.1. Boundaryless Information Flow

1.7. Part 7: Architecture Capability Framework

1.7.1. Overview

1.7.1.1. In order to successfully operate an architecture function within an enterprise, it is necessary to put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability.

1.7.1.2. Part VII: Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.

1.7.2. Establishing an Architecture Capability

1.7.2.1. Can be supported by the TOGAF Architecture Development Method (ADM).

1.7.2.2. Require the design of the four domain architectures

1.7.3. Architecture Board

1.7.3.1. Responsibilities

1.7.3.1.1. Common Goals

1.7.3.1.2. Operational

1.7.3.1.3. Governance

1.7.3.2. Role

1.7.3.2.1. A key element in a successful architecture governance strategy (see 50. Architecture Governance) is a cross-organization Architecture Board to oversee the implementation of the strategy

1.7.3.2.2. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.

1.7.3.2.3. levels

1.7.3.3. Setting Up the Architecture Board

1.7.3.3.1. Triggers

1.7.3.3.2. Sponsorship

1.7.3.3.3. Size of the Board

1.7.4. Architecture Compliance

1.7.4.1. Terminology

1.7.4.1.1. Irrelevant

1.7.4.1.2. Consistent

1.7.4.1.3. Compliant

1.7.4.1.4. Conformanance

1.7.4.2. Architecture Compliance Reviews

1.7.4.2.1. Purpose

1.7.4.2.2. Timing

1.7.4.2.3. Governance and Personnel Scenario

1.7.4.2.4. Architecture Compliance Review Process

1.7.5. Architecture Contracts

1.7.5.1. Architecture Contracts are the joint agreements between development partners and sponsors on the:

1.7.5.1.1. Deliverables

1.7.5.1.2. Quality

1.7.5.1.3. Fitness-for-purpose of an architecture

1.7.5.2. Successful implementation of these agreements will be delivered through effective architecture governance

1.7.6. Architecture Governance

1.7.6.1. Hierarchy of Governance:

1.7.6.1.1. Corporate Governance (Executive Team & Board of Directors)

1.7.6.1.2. Technology Governance

1.7.6.1.3. IT Governance

1.7.6.1.4. Architecture Governance

1.7.6.2. Characteristics of Governance

1.7.6.2.1. Discipline

1.7.6.2.2. Transparency

1.7.6.2.3. Independence

1.7.6.2.4. Accountability

1.7.6.2.5. Responsibility

1.7.6.2.6. Fairness

1.7.6.3. Architecture Governance Framework

1.7.6.3.1. Processes

1.7.6.3.2. Architecture Governance Organization

1.7.7. Architecture Maturity Models

1.7.7.1. Capability Maturity Models (CMMs)

1.7.7.1.1. They describe the practices that any organization must perform in order to improve its processes.

1.7.7.1.2. They provide a yardstick against which to periodically measure improvement.

1.7.7.1.3. They constitute a proven framework within which to manage the improvement efforts

1.7.7.1.4. They organize the various practices into levels, each level representing an increased ability to control and manage the development environment.

1.7.8. Architecture Skills Framework

1.7.8.1. Provide a view of the competency levels required for specific roles

1.7.8.1.1. The roles within a work area

1.7.8.1.2. The skills required by each role

1.7.8.1.3. The depth of knowledge required to fulfil the role successfully

1.7.8.2. Goals

1.7.8.2.1. Certification of Enterprise Architects

1.7.8.2.2. Specific Benefits

1.7.8.3. Enterprise Architecture Role and Skill Categories

1.7.8.3.1. Overview

1.7.8.3.2. TOGAF Roles

1.7.8.3.3. Categories of Skills

1.7.8.3.4. Proficiency Levels

1.7.8.4. Enterprise Architecture Role and Skill Categories

2. Exams

2.1. Part 1

2.1.1. Part 1 Exam

2.1.2. Questions and Answers

2.2. Part 2