Decoding the Zachman Framework: Blueprint Planning for Enterprise Architecture

Zachman Framework Overview

The Zachman Framework defines a 6×6 matrix that combines two orthogonal dimensions: stakeholder perspectives (Who) and core questions (What). Each cell maps to a specific architecture artifact, ensuring completeness and eliminating gaps.

Stakeholder Perspectives (vertical)

Executive Perspective (Scope/Context) : Business planners focus on external drivers, high‑level business functions, and the why of the enterprise.

Director Perspective (Business Concept) : Business‑concept owners build process models, define entities, relationships, roles, and rules.

Architect Perspective (System Logic) : Designers create logical models without committing to technologies.

Engineer Perspective (Technical Physical) : Builders translate logical models into concrete technical specifications such as platforms, databases, and network devices.

Technician Perspective (Tool Component) : Implementers handle deployment, configuration, and the as‑built artifacts.

Business Perspective (Operational Instance) : End users focus on actual operation, data, roles, and network messages.

Core Questions (horizontal)

Why (Motivation) : Business goals and constraints.

What (Data) : Business entities and information models.

How (Function) : Business processes and system logic.

Who (Responsibility) : Roles, stakeholders, and access subjects.

When (Timing) : Events, cycles, and schedules.

Where (Network) : Physical or logical locations and distribution.

The matrix forces a view of every role against every core question, producing a comprehensive, gap‑free panorama.

Zachman vs. TOGAF

Zachman answers “what an enterprise architecture should describe”; TOGAF (The Open Group Architecture Framework) provides the “how” – a phased Architecture Development Method (ADM) that translates the 6×6 matrix into an implementable lifecycle.

Core Positioning : Zachman – description meta‑framework; TOGAF – implementation methodology.

Core Goal : Zachman – standardize description, ensure completeness; TOGAF – guide implementation, achieve business‑technology alignment.

Core Logic : Zachman – 6 rows × 6 columns matrix; TOGAF – eight‑phase ADM lifecycle.

Application Roles : Zachman – architects, analysts (describe); TOGAF – designers, implementers, governors (design/implement/manage).

Core Value : Zachman – unified communication language, eliminate ambiguity; TOGAF – provide concrete steps, lower adoption barrier.

Practitioners often combine the two: using TOGAF’s ADM as the implementation skeleton while employing the Zachman matrix as a content checklist.

Process Design Using Zachman (e‑commerce order creation)

Planner – Why : Increase GMV, improve user experience.

Owner – What : Define core entities Customer, Product, Order and their relationships.

Designer – How : Design create_order workflow (inventory check, price calculation, order generation).

Builder – With What : Choose Spring Boot, MySQL, Redis, etc.

Implementer – How Implemented : Deploy via Kubernetes, configure CI/CD pipeline.

User – How Used : Provide simple UI/API for smooth ordering.

Sample Code Illustrating Zachman Concepts

// 1. Business entity definitions (What – Owner/Designer perspective)
type Customer struct {
    ID   string `json:"id"`
    Name string `json:"name"`
    Email string `json:"email"`
}

type Order struct {
    OrderID   string    `json:"order_id"`
    Customer  Customer  `json:"customer"`
    Items     []Item    `json:"items"`
    CreatedAt time.Time `json:"created_at"`
}

// 2. Business process definition (How – Designer/Builder perspective)
func CreateOrder(customer Customer, items []Item) (*Order, error) {
    // Validate customer (Who)
    if !isValidCustomer(customer) {
        return nil, errors.New("invalid customer")
    }
    // Check inventory (What & How)
    for _, item := range items {
        if !checkStock(item) {
            return nil, fmt.Errorf("item %s out of stock", item.ID)
        }
    }
    // Generate order (When & How)
    order := &Order{
        OrderID:   generateOrderID(), // timestamp/sequence
        Customer:  customer,
        Items:     items,
        CreatedAt: time.Now(),
    }
    // Persist (Where & With What)
    if err := saveOrder(order); err != nil {
        return nil, err
    }
    // Notify (How Used)
    go sendOrderNotification(order) // async notification
    return order, nil
}

Mnemonic: “Validate customer, check stock, create order, store, notify”. The code touches multiple Zachman cells.

Real‑World Example: JD.com Order Flow

Why (Planner) : Support trillion‑level GMV, achieve 99.99% order success.

What (Owner) : Core entities such as User, SKU, Warehouse, Promotion, etc.

How (Designer) : Complex state machine covering cart, discount calculation, risk control, inventory reservation, payment callbacks.

Who (Owner/Designer) : Distinguish C‑end users, merchants, customer service, warehouse staff.

When (Designer/Implementer) : Handle distributed‑transaction eventual consistency with timeout rollback.

Where (Builder/Implementer) : Deploy services across multiple IDC locations, using dedicated lines and sharded databases.

Debugging & Optimization Tips

Parameter Validation : Centralize validation at entry points (Who & What) to prevent dirty data.

Performance Optimization : Apply read/write splitting and caching for Where; async processing for How.

Testability : Decouple How (business logic) from With What (technology) to enable unit testing.

Monitoring & Alerting : Instrument When (key timestamps) and How Used (user experience) with Prometheus/Grafana.

Integration with Microservices

What : Domain models of services.

How : Orchestrated via API Gateway or Saga pattern.

With What : Services independently choose tech stacks (Go, Java, Python).

How Implemented : Managed uniformly through a service mesh such as Istio.

Advanced Patterns

Event‑Driven Architecture (EDA) : Treat When (events) as the core communication mechanism.

CQRS : Separate What (query model) from How (command model).

Domain Event Sourcing : Persist all state changes (How) as an event stream, matching Zachman’s historical requirement.

Conclusion

The Zachman Framework provides a meta‑model—a way of thinking about architecture itself. It does not prescribe specific technologies or processes, but ensures that every decision is examined from the appropriate perspective and answers the appropriate question.