TopicTrick Logo
Topictrick
HomeCoursesYouTubeBlogUtilitiesJuniorShopPricing
Loading...
Enterprise ArchitectureZachman Framework

Zachman When Column: Time and Schedule Architecture Explained

TT
TopicTrick Team
•
Zachman When Column: Time and Schedule Architecture Explained
← Back to Zachman Hub

Zachman When Column: Time and Schedule Architecture Explained

The "When" interrogative forms the fifth column of the Zachman Framework matrix. It answers the fundamental question: "When do things happen?" In other words, what are the timing requirements, scheduling needs, and temporal relationships in the enterprise?

The When column represents timing and scheduling architecture across all six perspectives - from the executive planner's business calendar down to the actual real-time events and scheduling decisions happening in systems. Understanding this column is essential for business continuity planning, real-time systems, event-driven architectures, and meeting service level agreements (SLAs).

What Does the When Column Address?

The When column specifically focuses on:

  • Event timing: When business events occur (order placement, payment, shipment)
  • Process scheduling: When processes run (batch jobs, nightly backups, monthly closings)
  • Data synchronisation: When data is replicated or refreshed
  • Lifecycle events: When entities are created, modified, or archived
  • Real-time requirements: What must happen immediately vs. what can be batched
  • SLA and compliance deadlines: When things must be completed

The When column is NOT about what exists (What), how it works (How), where it happens (Where), who does it (Who), or why it's needed (Why). It focuses purely on "when events occur and what timing constraints apply."

The When Column Across Six Perspectives

Row 1 (Planner): Business Calendar / Key Events

Question: When do key business events occur?

Artefacts:

  • Business calendar (fiscal year, quarters, months)
  • Key recurring events (board meetings, earnings announcements, financial closing)
  • Seasonal patterns (e.g., retail peak season, tax season for accounting firms)
  • External events (conferences, regulatory deadlines)

Characteristics:

  • Executive summary level - one to two pages
  • Business terminology only, no technical jargon
  • Relatively stable (recurring patterns repeat annually)

Example business calendar:

text
Annual Business Calendar:

Q1 (Jan-Mar): New Year planning, financial planning, budget season
Q2 (Apr-Jun): Mid-year review, product launches, annual conference
Q3 (Jul-Sep): Summer slowdown, strategic planning, market analysis
Q4 (Oct-Dec): Peak sales season, year-end closing, bonus planning

Key Events:
- Monthly: Board meeting (first Friday)
- Monthly: Financial closing (last Friday)
- Monthly: All-hands meeting (third Thursday)
- Quarterly: Earnings announcement (within 45 days of quarter end)
- Annually: Budget planning cycle (July-August)
- Annually: Strategic planning offsite (September)
- Annually: Annual conference (June)

External Deadlines:
- Tax filings: April 15 (US personal), June 15 (corporate estimated)
- Earnings reports (if public): Per SEC 8-K requirements
- Regulatory filings: Varies by industry

Why it matters: Establishes rhythm of business and identifies periods of high activity or special focus.

Row 2 (Owner): Process Schedule / Operational Timing

Question: When do key business processes occur?

Artefacts:

  • Process schedules (daily, weekly, monthly, quarterly, annual)
  • Peak periods and off-peak times
  • Batch job schedules (nightly, weekly)
  • Financial closing schedule (daily, month-end, quarter-end, year-end)
  • Maintenance windows and system downtime windows

Characteristics:

  • 5-10 pages
  • Business owner's view - understandable by operational staff
  • Changes when business processes or operational needs change

Example operational schedule:

text
Daily Schedule:

06:00 - System preparation (backup verification)
08:00 - Markets open, order intake begins
16:30 - Order cutoff for same-day processing
17:00 - Nightly processing begins
  - Batch billing
  - Data replication to disaster recovery
  - Performance optimization
22:00 - Nightly processing complete
22:30 - Next-day reconciliation begins
23:00 - Reconciliation complete
00:00 - System ready for next day

Weekly Schedule:

Monday 06:00 - Full backup (differential weekly)
Wednesday 14:00 - System maintenance window (2 hours)
Friday 17:00 - Week-end close processing
Friday 23:00 - Week-end archives

Monthly Schedule:

1st of month: Payroll processing
Last Friday: Financial closing
First Friday: Executive reporting
Mid-month: Reconciliation and audit

Peak Periods:

Q4 (Oct-Dec): Peak sales
- Order volume: 3x normal (300% increase)
- Support requests: 2x normal
- System capacity: Running at 85-90% utilisation
- Extended support hours: 24/7 during peak season

Tax Season (Jan-Mar for tax accountants):
- Processing volume: 10x normal
- System load: 95%+ utilisation
- Emergency support: On-call 24/7

SLA requirements:

text
Order Processing:
- Next-business-day orders: Must ship within 24 hours
- Standard orders: Must ship within 5 business days
- Peak season orders: May take up to 10 business days

Support:
- Critical issues: 1-hour response time
- High priority: 4-hour response time
- Normal: 24-hour response time
- Low priority: Best-effort

Financial Closing:
- Month-end close: Complete within 5 business days
- Quarter-end close: Complete within 10 business days
- Year-end close: Complete within 30 days

Why it matters: Ensures timing requirements are understood and processes execute according to schedule.

Row 3 (Designer): Event and Timing Architecture

Question: What events trigger actions and what are the timing requirements?

Artefacts:

  • Event model (what events exist, when they occur)
  • Event sequence diagrams (A happens, then B, then C)
  • Timing constraints (real-time, near-real-time, batch)
  • Data synchronisation requirements (when data must be consistent)
  • Lifecycle state machines (states and when transitions occur)

Characteristics:

  • 10-30 pages including diagrams
  • Architect's view - technical but not technology-specific
  • Detailed and comprehensive
  • Changes when system requirements change

Example event architecture:

text
Order-to-Cash Event Sequence:

1. CustomerPlacesOrder (Real-time)
   ├─ Event published: OrderCreated
   ├─ Data: order ID, customer ID, items, total amount
   └─ Timing: Must process within 100 ms

2. SystemValidatesInventory (Real-time)
   ├─ Event published: InventoryChecked (Success or OutOfStock)
   ├─ If OutOfStock → Event: BackorderCreated
   └─ Timing: Must process within 500 ms

3. PaymentProcessed (Real-time)
   ├─ Event published: PaymentCaptured or PaymentDeclined
   ├─ If PaymentCaptured → Event: OrderConfirmed
   └─ Timing: Must process within 2 seconds (PCI compliance)

4. PickAndPackOrder (Batch, within 24 hours)
   ├─ Event published: OrderPicked, OrderPacked
   ├─ Data: Warehouse location, packaging type
   └─ Timing: Complete within 24 hours

5. ShipOrder (Batch, within 24-48 hours)
   ├─ Event published: OrderShipped
   ├─ Data: Tracking number, expected delivery date
   └─ Timing: Complete within 48 hours

6. GenerateInvoice (Near real-time, within 5 minutes)
   ├─ Event published: InvoiceGenerated
   └─ Timing: Generate within 5 minutes of shipment

7. RecordRevenue (Batch, within 24 hours)
   ├─ Event published: RevenueRecorded
   ├─ Data: Revenue amount, accounting codes
   └─ Timing: Record revenue within 24 hours for GAAP compliance

8. ReceivePayment (Real-time as payment arrives)
   ├─ Event published: PaymentReceived
   └─ Timing: Immediate (processed by bank)

9. ReconcileAccount (Batch, nightly)
   ├─ Event published: AccountReconciled or DiscrepancyFound
   ├─ If DiscrepancyFound → Alert sent to finance team
   └─ Timing: Complete nightly by 06:00

State machine (Order lifecycle):

text
OrderCreated → (inventory check)
  ├─ Success → PaymentPending
  │   ├─ (payment captured)
  │   └─ OrderConfirmed → ReadyForShipment
  │       ├─ (pick and pack)
  │       └─ ReadyToShip → Shipped
  │           ├─ (delivered)
  │           └─ Delivered → Closed
  │
  └─ Failure (out of stock) → BackorderCreated
      ├─ (inventory replenished)
      └─ ReadyForShipment → ... (continues as above)
      
OR

PaymentPending → (payment declined)
  └─ PaymentFailed → AwaitingRetry or Cancelled

Synchronisation requirements:

text
Data Synchronisation Points:

Orders database → Inventory database (Real-time)
  - When: Immediately upon OrderCreated
  - Tolerance: <00 ms delay
  - If failed: Retry every 5 seconds for 2 minutes

Orders database → Accounting system (Batch, nightly)
  - When: Nightly at 22:00 UTC
  - Tolerance: < hour delay
  - If failed: Retry next scheduled batch

Orders database → Regional replicas (Async)
  - Primary DB (US) → EU replica: < min delay (async)
  - Primary DB (US) → APAC replica: < min delay (async)

Why it matters: Ensures system design correctly handles timing requirements and event sequencing.

Row 4 (Builder): Scheduling and Event System Design

Question: How is scheduling and event processing implemented?

Artefacts:

  • Technology choices for scheduling (cron, Quartz, workflow engine)
  • Event bus or message broker design (Kafka, RabbitMQ, SNS/SQS)
  • Real-time vs. batch trade-offs
  • Latency budgets (how much time each step can use)
  • Error handling and retry logic

Characteristics:

  • 15-40 pages depending on complexity
  • Technical and technology-specific
  • Designed for reliability, scalability, and meeting SLAs
  • Changes when technology choices change

Example scheduling architecture:

text
Order Processing Architecture (AWS):

Real-time Path (OrderCreated event):
  1. Customer places order via web UI
  2. Order API validates and persists order to DynamoDB
  3. Event published to SNS: OrderCreated
  4. SNS routes to SQS: InventoryValidationQueue
  5. Lambda (InventoryValidator) pulls from SQS
     - Checks inventory in DynamoDB
     - Publishes event: InventoryChecked (within 500ms)
  6. SNS routes to SQS: PaymentProcessingQueue
  7. Lambda (PaymentProcessor) pulls from SQS
     - Calls Payment Gateway API
     - Publishes event: PaymentCaptured or PaymentFailed (within 2 seconds)
  8. If PaymentCaptured:
     - SNS routes to SQS: OrderConfirmationQueue
     - Lambda sends confirmation email (SES)
     - Order state: CONFIRMED
  9. If PaymentFailed:
     - SNS routes to: ErrorQueue
     - Manual intervention required

Batch Processing Path (nightly):
  1. CloudWatch scheduled rule triggers at 22:00 UTC
  2. Lambda (OrderPicker) starts
     - Query: All CONFIRMED orders from last 24h
     - Action: Assign to warehouse bins
     - Publish event: OrderPicked
  3. Lambda (OrderPacker) starts
     - Query: All PICKED orders
     - Action: Mark as ready to ship
     - Publish event: OrderPacked
  4. Lambda (Shipper) starts
     - Query: All PACKED orders
     - Action: Generate shipping labels
     - Publish event: OrderShipped
  5. Lambda (InvoiceGenerator) starts
     - Query: All SHIPPED orders
     - Action: Generate invoice
     - Publish event: InvoiceGenerated
  6. Lambda (RevenueRecorder) starts
     - Query: All INVOICED orders
     - Action: Post to accounting system (API)
     - Publish event: RevenueRecorded

Data Synchronisation Batch Job:
  1. CloudWatch rule triggers nightly at 23:00
  2. Lambda (DatabaseSync)
     - Pull new/modified orders from primary (us-east-1)
     - Replicate to regional databases (eu-central-1, ap-northeast-1)
     - Log completion: "Synced 45,234 records in 8 minutes"
  3. Lambda (DataValidation)
     - Compare record counts between primary and replicas
     - If mismatch: Trigger alert to DBA team
     - Retry failed records

Why it matters: Ensures scheduling and event processing are implemented reliably and at scale.

Row 5 (Sub-Contractor): Scheduling Code and Configuration

Question: What are the executable scheduling jobs and event handlers?

Artefacts:

  • Cron job definitions or workflow definitions
  • Event handler code (Lambda, microservice endpoints, etc.)
  • Job scheduling configurations
  • Retry and error handling logic
  • Logging and monitoring code

Characteristics:

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

Example scheduling code:

python
# Nightly order processing job (triggered by CloudWatch)
import boto3
import logging
from datetime import datetime, timedelta

logger = logging.getLogger()
logger.setLevel(logging.INFO)

dynamodb = boto3.resource('dynamodb')
sns = boto3.client('sns')
orders_table = dynamodb.Table('Orders')

def lambda_handler(event, context):
    """
    Nightly batch job: Process confirmed orders for shipment.
    1. Identify CONFIRMED orders from last 24h
    2. Assign to warehouse bins
    3. Publish OrderPicked event
    """
    
    try:
        # Get yesterday's date for filtering
        yesterday = datetime.now() - timedelta(days=1)
        yesterday_str = yesterday.isoformat()
        
        # Query confirmed orders
        response = orders_table.query(
            IndexName='StatusDateIndex',
            KeyConditionExpression='#status = :status AND created_date > :date',
            ExpressionAttributeNames={
                '#status': 'status',
                '#date': 'created_date'
            },
            ExpressionAttributeValues={
                ':status': 'CONFIRMED',
                ':date': yesterday_str
            }
        )
        
        orders = response['Items']
        logger.info(f"Found {len(orders)} orders to process")
        
        picked_count = 0
        for order in orders:
            try:
                # Assign to warehouse bin
                bin_assignment = assign_to_bin(order)
                
                # Update order status
                orders_table.update_item(
                    Key={'order_id': order['order_id']},
                    UpdateExpression='SET #status = :status, bin_assignment = :bin',
                    ExpressionAttributeNames={'#status': 'status'},
                    ExpressionAttributeValues={
                        ':status': 'PICKED',
                        ':bin': bin_assignment
                    }
                )
                
                # Publish event
                sns.publish(
                    TopicArn='arn:aws:sns:us-east-1:123456789012:OrderEvents',
                    Message=f'{{"event": "OrderPicked", "order_id": "{order["order_id"]}", "timestamp": "{datetime.now().isoformat()}"}}',
                    Subject='OrderPicked'
                )
                
                picked_count += 1
                
            except Exception as e:
                logger.error(f"Error processing order {order['order_id']}: {str(e)}")
                # Publish error event for manual investigation
                sns.publish(
                    TopicArn='arn:aws:sns:us-east-1:123456789012:OrderEvents',
                    Message=f'{{"event": "OrderPickingFailed", "order_id": "{order["order_id"]}", "error": "{str(e)}"}}',
                    Subject='OrderPickingFailed'
                )
        
        logger.info(f"Successfully picked {picked_count} orders")
        
        return {
            'statusCode': 200,
            'body': f'Processed {picked_count} orders'
        }
        
    except Exception as e:
        logger.error(f"Batch job failed: {str(e)}")
        # Send alert to ops team
        sns.publish(
            TopicArn='arn:aws:sns:us-east-1:123456789012:Alerts',
            Message=f'Order picking batch job failed: {str(e)}',
            Subject='ALERT: Order Processing Failure'
        )
        raise

def assign_to_bin(order):
    """Assign order to nearest warehouse bin based on items and location."""
    # Business logic to determine bin
    # Returns bin location (e.g., "BIN-A3-R2-L4")
    pass

Event handler code:

python
# Real-time event handler for inventory validation
def validate_inventory_handler(event, context):
    """Handle OrderCreated event, validate inventory."""
    
    message = json.loads(event['Records'][0]['Sns']['Message'])
    order_id = message['order_id']
    items = message['items']  # List of {product_id, quantity}
    
    try:
        # Check inventory for each item
        all_in_stock = True
        for item in items:
            inventory = get_inventory_level(item['product_id'])
            if inventory < item['quantity']:
                all_in_stock = False
                break
        
        if all_in_stock:
            # Reserve inventory
            for item in items:
                reserve_inventory(item['product_id'], item['quantity'])
            
            # Publish success event
            sns.publish(
                TopicArn='arn:aws:sns:us-east-1:123456789012:OrderEvents',
                Message=json.dumps({
                    'event': 'InventoryValidationSuccess',
                    'order_id': order_id,
                    'timestamp': datetime.now().isoformat()
                }),
                Subject='InventoryValidationSuccess'
            )
        else:
            # Publish failure event
            sns.publish(
                TopicArn='arn:aws:sns:us-east-1:123456789012:OrderEvents',
                Message=json.dumps({
                    'event': 'InventoryValidationFailed',
                    'order_id': order_id,
                    'reason': 'OutOfStock',
                    'timestamp': datetime.now().isoformat()
                }),
                Subject='InventoryValidationFailed'
            )
        
    except Exception as e:
        logger.error(f"Inventory validation error: {str(e)}")
        raise

Why it matters: Makes scheduling and event processing operational, testable, and version-controlled.

Row 6 (Enterprise): Live Scheduling and Event Status

Question: When are events actually happening and is everything on schedule?

Artefacts:

  • Job execution logs (what ran, when, success/failure)
  • Event processing metrics (events per second, latency)
  • SLA compliance metrics (% of jobs meeting timing requirements)
  • Alerts and failures (jobs that missed deadlines)
  • Performance dashboard (job durations over time)

Characteristics:

  • Continuously changing (events happening every second)
  • Measured and observable
  • The source of truth for "what's actually happening"
  • Monitored for compliance with SLAs

Example operational metrics:

text
Real-time Event Processing (Last 24 hours):

OrderCreated events: 45,231 received
  - Processing time (p95): 245 ms (target: &lt;00 ms) ⚠️
  - Processing time (p99): 1,240 ms (target: &lt;00 ms) ⚠️
  - Success rate: 99.94% (46 failures)
  - Failures: 23 payment API timeout, 15 inventory check timeout, 8 other

InventoryValidation events: 45,231
  - Processing time (p95): 89 ms (target: &lt;00 ms) ✓
  - Success rate: 99.98%
  - Failures: 9 (database query timeout)

PaymentProcessing events: 44,892 (1 fewer due to inventory failures)
  - Processing time (p95): 1,890 ms (target: &lt; seconds) ✓
  - Processing time (p99): 2,450 ms (target: &lt; seconds) ⚠️
  - Success rate: 99.25% (336 failures)
  - Failures: 198 declined, 94 timeout, 44 validation error

Nightly Batch Jobs:

OrderPicker Job (22:00 UTC):
  - Start time: 22:00:00
  - End time: 22:03:45 (245 seconds)
  - Target: &lt;00 seconds ✓
  - Orders processed: 45,231
  - Success rate: 100%

OrderPacker Job (22:05 UTC):
  - Start time: 22:05:00
  - End time: 22:08:12 (192 seconds)
  - Target: &lt;00 seconds ✓
  - Orders processed: 44,892
  - Success rate: 99.92%
  - Failures: 36 (manual intervention required)

Shipper Job (22:10 UTC):
  - Start time: 22:10:00
  - End time: 22:14:33 (273 seconds)
  - Target: &lt;00 seconds ✓
  - Orders processed: 44,856
  - Success rate: 99.91%

DatabaseSync Job (23:00 UTC):
  - Start time: 23:00:00
  - End time: 23:08:15 (495 seconds)
  - Target: &lt;00 seconds ✓
  - Records synced: 45,231 to EU, 45,231 to APAC
  - Verification: All records verified ✓

SLA Compliance (Last 30 days):

Order Processing (next-business-day):
  - On-time delivery: 98.7% (target: >99%) ⚠️
  - Late orders: 582 (root cause: Late batch job starts 15% of time)

Month-end Close:
  - Completed within 5 days: 100% ✓
  - Latest completion: 4.2 days

Support Response Times:
  - Critical: 99.2% within 1 hour (target: >99.5%) ⚠️
  - High: 99.8% within 4 hours (target: >99.5%) ✓
  - Normal: 100% within 24 hours ✓

Alerts (Last 24 hours):

22:15 - OrderPicker job finished 2 min late (within acceptable variance)
23:45 - DatabaseSync finished 30 sec late (within acceptable variance)
12:30 - Critical alert: Payment API response time spike (resolved at 12:45)

Why it matters: Validates that timing requirements are being met and enables proactive alerting when SLAs are at risk.

Timing Planning: Using the When Column

The When column enables comprehensive timing and scheduling:

  1. Row 1 alignment: Business and IT agree on business calendar and key events.
  2. Row 2 design: Business defines operational schedules and SLA requirements.
  3. Row 3 architecture: Architects define event models and timing constraints.
  4. Row 4 implementation: Engineers select scheduling and messaging technology.
  5. Row 5 deployment: Developers implement scheduling jobs and event handlers.
  6. Row 6 monitoring: Operations team monitors job execution and SLA compliance.

This ensures timing requirements flow from business needs through to actual system operation.

Common Mistakes in the When Column

  1. No SLA definition: Not defining when things must complete. Result: Unclear expectations and blame game.

  2. Batch vs real-time confusion: Not understanding which processes must be real-time vs. which can batch. Result: Over-investment in real-time processing.

  3. No retry logic: Jobs failing with no automatic retry. Result: Manual intervention required for every failure.

  4. Ignoring peak load: Not planning for peak periods. Result: System performs well normally but fails during peak season.

  5. No monitoring: Never checking if jobs ran or if SLAs were met. Result: Surprises when things fail.

When Column vs Other Columns

  • When vs What: When is "timing," What is "data." Order data (What) is processed nightly (When).
  • When vs How: When is "schedule," How is "process." Order process (How) runs at 22:00 (When).
  • When vs Where: When is "timing," Where is "location." Processing happens daily (When) in US-East data centre (Where).
  • When vs Who: When is "schedule," Who is "people." Order processing (When) is done by automated job (Who).
  • When vs Why: When is "timing," Why is "motivation." Process runs nightly (When) to prepare for next-day shipment (Why).

Industry Examples: The When Column

Banking

  • Real-time: Payment processing, fund transfers, fraud detection
  • Batch: Nightly reconciliation, end-of-day settlement, monthly statement generation
  • Peak periods: Quarter-end closing, tax season, holiday shopping

Healthcare

  • Real-time: Patient vital monitoring, medication alerts, emergency notifications
  • Batch: Daily billing, weekly insurance claims, monthly reconciliation
  • Peak periods: Flu season, accident season (summer), end-of-year deductible resets

Retail

  • Real-time: Point-of-sale, inventory updates, fraud detection
  • Batch: Nightly closeout, weekly inventory counts, monthly financial close
  • Peak periods: Black Friday, holiday shopping, back-to-school

Timing Architecture Best Practices

  1. Define SLAs clearly: Know what must be real-time vs. batch. Put numbers on it.

  2. Implement retry logic: Failed jobs should retry automatically (with exponential backoff).

  3. Monitor everything: Log job starts, completions, and failures. Set alerts for SLA violations.

  4. Plan for peak load: Test system during peak periods. Don't assume peak load = normal load.

  5. Use event-driven architecture: Decouple processes using events. Enables better scaling and resilience.

Key Takeaways

  1. The When column describes timing and scheduling: It answers "when do events occur and what are the timing requirements?"

  2. Six perspectives provide a complete timing view: From business calendar to live job execution.

  3. SLAs must be defined explicitly: Know what must be real-time, what can be batch, and when failures are acceptable.

  4. Traceability from Row 1 to Row 6 is critical: Ensure business timing requirements flow through design to actual system performance.

  5. Monitor and alert on SLA violations: Proactively detect and fix timing issues before they impact business.

Next Steps

  • Explore Why Column (motivation and business rules) to see why timing requirements exist.
  • Read Practical Application: Event-Driven Architecture for real-world examples.
  • Jump to Other Interrogatives (What, How, Where, Who, Why) to see the complete picture.

The When column is critical for meeting business objectives and SLAs. Master it, and you master real-time systems and operational scheduling.

Meta Keywords: Zachman When column, scheduling, event-driven architecture, timing requirements, SLAs, batch processing, real-time processing, data synchronisation.