Zachman Where Column: Network and Location Architecture Explained

The "Where" interrogative forms the third column of the Zachman Framework matrix. It answers the fundamental question: "Where does the enterprise do things?" In other words, where are systems, data, and processes located geographically and architecturally?

The Where column represents infrastructure and network architecture across all six perspectives - from the executive planner's high-level geographic footprint down to the actual physical servers and network paths carrying data. Understanding this column is essential for business continuity, disaster recovery, performance optimisation, and regulatory compliance.

What Does the Where Column Address?

The Where column specifically focuses on:

Geographic distribution: Where the business operates (headquarters, regional offices, data centres)
Data replication: Where data is replicated or synchronised
System deployment: Where applications run (on-premises, cloud, hybrid)
Network topology: How systems connect to each other (LANs, WANs, VPNs)
Infrastructure locations: Where physical servers, storage, and networking equipment are located
Redundancy and failover: Where backup systems and disaster recovery sites are located

The Where column is NOT about what exists (What), how it works (How), who operates it (Who), when it happens (When), or why it's there (Why). It focuses purely on "where things are located and how they're distributed."

The Where Column Across Six Perspectives

Row 1 (Planner): Geographic Scope / Business Footprint

Question: Where does the business operate geographically?

Artefacts:

World map showing business locations (headquarters, regional offices, manufacturing facilities)
List of key geographic regions (North America, Europe, Asia-Pacific, Latin America)
Business presence in each region (sales office, manufacturing, customer service centre)
Geographic scope of customers and suppliers

Characteristics:

Executive summary level - one or two pages
Business terminology only, no technical jargon
Stable across years (rarely changes dramatically)

Example geographic scope:

text

Global Operations Map:

Headquarters: New York, USA
Regional Offices: 
  - London, UK (Europe)
  - Singapore (Asia-Pacific)
  - São Paulo, Brazil (Latin America)
  
Manufacturing:
  - Shanghai, China
  - Mexico City, Mexico
  - Warsaw, Poland

Customer Support:
  - 24x7 support centres in US, UK, India
  
Sales:
  - Present in 45 countries across 6 continents

Why it matters: Establishes the business's geographic scope and identifies where systems must have presence or coverage.

Row 2 (Owner): System Distribution / Operational Geography

Question: Where are key systems and data centres located from an operational perspective?

Artefacts:

Network map showing office locations and their connectivity
Primary and disaster recovery data centre locations
Regional system replicas or installations
Key connectivity needs (e.g., "headquarters must have real-time access to customer database")

Characteristics:

3-10 pages including diagrams
Business owner's view - understandable by non-technical stakeholders
Reflects current operational footprint and planned changes
Changes when geographic strategy changes

Example operational geography:

text

Primary Infrastructure:
  - Main data centre: New Jersey, USA (production systems)
  - Secondary data centre: Virginia, USA (disaster recovery)
  
Regional Systems:
  - Europe: Frankfurt, Germany (EU customer data must reside in EU)
  - Asia-Pacific: Tokyo, Japan (serves AP customers)
  - Latin America: Miami, USA (serves LATAM customers)
  
Connectivity:
  - Headquarters (New York) → Main data centre (New Jersey): Low-latency link
  - Regional offices → Nearest data centre: High-speed WAN links
  - All offices → Internet: Redundant ISP connections

Business continuity requirements:

RTO (Recovery Time Objective): 4 hours
RPO (Recovery Point Objective): 1 hour
Failover to secondary data centre must be automatic

Why it matters: Ensures systems are positioned to support business operations and meet regulatory requirements (e.g., data residency in EU).

Row 3 (Designer): Logical System Architecture / Network Design

Question: What is the logical system architecture and network topology?

Artefacts:

Logical network diagram (systems, subsystems, connections)
Data replication topology (primary-replica, master-master, peer-to-peer)
System clustering and partitioning strategy (how data is split across locations)
Latency and bandwidth requirements between systems
Network zones (DMZ, internal, backend)

Characteristics:

5-20 pages including diagrams
Architect's view - technical but not infrastructure-specific
Detailed but not dependent on specific cloud provider or equipment
Changes when system architecture or requirements change

Example logical architecture:

text

Internet
  ↓
Load Balancer (logical)
  ↓
├─ Web Tier (multiple instances)
│   - Product catalogue
│   - Shopping cart
│   - User interface
│
├─ API Tier (multiple instances)
│   - Order processing
│   - Payment processing
│   - Inventory management
│
├─ Application Tier
│   - Business logic
│   - Workflow engine
│   - Reporting
│
└─ Data Tier (replicated across locations)
    - Primary database (New Jersey)
    - Regional replicas (Frankfurt, Tokyo)
    - Cache layer (distributed)

Replication topology:

text

Primary DB (New Jersey)
  ↓ Async replication
  ├─ Replica (Virginia) [Failover target]
  ├─ Replica (Frankfurt) [EU customer data]
  └─ Replica (Tokyo) [AP customer data]

Network requirements:

New Jersey to Virginia: < ms latency
New Jersey to Frankfurt: <50 ms latency acceptable (async replication)
New Jersey to Tokyo: <50 ms latency acceptable (async replication)

Why it matters: Ensures logical design is sound before committing to specific infrastructure.

Row 4 (Builder): Physical Infrastructure / Cloud Architecture

Question: How is the system deployed on specific physical or cloud infrastructure?

Artefacts:

Infrastructure architecture diagram (specific data centres, cloud regions, availability zones)
Technology choices (on-premises vs cloud vs hybrid; AWS vs Azure vs GCP)
Server specifications (compute, memory, storage, network)
Load balancing and failover strategy
Disaster recovery plan and failover procedures

Characteristics:

10-40 pages depending on complexity
Technical and infrastructure-specific
Designed for reliability, performance, and cost-effectiveness
Changes when infrastructure strategy or technology choices change

Example for AWS multi-region architecture:

text

AWS Infrastructure:

Primary Region: us-east-1 (N. Virginia)
  ├─ VPC: 10.0.0.0/16
  ├─ AZ 1a: Compute layer
  │   └─ EC2 instances (web tier, app tier)
  ├─ AZ 1b: Data layer
  │   └─ RDS Multi-AZ (primary database)
  ├─ AZ 1c: Cache layer
  │   └─ ElastiCache (Redis cluster)
  └─ Load Balancer: Application Load Balancer (ALB)

Secondary Region: us-east-2 (Ohio) [DR standby]
  ├─ VPC: 10.1.0.0/16
  ├─ RDS read replica (standby, can be promoted)
  └─ ASG (auto scaling group) for rapid failover

International Regions:
  eu-central-1 (Frankfurt): EU customer data replica
  ap-northeast-1 (Tokyo): APAC customer data replica

Route 53: Geo-routing
  - EU customers → eu-central-1
  - APAC customers → ap-northeast-1
  - Americas → us-east-1 (primary)

Replication:
  us-east-1 RDS → us-east-2 RDS read replica
  us-east-1 RDS → eu-central-1 RDS read replica (cross-region)
  us-east-1 RDS → ap-northeast-1 RDS read replica (cross-region)

Failover procedure:

Monitor detects us-east-1 primary region failure
Route 53 health checks fail for us-east-1
Route 53 automatic failover redirects traffic to us-east-2
Application auto-scaling in us-east-2 brings up additional capacity
RDS read replica in us-east-2 promoted to primary

Why it matters: Ensures system is deployed on infrastructure that's reliable, scalable, and cost-effective.

Row 5 (Sub-Contractor): Infrastructure Code / Deployment Scripts

Question: What are the executable deployment scripts and infrastructure-as-code definitions?

Artefacts:

Infrastructure-as-code (IaC) files (Terraform, CloudFormation, Ansible)
Deployment scripts (bash, Python, CI/CD pipelines)
Configuration management files
Network and firewall rules
Monitoring and alerting configurations

Characteristics:

Hundreds to thousands of lines of code
Fully executable and version-controlled
Highly volatile (changes constantly)
"Out of context" without explanation - requires deep infrastructure knowledge

Example Terraform code:

hcl

# Create VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "production-vpc" }
}

# Create subnets in multiple AZs
resource "aws_subnet" "az1" {
  vpc_id = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}

# Create RDS Multi-AZ database
resource "aws_db_instance" "primary" {
  allocated_storage = 100
  db_name = "production"
  engine = "postgres"
  instance_class = "db.r5.2xlarge"
  multi_az = true
  backup_retention_period = 30
  publicly_accessible = false
}

# Create ElastiCache Redis cluster
resource "aws_elasticache_cluster" "cache" {
  cluster_id = "prod-cache"
  engine = "redis"
  node_type = "cache.r6g.xlarge"
  num_cache_nodes = 3
  automatic_failover_enabled = true
}

# Create Application Load Balancer
resource "aws_lb" "main" {
  name = "prod-alb"
  load_balancer_type = "application"
  internal = false
  subnets = [aws_subnet.az1.id, aws_subnet.az2.id]
}

Why it matters: Makes infrastructure reproducible and version-controlled. Enables rapid deployment and recovery.

Row 6 (Enterprise): Live Infrastructure / Operational Topology

Question: What infrastructure is actually running and how is it performing?

Artefacts:

Current infrastructure inventory (servers, networks, storage)
Resource utilisation metrics (CPU, memory, disk, network)
Latency and bandwidth measurements
Geo-location of data and systems (to verify compliance)
Disaster recovery status (is failover functional?)

Characteristics:

Continuously changing (infrastructure is provisioned and deprovisioned constantly)
Measured and observable
The source of truth for "what we're actually running"
Monitored for performance, cost, and compliance

Example operational metrics:

text

Infrastructure Status (Real-time):

Primary Region (us-east-1):
  ├─ EC2 instances: 47 running
  │   - Web tier: 12 instances (70% CPU avg, healthy)
  │   - App tier: 28 instances (45% CPU avg, healthy)
  │   - API tier: 7 instances (82% CPU avg, approaching limit)
  │
  ├─ RDS Primary Database
  │   - Storage: 127 GB / 200 GB (63%)
  │   - CPU: 35% average
  │   - Connections: 456 / 500 (91%)
  │   - Replication lag: &lt;00 ms
  │
  ├─ ElastiCache Redis
  │   - Memory: 48 GB / 64 GB (75%)
  │   - Hit rate: 92.3%
  │   - Evictions: 1.2/min
  │
  └─ Network
      - Ingress: 450 Mbps (40% of capacity)
      - Egress: 320 Mbps (35% of capacity)

Geo-location Compliance:
  ✓ EU customer data: All in eu-central-1 (GDPR compliant)
  ✓ US customer data: All in us-east-1 (US-regulated)
  ✓ APAC customer data: All in ap-northeast-1 (Regional)

Disaster Recovery Status:
  ✓ Secondary region (us-east-2) ready: 4-minute failover time
  ✓ Last DR drill: 2026-04-01 (successful)
  ✓ RPO: 12 minutes (acceptable)
  ✓ RTO: 4 minutes (meets SLA)

Alerts and monitoring:

API tier CPU approaching limit - autoscaling triggered
RDS connections at 91% - consider connection pooling
Cache eviction rate increasing - consider larger instance type

Why it matters: Validates that infrastructure is operating correctly and meeting business objectives (performance, compliance, disaster recovery).

Infrastructure Planning: Using the Where Column

The Where column enables comprehensive infrastructure planning:

Row 1 alignment: Business and IT agree on geographic footprint.
Row 2 design: Business defines infrastructure requirements (redundancy, compliance).
Row 3 architecture: Architects design logical infrastructure topology.
Row 4 implementation: Infrastructure engineers select specific cloud/on-premises services.
Row 5 deployment: Infrastructure teams deploy using IaC.
Row 6 monitoring: Operations team monitors actual infrastructure health and utilisation.

This ensures infrastructure supports business requirements and meets SLAs.

Common Mistakes in the Where Column

Centralised everything: All data and systems in one data centre. Result: Single point of failure, poor regional performance.
Ignoring compliance: Deploying customer data in wrong geographic regions. Result: Regulatory violations.
Over-replication: Replicating every database to every region. Result: Unnecessary cost and complexity.
No disaster recovery: No failover plan or secondary infrastructure. Result: Catastrophic failure leads to total outage.
Ignoring Row 6 reality: Never measuring actual infrastructure performance. Result: Infrastructure optimised for wrong metrics.

Where Column vs Other Columns

Where vs What: Where is "location," What is "data." Customer data (What) is replicated to multiple regions (Where).
Where vs How: Where is "infrastructure," How is "processes." Payment processing (How) happens in us-east-1 (Where).
Where vs Who: Where is "location," Who is "actors." Security team (Who) monitors data centre (Where).
Where vs When: Where is "geography," When is "timing." Data is replicated to Frankfurt (Where) every hour (When).
Where vs Why: Where is "infrastructure," Why is "motivation." We replicate to EU (Where) because of GDPR (Why).

Industry Examples: The Where Column

Financial Services

Geographic strategy: Headquarters in New York, trading floors in London and Tokyo (24-hour coverage)
Data distribution: Primary data centre in New Jersey, disaster recovery in Chicago, regulatory archives in Frankfurt
Compliance: Customer data must stay within national boundaries

Healthcare

Geographic strategy: Regional hospitals connected to central data warehouse
Data distribution: Patient records in HIPAA-compliant data centres, test backups in separate region
Compliance: Patient data cannot leave national borders

Retail

Geographic strategy: Corporate headquarters, regional distribution centres, thousands of stores
Data distribution: Corporate data centre, regional caches for store inventory
Compliance: Local data requirements in some countries

Infrastructure Architecture Best Practices

Maintain traceability: Each Row 5 IaC resource maps back to a Row 3 or Row 4 architecture decision.
Version your infrastructure: Use version control for Rows 3-5. Treat infrastructure like code.
Plan for disaster recovery: Always design for failover. Test it regularly (monthly minimum).
Comply with regulations: If operating globally, understand data residency and compliance requirements for each region.
Monitor continuously: Measure Row 6 metrics and compare with Row 2 requirements (RTO, RPO, performance).

Key Takeaways

The Where column describes infrastructure and network architecture: It answers "where are systems, data, and processes located?"
Six perspectives provide a complete infrastructure view: From business footprint to live system performance.
Traceability from Row 1 to Row 6 is critical: Ensure business requirements flow through architecture to actual infrastructure.
The Where column enables disaster recovery and compliance: Proper infrastructure distribution protects against failure and meets regulatory requirements.
Plan for failover: Design systems to withstand single failures and regional outages.

Next Steps

Explore Who Column (actors and organisations) to see who operates the infrastructure.
Read Practical Application: Disaster Recovery and Business Continuity for real-world examples.
Jump to Other Interrogatives (What, How, Who, When, Why) to see the complete picture.

The Where column is critical for operational resilience and regulatory compliance. Master it, and you master infrastructure architecture and disaster recovery.

Meta Keywords: Zachman Where column, network architecture, infrastructure, cloud architecture, disaster recovery, data distribution, multi-region, data centre.