What ISO 42010 Got Right That TOGAF Missed
Enterprise architecture has a framework problem. Not a shortage of frameworks — TOGAF, Zachman, FEAF, SABSA, and a dozen others are available, each with its proponents and its practitioners. The problem is that the dominant framework, TOGAF, was designed for a world that no longer exists. And the one that got the fundamentals right, ISO 42010, never achieved the mainstream adoption it deserved.
This is worth understanding — not as academic history, but as a practical guide to how architecture should function in an era of accelerating AI adoption.
What TOGAF Got Wrong
TOGAF's Architecture Development Method is a ten-phase process: Preliminary, Architecture Vision, Business Architecture, Information Systems Architecture (split into data and application), Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, Architecture Change Management, and Requirements Management.
Reading that list is instructive. TOGAF was designed when architecture was predominantly about large-scale systems integration, when transformation programmes ran on three-to-five-year timescales, and when the primary deliverable of an EA function was documentation.
The ADM is prescriptive and sequential. You work through phases. Each phase has inputs and outputs. The artefacts are specified. The process is designed to be repeatable across engagements, which made it useful for the large consulting firms that codified and popularised it. It also made it slow, heavyweight, and disconnected from the speed at which organisations actually need to make decisions.
The deeper problem is that TOGAF frames architecture as a production process — something that generates artefacts — rather than as a decision support function. The question "should we invest in this AI capability?" is not well-served by a process that asks you to first complete an Architecture Vision phase.
What ISO 42010 Got Right
ISO 42010 — formally, ISO/IEC/IEEE 42010:2011, "Systems and software engineering — Architecture description" — takes a fundamentally different starting point. Rather than specifying a process, it specifies a conceptual model: what architecture is, how it should be described, and how descriptions should relate to stakeholder concerns.
The core concept is the viewpoint. An architecture description in ISO 42010 terms is a set of views, each view governed by a viewpoint, and each viewpoint defined by the concerns it addresses for the stakeholders who hold them.
This is the key insight. Architecture work starts with concerns, not artefacts. The question that drives an ISO 42010-compliant architecture engagement is: who are the stakeholders, what are their concerns, and which viewpoints are appropriate to address those concerns? Everything else — the models, the diagrams, the documentation — is subordinate to that question.
The practical difference is significant. When a CIO asks "where should we invest in AI?", an ISO 42010 approach starts by identifying who needs to be informed by that decision (the CIO, the CFO, business domain owners, IT operations), what their specific concerns are (financial risk, operational continuity, strategic alignment, security), and which views of the architecture are relevant to addressing each concern.
A TOGAF approach starts with the Preliminary phase and works through the ADM. The answer might arrive eventually, but it will take longer and carry more overhead than the question warrants.
Architecture as Decision Support
The distinction between TOGAF and ISO 42010 maps onto a broader tension in enterprise architecture between two competing conceptions of what EA is for.
One conception — reflected in TOGAF's origins — is that EA is a documentation and governance function. Its job is to maintain an accurate model of the current and future state, to ensure that changes are assessed against that model, and to produce the artefacts that allow the architecture to be understood and governed.
The other conception — closer to ISO 42010's intent — is that EA is a decision support function. Its job is to ensure that the people making strategic and investment decisions have the information, models, and analysis they need to make good decisions, in the timeframe those decisions need to be made.
In a slower-moving world, the documentation-first approach was viable. Decisions had long enough lead times that a thorough architectural review was feasible. The architecture artefacts had shelf lives measured in years.
AI adoption has collapsed those lead times. Organisations are making decisions about AI capabilities, AI vendors, AI governance, and AI integration on timescales of weeks, not quarters. An architecture function that requires a full ADM cycle to respond is not an architecture function — it's a bottleneck.
What Modern EA Looks Like
The architecture function that serves an AI-era organisation is viewpoint-driven and concern-led. It maintains a portfolio view not as a compliance exercise but as a tool for active decision support. It develops viewpoints for the concerns that matter most to leadership — capability alignment, technology risk, vendor dependency, AI readiness — and keeps them current.
This does not require ISO 42010 certification. It requires the mindset shift that ISO 42010 represents: architecture work is justified by the decisions it informs, not the artefacts it produces.
The question to ask of any architecture activity is: which stakeholder concern does this address, and how will it improve a decision? If the answer is unclear, the activity is overhead.
EA frameworks are tools, not ends in themselves. The organisations making the best decisions in 2026 are the ones that have adopted the lightweight, concern-driven approach ISO 42010 points toward — whether they know the standard by name or not.