Visual Atlas — Maps 1–4
Map 1 — Strategy → Data Architecture → Technology Execution
BUSINESS STRATEGY
capabilities • processes • information needs
↓ translation / alignment
DATA ARCHITECTURE
models • definitions • structures • flows • standards • requirements
↓ guidance / constraint / implementation
TECHNOLOGY + PROJECT EXECUTION
applications • platforms • integrations • delivered capability
Interpretation: Architecture preserves enterprise intent while projects execute. The arrows are not a one-time waterfall handoff.
Rebuild check: include business need, architecture blueprint/requirements, execution, and the alignment relationship.
Source: pp. 101–103.
Map 2 — Four Enterprise Architecture domains
BUSINESS
value • capabilities • processes • events • strategy
↓ requirements
DATA
models • definitions • mappings • flows • structured interfaces
↕
APPLICATION
business systems • software packages • application/database function
↓ hosted/enabled by
TECHNOLOGY
platforms • networks • infrastructure • security • integration tech
Interpretation: Each domain answers a different connected question. A data question does not become Application Architecture merely because software stores the data.
Rebuild check: classify by object of concern: value/process; data; application function; physical enablement.
Source: pp. 103–104; Table 6.
Map 3 — Zachman interrogatives × perspectives
WHAT | HOW | WHERE | WHO | WHEN | WHY
Perspective 1 [artifact/view cells across six questions]
Perspective 2 [more detailed stakeholder view]
Perspective 3 [more detailed representation]
... [toward implementation / operation]
Interpretation: the matrix classifies architecture descriptions by fundamental interrogative and perspective.
Write beside the map: ONTOLOGY — NOT METHODOLOGY.
Rebuild check: all six interrogatives + multiple perspectives; do not draw arrows implying a required project sequence.
Source: pp. 104–105; Figure 22.
Map 4 — Enterprise Data Model abstraction stack
ENTERPRISE CONCEPTUAL VIEW
↓ ↑ vertical lineage
SUBJECT AREA CONCEPTS
↓ ↑
ENTERPRISE LOGICAL MODEL
↓ ↑
PROJECT LOGICAL MODEL
↓ ↑
PROJECT PHYSICAL / IMPLEMENTATION MODEL
↔ horizontal links connect peer models/entities at the same level
Interpretation: moving downward adds detail/implementation specificity; moving upward restores broader business meaning. Vertical mappings create lineage; horizontal mappings preserve peer relationships across Subject Areas/models.
Rebuild check: do not label a project physical model as the whole Data Architecture.
Source: pp. 106–109; Figures 23–24.