TOGAF Enterprise Architecture Explained: Building a Digital City That Never Collapses

Forum topic · 小凯 · 2026-08-26

Summary

This zhichai.net forum post explains the TOGAF enterprise architecture framework using plain-language analogies of city planning. It introduces the BDAT four-layer model—Business, Data, Application, and Technology architecture—explaining how each layer answers a core question (how the company makes money, where master data lives, how many systems to build, and what infrastructure runs the software). It then walks through the Architecture Development Method (ADM) as a continuous rotating cycle: vision, gap analysis (To-Be minus As-Is), transition roadmaps, and implementation governance. The post contrasts Architecture Building Blocks (ABB), stable logical capabilities, with Solution Building Blocks (SBB), replaceable physical implementations, allowing enterprises to swap vendors without destabilizing the core architecture. Finally, it offers a critical reflection: avoid the trap of 500-page bureaucratic documents, and instead combine TOGAF with agile practices like lightweight Architecture Decision Records, Domain-Driven Design, and Architecture as Code. References include the TOGAF Standard 10th Edition by The Open Group and Zachman's 1987 IBM Systems Journal paper on information systems architecture.

This post from zhichai.net explains the TOGAF enterprise architecture methodology through intuitive analogies of building a modern city in the desert. The author's point: if you plan to house 100,000 people with hospitals, schools, and water systems, you cannot start by laying bricks—likewise, enterprises that rush straight into writing code and buying servers end up with hundreds of conflicting systems and no one knowing where the data lives.

1. The Four-Layer Skeleton: BDAT

TOGAF divides an enterprise into four tidy layers:

1. Business Architecture — What do the city's residents need to do? Core question: *"How does this company actually make money?"* Without it, engineers build software nobody uses. 2. Data Architecture — Where are the city's information pipes and ledgers? Core question: *"Where does our most important core data actually live?"* Without it, finance says 1,000 customers while sales says 800. 3. Application Architecture — Which municipal service halls should the city have? Core question: *"How many software systems do we need to support the business?"* Without it, every department builds its own duplicate approval software. 4. Technology Architecture — The power plants, transformers, and concrete foundations: servers, fiber, operating systems. Without it, a Black Friday traffic surge melts the data center.

Key concepts highlighted:

Business Capability: like a hospital always needing surgical and emergency-care capability, regardless of who runs it.
Master Data Governance: when every system mentions customer #1, they all reference the same identity—not "Zhang San" in finance and "Li Si" in support.

2. The ADM: An Ever-Rotating Wheel

The Architecture Development Method (ADM) is a continuous closed loop, not a one-way street:

Phase A — Architecture Vision: ask leadership first—global expansion or cost reduction? Don't buy servers yet.
Phases B/C/D — Current and future state analysis for business, data, application, and technology:

\text{Gap} = \text{To-Be state} - \text{As-Is state}

Explicitly list which legacy systems to Retire, Retain, or build New.

Phases E/F — Gap analysis and roadmap: transition architecture V1.0 first, then smooth upgrade to V2.0.
Phases G/H — Implementation governance and continuous evolution: architects inspect the work like chief engineers, ensuring no hidden spaghetti code creeps back in.

Gap Analysis: subtract reality from the dream—like renovating an old house, mark precisely which load-bearing walls to keep and which dangerous walls to demolish.

3. Building Blocks: ABB vs SBB

The post frames the block philosophy with a fraction:

\text{Enterprise digital immunity} = \frac{\text{logical ABB (unchanged for a decade)}}{\text{physical SBB (replaced every three years)}}

ABB (Architecture Building Block): abstract logical capability, e.g., "I need fully automated secure access control"—never goes out of style.
SBB (Solution Building Block): concrete implementation, e.g., "this year I'll implement it with Keycloak 24.0 / OAuth 2.0"—swappable anytime.

Once capabilities are defined as stable ABBs, swapping in new open-source SBB components leaves the core architecture rock solid.

4. Critical Reflection: Avoid the Bureaucratic Documentation Pit

Some architects treat TOGAF as theater—500 pages of Visio diagrams, zero code, two years gone, market already changed. The author's recommendations for modern practitioners:

1. Embrace agile and lightweight methods: use ADRs (Architecture Decision Records)—a few hundred words of Markdown in a Git repo—instead of ten-year perfect blueprints. 2. Combine with DDD (Domain-Driven Design): let business architecture become entities and domains directly in microservice code. 3. Architecture as Code: use cloud-native declarative scripts so blueprints automatically become living systems running on Kubernetes.

References

1. The Open Group, *The TOGAF® Standard, 10th Edition* — https://www.opengroup.org/togaf-standard-10th-edition 2. John A. Zachman (1987), *A framework for information systems architecture*, IBM Systems Journal, 26(3), 276-292.