Zachman How Column: Function and Process Architecture Explained

Zachman How Column: Function and Process Architecture Explained

The "How" interrogative forms the second column of the Zachman Framework matrix. It answers the fundamental question: "How does the enterprise do things?" In other words, what functions, processes, workflows, and value chains does the enterprise execute to create value?

The How column represents process and functional architecture across all six perspectives - from the executive planner's high-level functional decomposition down to the actual working system executing logic in real-time. Understanding this column is essential for process optimisation, systems integration, and operational excellence.

What Does the How Column Address?

The How column specifically focuses on:

• Functions: Capabilities and activities (billing, order fulfilment, customer service, accounting)
• Processes: Sequences of steps to accomplish a function (order-to-cash, procure-to-pay, hire-to-retire)
• Value chains: How value flows through the enterprise (Porter's Value Chain model)
• Workflows: Orchestration and automation of steps
• Business rules: Logic governing how things are done
• System logic: Application code and algorithms executing processes

The How column is NOT about data (What), locations (Where), actors (Who), timing (When), or motivation (Why). It focuses purely on "what sequences of activities happen and how they're orchestrated."

The How Column Across Six Perspectives

Row 1 (Planner): Function List / Process Decomposition

Question: What high-level functions does the business need to perform?

Artefacts:

• High-level function list: Sales, Marketing, Production, Finance, HR, IT
• Brief description of each function (one or two sentences)
• Functional decomposition showing relationships (Marketing leads to Sales)
• Scope of which functions are in-scope vs out-of-scope

Characteristics:

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

Example function list:

1. Sales
   - Generate customer leads
   - Quote customers
   - Process orders
   - Bill customers

2. Operations
   - Manufacture products
   - Manage inventory
   - Fulfil orders

3. Finance
   - Account for transactions
   - Manage cash
   - Report financial results

4. HR
   - Recruit and hire
   - Manage compensation
   - Train employees

Why it matters: Establishes shared understanding of "what business we're in" and "what we do."

Row 2 (Owner): Value Chain / Business Process Model

Question: How do functions connect to create value from the business owner's perspective?

Artefacts:

• Business process model (using notation like BPMN, flowcharts, or swim lanes)
• Value chain diagram showing inputs, activities, and outputs
• Business process descriptions (text narratives of key workflows)
• Business rules and decision points

Characteristics:

• 5-20 pages including diagrams and narrative
• Business owner's view - understandable by non-technical stakeholders
• Reflects current state or desired future state
• Changes when business strategy or model changes

Example business process (Order-to-Cash):

Customer places order
  ↓
Validate inventory
  ↓
Confirm order with customer
  ↓
Pick and pack order
  ↓
Ship order to customer
  ↓
Generate invoice
  ↓
Receive payment
  ↓
Process payment
  ↓
Close order

Business rules:

• Orders must have valid payment method before processing
• Large orders (>$10k) require manager approval
• Expedited shipping available for orders placed before 2 PM

Decision points:

• If inventory insufficient → Backorder or cancel
• If payment fails → Hold order and notify customer
• If delivery address invalid → Contact customer for correction

Why it matters: Ensures business and IT understand how value flows. Identifies where improvements are possible.

Row 3 (Designer): Logical Process Model / System Functions

Question: What are the system's functions and processes, independent of how they're implemented?

Artefacts:

• Functional requirements specification (detailed, system-level)
• Use case diagrams or process workflows
• State machines (what states entities transition through)
• Algorithm descriptions (logic for important decisions)
• Integration points (how systems handoff to each other)

Characteristics:

• 20-50 pages depending on complexity
• System designer's view - technical but not technology-specific
• Detailed and comprehensive - specifies exactly what the system must do
• Changes when system requirements change, not when implementation technology changes

Example logical process specification:

Process: Validate Payment
Inputs: Payment amount, Customer ID, Account balance
Logic:
  1. Retrieve customer account
  2. If account status = "SUSPENDED" → Reject payment (return error)
  3. If account status = "ACTIVE":
     a. If balance >= payment amount → Approve payment
     b. If balance < payment amount → Reject payment (insufficient funds)
  4. Log validation attempt
Outputs: Approval/Rejection decision, Reason code, Timestamp

State transitions:
  Account: PENDING_VALIDATION → PAYMENT_APPROVED → FUNDS_TRANSFERRED
  or
  Account: PENDING_VALIDATION → PAYMENT_DECLINED → AWAITING_RESUBMISSION

Integration points:

Order System → Payment System: "Validate payment of $500 for order 12345"
Payment System → Accounting System: "Record transaction 98765: Received $500"
Accounting System → Reporting System: "Update monthly revenue by +$500"

Why it matters: Ensures system design is sound and can be implemented by any capable development team using any technology.

Row 4 (Builder): Physical Process Model / System Design

Question: How is the system implemented in specific technologies?

Artefacts:

• Detailed system design documents (architecture, components, interfaces)
• Technology-specific implementation details (microservices, APIs, message queues)
• Integration patterns (REST, events, synchronous, asynchronous)
• Performance optimisations (caching, indexing, parallelisation)
• Error handling and recovery procedures

Characteristics:

• 30-100 pages depending on complexity
• Technical and technology-specific (e.g., Java/Spring, Node.js, Python)
• Designed for performance, scalability, and maintainability
• Changes when technology stack changes or performance requirements change

Example for microservices architecture:

Order Service (Java/Spring Boot):
  - REST endpoint: POST /orders (create order)
  - Calls: Inventory Service (check stock)
  - Publishes event: OrderCreated

Payment Service (Node.js/Express):
  - REST endpoint: POST /payments/validate
  - Calls: Bank API (process payment)
  - Publishes event: PaymentProcessed
  - Consumes event: OrderCreated

Inventory Service (Python/FastAPI):
  - REST endpoint: GET /inventory/{productId}
  - Database: PostgreSQL
  - Cache: Redis (products, inventory levels)
  - Publishes event: StockLevelUpdated

Notification Service:
  - Consumes events: OrderCreated, PaymentProcessed, ShipmentDispatched
  - Sends: Email, SMS, Push notifications

API specifications:

POST /api/v1/orders
Request:
  {
    "customerId": "CUST123",
    "items": [
      {"productId": "PROD456", "quantity": 2}
    ],
    "shippingAddress": "123 Main St, New York, NY"
  }
Response:
  {
    "orderId": "ORD789",
    "status": "CREATED",
    "estimatedDelivery": "2026-04-28"
  }

Why it matters: Ensures the system is implemented correctly for the chosen technology stack and performs well.

Row 5 (Sub-Contractor): Implementation Code / Business Logic

Question: What is the actual executable code implementing the processes?

Artefacts:

• Source code (Java, Python, JavaScript, etc.)
• Configuration files
• Deployment scripts
• Testing code (unit tests, integration tests)
• Documentation for developers

Characteristics:

• Thousands to millions of lines of code
• Fully executable and version-controlled
• Highly volatile (changes constantly)
• "Out of context" without explanation - requires deep technical knowledge

Example pseudocode:

def validate_payment(payment_amount, customer_id, account_balance):
    """
    Validate payment amount against customer account balance.
    Returns: (is_valid, reason_code, timestamp)
    """
    customer = get_customer(customer_id)
    
    if customer.status == "SUSPENDED":
        log_validation_attempt(customer_id, False, "ACCOUNT_SUSPENDED")
        return (False, "ACCOUNT_SUSPENDED", now())
    
    if customer.status != "ACTIVE":
        log_validation_attempt(customer_id, False, "ACCOUNT_INVALID")
        return (False, "ACCOUNT_INVALID", now())
    
    if account_balance >= payment_amount:
        log_validation_attempt(customer_id, True, "APPROVED")
        return (True, "APPROVED", now())
    else:
        log_validation_attempt(customer_id, False, "INSUFFICIENT_FUNDS")
        return (False, "INSUFFICIENT_FUNDS", now())

Why it matters: Makes the processes operational. Code is version-controlled, tested, and executable.

Row 6 (Enterprise): Live System / Process Execution

Question: What processes are actually running and how are they performing?

Artefacts:

• Operational metrics (orders processed per hour, average latency, error rate)
• Event logs and audit trails (what happened and when)
• Performance dashboards (throughput, latency, resource utilisation)
• Error logs and exceptions
• Business metrics (orders completed, revenue processed, customer satisfaction)

Characteristics:

• Continuously changing (processes execute every second)
• Measured and observable
• The source of truth for "what's actually happening"
• Monitored for performance, errors, and business outcomes

Example operational metrics:

Order Processing (last 24 hours):
  - Orders created: 45,231
  - Orders completed: 44,892
  - Orders in progress: 339
  - Average processing time: 4 minutes 23 seconds
  - Median processing time: 3 minutes 12 seconds
  - 95th percentile: 8 minutes 15 seconds
  - Error rate: 0.74% (336 failed orders)
  
Top errors:
  - Payment declined: 198 (58.9%)
  - Inventory unavailable: 94 (28%)
  - Validation failure: 44 (13.1%)
  
Performance:
  - API response time (p95): 245 ms
  - Database query time (p95): 89 ms
  - Cache hit rate: 94.2%

Why it matters: Validates that the system is operating correctly and achieving business objectives.

Process Optimisation: Using the How Column

The How column enables continuous process optimisation:

1. Row 1 alignment: Business and IT agree on key functions.
2. Row 2 design: Business defines current state processes and desired future state.
3. Row 3 specification: Architects specify system-independent requirements.
4. Row 4 implementation: Engineers design technology-specific solution.
5. Row 5 deployment: Developers implement and test.
6. Row 6 monitoring: Operations measure actual performance.

This traceability allows identification of bottlenecks, inefficiencies, and improvement opportunities at every level.

Common Mistakes in the How Column

1. Too granular in Row 1: Detailing every step instead of high-level functions. Result: Overwhelming the executive with unnecessary detail.

2. Mixing With other columns: Including data (What), locations (Where), or actors (Who) in process descriptions. Result: Confusion about what the How column represents.

3. Skipping Row 2: Going directly from function list to system design without defining business processes. Result: Requirements misaligned with business.

4. Over-automation: Automating every process without considering where human judgment is needed. Result: Inflexible system that breaks when exceptions occur.

5. Ignoring Row 6 metrics: Never measuring actual process performance. Result: System optimised for wrong metrics.

How Column vs Other Columns

• How vs What: How is "verbs" (processes), What is "nouns" (data). Billing process (How) operates on customer data (What).
• How vs Where: How is "logic," Where is "location." Order process (How) executes in cloud region (Where).
• How vs Who: How is "activities," Who is "actors." Approval workflow (How) involves managers (Who).
• How vs When: How is "sequence," When is "timing." Order processing (How) happens at scheduled intervals (When).
• How vs Why: How is "implementation," Why is "motivation." We automate billing (How) to reduce costs (Why).

Industry Examples: The How Column

Banking

• Core processes: Account opening, deposit processing, loan origination, fraud detection, settlement
• Value chain: Customer → Account → Deposits/Loans → Interest → Reporting

Healthcare

• Core processes: Patient registration, appointment scheduling, diagnosis, treatment, billing
• Value chain: Patient → Intake → Diagnosis → Treatment → Billing → Payment

Retail

• Core processes: Demand forecasting, procurement, inventory management, order fulfilment, returns
• Value chain: Forecast → Order → Receive → Store → Sell → Deliver → Return

Process Architecture Best Practices

1. Maintain traceability: Each Row 5 code component maps back to a Row 3 or Row 4 process specification.

2. Version your processes: Use version control for Rows 3-5. Track changes over time.

3. Automate wisely: Automate repetitive processes but keep manual override for exceptions.

4. Monitor continuously: Measure Row 6 (actual process performance) and compare with Row 2 (intended process).

5. Document workflows: Use visual notation (BPMN, flowcharts) rather than text descriptions alone.

Key Takeaways

1. The How column describes functions and processes: It answers "what sequences of activities does the enterprise execute?"

2. Six perspectives provide a complete process view: From business decomposition to live system performance.

3. Traceability from Row 1 to Row 6 is critical: Ensure business processes flow through design and implementation to actual system performance.

4. The How column enables continuous improvement: Comparing Rows 2 (intended) with Row 6 (actual) reveals improvement opportunities.

5. Do not automate without understanding the current process: Row 2 must be well-understood before system design in Row 3.

Next Steps

• Explore Where Column (locations and distribution) to see where these processes execute.
• Read Practical Application: Process Optimisation for real-world examples.
• Jump to Other Interrogatives (What, Where, Who, When, Why) to see the complete picture.

The How column is the heart of operational excellence. Master it, and you master process architecture and continuous improvement.

Meta Keywords: Zachman How column, process architecture, function decomposition, business processes, BPMN, value chain, workflows, process optimisation.