The Six Perspectives of Zachman: Stakeholder Rows Explained

If the six interrogatives (What, How, Where, Who, When, Why) form the columns of the Zachman Framework, the six perspectives form the rows. Each row represents a different stakeholder's view of the enterprise, at a different level of abstraction.

The six perspectives are sometimes called the "six levels" or "six layers" of the Zachman matrix. They range from the broadest, most abstract view (the executive planner's scope) down to the most detailed, most concrete view (the actual functioning enterprise).

Introduction: The Six Perspectives

The six perspectives reflect the insight that a complete architecture must be described at multiple levels of abstraction:

Row 1: The executive/planner's view - scope and context
Row 2: The business owner's view - conceptual model
Row 3: The architect/designer's view - logical design
Row 4: The engineer/builder's view - physical implementation
Row 5: The specialist/technician's view - detailed components
Row 6: The actual working system - the enterprise itself

This mirrors classical architecture (buildings). An architect describes a building at multiple levels:

Site plan and location (scope)
Functional layout (owner's view)
Construction drawings (designer's view)
Material specifications (builder's view)
Installation details (specialist's view)
The actual constructed building (working system)

The Zachman Framework applies the same logic to enterprise architecture.

The Six Perspectives Explained

Row 1: Contextual - The Planner's Scope

Stakeholder: Executive, Chief Executive Officer, Business Planner

Perspective: "What is the scope and context of the enterprise? What is our business environment?"

Level of abstraction: Highest - most abstract

What this row addresses:

Business scope and boundaries
Market context and environment
High-level goals and strategy
Entity types (nouns the business cares about)
High-level process areas
Geographic scope
Organisational units
Key business rules
Strategic drivers

Characteristics:

Uses business language, not technical jargon
Focuses on "what" and "why," not "how"
Typically one-to-two pages (executive summary level)
Resistant to change (reflects stable business strategy)

Manifestations across interrogatives:

What: Entity list (customers, orders, products, accounts)
How: Process list (order management, billing, support)
Where: Site/geography list (headquarters, regional offices)
Who: Organisational units (sales, operations, finance)
When: Event list (quarter-end close, annual planning)
Why: Goal list (growth, profitability, customer satisfaction)

Example: "Our bank has customer accounts across five geographic regions. Customers deposit, withdraw, and transfer funds. We operate 200 branch locations."

Row 2: Conceptual - The Owner's Business Model

Stakeholder: Business owner, product manager, business analyst, process owner

Perspective: "How does the business actually work? What are the business processes and relationships?"

Level of abstraction: Business level - logical from a business viewpoint

What this row addresses:

Detailed business processes and value chain
Business entity-relationship models
Business rules and policies
Customer journeys and workflows
Organisational responsibilities (RACI)
Information flows between departments
Key decision points
Performance metrics

Characteristics:

Uses business terminology
Describes "how the business operates"
May span 10-50 pages depending on complexity
Moderately resistant to change (reflects business model, which evolves slowly)
Does not prescribe how technology will be used

Manifestations across interrogatives:

What: Entity-relationship diagram (customers have accounts, accounts have transactions)
How: Detailed business process flowchart (order receives → stock check → payment → fulfillment)
Where: Business network map (which regions handle which functions)
Who: Organisational chart and RACI matrix (who approves orders, who handles billing)
When: Business event model (when orders arrive, when invoices go out)
Why: Business rules (customers in Europe pay in Euros, orders must ship within 48 hours)

Example: "When a customer places an order, the sales team enters it. Inventory is checked. If in stock, payment is processed. Warehouse is notified and picks the order. Shipping prepares the package."

Row 3: Logical - The Designer's System Model

Stakeholder: Enterprise architect, solutions architect, systems designer

Perspective: "What is the system's logical architecture, independent of specific technology choices?"

Level of abstraction: System level - logical (technology-independent)

What this row addresses:

Logical data model (entities and relationships without database specificity)
System functions and capabilities
System interfaces and interactions
Information flows between systems
Logical network architecture
Access control requirements
System constraints and performance requirements
Alternative solutions

Characteristics:

Uses technical but technology-neutral language
Describes "what the system must do" without "how" (technology)
Spans 20-100 pages depending on complexity
Moderately volatile (evolves as requirements are refined)
Can be implemented using multiple technology stacks

Manifestations across interrogatives:

What: Logical data model (Order entity with attributes and relationships, independent of database choice)
How: Logical system workflow (Validate Order → Check Inventory → Process Payment → Create Fulfillment Task)
Where: Logical network model (Customer Tier, Business Logic Tier, Data Tier)
Who: System access model and role definitions (Customer role, Staff role, Admin role)
When: Processing sequence and timing requirements (Order must be fulfilled within 24 hours)
Why: System constraints (must support 10,000 concurrent users, 99.99% uptime, < second response time)

Example: "The system accepts orders via a web service. It validates the order against business rules. It queries the inventory system for availability. It calls the payment processor. Upon success, it creates a fulfillment task."

Row 4: Physical - The Builder's Technology Model

Stakeholder: Technical architect, solutions engineer, application architect, DBA

Perspective: "What specific technologies, tools, and platforms will we use to implement the system?"

Level of abstraction: Technology level - physical implementation choices

What this row addresses:

Specific technology stack choices (Java vs Python, Oracle vs PostgreSQL, AWS vs Azure)
Application architecture (monolith vs microservices, REST vs message queue)
Database design (schemas, indexes, partitioning)
Network infrastructure (load balancers, firewalls, CDNs)
Security implementation (encryption, authentication, authorization)
Performance and scalability implementation (caching, replication)
Third-party integrations
Deployment architecture

Characteristics:

Uses specific technology terminology
Describes "how to implement" using specific tech
Spans 30-150 pages depending on complexity
Volatile (evolves as technologies change and new options emerge)
Binding - commits the organisation to specific technology choices

Manifestations across interrogatives:

What: Physical database schema (Order table with specific columns, types, constraints in Oracle)
How: Application design (Spring Boot microservices, each handling specific functions)
Where: Infrastructure topology (Java app servers in us-east-1, database in us-west-2, CDN for static content)
Who: Security design (OAuth 2.0 authentication, Role-Based Access Control in Spring Security)
When: Scheduling design (Quartz jobs for batch processing, Kafka for event streaming)
Why: Technology choices justified (We chose AWS for elasticity, PostgreSQL for open source, Kafka for scalable event handling)

Example: "We will implement using Java Spring Boot microservices running on AWS ECS. The database is PostgreSQL with multi-region replication. Authentication is OAuth 2.0 via AWS Cognito."

Row 5: Detailed - The Sub-Contractor's Component View

Stakeholder: Developer, DBA, security engineer, system administrator

Perspective: "What are the specific components, code, configuration, and deployment details?"

Level of abstraction: Component level - detailed implementation

What this row addresses:

Source code and algorithms
Database DDL (Data Definition Language)
Configuration files
Deployment scripts
Security policies and access controls
Specific third-party library versions
Build and release procedures
Operational runbooks

Characteristics:

Uses programming language and tool-specific terminology
Describes "how to build and deploy" in specific terms
Span from hundreds to thousands of pages (one source file can be 100+ pages)
Highly volatile (changes continuously as code is written)
Out-of-context - difficult to understand without deep technical knowledge

Manifestations across interrogatives:

What: DDL (CREATE TABLE Order statements with specific columns and types)
How: Source code (Java classes for OrderService, OrderValidator, PaymentProcessor)
Where: Deployment configuration (Docker containers, Kubernetes manifests, network policies)
Who: Access control lists (IAM roles, database user permissions, SSH key management)
When: Cron jobs and schedulers (Spring @Scheduled tasks, database job schedules)
Why: Implementation rules (validation logic, business rule enforcement in code, SLA compliance code)

Example: "The OrderService class handles order receipt. It calls OrderValidator to ensure business rules. PaymentProcessor handles payment. Upon success, FulfillmentService creates a task. All code is available in GitHub repo..."

Row 6: Functional - The Enterprise (Working System)

Stakeholder: End users, operations team, customers

Perspective: "This is the actual working system - the implemented enterprise architecture in operation."

Level of abstraction: Lowest - most concrete - actual reality

What this row addresses:

Live running systems
Actual operational data
Real users and sessions
Current performance metrics
Actual uptime and reliability
Real customer experience

Characteristics:

The actual, working enterprise
Not a model or design - this is reality
Constantly changing (data, performance, user base)
Measured through monitoring and observability
The source of truth for "what is actually happening"

Manifestations across interrogatives:

What: Live database contents (actual customer accounts and orders)
How: Running processes (real-time order processing, customers currently shopping)
Where: Deployed infrastructure (live servers, running data centres)
Who: Actual users and sessions (John logged in from New York, Jane logged in from London)
When: Real events occurring (orders arriving every second, daily batch jobs running)
Why: Real-world constraints being enforced (business rules actually preventing invalid transactions)

Example: "Right now, 2,350 customers are shopping. 47 orders are being processed. The system is responding in 890ms average. Database contains 145 million live customer records."

The Six Perspectives as Abstraction Levels

Think of the six perspectives as a bridge from abstract (Row 1) to concrete (Row 6):

text

Row 1 (Planner)       ← Most abstract
Row 2 (Owner)
Row 3 (Designer)
Row 4 (Builder)
Row 5 (Sub-Contractor)
Row 6 (Enterprise)     ← Most concrete

Each row adds detail and specificity. A manager can understand Row 1 (scope). An architect can design Row 3 (logical). A developer implements Row 5 (components). All describe the same enterprise, but at different levels of detail.

How the Six Perspectives Work Together

The power comes from the combination:

Row 1 ensures scope alignment: Everyone agrees on the business boundaries and goals.
Row 2 ensures business understanding: Business and IT agree on how the business works.
Row 3 ensures architectural soundness: Architects ensure the logical design meets requirements.
Row 4 ensures technical feasibility: Builders ensure technologies can implement the design.
Row 5 ensures implementation quality: Developers implement according to specifications.
Row 6 validates everything: The actual system works (or reveals where models were wrong).

Perspective Traceability: From Business to Implementation

A key use of the six perspectives is traceability - ensuring that a requirement from Row 1 flows through all rows and is actually implemented in Row 6.

Example traceability: "Orders must ship within 24 hours"

Row 1 (Planner): Business goal - "Ship orders within 24 hours to stay competitive"
Row 2 (Owner): Business process - "When order is received, warehouse must pick and ship within 20 hours (buffer)"
Row 3 (Designer): System requirement - "Fulfillment task must be created within 5 minutes of order receipt; warehouse management system must notify shipping within 20 hours"
Row 4 (Builder): Technology decision - "Use message queue to immediately notify warehouse; use job scheduler to auto-escalate unfulfilled orders after 18 hours"
Row 5 (Sub-Contractor): Code - "Implement logic to create FulfillmentTask within 5 minutes; Quartz job to escalate unshipped orders after 18 hours"
Row 6 (Enterprise): Reality - "Track actual order-to-ship times; 99.2% of orders ship within 24 hours; 0.8% escalated"

Pitfall: Jumping Rows

A common architectural mistake is skipping rows. For example:

Skipping Row 2 (Conceptual): Going directly from scope (Row 1) to logical design (Row 3). Result: Requirements are incomplete or misunderstood.
Skipping Row 3 (Logical): Going directly from business process (Row 2) to physical technology (Row 4). Result: Architecture is technology-biased and not future-proof.
Skipping Row 4 (Physical): Going directly from logical design (Row 3) to code (Row 5). Result: Implementation misses scalability or performance requirements.

Each row is necessary. Each provides distinct value and catches different types of errors.

Practical Application: Using the Six Perspectives

When architecting a system:

Define Row 1: Stakeholders agree on scope and business goals.
Define Row 2: Business owner defines how the business operates.
Define Row 3: Architect designs the logical system, independent of technology.
Get approval before proceeding: Stakeholders and business agree to Row 3 design.
Define Row 4: Architect chooses specific technologies based on Row 3 requirements.
Define Row 5: Development team implements Row 4 design.
Validate Row 6: Monitor actual system against all rows - do they match? Do requirements flow through?

Key Takeaways

The six perspectives represent abstraction levels: From planner (abstract) to enterprise (concrete).
Each perspective has distinct stakeholders: Different people own and understand different rows.
All six rows are necessary: Each provides unique architectural value.
Traceability from Row 1 to Row 6 is critical: Requirements should flow from business goals through implementation to actual system.
Skipping rows causes architectural problems: Each row catches different types of errors.

Next Steps

Explore Each Perspective in Depth for detailed dives into Rows 1-6.
Read Six Interrogatives to understand the columns.
Jump to Practical Application to see real examples.
Explore Matrix Cells to understand how specific cells combine perspectives with interrogatives.

The six perspectives are the foundation for thinking about enterprise architecture at multiple levels. Mastering them is essential to using the Zachman Framework effectively.

Meta Keywords: Zachman perspectives, six perspectives, Zachman rows, enterprise architecture levels, abstraction levels, stakeholder views, architecture viewpoints, Zachman matrix rows.