frameworks
TOGAF: The Open Group Architecture Framework
An introduction to TOGAF, the most widely adopted enterprise architecture framework for developing and managing enterprise architectures.
TOGAF: The Open Group Architecture Framework
TL;DR
TOGAF is the world's most widely used enterprise architecture framework, providing a comprehensive approach for designing, planning, implementing, and governing enterprise information technology architecture. Its core is the Architecture Development Method (ADM), a phased approach to developing and maintaining enterprise architecture.
Key Takeaways
- ADM is the core: The Architecture Development Method provides the iterative process for EA development
- Four architecture domains: Business, Data, Application, and Technology
- Enterprise Continuum: Repository for reusable architecture assets at different abstraction levels
- Tailorable: TOGAF is a framework to adapt, not a rigid methodology to follow exactly
- Certification available: Two levels (Foundation and Certified) demonstrate TOGAF competency
Why This Matters
Without a structured approach, enterprise architecture efforts often fail to deliver value. Teams produce documents nobody reads, make recommendations that aren't implemented, and struggle to demonstrate ROI. TOGAF provides proven processes, deliverables, and governance structures that connect architecture work to business outcomes. While not perfect, TOGAF's widespread adoption means common vocabulary and practices across organizations.
TOGAF Adoption
TOGAF is used by 80% of Global 50 companies and 60% of Fortune 500 companies. This widespread adoption creates a common language for discussing enterprise architecture across organizations.
TOGAF Components
Framework Structure
TOGAF FRAMEWORK COMPONENTS
┌─────────────────────────────────────────────────────────────┐
│ TOGAF DOCUMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ PART I: INTRODUCTION │
│ └── Core concepts and definitions │
│ │
│ PART II: ARCHITECTURE DEVELOPMENT METHOD (ADM) │
│ └── The iterative process for developing architecture │
│ │
│ PART III: ADM GUIDELINES & TECHNIQUES │
│ └── Detailed guidance for applying the ADM │
│ │
│ PART IV: ARCHITECTURE CONTENT FRAMEWORK │
│ └── Metamodel, artifacts, deliverables, building blocks │
│ │
│ PART V: ENTERPRISE CONTINUUM & TOOLS │
│ └── Repository structure and reusable assets │
│ │
│ PART VI: ARCHITECTURE CAPABILITY FRAMEWORK │
│ └── Establishing and operating EA capability │
│ │
└─────────────────────────────────────────────────────────────┘
The Four Architecture Domains
TOGAF ARCHITECTURE DOMAINS
┌─────────────────────────────────────────────────────────────┐
│ BUSINESS ARCHITECTURE │
│ Business strategy, governance, organization, processes │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ DATA ARCHITECTURE │ │ APPLICATION ARCH. │ │
│ │ Logical and │ │ Application systems │ │
│ │ physical data │ │ and interactions │ │
│ │ assets │ │ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ INFORMATION SYSTEMS ARCHITECTURE │
├─────────────────────────────────────────────────────────────┤
│ TECHNOLOGY ARCHITECTURE │
│ Hardware, software, and network infrastructure │
└─────────────────────────────────────────────────────────────┘
Architecture Development Method (ADM)
The ADM Cycle
┌─────────────────┐
│ Preliminary │
│ (Setup) │
└────────┬────────┘
│
┌────────▼────────┐
│ A. │
│ Architecture │
│ Vision │
└────────┬────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────────▼────┐ ┌──────▼──────┐ ┌────▼────────┐
│ B. │ │ C. │ │ D. │
│ Business │ │ Information │ │ Technology │
│Architecture │ │ Systems │ │Architecture │
└────────┬────┘ └──────┬──────┘ └────┬────────┘
│ │ │
└──────────────┼──────────────┘
│
┌────────▼────────┐
│ E. │
│ Opportunities & │
│ Solutions │
└────────┬────────┘
│
┌────────▼────────┐
│ F. │
│ Migration │
│ Planning │
└────────┬────────┘
│
┌────────▼────────┐
│ G. │
│ Implementation │
│ Governance │
└────────┬────────┘
│
┌────────▼────────┐
│ H. │
│ Architecture │
│ Change Mgmt │
└─────────────────┘
Center: Requirements Management
(Continuous throughout all phases)
Phase Summary
| Phase | Name | Purpose | Key Deliverable |
|---|---|---|---|
| Prelim | Preliminary | Establish EA capability | Architecture Principles |
| A | Architecture Vision | Scope and gain approval | Statement of Architecture Work |
| B | Business Architecture | Define business architecture | Business Architecture Document |
| C | Information Systems | Data and application architecture | IS Architecture Document |
| D | Technology Architecture | Infrastructure architecture | Technology Architecture Document |
| E | Opportunities & Solutions | Identify implementation approach | Implementation Strategy |
| F | Migration Planning | Create roadmap | Architecture Roadmap |
| G | Implementation Governance | Oversee implementation | Compliance Reports |
| H | Architecture Change Mgmt | Manage changes | Change Requests |
| RM | Requirements Management | Manage requirements | Requirements Repository |
Iteration
The ADM is iterative, not waterfall. You'll cycle through phases multiple times, and you can adapt the sequence based on your organization's needs.
Enterprise Continuum
Continuum Overview
ENTERPRISE CONTINUUM
Generic ◄───────────────────────────────────────► Specific
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE CONTINUUM │
├───────────────┬───────────────┬───────────────┬─────────────┤
│ Foundation │ Common │ Industry │Organization │
│ Architectures│ Systems │ Architectures│Specific │
│ │ Architectures│ │ │
│ TRM, III-RM │ SOA, Cloud │ Banking, │ Your │
│ │ │ Healthcare │ Company │
└───────────────┴───────────────┴───────────────┴─────────────┘
┌─────────────────────────────────────────────────────────────┐
│ SOLUTIONS CONTINUUM │
├───────────────┬───────────────┬───────────────┬─────────────┤
│ Foundation │ Common │ Industry │Organization │
│ Solutions │ Systems │ Solutions │ Specific │
│ │ Solutions │ │ Solutions │
│ Platforms, │ ERP, CRM │ Core Banking│ Custom │
│ Languages │ packages │ systems │ applications│
└───────────────┴───────────────┴───────────────┴─────────────┘
Architecture Repository
ARCHITECTURE REPOSITORY STRUCTURE
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE REPOSITORY │
├─────────────────────────────────────────────────────────────┤
│ │
│ ARCHITECTURE METAMODEL │
│ └── Types of architectural elements and relationships │
│ │
│ ARCHITECTURE CAPABILITY │
│ ├── Parameters, structures, processes │
│ └── For operating EA practice │
│ │
│ ARCHITECTURE LANDSCAPE │
│ ├── Strategic Architecture (long-term) │
│ ├── Segment Architecture (domain-specific) │
│ └── Capability Architecture (detailed) │
│ │
│ STANDARDS INFORMATION BASE │
│ └── Technology standards, policies, guidelines │
│ │
│ REFERENCE LIBRARY │
│ └── Templates, patterns, reference architectures │
│ │
│ GOVERNANCE LOG │
│ └── Decisions, compliance assessments, waivers │
│ │
└─────────────────────────────────────────────────────────────┘
Architecture Governance
Governance Structure
ARCHITECTURE GOVERNANCE
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE BOARD │
│ Senior stakeholders who approve architectures │
│ and resolve escalated issues │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE REVIEW │
│ Technical review of solutions against │
│ architecture standards and principles │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ COMPLIANCE ASSESSMENT │
│ Ongoing monitoring of architecture │
│ conformance in projects │
└─────────────────────────────────────────────────────────────┘
Architecture Principles Template
ARCHITECTURE PRINCIPLE FORMAT
NAME: [Short memorable name]
STATEMENT: [One sentence declaring the principle]
RATIONALE: [Why this principle is important]
IMPLICATIONS:
├── [Impact on architecture decisions]
├── [Impact on implementation]
└── [Constraints introduced]
EXAMPLE:
─────────────────────────────────────────────
NAME: Buy Before Build
STATEMENT: We will procure commercial solutions
before developing custom software.
RATIONALE: Custom development is expensive,
slow, and creates maintenance burden.
Commercial solutions leverage vendor
expertise and community support.
IMPLICATIONS:
├── Projects must evaluate 3+ vendors
├── Customization limited to configuration
├── Build requires Architecture Board approval
└── Total cost of ownership comparison required
TOGAF and Other Frameworks
Framework Comparison
| Feature | Aspect | TOGAF | Zachman | FEAF |
|---|---|---|---|---|
| Type | Process framework | Taxonomy/ontology | US Federal framework | |
| Focus | How to develop EA | What to document | Government EA | |
| Prescriptive | Moderate | Low | High | |
| Best for | Private sector | Classification | Government |
TOGAF with Cloud Frameworks
TOGAF + CLOUD FRAMEWORK ALIGNMENT
TOGAF DOMAIN AWS WELL-ARCHITECTED AZURE WELL-ARCHITECTED
──────────────────────────────────────────────────────────────────────────
Business Architecture → (Business outcomes) (Business metrics)
Data Architecture → (Data strategy) (Data management)
Application Arch. → Operational Excellence Operational Excellence
Performance Efficiency Performance Efficiency
Technology Arch. → Security Security
Reliability Reliability
Cost Optimization Cost Optimization
Sustainability (incorporated)
INTEGRATION APPROACH
├── Use TOGAF ADM for enterprise-wide planning
├── Apply cloud frameworks for workload design
├── Map cloud recommendations to TOGAF artifacts
└── Use cloud assessments as input to Phase H
TOGAF Certification
Certification Levels
| Level | Name | Focus | Exam |
|---|---|---|---|
| Level 1 | TOGAF Foundation | Core concepts, terminology | 40 questions, 60% pass |
| Level 2 | TOGAF Certified | Application of TOGAF | 8 scenarios, 60% pass |
| Combined | Both levels | Complete certification | Combined exam available |
Certification Value
- Common vocabulary: Speak the same language as other architects
- Credibility: Demonstrates formal training
- Career advancement: Often required for EA roles
- Framework knowledge: Structured understanding of EA practices
Certification Prep
The Open Group provides official study guides, and numerous training providers offer courses. Focus on understanding concepts, not memorizing—the exams test application.
Practical Application
When to Use TOGAF
| Use TOGAF | Consider Alternatives |
|---|---|
| Enterprise-wide transformation | Single project/system |
| Large organization | Small startup |
| Regulatory/compliance requirements | Agile-only environment |
| Need for formal governance | Informal culture |
| Long-term strategic planning | Short-term tactical work |
Tailoring TOGAF
TAILORING APPROACHES
LIGHT-TOUCH TOGAF
├── Use ADM phases as checklist
├── Focus on key deliverables only
├── Skip formal governance for small efforts
└── Best for: Small organizations, agile environments
FULL TOGAF
├── Complete ADM with all inputs/outputs
├── Formal governance and review boards
├── Comprehensive repository
└── Best for: Large enterprises, regulated industries
HYBRID
├── Select phases relevant to scope
├── Adapt deliverable formats
├── Integrate with agile practices
└── Best for: Most organizations
Quick Reference Card
┌─────────────────────────────────────────────────────────────┐
│ TOGAF CHEAT SHEET │
├─────────────────────────────────────────────────────────────┤
│ │
│ FOUR DOMAINS │
│ ───────────────────────────────────────────────────────── │
│ Business → Strategy, processes, organization │
│ Data → Logical and physical data assets │
│ Application → Systems and their interactions │
│ Technology → Infrastructure (hardware, software, network) │
│ │
│ ADM PHASES (The Core) │
│ ───────────────────────────────────────────────────────── │
│ Preliminary → Establish EA capability │
│ A. Vision → Scope, approval, vision │
│ B. Business → Business architecture │
│ C. Info Sys → Data + Application architecture │
│ D. Tech → Technology architecture │
│ E. Opps → Implementation approach │
│ F. Migration→ Roadmap and planning │
│ G. Implement→ Governance during delivery │
│ H. Change → Manage architecture changes │
│ RM → Requirements (continuous) │
│ │
│ KEY ARTIFACTS │
│ ───────────────────────────────────────────────────────── │
│ Architecture Principles → Guiding rules │
│ Statement of Arch Work → Project charter │
│ Architecture Definition → Detailed documentation │
│ Architecture Roadmap → Sequenced initiatives │
│ Compliance Assessment → Conformance review │
│ │
│ BUILDING BLOCKS │
│ ───────────────────────────────────────────────────────── │
│ ABB (Architecture) → What capability is needed? │
│ SBB (Solution) → How will we implement it? │
│ │
└─────────────────────────────────────────────────────────────┘
Related Topics
- TOGAF ADM Deep Dive - Detailed phase guidance
- ArchiMate - EA modeling notation
- AWS Well-Architected - Cloud architecture framework
Sources
- TOGAF Standard, Version 9.2 - The Open Group
- TOGAF Library - Official documentation
- TOGAF Certification - Certification program