Zachman Framework Study Guide: Master the 6x6 Matrix and Key Concepts

This comprehensive study guide consolidates everything you need to master Zachman Framework. Use this as your complete reference guide for learning and certification prep.

The 6 Interrogatives (Columns)

What (Column 1): Entities & Data

Question: What things does the enterprise care about?

Examples: Customer, Product, Order, Invoice, Employee

By Row:

Planner (Row 1): List of business entities in scope
Owner (Row 2): Current databases, record counts, quality
Designer (Row 3): Logical data model (ER diagram)
Builder (Row 4): Physical database schema (DDL)
Sub-Contractor (Row 5): Database scripts, data loading code
Enterprise (Row 6): Live data metrics, record counts, quality

Memory aid: "What = Data, Entities, Information"

How (Column 2): Functions & Processes

Question: How does the enterprise operate?

Examples: Order Processing, Fulfillment, Billing, Risk Assessment

By Row:

Planner: High-level business processes
Owner: Current workflows, manual steps
Designer: Target processes (workflow diagrams)
Builder: API specs, microservices architecture
Sub-Contractor: Source code, job implementations
Enterprise: Operational metrics (throughput, latency)

Memory aid: "How = Process, Function, Workflow"

Where (Column 3): Location & Infrastructure

Question: Where are systems deployed? Where is data located?

Examples: US datacenter, AWS region, Edge location

By Row:

Planner: Geographic scope
Owner: Current datacenters
Designer: Target locations, disaster recovery
Builder: Cloud infrastructure (VPCs, regions)
Sub-Contractor: Deployment scripts (Kubernetes)
Enterprise: Live infrastructure status

Memory aid: "Where = Location, Infrastructure, Geography"

Who (Column 4): People & Roles

Question: Who uses the system? Who owns the data?

Examples: Customer, Fulfillment Manager, Admin

By Row:

Planner: Stakeholder analysis
Owner: Current organizational roles
Designer: Target roles, responsibilities
Builder: Access control design (RBAC)
Sub-Contractor: Provisioning scripts
Enterprise: Current users, access patterns

Memory aid: "Who = People, Roles, Users, Actors"

When (Column 5): Timing & Events

Question: When do things happen? What's the timing?

Examples: Real-time, batch nightly, scheduled weekly

By Row:

Planner: Strategic timeline
Owner: Current SLAs, batch schedules
Designer: Target timing requirements
Builder: Job scheduling (cron, Lambda)
Sub-Contractor: Actual job implementations
Enterprise: SLA compliance, job execution status

Memory aid: "When = Timing, Schedule, Events, Real-time vs. Batch"

Why (Column 6): Motivation & Rules

Question: Why do things work this way? What are the business rules?

Examples: GDPR compliance, fraud prevention, cost optimization

By Row:

Planner: Business strategy, ROI
Owner: Current constraints, compliance
Designer: Target requirements, constraints
Builder: Configuration, policies, feature flags
Sub-Contractor: Policy-as-code, compliance automation
Enterprise: Business metrics, compliance status

Memory aid: "Why = Motivation, Business Rules, Constraints, Strategy"

The 6 Perspectives (Rows)

Row 1: Planner Perspective

Who: CEO, strategic leaders, business executives Focus: Strategic scope and intent Timeframe: Multi-year strategy (3-5 years) Level of detail: High-level, big picture Technology: None (technology-independent) Artifacts: Business case, strategic roadmap, stakeholder analysis

Key principle: "What are we trying to achieve?"

Row 2: Owner Perspective

Who: Business process owners, current operation leads Focus: Current state, as-is operations Timeframe: Today's reality Level of detail: Medium (enough to understand current state) Technology: Current tech (Salesforce, SAP, legacy systems) Artifacts: Inventory lists, process maps, org chart

Key principle: "How do things actually work today?"

Row 3: Designer Perspective

Who: System architects, solution designers Focus: Target architecture, to-be design Timeframe: Future target state (achievable in 2-3 years) Level of detail: Comprehensive but technology-independent Technology: None (logical design, not physical) Artifacts: Entity-relationship diagrams, process models, requirements

Key principle: "How should the system be designed (independent of technology)?"

Row 4: Builder Perspective

Who: Infrastructure teams, tech leads Focus: Technology-specific implementation Timeframe: Implementation (how to build the design) Level of detail: Technical specs (detailed) Technology: Specific (AWS, PostgreSQL, Java, etc.) Artifacts: Database schema, API specs, infrastructure configs

Key principle: "How do we build this with specific technology?"

Row 5: Sub-Contractor Perspective

Who: Developers, DevOps, engineers Focus: Executable code and automation Timeframe: Working software, production-ready Level of detail: Line-by-line (source code) Technology: Programming language, libraries Artifacts: Source code in git, deployment scripts, containers

Key principle: "Here's the actual working code."

Row 6: Enterprise Perspective

Who: Operations, monitoring, business leadership Focus: Live system reality, operational metrics Timeframe: Real-time, now Level of detail: Observed metrics (not designed, but real) Technology: Running systems (actual observed) Artifacts: Operational dashboards, metrics, business KPIs

Key principle: "What's actually happening in the live system?"

Key Relationships Between Rows

Rows 1-3: Plan & Design (intention)

Row 1: Strategic intent ("We want to transform")
Row 2: Current state ("Here's where we are")
Row 3: Target design ("Here's where we want to go")

Rows 4-5: Build & Execute (implementation)

Row 4: Technology specs ("With these tools")
Row 5: Working code ("Here's the implementation")

Row 6: Reality (actual state)

Row 6: Live operations ("Here's what's actually running")

Validation:

Compare Row 6 (actual) to Row 5 (intended implementation) → Are we running what we built?
Compare Row 5 (implementation) to Row 4 (specs) → Did we build to spec?
Compare Row 4 (technical specs) to Row 3 (requirements) → Do our specs meet requirements?
Compare Row 3 (target design) to Row 1 (strategy) → Does design support strategy?

Common Confusions Clarified

Confusion 1: Row 3 vs. Row 4

Row 3 (Designer): "Logical data model, technology-independent"

What: ER diagram with entities and relationships
How: Process models (BPMN, independent of tools)
Example: "Customer has many Orders" (entity-relationship)

Row 4 (Builder): "Physical implementation with specific technology"

What: PostgreSQL DDL, specific column types
How: API specs (REST, gRPC, specific format)
Example: "CREATE TABLE customer (id BIGINT, email VARCHAR(255))"

Memory aid: "Row 3 = What we need. Row 4 = How we'll build it."

Confusion 2: Owner vs. Designer

Owner (Row 2): "Today's reality"

Describes current state accurately (as-is)
Might be messy, inefficient, outdated
Example: "Manual order entry, batch processing, multiple databases"

Designer (Row 3): "Tomorrow's target"

Describes desired future state (to-be)
Should be better, more efficient, more modern
Example: "Automated order entry, real-time processing, single database"

Memory aid: "Owner = Is. Designer = Should Be."

Confusion 3: Which Row Should I Document?

Question: "I need to document customer data. Which row?"

Answer depends:

Describing current databases? Row 2 (Owner)
Designing new data model? Row 3 (Designer)
Specifying database schema? Row 4 (Builder)
Writing SQL scripts? Row 5 (Sub-Contractor)
Checking live data counts? Row 6 (Enterprise)

Memory aid: "What am I trying to achieve? That determines the row."

Zachman in Practice: Order Management Example

Planner (Row 1): "Enable online order placement"

Business entities: Customer, Product, Order
Business value: $10M revenue opportunity
Timeline: 6-month project

Owner (Row 2): "Today: Phone orders, manual entry, overnight processing"

Current database: Salesforce (orders), SAP (inventory)
Pain point: 2-day order-to-fulfillment (customers want faster)

Designer (Row 3): "Target: Online ordering, real-time inventory, next-day fulfillment"

Entities: Customer (unified), Product (master), Order (real-time), Inventory (real-time)
Process: Online submit → Real-time validation → Immediate confirmation

Builder (Row 4): "AWS cloud, PostgreSQL, Java/Spring Boot"

Database: RDS PostgreSQL, table schemas
APIs: Order service REST API
Infrastructure: EKS (Kubernetes), load-balanced

Sub-Contractor (Row 5): "Source code, Kubernetes manifests, CI/CD"

Java code (OrderService microservice)
Terraform (infrastructure deployment)
Git workflows (CI/CD pipeline)

Enterprise (Row 6): "Live system: Processing 1,200 orders/day, 99.94% uptime"

Metrics: Order completion time 2.3 hours, 98.5% customer satisfaction
Business impact: $12M revenue (exceeds $10M target)

Study Checklist

Understand each interrogative (What, How, Where, Who, When, Why)
Understand each perspective (Planner through Enterprise)
Can describe what each cell contains
Can distinguish Row 1 from Row 3 (strategy vs. design)
Can distinguish Row 3 from Row 4 (logical vs. physical)
Can give real example for each row
Can explain relationships between rows
Can apply Zachman to real project

Key Takeaways

6 interrogatives: What, How, Where, Who, When, Why (column questions)
6 perspectives: Planner through Enterprise (row perspectives)
36 cells total: Each intersection (row/column) is a distinct cell
Clear progression: Row 1 (strategy) → Row 3 (design) → Row 5 (code) → Row 6 (reality)
Validation: Compare rows to ensure architecture meets intent

Next Steps

Print Zachman 6x6 matrix
Walk through each cell; write 2-3 sentences about each
Apply to real project you know
Practice explaining to others (teaches deep understanding)

Zachman mastery comes from understanding the matrix, not memorizing definitions.

Meta Keywords: Zachman Framework study guide, 6x6 matrix, interrogatives, perspectives, learning guide.