Enterprise Architecture: The Blueprint That Never Quite Fits

In 1987, John Zachman published a paper in the IBM Systems Journal that introduced what became known as the Zachman Framework. It was not really a methodology. It was a taxonomy, a two-dimensional grid that organized enterprise architecture artifacts by what they described (data, function, network, people, time, motivation) and who was looking at them (executives, business managers, system architects, designers, builders, subcontractors). The idea was that an enterprise, like a building, needed a complete set of drawings produced at different levels of abstraction, each serving a different audience. No single drawing was "the architecture." The architecture was the whole set, the totality of representations needed to understand, build, and operate the enterprise. It was a genuinely elegant idea.

TOGAF came later, developed by The Open Group, and took a more methodological approach. Where Zachman gave you a taxonomy of what to document, TOGAF gave you a process for how to develop, maintain, and govern architecture. The Architecture Development Method, which most practitioners just call the ADM, walks architecture teams through phases from preliminary work through architecture vision, business architecture, information systems architecture, technology architecture, and then a series of transition and governance phases. TOGAF has become the dominant methodology in the field. By most accounts, a significant proportion of large enterprises that have formal EA programs use TOGAF or something derived from it. Certification programs exist and are widely pursued.

The problem is not that Zachman or TOGAF are wrong. The problem is what enterprise architecture programs have often become in practice, and why that differs so much from the theory.

I have talked to architects in large organizations and read enough EA literature to recognize the same complaint across different contexts. The EA team produces artifacts, lots of them. Architecture diagrams, principle documents, technology roadmaps, capability maps, application portfolio assessments. These take real time to produce. They are carefully structured and formally reviewed. And then they sit in a repository that the engineering teams actually delivering software have never opened and have no particular reason to open. The gap between the architecture as documented and the architecture as built can be enormous, and the EA team often finds out about divergence only when something breaks or a new capability request reveals that the documented landscape and the actual landscape have drifted significantly apart.

TOGAF has a concept called the architecture repository, the governed store of all architectural artifacts, and a concept called the architecture board, the body that reviews and approves architectural decisions. In principle, these mechanisms ensure that decisions are made against an authoritative architectural baseline. In practice, delivery teams under schedule pressure do not wait for architecture board reviews, because architecture board reviews take time that the sprint schedule does not have. The board exists, the repository exists, the governance exists on paper, and the actual decisions get made by engineers in pull requests. The architecture is the sum of the pull requests, not the sum of the documents in the repository.

This is the gap I keep running into: EA frameworks were designed for an era of waterfall delivery and multi-year programs where there was time to develop comprehensive architecture documentation before any code was written. Agile delivery moved that timeline. A two-week sprint cannot wait four weeks for architecture review. A continuous deployment pipeline cannot be paused while the architecture board meets to assess implications. The governance model embedded in TOGAF's ADM assumes a pace of decision-making that most modern engineering organizations have outgrown. This is not a flaw in TOGAF's logic. It is a design choice that was reasonable when the methodology was developed and has aged poorly.

The IT-business alignment framing from Henderson and Venkatraman (1993), as I described in my post on why alignment is still unsolved after three decades, captures what EA programs are supposed to address: the gap between business strategy and IT infrastructure, and the organizational and IT strategy layers in between. EA is one of the primary organizational mechanisms for maintaining that alignment. The Zachman grid and the TOGAF ADM are tools for making the alignment visible, governing it, and updating it when the strategy changes. The reason EA so often fails to deliver on this promise is not that the frameworks are wrong but that the alignment problem is harder than any framework can fully address, because alignment requires ongoing negotiation between business and IT leaders who are often not in the same room, have different priorities, and use different vocabulary.

Modern organizations have started responding to the gap with what some call "lightweight EA" or "evolutionary architecture." The idea is to treat architecture decisions not as comprehensive blueprints produced upfront but as a series of fitness functions and decision records produced incrementally, as close to the code as possible. Architecture decision records (ADRs) are probably the most widely adopted version of this. Instead of a comprehensive architecture document that nobody reads, you get a series of short records, each documenting one significant architectural choice, the options considered, the decision made, and the reasoning. An engineer who encounters a confusing design choice can find the ADR that explains it. The governance is embedded in the decision trail, not in a separate repository.

Platform engineering is the infrastructure version of the same response. Rather than governing technology choices through an architecture board that approves or rejects requests, you build an internal developer platform that makes the architecturally approved choices the path of least resistance. Developers pick from a curated set of options. The curation is the governance, expressed as default tooling rather than approval processes. This approach aligns well with the Richard Thaler and Cass Sunstein concept of choice architecture, structuring defaults to produce desired behavior without requiring active enforcement, though I hedge that connection as an interpretation rather than a formal claim in the literature.

Zachman's 1987 insight that enterprises need architecture described at multiple levels of abstraction for different audiences still holds. The problem was never the insight. The problem is that "having architecture" got conflated with "producing architecture documents" and "governing architecture" got conflated with "reviewing architecture documents through a formal board." The documents are a means. The governance is a means. The actual goal is that the technical system the organization runs is coherent, can be understood by the people who need to make decisions about it, and can be changed when the business requires it. Whether that goal is best served by TOGAF's ADM or by ADRs and platform engineering defaults depends on the organization's size, delivery model, and tolerance for governance overhead. Most large organizations seem to be discovering, somewhat painfully, that the answer is not TOGAF as written.