How to Build a Digital City That Never Falls: Decoding TOGAF Enterprise Architecture with a Physicist's Intuition

Forum topic · 小凯 · 2026-08-26

Summary

This forum post explains TOGAF (The Open Group Architecture Framework) enterprise architecture using accessible, physics-inspired analogies. It breaks down the BDAT model—Business, Data, Application, and Technology architecture—by comparing enterprise layers to city planning components such as utilities, hospitals, and power grids. The article then walks through the Architecture Development Method (ADM) as a continuous improvement cycle covering vision, gap analysis, roadmaps, and governance, and explains the distinction between Architecture Building Blocks (ABB) and Solution Building Blocks (SBB) as a layered abstraction that protects core capabilities from technology churn. The author closes with a critical reflection, warning against bureaucratic documentation traps and advocating modern practices like lightweight Architecture Decision Records (ADRs), Domain-Driven Design (DDD), and Architecture as Code. References include the TOGAF Standard 10th Edition and Zachman's 1987 foundational paper on information systems architecture. A beginner-friendly primer for engineers and architects interested in digital transformation.

How to Build a Digital City That Never Falls: Decoding TOGAF Enterprise Architecture with a Physicist's Intuition

> If you ask a bricklayer how to build a house, he'll immediately talk about bricks, cement, and shovels. But if you plan to build a modern city for 100,000 people in the desert—with hospitals, schools, and a water supply system—starting by hauling bricks would guarantee nothing but chaos. It's the same inside large companies: when engineers hear "system upgrade," they rush to write code and buy servers. Years later, hundreds of systems fight each other and nobody knows where the data actually lives. To escape this enterprise digital quagmire, the TOGAF enterprise architecture methodology was invented. Let's break it down with plain, physics-style intuition.

1. The Four-Layer Skeleton of a Digital Building: the BDAT Model

TOGAF slices a complex enterprise into four neat layers (BDAT):

> Business Capability: like a hospital's "surgery capability" — it must remain rock-solid no matter who runs the hospital. > > Master Data Governance: ensuring "customer #1 Zhang San" refers to the same identity in every system, not different people in finance and customer service.

2. The Ever-Turning Wheel: the ADM (Architecture Development Method)

TOGAF's ADM is not a one-way street but a continuously rotating closed loop:

1. Vision first (Phase A): Don't buy servers right away — ask the boss whether the company plans global expansion or cost reduction over the next three years. 2. Gap analysis (Phases B/C/D):

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

Clearly list which legacy systems to Retire, Retain, or build New. 3. Roadmap (Phases E/F): Eat one bite at a time — deliver transition architecture V1.0, then smoothly upgrade to V2.0. 4. Governance & evolution (Phases G/H): Architects supervise implementation like a chief engineer, ensuring no one quietly rewrites spaghetti code at the bottom.

> Gap Analysis: subtracting reality from the dream — like renovating a house, precisely marking which walls are load-bearing (keep) and which are dangerous (demolish).

3. Smart Building Blocks: ABB and SBB

TOGAF plays with building blocks like a physicist playing with atoms:

\text{Enterprise digital immunity} = \frac{\text{Logical blocks ABB (stable for a decade)}}{\text{Physical components SBB (replaced every few years)}}

Architecture Building Block (ABB): an abstract capability, e.g., "I need automated secure access control" — never outdated by technology trends.
Solution Building Block (SBB): a concrete implementation, e.g., "this year we use Keycloak 24.0 / OAuth 2.0" — swap it whenever something better appears.

Once enterprise capabilities are defined as standard ABBs, replacing old databases with new open-source components (SBBs) leaves the core architecture rock-solid.

4. A Critical Reflection: Don't Fall Into the Bureaucratic Documentation Pit!

Some architects treat TOGAF as a show — drawing 500 pages of Visio diagrams and writing thick Word documents, then producing zero code while the market moves on. Modern architects should instead:

1. Embrace agility and lightness: Use lightweight ADRs (Architecture Decision Records) — a few hundred words of Markdown in a Git repo instead of ten-year perfect blueprints. 2. Combine with Domain-Driven Design (DDD): Turn business architecture directly into entities and domains 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* — The Open Group TOGAF Standard 10th Edition. Establishes the modular system of modern enterprise architecture, unifying the ADM cycle, the BDAT pillars, agile delivery, business capability modeling, and cloud-native microservices. 2. John A. Zachman (1987): *A framework for information systems architecture*, *IBM Systems Journal*, 26(3), 276–292. First proposed a multidimensional classification matrix for complex information systems, laying the philosophical foundation of enterprise architecture (EA) methodology.

How to Build a Digital City That Never Falls: Decoding TOGAF Enterprise Architecture with a Physicist's Intuition

Summary

How to Build a Digital City That Never Falls: Decoding TOGAF Enterprise Architecture with a Physicist's Intuition

1. The Four-Layer Skeleton of a Digital Building: the BDAT Model

2. The Ever-Turning Wheel: the ADM (Architecture Development Method)

3. Smart Building Blocks: ABB and SBB

4. A Critical Reflection: Don't Fall Into the Bureaucratic Documentation Pit!

References

Tags