The TOGAF Debate
Walk into any enterprise architecture discussion and you will find two camps: those who swear by TOGAF and those who dismiss it as bureaucratic overhead from a bygone era. Both positions miss the point.
TOGAF, the Open Group Architecture Framework, was first published in 1995. In technology terms, that is ancient history. Yet it remains the most widely adopted enterprise architecture framework, with certifications held by hundreds of thousands of practitioners worldwide. The question is not whether TOGAF is perfect — it is not — but whether its core ideas remain valuable when properly adapted.
What TOGAF Gets Right
The Architecture Development Method (ADM)
The ADM provides a structured approach to architecture development that prevents the common failure mode of jumping straight to technology selection without understanding business context. Its iterative nature is often overlooked: the ADM was never intended as a waterfall process.
The phases that deliver consistent value:
- Architecture Vision (Phase A): Aligning stakeholders on the problem before discussing solutions
- Business Architecture (Phase B): Understanding value streams and capabilities before drawing system diagrams
- Gap Analysis: Systematically identifying what needs to change between current and target states
The Enterprise Continuum
The concept of building reusable architecture assets — from industry reference models down to organization-specific building blocks — is more relevant than ever. In a world of microservices and cloud-native development, the ability to standardize common patterns while allowing variation where it matters is essential.
Stakeholder Management
TOGAF’s emphasis on viewpoints and views, tailored to different stakeholder concerns, is a practice every architecture team should adopt regardless of their framework preferences.
Where TOGAF Falls Short
Governance Overhead
The full TOGAF governance model, with its architecture boards, compliance reviews, and dispensation processes, is designed for organizations where architecture changes are infrequent and high-impact. In an environment of continuous delivery and autonomous teams, this model creates bottlenecks.
Insufficient Treatment of Data
TOGAF’s data architecture phase has not kept pace with the data mesh, data lakehouse, and real-time analytics paradigms that define modern data strategy.
Cloud-Native Blindness
The framework assumes a relatively stable technology landscape. Cloud-native patterns, where infrastructure is code and services are ephemeral, require architectural thinking that TOGAF does not adequately address.
Our Adapted Approach
At Fintexis, we have developed a pragmatic adaptation of TOGAF that retains its strengths while addressing its limitations.
Lightweight ADM Iterations
Instead of comprehensive architecture cycles, we run focused architecture sprints:
- Context Sprint (1 week): Stakeholder interviews, capability mapping, constraint identification
- Options Sprint (1 week): Architecture alternatives with explicit trade-off analysis
- Decision Sprint (3 days): Stakeholder review, decision documentation, roadmap alignment
- Validation Sprint (ongoing): Architecture fitness functions, automated compliance checks
Fitness Functions Replace Governance Boards
Drawing from the evolutionary architecture approach, we implement automated fitness functions that continuously validate architectural decisions. A microservice exceeding its latency budget triggers an alert, not a governance review meeting scheduled three weeks later.
Living Architecture Documentation
Architecture documentation in a wiki or slide deck becomes stale immediately. We maintain architecture as code: decision records in version control, system diagrams generated from infrastructure definitions, and capability models linked to running services.
Making TOGAF Work Today
The enterprises that extract the most value from TOGAF are those that treat it as a thinking framework rather than a process framework. Use the ADM to ensure you ask the right questions. Use the metamodel to organize your architecture knowledge. Use the governance concepts to establish appropriate guardrails.
But do not let the framework become the goal. The goal is architecture that enables business outcomes. If a TOGAF artifact does not serve that purpose, do not create it.
Architecture frameworks, like architecture itself, must evolve. The organizations that thrive are those that take the best ideas from structured frameworks like TOGAF and blend them with the agility that modern business demands.