TOGAF Foundation Exam Cheatsheet - Comprehensive Edition

Overview of TOGAF
The Open Group Architecture Framework (TOGAF) is an enterprise architecture framework that provides
an approach for designing, planning, implementing, and governing an enterprise information technology
architecture.

Definition of Enterprise Architecture

Enterprise Architecture is a conceptual blueprint that defines the structure and operation of an organization. The
intent is to determine how the organization can most effectively achieve its current and future objectives.

Key Benefits of TOGAF

Reduced Complexity - Provides systematic approach to reduce IT complexity
Lower Risk - Proven methodology reduces implementation risks

Improved Efficiency - Streamlines business processes and IT operations

Better Decision Making - Provides clear information for strategic decisions

Enhanced Communication - Common language between business and IT

Compliance - Helps meet regulatory and governance requirements
Cost Reduction - Eliminates redundancy and improves resource utilization

TOGAF Structure
TOGAF consists of:

1. Architecture Development Method (ADM) - The core methodology

2. Enterprise Continuum & Tools - Classification system for assets

3. TOGAF Reference Models - Foundation and integrated information infrastructure

4. Architecture Capability Framework - Organizational structures and roles

Architecture Development Method (ADM) - Detailed

The ADM is the core of TOGAF - a step-by-step approach to developing enterprise architecture.

ADM Cycle Diagram

[PRELIMINARY PHASE]
|
[A: ARCHITECTURE VISION]
/\
/ \
 [H: CHANGE] [B: BUSINESS]
MANAGEMENT ARCHITECTURE
| |
| |
[G: IMPLEMENTATION] [C: INFORMATION]
GOVERNANCE SYSTEMS ARCH
| |
| |
[F: MIGRATION] [D: TECHNOLOGY]
PLANNING ARCHITECTURE
\ /
\/
[E: OPPORTUNITIES & SOLUTIONS]

[REQUIREMENTS MANAGEMENT - CENTER OF ALL]

Detailed Phase Breakdown

Preliminary Phase: Framework and Principles

Objective: Prepare and initiate architecture activities

Key Activities:

Define enterprise architecture framework

Define architecture principles

Establish governance framework

Evaluate enterprise context and requirements

Establish architecture capability

Key Inputs:

TOGAF framework
Other architecture frameworks

Board strategies and business plans

Business principles, goals, and drivers

Governance and legal framework

Key Outputs:

Architecture Framework tailored for organization

Architecture Principles

Initial Architecture Repository

 Business principles, goals, and business drivers

Architecture governance framework

Critical Success Factors:

Senior management commitment

Clear business drivers

Appropriate organizational structure

Phase A: Architecture Vision

Objective: Set scope, constraints, and expectations for architecture project

Key Activities:

Establish project scope

Confirm business goals and drivers

Define stakeholders and their requirements

Develop Architecture Vision

Define architecture work statement

Secure approval for Statement of Architecture Work

Key Inputs:

Request for Architecture Work

Business principles, goals, and drivers

Organizational Model for Enterprise Architecture

Tailored Architecture Framework

Key Outputs:

Approved Statement of Architecture Work

Architecture Vision including:

Problem description

Objective of Statement of Architecture Work

Summary of changes to enterprise

Business requirements

Architecture requirements

Gap analysis results

Impact assessment
 Communications Plan

Additional content in Architecture Repository

Stakeholder Analysis Matrix:

Stakeholder Interest Influence Strategy

Business Executives High High Manage Closely

IT Management High Medium Keep Satisfied

End Users Medium Low Keep Informed

External Partners Low Medium Monitor

 

Phase B: Business Architecture

Objective: Develop target Business Architecture supporting Architecture Vision

Key Activities:

Select reference models, viewpoints, and tools

Develop baseline Business Architecture description

Develop target Business Architecture description

Perform gap analysis

Define candidate roadmap components

Resolve impacts across Architecture Landscape

Conduct formal stakeholder review

Finalize Business Architecture

Create Architecture Definition Document

Business Architecture Deliverables:

Business Architecture Models:

Organization/Actor catalog
Business Service/Function catalog

Location catalog
Process/Event/Control/Product catalog

Business Interaction matrix

Actor/Role matrix

Business Service/Information matrix

Business Process Modeling Example:

 Order Process Flow:
[Customer] -> [Order Entry] -> [Inventory Check] -> [Payment Processing] -> [Fulfillment] -> [Delivery]
| | | | | |
Inputs: Validate Check Stock Process Payment Pick & Pack Ship Order
Order Info Customer Available Secure Payment Warehouse Logistics
Payment Order Details Update Inventory Update Account Activities Tracking

Phase C: Information Systems Architectures

Split into two parts: Data Architecture and Application Architecture

Phase C1: Data Architecture

Develop baseline Data Architecture description

Consider data management implications

Develop target Data Architecture description

Perform gap analysis for data architecture

Data Architecture Catalogs:

Data Entity/Data Component catalog

Logical Data Component catalog

Physical Data Component catalog

Phase C2: Application Architecture

Develop baseline Application Architecture description

Develop target Application Architecture description

Perform gap analysis for application architecture

Application Architecture Matrices:

Application/Organization matrix

Role/Application matrix
Application/Function matrix

Application Communication matrix

Phase D: Technology Architecture

Objective: Develop target Technology Architecture supporting Architecture Vision

Key Technology Architecture Components:

Computing Hardware - Servers, workstations, network devices

 Network Hardware - Routers, switches, firewalls

Communications Hardware - Modems, multiplexers

System Software - Operating systems, database management systems

Network Software - Network operating systems, communications protocols

Application Software - Middleware, utilities, application platforms

Technology Standards Categories:

1. Products - Specific technology products

2. Services - Technology services and support

3. Communications - Network and communications standards

4. Data - Data formats and protocols

5. Applications Software - Application development standards

6. Computing - Hardware and system software standards

Phase E: Opportunities & Solutions

Objective: Initial complete version of Architecture Roadmap and Implementation and Migration Plan

Key Activities:

Determine/confirm key corporate change attributes

Determine business constraints

Review and consolidate gap analysis from previous phases

Review consolidated requirements across related architecture projects

Consolidate and reconcile interoperability requirements

Refine and validate dependencies

Confirm readiness and risk for business transformation

Capability Assessment Matrix:

Capability Current State Target State Gap Priority Effort

Customer Management Manual, Paper-based Digital, Integrated High 1 High

Inventory Control Separate Systems Real-time, Unified Medium 2 Medium

Financial Reporting Weekly Batch Daily Real-time Medium 3 Low

 

Phase F: Migration Planning

Objective: Finalize Architecture Roadmap and Implementation and Migration Plan

Implementation Factor Assessment Criteria:

 1. Strategic Impact - Alignment with business strategy

2. Business Value - Financial and operational benefits

3. Resource Availability - Skills, budget, time

4. Enterprise Risk - Implementation and business risks

5. Stakeholder Commitment - Support from key stakeholders

6. Implementation Complexity - Technical and organizational complexity

Migration Planning Matrix:

Timeline: Year 1 Year 2 Year 3

Quarter: Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Project A: [===Phase 1===][===Phase 2===]
Project B: [====Implementation====]
Project C: [===Phase 1===][===Phase 2===]
Dependencies: A->B, B->C

Phase G: Implementation Governance

Objective: Ensure conformance with target architecture

Architecture Compliance Review Process:

1. Trigger - Project checkpoint or milestone

2. Preparation - Gather project artifacts and requirements

3. Review - Compare project against architecture requirements

4. Assessment - Determine compliance level and issues

5. Remediation - Define corrective actions if needed

6. Sign-off - Formal approval or conditional approval

Compliance Assessment Levels:

Fully Compliant - No issues identified

Compliant with Issues - Minor issues that can be addressed

Non-Compliant - Significant issues requiring remediation

Not Assessed - Insufficient information for assessment

Phase H: Architecture Change Management

Objective: Keep architecture current and relevant

Change Management Process:

 Change Request -> Impact Assessment -> Architecture Board Review ->
Decision (Approve/Reject/Defer) -> Implementation -> Update Repository

Types of Architecture Changes:

1. Simplification Changes - Remove unnecessary complexity

2. Incremental Changes - Small additions or modifications

3. Re-architecting Changes - Significant structural changes

4. New Architecture - Complete replacement

Requirements Management (Continuous Process)

Objective: Manage architecture requirements throughout the ADM

Requirements Categories:

Functional Requirements - What the system must do

Non-Functional Requirements - Quality attributes (performance, security, etc.)

Design Constraints - Restrictions on design choices

Implementation Constraints - Restrictions on implementation

Requirements Traceability Matrix:

Requirement Architecture Implementation

Description Source Status
ID Component Project

Customer self- Business

BR-001 Customer Portal CRM Project Planned
service Strategy

SLA In
TR-001 99.9% availability Infrastructure Infrastructure Upgrade
Requirements Progress
 

Enterprise Continuum & Tools - Detailed

The Enterprise Continuum provides methods for classifying architecture and solution artifacts.

Enterprise Continuum Structure Diagram

GENERIC ←――――――――――――――――――――――――――――――――――――――――――→
SPECIFIC

Foundation Common Systems Industry Organization

Architectures Architectures Architectures Architectures
| | | |
v v v v
 Generic Generic Industry Company
Solutions Industry Solutions Solutions
Solutions

ABSTRACT
←――――――――――――――――――――――――――――――――――――――――――→
CONCRETE

Architecture Repository Structure

Architecture Repository
├── Architecture Metamodel
│ ├── Content Metamodel
│ ├── Architecture Capability
│ └── Architecture Landscape
├── Architecture Method
│ ├── ADM
│ └── ADM Guidelines & Techniques
├── Architecture Content
│ ├── Deliverables
│ ├── Artifacts
│ └── Building Blocks
├── Reference Library
│ ├── External Reference Materials
│ ├── Architecture Guidelines
│ ├── Architecture Patterns
│ └── Viewpoints Library
├── Standards Information Base
│ ├── Technical Reference Model
│ ├── Standards Profiles
│ └── Organization Standards
└── Governance Log
├── Decision Log
├── Compliance Assessments
└── Calendar/Review Schedule

Building Blocks Hierarchy

Architecture Building Blocks (ABBs):

Define required functionality

Capture architecture requirements

Direct and guide development of Solution Building Blocks

Solution Building Blocks (SBBs):

 Define components for implementation

Fulfill business requirements

Product or vendor-specific implementations

Relationship Example:

ABB: "Customer Data Management"

├── Requirements: Store customer information, ensure data quality
├── Interfaces: Customer query, customer update, data validation
└── SBB Options:
├── Oracle Customer Hub
├── Salesforce CRM
└── Custom Database Solution

Architecture Content Framework - Detailed

Content Metamodel Core Concepts

Entities and Relationships:

Actor - Person, organization, or system that has roles and responsibilities

Role - Responsibility for specific behavior

Business Service - Supports business capabilities

Process - Structured set of activities

Function - Delivers business capabilities

Information - Data with context and meaning

Data - Raw facts and figures

Application - Software that supports business functions

Technology - Infrastructure components

Deliverable-Artifact-Building Block Relationship

Architecture Definition Document (Deliverable)

├── Business Architecture (Artifact)
│ ├── Organization Chart (Catalog)
│ ├── Business Process Models (Diagrams)
│ └── Actor/Role Matrix (Matrix)
├── Data Architecture (Artifact)
│ ├── Data Entity Catalog (Catalog)
│ ├── Logical Data Model (Diagram)
│ └── System/Data Matrix (Matrix)
└── Application Architecture (Artifact)
 ├── Application Portfolio Catalog (Catalog)
├── Application Communication Diagram (Diagram)
└── Application/Function Matrix (Matrix)

Architecture Views and Viewpoints

Viewpoint Categories:

1. Catalogs (What)
Organization/Actor catalog
Business Service catalog

Application Portfolio catalog

Technology Portfolio catalog

2. Matrices (How things relate)

Business/Data matrix

Application/Data matrix
System/Technology matrix
Requirements/Architecture matrix

3. Diagrams (How things work together)

Business Process diagrams

Application Communication diagrams

Network Computing diagrams
Enterprise Security diagrams

Detailed View Examples

Business Service/Information Matrix:

Business Service Customer Data Product Data Order Data Financial Data

Customer Management Create/Read/Update Read Read/Update Read

Order Processing Read Read Create/Read/Update Update

Financial Reporting Read Read Read Create/Read/Update

 

Application Communication Diagram Elements:

Applications (boxes)

Communication paths (lines)

Protocols used (labels)

Data flows (arrows)

 Network boundaries (groupings)

Architecture Governance - Comprehensive

Architecture Governance Framework

Architecture Governance Framework

├── Organizational Structure
│ ├── Architecture Board
│ ├── Architecture Compliance Review
│ └── Architecture Contracts
├── Architecture Processes
│ ├── Architecture Development
│ ├── Architecture Compliance
│ └── Architecture Change Management
├── Architecture Information
│ ├── Architecture Repository
│ ├── Standards Information Base
│ └── Governance Log
└── Architecture Tools
├── Architecture Development Tools
├── Architecture Compliance Tools
└── Architecture Repository Tools

Architecture Board Composition and Responsibilities

Typical Architecture Board Members:

Chief Architect (Chair) - Strategic direction and vision

Business Representatives - Business requirements and priorities
IT Management - Implementation feasibility and resources

Security Officer - Security requirements and compliance

Data Officer - Data governance and quality

Project/Program Managers - Implementation coordination

Architecture Board Meeting Agenda Template:

1. Review Previous Minutes - Actions and decisions

2. Architecture Compliance Reviews - Project assessments

3. Change Requests - Architecture modifications

4. New Architecture Projects - Approval and prioritization

5. Standards Updates - New standards and guidelines

6. Issues and Escalations - Problem resolution
 7. Strategic Initiatives - Long-term planning

Architecture Contracts
Contract Types:

1. Business-IT Architecture Contract - Between business and IT organizations

2. Service Level Agreements - Performance and availability requirements

3. Operational Level Agreements - Internal service agreements

4. Architecture Compliance Reviews - Formal compliance checkpoints

Architecture Contract Template:

Architecture Contract
├── Parties and Roles
├── Architecture Requirements
│ ├── Functional Requirements
│ ├── Non-Functional Requirements
│ └── Constraints
├── Architecture Deliverables
├── Success Criteria
├── Compliance Checkpoints
├── Issue Escalation Process
└── Change Management Process

Migration Planning Techniques - Advanced

Business Transformation Readiness Assessment - Detailed

Assessment Categories and Factors:

1. Vision (Weight: 15%)

5: Clear, compelling vision communicated to all

3: Vision exists but not well communicated

1: No clear vision for transformation

2. Desire, Willingness, and Resolve (Weight: 15%)

5: Strong desire and commitment at all levels
3: Mixed commitment across organization

1: Resistance to change predominant

3. Need (Weight: 15%)

5: Compelling business case, urgent need

3: Business case exists but not compelling

 1: No clear business need identified

4. Business Case (Weight: 10%)

5: Strong financial justification, approved funding
3: Adequate business case, funding identified

1: Weak business case, funding uncertain

5. Funding (Weight: 10%)

5: Full funding committed and available

3: Funding identified but not fully committed

1: Funding not identified or insufficient

6. Sponsor/Leadership (Weight: 10%)

5: Strong visible leadership, active sponsorship
3: Adequate leadership support

1: Weak or absent leadership support

7. Governance (Weight: 10%)

5: Clear decision-making authority and processes
3: Adequate governance structures

1: Unclear or ineffective governance

8. Accountability (Weight: 5%)

5: Clear roles, responsibilities, and accountability

3: Roles defined but accountability unclear

1: Roles and accountability not defined

9. IT Capacity to Execute (Weight: 5%)

5: Strong IT capability and capacity

3: Adequate IT resources

1: Limited IT capability or capacity

10. Enterprise Capacity to Execute (Weight: 5%)

5: Strong organizational change capability
3: Adequate change management capability
1: Limited organizational change capability

Readiness Score Calculation: Total Score = Σ(Factor Score × Weight)

4.0-5.0: Ready to proceed

3.0-3.9: Proceed with caution, address gaps

2.0-2.9: Significant preparation needed
 1.0-1.9: Not ready, major interventions required

Implementation Factor Assessment Matrix

Assessment Criteria Details:

1. Strategic Impact
Business strategy alignment
Competitive advantage potential
Market positioning impact

2. Business Value
Financial benefits (ROI, cost savings)

Operational benefits (efficiency, quality)

Strategic benefits (capability, agility)

3. Risk Assessment
Technical risk (complexity, maturity)
Business risk (impact, disruption)

Resource risk (availability, skills)

4. Resource Requirements
Financial investment needed
Human resources required
Time and schedule constraints

Sample Assessment Matrix:

Project Strategic Impact Business Value Risk Level Resource Needs Priority Score

CRM Implementation High (9) High (8) Medium (6) High (7) 7.5

Infrastructure Upgrade Medium (6) Medium (7) Low (8) Medium (6) 6.8

Mobile Platform High (8) High (9) High (4) Medium (6) 6.8
 

Capability-Based Planning Approach

Capability Hierarchy Example:
 Enterprise Capabilities
├── Customer Management
│ ├── Customer Acquisition
│ │ ├── Lead Generation
│ │ ├── Lead Qualification
│ │ └── Customer Onboarding
│ ├── Customer Retention
│ │ ├── Customer Service
│ │ ├── Account Management
│ │ └── Customer Analytics
│ └── Customer Experience
│ ├── Multi-channel Experience
│ ├── Personalization
│ └── Customer Journey Management
├── Product Management
│ ├── Product Development
│ ├── Product Marketing
│ └── Product Support
└── Operations Management
├── Supply Chain
├── Manufacturing
└── Quality Management

Capability Maturity Assessment:

Capability Current Maturity Target Maturity Gap Investment Priority

Customer Analytics Level 2: Repeatable Level 4: Managed 2 levels High

Lead Generation Level 3: Defined Level 4: Managed 1 level Medium

Multi-channel Experience Level 1: Initial Level 4: Managed 3 levels High

 

Architecture Principles - Comprehensive Framework

Principle Categories and Examples

Business Principles:

1. Primacy of Principles
Statement: Architecture principles apply to all initiatives

Rationale: Ensures consistency and reduces complexity

Implications: All projects must comply with principles

2. Maximize Benefit to the Enterprise

Statement: Decisions are made for enterprise benefit

Rationale: Prevents suboptimization

 Implications: May require local sacrifices for global benefit

3. Business Continuity
Statement: Operations continue despite system failures
Rationale: Business cannot afford extended downtime

Implications: Requires redundancy and backup procedures

Data Principles:

1. Data is an Asset
Statement: Data is a valuable enterprise resource

Rationale: Data has measurable value and cost

Implications: Data must be protected and managed

2. Data is Shared
Statement: Users have access to data for legitimate purposes

Rationale: Sharing reduces duplication and improves quality

Implications: Common data definitions and security controls needed

3. Data is Accessible
Statement: Data is accessible for authorized users when needed
Rationale: Timely access to accurate data is essential

Implications: Clear data ownership and access procedures required

Application Principles:

1. Technology Independence
Statement: Applications are independent of technology choices
Rationale: Reduces impact of technology changes

Implications: Standard interfaces and abstraction layers needed

2. Ease of Use
Statement: Applications are easy to use
Rationale: Improves productivity and reduces training
Implications: User-centered design and usability testing required

Technology Principles:

1. Interoperability
Statement: Software and hardware should conform to standards
Rationale: Standards enable integration and reduce costs

Implications: May limit technology choices

 2. Control Technical Diversity
Statement: Technology diversity is controlled

Rationale: Reduces complexity and support costs

Implications: Approved technology lists and standards needed

Principle Development Process

Principle Development Process:

Business Strategy → Business Requirements → Architecture Principles →
Architecture Policies → Architecture Standards → Implementation Guidelines

Advanced ADM Techniques

Architecture Partitioning
Partitioning Approaches:

1. By Subject Matter - Business domains (HR, Finance, Sales)

2. By Organizational Unit - Divisions, subsidiaries, geographic regions

3. By Time Horizon - Short-term, medium-term, long-term

4. By Level of Detail - Conceptual, logical, physical

Federated Architecture Approach:

Enterprise Architecture
├── Corporate Architecture (Strategic)
│ ├── Business Architecture Principles
│ ├── Integration Standards
│ └── Governance Framework
├── Domain Architectures (Tactical)
│ ├── Sales & Marketing Architecture
│ ├── Operations Architecture
│ └── Finance Architecture
└── Solution Architectures (Operational)
├── CRM Solution Architecture
├── ERP Solution Architecture
└── E-commerce Solution Architecture

Architecture Maturity Models

Architecture Capability Maturity Levels:

1. Level 0 - None: No architecture capability

2. Level 1 - Initial: Ad-hoc architecture activities

 3. Level 2 - Developing: Some architecture processes defined
4. Level 3 - Defined: Architecture processes standardized

5. Level 4 - Managed: Architecture processes measured

6. Level 5 - Optimizing: Continuous architecture improvement

Maturity Assessment Areas:

Architecture Process - Methodology and procedures

Architecture Development - Skills and techniques

Business Linkage - Alignment with business strategy

Senior Management Involvement - Leadership and sponsorship

Operating Unit Participation - Business engagement

Architecture Communication - Stakeholder communication

IT Security - Security integration

Architecture Governance - Control and compliance

Gap Analysis Techniques

Types of Gaps:

1. Functional Gaps - Missing business capabilities

2. Technical Gaps - Technology shortcomings

3. Data Gaps - Information availability issues

4. Skills Gaps - Capability and expertise shortcomings

5. Process Gaps - Procedural deficiencies

Gap Analysis Matrix Template:

Architecture Domain Baseline State Target State Gap Description Impact Priority

Process automation
Business Architecture Manual processes Automated workflows High 1
needed

Integrated data
Data Architecture Siloed databases Data integration required Medium 2
warehouse

Application Application
Legacy systems Modern applications High 1
Architecture modernization

Technology Aging Infrastructure

Cloud platform Medium 3
Architecture infrastructure transformation
 
Stakeholder Management - Advanced

Comprehensive Stakeholder Analysis

Stakeholder Categories:

1. Primary Stakeholders - Directly affected by architecture

2. Secondary Stakeholders - Indirectly affected

3. Key Players - Significant influence on success

4. Context Setters - Define operating environment

Stakeholder Analysis Framework:

Stakeholder Analysis
├── Identification
│ ├── Business Stakeholders
│ ├── IT Stakeholders
│ ├── External Stakeholders
│ └── Regulatory Stakeholders
├── Analysis
│ ├── Interests and Concerns
│ ├── Influence and Power
│ ├── Relationships
│ └── Communication Preferences
├── Strategy Development
│ ├── Engagement Approach
│ ├── Communication Plan
│ ├── Influence Strategy
│ └── Relationship Building
└── Management
├── Regular Engagement
├── Feedback Collection
├── Relationship Monitoring
└── Strategy Adjustment

Power/Interest Grid Strategies:

High Power, High Interest: Manage Closely - Key decision makers

High Power, Low Interest: Keep Satisfied - Influential but not engaged
Low Power, High Interest: Keep Informed - Affected but limited influence

Low Power, Low Interest: Monitor - Minimal engagement needed

Communication Planning
Communication Matrix Template:
 Stakeholder
Information Needs Frequency Method Format Responsibility
Group

Senior Executive
Strategic progress, ROI Monthly Presentation Chief Architect
Executives dashboard

Impact on processes,
Business Users Weekly Email, meetings Status updates Business Architect
training

Technical details, Collaboration Technical

IT Teams Daily Solution Architect
timelines tools documents

Formal Technical Integration

External Partners Interface requirements As needed
documents specifications Architect
 

Risk Management in Architecture

Architecture Risk Categories

Technical Risks:

Complexity Risk - Solution too complex to implement or maintain

Technology Risk - Technology immaturity or obsolescence

Integration Risk - Difficulty integrating with existing systems

Performance Risk - Solution cannot meet performance requirements

Security Risk - Security vulnerabilities or compliance issues

Business Risks:

Schedule Risk - Implementation timeline cannot be met

Budget Risk - Costs exceed approved budget

Resource Risk - Required skills or resources not available

Change Risk - Business requirements change during implementation
Adoption Risk - Users do not adopt new solution

Organizational Risks:

Governance Risk - Inadequate oversight and control

Communication Risk - Poor stakeholder communication

Cultural Risk - Resistance to organizational change

Skills Risk - Inadequate capabilities for transformation

Leadership Risk - Insufficient senior management support
Risk Assessment Matrix
Risk Impact Levels:

5 - Catastrophic - Project failure, significant business disruption

4 - Major - Significant schedule/budget impact, business impact

3 - Moderate - Noticeable schedule/budget impact, limited business impact

2 - Minor - Small schedule/budget impact, minimal business impact

1 - Insignificant - No significant impact

Risk Probability Levels:

5 - Almost Certain - >90% chance of occurring

4 - Likely - 70-90% chance of occurring

3 - Possible - 30-70% chance of occurring

2 - Unlikely - 10-30% chance of occurring
1 - Rare - <10% chance of occurring

Risk Score = Impact × Probability

20-25: Extreme Risk - Immediate action required

15-19: High Risk - Action required within 30 days

10-14: Medium Risk - Action required within 90 days

5-9: Low Risk - Monitor and review

1-4: Very Low Risk - Accept risk

Risk Response Strategies

1. Risk Avoidance - Eliminate risk by changing approach

2. Risk Mitigation - Reduce probability or impact

3. Risk Transfer - Shift risk to third party

4. Risk Acceptance - Accept risk and monitor

Risk Register Template:

 Risk
Description Category Impact Probability Score Response Strategy Owner Status
ID

Legacy system
Mitigate - POC IT
R001 integration Technical 4 3 12 Open
development Manager
complexity

User resistance to Mitigate - Change HR

R002 Business 3 4 12 Open
new processes management Manager
 

TOGAF Reference Models

Technical Reference Model (TRM)

TRM Structure:

Technical Reference Model

├── Application Platform
│ ├── Application Platform Interface
│ ├── Application Software
│ └── Application Development Environment
├── System Software
│ ├── Operating System Services
│ ├── Network Services
│ └── Transaction Processing
├── Network Infrastructure
│ ├── Communications Infrastructure Interface
│ ├── Network Media
│ └── Network Nodes
└── Hardware Platform
├── Hardware Platform Interface
├── Physical Hardware
└── Hardware Components

Platform Services Categories:

Data Management Services - Database, file systems, directories

Graphics and Imaging Services - GUI, graphics, multimedia
International Operation Services - Internationalization, localization

Location and Directory Services - Naming, directory services

Network Services - Data communications, distributed computing

Operating System Services - Kernel, file systems, memory management

Security Services - Authentication, authorization, encryption
Software Engineering Services - Development tools, CASE tools
 System and Network Management Services - Configuration, performance monitoring
Transaction Processing Services - Transaction monitors, messaging

User Interface Services - Presentation, window systems

Integrated Information Infrastructure Reference Model (III-RM)

III-RM Components:

Integrated Information Infrastructure Reference Model

├── Business Applications
│ ├── Industry-specific Applications
│ ├── Enterprise Applications
│ └── Departmental Applications
├── Infrastructure Applications
│ ├── System Management
│ ├── Network Management
│ └── Security Management
├── Application Platform
│ ├── DBMS, Transaction Processing
│ ├── Messaging, Directory Services
│ └── Web Services, Portals
├── Communications Infrastructure
│ ├── Network Infrastructure
│ ├── Internet/Intranet
│ └── Telecommunications
└── Qualities
├── Manageability
├── Security
├── Scalability
└── Availability

Information Infrastructure Services:

Brokerage - Connecting users with information providers

Data Management - Storage, access, and manipulation of data

Data Interchange - Translation between data formats

Directory Services - Location of resources and services

Process Control - Workflow and business process management
Security - Authentication, authorization, and audit

Systems Management - Configuration and performance management

User Interface - Presentation and interaction services
Architecture Compliance

Compliance Assessment Process

Compliance Review Stages:

1. Project Request - Project submits architecture for review

2. Basic Compliance Check - Automated checks against standards

3. Detailed Review - Manual review by architecture team

4. Risk Assessment - Evaluate risks of non-compliance

5. Recommendation - Approve, approve with conditions, or reject

6. Remediation - Address identified issues

7. Re-review - Review remediated architecture

8. Final Sign-off - Formal approval to proceed

Compliance Checklists by Architecture Domain:

Business Architecture Compliance:

Business requirements clearly defined and traceable

Business processes align with enterprise standards
Service interfaces properly specified
Business rules documented and consistent
Stakeholder requirements addressed

Data Architecture Compliance:

Data models conform to enterprise standards

Data quality requirements specified
Data security and privacy requirements addressed
Data retention and archival policies followed
Master data management approach defined

Application Architecture Compliance:

Application follows enterprise integration patterns

Security requirements implemented according to standards
Performance requirements specified and validated
User interface standards followed
Application portfolio rationalization considered

Technology Architecture Compliance:

Technology choices align with enterprise standards

 Infrastructure scalability and availability addressed
Disaster recovery and business continuity planned
Technology lifecycle management considered
Vendor management and support addressed

Non-Compliance Handling
Dispensation Process:

1. Justification - Business case for non-compliance

2. Impact Assessment - Evaluate risks and implications

3. Mitigation Plan - Address identified risks

4. Time-bound Approval - Temporary approval with timeline

5. Compliance Plan - Path to full compliance

6. Monitoring - Track progress toward compliance

Common Dispensation Reasons:

Legacy System Constraints - Technical limitations of existing systems

Vendor Limitations - COTS product doesn't support standards

Time Constraints - Urgent business need requiring compromise

Cost Constraints - Full compliance cost-prohibitive

Regulatory Requirements - External requirements conflict with standards

Business Scenarios Technique

Business Scenario Development Process

Scenario Creation Steps:

1. Problem Definition - Identify business problem or opportunity

2. Environment Assessment - Current business and technical environment

3. Objective Identification - Desired business outcomes

4. Human Actors - People involved in the scenario

5. Computer Actors - Systems involved in the scenario
6. Roles and Responsibilities - Who does what

7. Required Processes - Business processes needed

8. Assumptions - Key assumptions and constraints

9. Success Measures - How success is measured

Sample Business Scenario Template:

Scenario Name: Online Customer Onboarding

Business Problem: Current customer onboarding is manual, paper-based, and takes 5-10 days, resulting in poor
customer experience and high operational costs.

Business Objectives:

Reduce onboarding time to same-day completion

Improve customer satisfaction scores by 25%

Reduce onboarding costs by 40%

Human Actors:

New Customer (initiates onboarding)

Customer Service Representative (assists with complex cases)
Compliance Officer (approves high-risk customers)

Computer Actors:

Online Portal (customer interface)

CRM System (customer data management)

Document Management System (document storage)
Credit Check System (risk assessment)

Process Flow:

Customer Registration → Identity Verification → Document Upload →

Risk Assessment → Approval/Rejection → Account Creation → Welcome Communication

Success Criteria:

80% of customers complete onboarding without assistance

Average onboarding time < 2 hours

Customer satisfaction score > 4.5/5.0

Architecture Skills Framework

Architecture Competency Levels

Skills Categories and Competency Levels:

1. Generic Skills (Leadership, Communication, etc.)

Level 1 - Awareness: Basic understanding

 Level 2 - Novice: Can perform with guidance
Level 3 - Intermediate: Can perform independently

Level 4 - Advanced: Can guide others

Level 5 - Expert: Recognized authority

2. Business Skills (Business Strategy, Process Improvement, etc.) 3. Architecture Skills (Design, Modeling,
Planning, etc.)
4. Program/Project Management Skills 5. IT General Knowledge Skills 6. Technical Skills (Development,
Infrastructure, etc.)

Architecture Roles and Responsibilities

Chief Architect:

Responsibilities: Enterprise architecture strategy, governance oversight, stakeholder management

Skills Required: Strategic thinking, leadership, business acumen, architecture expertise
Typical Experience: 15+ years IT, 5+ years architecture leadership

Domain Architect (Business/Data/Application/Technology):

Responsibilities: Domain-specific architecture design, standards development, compliance monitoring

Skills Required: Domain expertise, technical design, modeling, analysis

Typical Experience: 10+ years IT, 3+ years architecture

Solution Architect:

Responsibilities: End-to-end solution design, technology selection, implementation guidance

Skills Required: Technical breadth, integration expertise, problem-solving

Typical Experience: 8+ years IT, 2+ years solution design

Enterprise Architect:

Responsibilities: Cross-domain architecture integration, roadmap development, transformation planning

Skills Required: Systems thinking, integration, planning, communication

Typical Experience: 12+ years IT, 4+ years enterprise architecture

Architecture Team Structure Models

Centralized Model:
 Chief Architect
├── Enterprise Architects
├── Domain Architects
│ ├── Business Architect
│ ├── Data Architect
│ ├── Application Architect
│ └── Technology Architect
└── Solution Architects

Federated Model:

Enterprise Architecture Office

├── Corporate Architecture Team
├── Business Unit Architecture Teams
│ ├── BU A Architecture Team
│ ├── BU B Architecture Team
│ └── BU C Architecture Team
└── Center of Excellence
├── Architecture Methods
├── Architecture Tools
└── Architecture Training

Advanced Architecture Patterns

Integration Patterns
1. Point-to-Point Integration:

Direct connections between applications

Simple but creates complexity as applications grow

Suitable for small numbers of applications

2. Hub and Spoke:

Central integration hub connects all applications

Reduces number of connections

Single point of failure risk

3. Enterprise Service Bus (ESB):

Distributed integration platform

Service-oriented architecture enabler

Supports multiple communication patterns

4. API Management:

Centralized API gateway and management

Supports microservices architecture

Enables external partner integration

Data Architecture Patterns

1. Data Lake:

Store data in native format

Schema-on-read approach

Suitable for big data and analytics

2. Data Warehouse:

Structured data storage

Schema-on-write approach
Optimized for reporting and analysis

3. Master Data Management (MDM):

Single source of truth for key business entities

Data governance and quality focus

Supports operational and analytical systems

4. Data Mesh:

Decentralized data architecture

Domain-oriented data ownership

Data-as-a-product approach

Application Architecture Patterns

1. Monolithic Architecture:

Single deployable unit

Simple development and deployment
Challenges with scaling and technology diversity

2. Service-Oriented Architecture (SOA):

Business services with defined interfaces

Reusable and composable services

 Enterprise-scale integration

3. Microservices Architecture:

Small, independent services

Technology diversity enabled

DevOps and continuous deployment friendly

4. Event-Driven Architecture:

Asynchronous communication via events

Loose coupling between components

Real-time processing capabilities

Exam Preparation Strategy

Key Formula and Numbers

ADM Phases: 9 total (Preliminary + A through H + Requirements Management)

Architecture Domains: 4 (Business, Data, Application, Technology)

Enterprise Continuum Levels: 4 (Foundation → Common Systems → Industry → Organization-Specific)

Architecture Repository Components: 6 main areas

1. Architecture Metamodel

2. Architecture Method
3. Architecture Content

4. Reference Library
5. Standards Information Base
6. Governance Log

Business Transformation Readiness Factors: 10 assessment areas

Architecture Maturity Levels: 6 levels (0-5: None → Optimizing)

Exam Question Types and Strategies

1. Definition Questions (What is...?)

Focus on precise TOGAF terminology

Know exact definitions from the specification

Common topics: ADM phases, building blocks, viewpoints

2. Process Questions (What happens in Phase X?)

 Understand inputs, activities, and outputs for each phase

Know the sequence and dependencies

Focus on objectives of each phase

3. Relationship Questions (How do X and Y relate?)

Understand connections between concepts

Know the Enterprise Continuum structure

Understand stakeholder relationships

4. Application Questions (In this scenario, what would you do?)

Apply TOGAF principles to business situations

Consider all relevant stakeholders

Think about governance and compliance

5. Best Practice Questions (What is the recommended approach?)

Know TOGAF recommended practices

Understand when to use specific techniques

Consider architecture principles

Study Schedule Recommendation

Week 1-2: Foundation Knowledge

TOGAF overview and core concepts

ADM overview and phase objectives

Enterprise Continuum basics

Week 3-4: ADM Deep Dive

Detailed study of each ADM phase

Inputs, activities, and outputs

Phase relationships and iterations

Week 5: Architecture Content

Architecture Content Framework

Deliverables, artifacts, and building blocks

Views and viewpoints

Week 6: Governance and Management

 Architecture governance framework
Compliance and change management

Stakeholder management

Week 7: Advanced Topics

Migration planning techniques

Architecture patterns

Risk management

Week 8: Review and Practice

Practice exams and questions

Review weak areas

Final preparation

Common Exam Mistakes to Avoid

1. Confusing ADM Phase Objectives - Each phase has specific goals

2. Mixing Up Building Block Types - ABB vs SBB characteristics

3. Incorrect Enterprise Continuum Order - Generic to Specific progression

4. Stakeholder Management Confusion - Power vs Interest grid strategies

5. Architecture Governance Roles - Architecture Board vs other bodies

6. Phase Deliverable Confusion - Know which deliverables come from which phases
7. Requirements Management Placement - It's continuous, not a separate phase
8. Architecture Principles vs Standards - Different levels of guidance

9. Migration Planning Techniques - When to use which assessment method

10. Compliance vs Dispensation - Understanding the difference and process

Final Exam Tips

Before the Exam:

Get plenty of rest the night before

Arrive early and bring required identification

Have backup transportation planned

Bring permitted materials (calculator, etc.)

During the Exam:

Read questions carefully, watch for key words

 Eliminate obviously wrong answers first
Manage time - don't spend too long on difficult questions

Mark questions for review if unsure

Use process of elimination for difficult questions

Question Analysis Technique:

1. Identify the Topic - Which TOGAF area is being tested?

2. Understand What's Asked - Definition, process, relationship, or application?

3. Apply TOGAF Knowledge - Use specific TOGAF concepts and terminology

4. Eliminate Wrong Answers - Cross out clearly incorrect options

5. Select Best Answer - Choose the most complete and accurate response

Time Management:

90 minutes for 40 questions = ~2.25 minutes per question

First pass: Answer questions you know confidently (60 minutes)

Second pass: Work on questions requiring more thought (20 minutes)

Final pass: Review marked questions and guess if needed (10 minutes)

Summary of Critical Success Factors

For TOGAF Implementation

1. Senior Management Commitment - Executive sponsorship essential

2. Clear Business Drivers - Well-defined reasons for architecture

3. Appropriate Skills - Trained and experienced architecture team
4. Stakeholder Engagement - Active participation from business stakeholders

5. Governance Framework - Effective oversight and decision-making

6. Cultural Readiness - Organization prepared for change

7. Resource Availability - Adequate funding and staffing

8. Communication - Clear, consistent messaging to all stakeholders

For Exam Success

1. Comprehensive Study - Cover all TOGAF components thoroughly

2. Practice Questions - Use official practice exams and questions

3. Hands-on Experience - Apply concepts in real or simulated projects

4. Study Groups - Discuss concepts with other candidates

 5. Official Materials - Use TOGAF specification and study guides
6. Time Management - Practice under exam time constraints

7. Concept Connections - Understand how concepts relate to each other

8. Terminology Mastery - Know exact TOGAF definitions and terms

This comprehensive cheatsheet covers all major TOGAF Foundation exam topics. Focus on understanding
concepts and their relationships rather than just memorizing facts. Good luck with your exam!