Introduction
"TOGAF is too heavy for us." This is a sentiment I hear regularly from IT leaders, and it's understandable—the certification curriculum covers an enormous amount of material. But here's what often gets missed: the framework itself is designed to be tailored. TOGAF is exactly as heavy as you choose to make it.
Here's the crucial distinction: the framework is flexible; the certification is demanding. The Open Group designed TOGAF to be adapted and tailored. But the certification—especially the Practitioner level—requires understanding the complete framework. Why? Because you can't intelligently simplify what you don't understand.
This creates a perception problem. People study for certification, encounter the full scope of TOGAF's content (30+ deliverables, detailed phase descriptions, extensive reference materials), and conclude the framework must be heavy. But studying everything and implementing everything are fundamentally different activities.
TOGAF is a toolbox, not a mandate. The certification teaches you what's available; your organisation decides what to use. For mid-size companies, starting with an application repository and a simple four-section template delivers immediate value without bureaucratic overhead. You either invest in learning the full framework to make informed choices, or you engage a consultant who already has.
Debunking the Myths
Before exploring TOGAF's practical application, let's address the common objections head-on.
1 "TOGAF is too heavy for our organisation"
TOGAF requires extensive documentation, formal governance boards, and months of planning before any work can begin. It's designed for large enterprises with dedicated architecture teams.
TOGAF explicitly states that the ADM "should be adapted" to your needs. The framework provides guidance on tailoring, including iteration, simplification, and phase selection. You choose what to implement.
Start with one artifact (application portfolio) and one simplified process (lightweight ADM for new projects). Expand only when value is demonstrated and capacity allows.
2 "The certification covers things we'll never use"
Learning the entire framework for certification is a waste when you'll only use a fraction of it.
Understanding the complete framework enables informed decisions about what to adopt. You can't effectively simplify what you don't understand. The certification ensures a common vocabulary across the industry.
A chef learns classical techniques before developing their own style. A project manager learns full PMBOK before applying agile adaptations. Comprehensive learning enables intelligent simplification.
3 "TOGAF is too theoretical and lacks practical examples"
The framework provides abstract concepts without showing how to apply them in real situations.
This criticism has some validity—even academic analyses note the lack of detailed worked examples. However, this is intentional: TOGAF provides structure and principles, not prescriptive solutions.
The framework's flexibility is its strength. It provides guardrails without dictating implementation, allowing organisations to develop practices suited to their culture and capabilities.
TOGAF Fundamentals
Understanding the core components helps you decide what to adopt. TOGAF 10, the latest version released in April 2022, organises content into Fundamental and Series Guides, making it easier to navigate.
The Four Architecture Domains
TOGAF defines four interrelated areas of specialisation that together describe an enterprise's architecture:
Defines the business strategy, governance, organisation, and key business processes. This domain answers "what does the business do and how is it organised?" Start here to ensure technology serves business needs.
Describes the structure of logical and physical data assets and data management resources. Answers "what data does the organisation need and how is it organised?" Critical for data-driven decision making.
Provides a blueprint for individual applications, their interactions, and relationships to core business processes. Answers "what systems support the business?" This is often the entry point for EA initiatives.
Describes the hardware, software, and network infrastructure needed to support applications. Answers "what technology enables the systems?" Includes infrastructure, platforms, and technical standards.
The Architecture Development Method (ADM)
The ADM is the core of TOGAF—a tested, repeatable process for developing architectures. It consists of a Preliminary Phase, eight main phases (A through H), and Requirements Management at the centre.
Preliminary
Establish architecture capability
Phase A
Architecture Vision
Phase B
Business Architecture
Phases C & D
IS & Technology Architecture
Phases E & F
Opportunities & Migration
Phases G & H
Governance & Change
The ADM is explicitly designed to be iterative and adaptable. You can cycle through it at different levels of detail, skip phases that don't apply, or focus on specific domains. The circular diagram represents ongoing refinement, not a sequential waterfall.
Start Simple: The Application Portfolio
For most mid-size companies, the highest-value starting point is an Application Portfolio Catalog. This single artifact provides immediate visibility into your technology landscape without requiring extensive process changes.
What is an Application Portfolio?
An Application Portfolio Catalog is a structured inventory of all applications within your organisation. TOGAF defines it as part of the Architecture Repository, but you don't need the full repository to benefit from this artifact.
Essential Attributes to Capture
Application Name & Description
Clear identification and purpose statement. Include common aliases and acronyms used within the organisation.
Business Capability Supported
What business function does this enable? Link to a simple capability map for strategic alignment visibility.
Lifecycle Status
Active, sunset, emerging, or retired. Critical for investment decisions and risk assessment.
Technology Stack
Platform, language, database. Enables technical debt assessment and modernisation planning.
Business Criticality
High, medium, low. Drives prioritisation for resilience, support, and investment.
Owner & Support Team
Accountability clarity. Who decides on changes? Who handles incidents?
Integration Points
What other systems does it connect to? Essential for impact analysis and dependency management.
Vendor & Licensing
Commercial or custom? Contract expiration? Budget and negotiation intelligence.
Immediate Benefits
Identify duplicate applications serving similar purposes. Consolidation reduces licensing costs, integration complexity, and support burden.
See aging technologies, unsupported platforms, and single points of failure. Proactive risk management becomes possible when the landscape is visible.
Connect technology investments to business capabilities. Justify spend, identify gaps, and ensure new projects consider existing assets.
Understand downstream effects before making changes. Integration mapping prevents "surprise dependencies" during projects.
Tooling: Start Simple
Enterprise tools like SAP LeanIX or Ardoq are excellent for mature EA practices, but they're not prerequisites. Your options range from simple to sophisticated:
A well-structured Excel or Google Sheet gets you started immediately. Zero cost, familiar interface, easy to share. Good enough for organisations with under 50 applications.
With AI-assisted development, a simple web app with search, filtering, and basic visualisation can be built in a few hours. Perfect fit for your exact needs, no licensing costs, full control over features and data.
LeanIX, Ardoq, or similar platforms offer advanced capabilities: automated discovery, integrations, pre-built analytics. Worth the investment once your practice matures and manual approaches become bottlenecks.
Don't aim for perfection on day one. Start with 80% accuracy on critical applications. The catalog improves through use—every project that references it adds corrections and details. A living document with known gaps beats an obsolete masterpiece.
Lightweight ADM: A Holistic Template
The power of TOGAF's ADM isn't in rigid phase gates—it's in ensuring you consider all dimensions of a problem. For mid-size companies, distill it to a single template that serves as both a checklist and a consistent way to organise your architectural work.
The Four-Section Template
This template ensures holistic coverage without bureaucratic overhead. Think of it as a structured way to capture your thinking transparently and consistently across projects.
1 Business Context
Business objective driving the initiative. Stakeholders and their concerns. Constraints (budget, timeline, regulatory). Success criteria—how will we know this worked?
Technology decisions without business context lead to solutions looking for problems. This section ensures alignment before any design work begins.
1-2 hours. A conversation with key stakeholders followed by a one-page summary.
2 As-Is Architecture (All Layers)
Business: Current processes, capabilities, pain points. Application: Existing systems in scope, from your portfolio. Data: Key data entities, ownership, quality issues. Infrastructure: Current platforms, technical constraints.
You can't plan a journey without knowing your starting point. The holistic view prevents surprises—that forgotten integration, that data quality issue, that infrastructure limitation.
2-4 hours. Much faster once your application portfolio exists—you're assembling known information, not discovering it.
3 To-Be Architecture (All Layers)
The target state across the same four layers. What does the future look like? New applications, retired systems, data flows, infrastructure changes. Be specific enough to guide implementation.
The To-Be creates a shared vision. Teams can make autonomous decisions that align because they understand the destination, not just the next step.
2-4 hours for typical projects. More for transformational initiatives. Include a simple diagram—visual communication accelerates alignment.
4 Gap Analysis & Recommendations
Explicit gaps between As-Is and To-Be. Recommended actions to close each gap. Dependencies, risks, and decision points. Sequence and priorities.
This is where architecture becomes actionable. Clear gaps lead to clear work packages. Documented decisions enable accountability and learning.
1-2 hours. The hard thinking was done in sections 2 and 3—this synthesises it into action.
The value of this template isn't the documentation—it's the thinking it forces. By systematically considering Business, Application, Data, and Infrastructure for both current and future states, you avoid the tunnel vision that leads to integration nightmares and missed requirements. Use it as a checklist: "Have I considered all layers? Have I talked to stakeholders from each domain?"
Architecture Decision Records
Complement the template with ADRs for significant choices. They capture the why behind decisions, enabling future teams to understand context.
Title: Short description of the decision
Status: Proposed, Accepted, Deprecated, Superseded
Context: What is the issue? What forces are at play?
Decision: What is the response to the issue?
Consequences: What are the results? Trade-offs accepted?
Implementation Roadmap
Phase 1: Foundation Months 1–3
- Inventory Critical Applications: Start with business-critical systems. Capture the essential attributes. Don't boil the ocean—focus on the applications that matter most.
- Establish Ownership: Assign a portfolio owner (often an Enterprise Architect or IT Manager). Define who updates what and when. Simple RACI, not governance theatre.
- Choose Your Tool: Start with a spreadsheet if needed. Move to a proper tool (LeanIX, Ardoq, or even a well-structured SharePoint) once the discipline is established.
- Communicate Value: Share portfolio insights with leadership. Show duplication, risk concentrations, or modernisation opportunities. Demonstrate value early.
Phase 2: Integration Months 4–6
- Embed in Project Process: Make portfolio review a standard step in project initiation. "Have you checked what already exists?" becomes a habit.
- Introduce Lightweight ADM: Pilot the simplified ADM on 2-3 new projects. Refine based on feedback. Adjust effort levels to match project scale.
- Expand Coverage: Add remaining applications to the portfolio. Include shadow IT where visible. Accuracy improves through use.
- Track Decisions: Begin capturing ADRs for new projects. Create a searchable repository. Future projects benefit from past reasoning.
Phase 3: Maturation Months 7–12
- Link to Strategy: Connect applications to business capabilities and strategic objectives. Enable investment prioritisation conversations.
- Add Technology Roadmaps: Use lifecycle status and technical debt indicators to plan modernisation. Coordinate vendor negotiations.
- Measure and Refine: Track reuse rates, rationalisation savings, and project delivery improvements. Use data to justify continued investment.
- Consider Expansion: Based on demonstrated value, decide whether to adopt additional TOGAF elements. Let success drive scope expansion.
The Pragmatist's Path
TOGAF is not a religion requiring full devotion. It's a framework that gives you a common vocabulary, tested patterns, and a holistic way of thinking about enterprise architecture. There's no TOGAF police auditing your implementation. Take what serves your organisation. Adapt what needs adaptation. Skip what doesn't apply. Start with an application portfolio—even a simple vibe-coded app can work. Use the four-section template as a checklist to ensure you're thinking holistically across all layers. The goal is better technology decisions aligned with business outcomes, organised transparently and consistently—not framework compliance for its own sake.
Comments
How has your organisation approached TOGAF implementation? Share your experiences and lessons learned.