Zachman Who Column: People and Organisational Architecture Explained

The "Who" interrogative forms the fourth column of the Zachman Framework matrix. It answers the fundamental question: "Who does it?" In other words, which people, roles, departments, and organisational entities are involved in operating the enterprise?

The Who column represents organisational and resource architecture across all six perspectives - from the executive planner's high-level organisational structure down to the actual people executing activities day-to-day. Understanding this column is essential for organisational design, change management, resource planning, and role-based access control.

What Does the Who Column Address?

The Who column specifically focuses on:

Organisational structure: Departments, teams, reporting relationships
Roles and responsibilities: What each role or department is accountable for
Stakeholder management: Who has interest or influence in specific initiatives
Resource allocation: Who is assigned to specific projects or activities
Skillsets and competencies: What knowledge or experience each role requires
Access control and security: Who can access what systems and data

The Who column is NOT about data (What), processes (How), locations (Where), timing (When), or motivation (Why). It focuses purely on "who are the people and organisations involved."

The Who Column Across Six Perspectives

Row 1 (Planner): Organisational Scope / Executive Stakeholders

Question: Who are the key organisational units and stakeholders?

Artefacts:

Organisational chart (CEO, executive team, major departments)
Key external stakeholders (board members, major customers, regulatory bodies)
Governance bodies (steering committee, architecture council)
List of departments or business units involved

Characteristics:

Executive summary level - one to two pages
Business terminology only, no technical jargon
Relatively stable (rarely changes except in major restructurings)

Example organisational scope:

text

Executive Level:
  - CEO (Chief Executive Officer)
  - Chief Operating Officer (COO)
  - Chief Financial Officer (CFO)
  - Chief Technology Officer (CTO)
  
Major Departments:
  - Sales & Marketing
  - Operations
  - Finance & Accounting
  - Human Resources
  - IT & Technology

Key External Stakeholders:
  - Board of Directors
  - Major customers (top 10 account holders)
  - Regulatory bodies (SEC, EPA)
  - Key suppliers and partners

Governance Structures:
  - Enterprise Architecture Council (monthly meetings)
  - IT Steering Committee (monthly decisions)
  - Risk Management Committee (quarterly review)

Why it matters: Establishes who makes decisions and who has interest in enterprise initiatives.

Row 2 (Owner): Functional Organisational Structure / Business Unit Mapping

Question: How is the business organised by function, and who is responsible for each?

Artefacts:

Detailed organisational chart (shows reporting relationships)
RACI matrix (Responsible, Accountable, Consulted, Informed) for key processes
Department descriptions (purpose, responsibilities, headcount)
Stakeholder matrix (who cares about what initiatives)

Characteristics:

5-15 pages including organisational chart and matrices
Business owner's view - understandable by all stakeholders
Reflects current organisational structure and planned changes
Changes when business reorganises or changes strategy

Example functional structure:

text

Chief Operating Officer
  ├─ Director of Sales (12 people)
  │   ├─ Enterprise Sales Manager
  │   ├─ Mid-Market Sales Manager
  │   └─ Sales Operations Manager
  │
  ├─ Director of Operations (45 people)
  │   ├─ Manufacturing Manager
  │   ├─ Logistics Manager
  │   └─ Quality Assurance Manager
  │
  └─ Director of Customer Success (28 people)
      ├─ Support Manager
      ├─ Implementation Manager
      └─ Training Manager

RACI Matrix Example (Order-to-Cash Process):

text

                    | Sales | Operations | Finance | IT
Create order        |   C   |     A      |    C    | R
Process payment     |   I   |     C      |    A    | R
Ship order          |   I   |     A      |    C    | R
Billing & invoicing |   I   |     C      |    A    | R
Revenue recognition |   I   |     C      |    A    | I

R = Responsible (does the work)
A = Accountable (final approval)
C = Consulted (provides input)
I = Informed (kept in the loop)

Stakeholder matrix for initiatives:

text

Initiative: Digital Transformation
Stakeholders:
  - CTO: Sponsor (high influence, high interest)
  - CFO: Approver (high influence, medium interest)
  - Director of Sales: Key stakeholder (medium influence, high interest)
  - IT Director: Executive (high influence, high interest)
  - Business users: Affected (low influence, high interest)

Why it matters: Ensures clear accountability and identifies whose buy-in is needed for initiatives.

Row 3 (Designer): Role and Competency Architecture

Question: What roles, competencies, and interfaces are needed?

Artefacts:

Role definitions (job descriptions, responsibilities)
Required competencies for each role (skills, experience, education)
Role hierarchies (who reports to whom in system architecture)
Interface specifications (how roles interact)

Characteristics:

10-30 pages depending on complexity
Architect's view - detailed but not organisation-specific
Reflects system requirements independent of current organisational structure
Changes when system requirements change

Example role architecture:

text

System Administrator Role:
  Responsibilities:
    - User account creation and management
    - System monitoring and alerting
    - Backup and recovery operations
    - Security patch deployment
    - Capacity planning

  Required Competencies:
    - Windows/Linux administration (7+ years)
    - Database administration basics (5+ years)
    - Networking fundamentals (5+ years)
    - Security best practices
    - ITIL Foundation certification

  Interfaces:
    - Receives requests from: IT Help Desk (via ticketing system)
    - Escalates to: Senior DBA (for complex database issues)
    - Reports to: IT Operations Manager
    - Coordinates with: Security team (for access provisioning)

Data Architect Role:
  Responsibilities:
    - Logical data model design
    - Data governance policies
    - Master data management
    - Data quality standards

  Required Competencies:
    - Database design (10+ years)
    - SQL and data modeling
    - Data governance frameworks
    - ETL and data integration
    - Leadership and communication

  Interfaces:
    - Consults with: Business analysts
    - Leads: Data governance council
    - Escalates to: CTO (for strategic decisions)

Access control role structure (RBAC - Role-Based Access Control):

text

System roles (tied to organisation):
  - Administrator (full system access)
  - Analyst (read-only access to reports)
  - Operator (can execute workflows)
  - Auditor (read-only access to audit trails)
  - Guest (limited time-based access)

Why it matters: Ensures system design includes appropriate user roles and access controls.

Row 4 (Builder): Organisational Unit to System Mapping

Question: How are organisational units structured within the IT system?

Artefacts:

Directory structure (LDAP/Active Directory schema)
User provisioning and de-provisioning procedures
Group and role definitions in identity management system
Access control policies (who can access what systems)
System user accounts for service accounts

Characteristics:

10-30 pages depending on complexity
Technical and system-specific
Designed for security, auditability, and maintainability
Changes when organisational structure changes or security policies change

Example for Active Directory / LDAP structure:

text

Directory Structure:

ou=users,dc=company,dc=com
  ├─ ou=Sales,ou=users,dc=company,dc=com
  │   ├─ cn=john.smith,ou=Sales,ou=users,dc=company,dc=com
  │   │   memberOf: cn=Sales_Users,ou=groups,...
  │   │   memberOf: cn=Order_Entry,ou=groups,...
  │   │
  │   └─ cn=jane.doe,ou=Sales,ou=users,dc=company,dc=com
  │       memberOf: cn=Sales_Managers,ou=groups,...
  │
  ├─ ou=Operations,ou=users,dc=company,dc=com
  │   ├─ cn=bob.jones,ou=Operations,...
  │   │   memberOf: cn=Warehouse_Staff,ou=groups,...
  │   │
  │   └─ cn=alice.wilson,ou=Operations,...
  │       memberOf: cn=Operations_Managers,ou=groups,...
  │
  └─ ou=IT,ou=users,dc=company,dc=com
      ├─ cn=admin.account,ou=IT,...
      │   memberOf: cn=System_Administrators,ou=groups,...
      │
      └─ cn=helpdesk.user,ou=IT,...
          memberOf: cn=Help_Desk,ou=groups,...

ou=groups,dc=company,dc=com
  ├─ cn=Sales_Users
  │   member: john.smith, jane.doe, ...
  │   rights: Read/Write on Orders database
  │
  ├─ cn=Sales_Managers
  │   member: jane.doe, ...
  │   rights: Read/Write on Orders, approval authority
  │
  ├─ cn=System_Administrators
  │   member: admin.account, ...
  │   rights: Full system access

ou=service-accounts,dc=company,dc=com
  ├─ cn=nightly-backup-account
  │   rights: Read on all databases, Write on backup storage
  │
  └─ cn=report-generator-account
      rights: Read on analytics database

User provisioning workflow:

text

New employee hired
  ↓
HR creates employee record in HRIS system
  ↓
System automatically creates:
    - AD user account
    - Email account
    - Network home directory
    - Initial group memberships
  ↓
Manager approves additional access (application permissions)
  ↓
IT provisions system access (databases, applications, etc.)
  ↓
User receives credentials and can log in

Why it matters: Ensures security, auditability, and efficient user management at scale.

Row 5 (Sub-Contractor): Identity Management Code / Scripts

Question: What code and scripts implement user management and access control?

Artefacts:

User provisioning scripts (PowerShell, Python, Java)
Identity and access management (IAM) code
API code for user creation, modification, deletion
Audit logging code (who did what when)
Self-service password reset and profile management 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 Python provisioning script:

python

def provision_new_user(first_name, last_name, email, department):
    """Provision a new user account in all systems."""
    
    # 1. Create Active Directory user
    ad_user = create_ad_user(
        username=f"{first_name.lower()}.{last_name.lower()}",
        email=email,
        department=department
    )
    
    # 2. Create email account
    create_email_account(
        email=email,
        first_name=first_name,
        last_name=last_name
    )
    
    # 3. Create home directory
    create_home_directory(
        username=ad_user['username'],
        path=f"/home/{ad_user['username']}"
    )
    
    # 4. Add to department group
    add_to_group(
        username=ad_user['username'],
        group=f"{department}_users"
    )
    
    # 5. Assign initial permissions based on role
    role = get_initial_role(department)
    assign_permissions(
        username=ad_user['username'],
        role=role
    )
    
    # 6. Send welcome email with temporary password
    send_welcome_email(
        email=email,
        username=ad_user['username'],
        temp_password=ad_user['temp_password']
    )
    
    # 7. Log audit entry
    audit_log(
        action="user_provisioned",
        username=ad_user['username'],
        department=department,
        timestamp=now()
    )
    
    return ad_user

def revoke_user_access(username, reason):
    """Revoke all access for a departing user."""
    
    # 1. Disable AD account
    disable_ad_user(username)
    
    # 2. Revoke all group memberships
    groups = get_user_groups(username)
    for group in groups:
        remove_from_group(username, group)
    
    # 3. Disable email account
    disable_email_account(username)
    
    # 4. Reset home directory permissions (no access)
    revoke_home_directory_access(username)
    
    # 5. Kill active sessions
    kill_user_sessions(username)
    
    # 6. Archive user data
    archive_user_data(username)
    
    # 7. Log audit entry
    audit_log(
        action="user_revoked",
        username=username,
        reason=reason,
        timestamp=now()
    )

Why it matters: Makes user provisioning and access control automated, auditable, and consistent.

Row 6 (Enterprise): Live Organisational Roster / Access Reality

Question: Who actually has access to what systems and data?

Artefacts:

Current user roster (who is active, who has been deprovisioned)
Active access lists (who has what permissions)
Access request and approval status
Audit trails (who accessed what when)
Compliance status (all access provisioned correctly?)

Characteristics:

Continuously changing (users join, leave, change roles)
Measured and observable
The source of truth for "who actually has access"
Monitored for security and compliance

Example operational metrics:

text

User Roster Status (Real-time):
  - Total users: 4,287
  - Active users (last 30 days): 4,156 (96.9%)
  - Deprovisioned (awaiting cleanup): 23
  - Disabled (on leave): 108
  - Pending provisioning: 7 (average provisioning time: 2.3 days)

System Access Status:
  - Users with admin access: 47 (requires annual review)
  - Users with access to customer data: 1,234 (requires quarterly review)
  - Users with access to financial systems: 89
  - Service accounts (non-human): 156

Access Changes (last 24 hours):
  - New users provisioned: 3
  - Users de-provisioned: 2
  - Access changes approved: 12
  - Access changes pending approval: 5
  - Access requests denied: 1

Compliance Status:
  - Segregation of duties violations: 0
  - Users with access to systems without job requirements: 2 (under review)
  - Accounts without login in 90+ days: 12 (marked for cleanup)
  - Service accounts with expired passwords: 0

Recent Security Events:
  - Failed login attempts (last 24h): 234
  - Successful access by inactive accounts: 0
  - Admin access outside business hours: 3 (reviewed, approved)

Audit trail example:

text

Timestamp: 2026-04-21 14:23:45 UTC
User: john.smith
Action: Accessed customer database
System: CustomerDB
Result: Success
Records accessed: 1,234
Duration: 45 minutes

Timestamp: 2026-04-21 14:45:12 UTC
User: jane.doe
Action: Elevated to admin role
Requested by: HR system
Approved by: IT Manager
Reason: Role change to Operations Manager

Why it matters: Validates that access controls are working correctly and security policies are enforced.

Organisational Design: Using the Who Column

The Who column enables comprehensive organisational design:

Row 1 alignment: Business and IT agree on key organisational units.
Row 2 design: Business defines organisational structure and RACI.
Row 3 architecture: Architects define roles, competencies, and interfaces.
Row 4 implementation: IT implements organisational structure in systems (AD, LDAP).
Row 5 deployment: Teams implement provisioning and access control code.
Row 6 monitoring: Security team monitors actual access and compliance.

This ensures organisational structure is reflected in systems and access is properly controlled.

Common Mistakes in the Who Column

No RACI matrix: Unclear who is responsible and accountable for decisions. Result: Blame game when things go wrong.
Role creep: Users accumulate access over time without removal. Result: Excessive privileges and security risk.
Ignoring competency requirements: Hiring for roles without checking skill requirements. Result: Inadequate performance.
No access reviews: Never validating who actually needs access. Result: Compliance failures.
Mixing organisational structure with system roles: Changing organisational structure breaks system access. Result: Systems break when company reorganises.

Who Column vs Other Columns

Who vs What: Who is "people," What is "data." Customer service team (Who) manages customer data (What).
Who vs How: Who is "actors," How is "activities." Customer service team (Who) executes support process (How).
Who vs Where: Who is "people," Where is "location." Sales team (Who) works in New York (Where).
Who vs When: Who is "actors," When is "timing." Support team (Who) works 24/7 (When).
Who vs Why: Who is "people," Why is "motivation." Support team (Who) exists to improve customer satisfaction (Why).

Industry Examples: The Who Column

Banking

Organisational structure: Branch managers, loan officers, tellers, security staff
Critical roles: Loan approval authority (segregation of duties requires separation)
Access control: Tellers cannot approve loans; loan officers cannot handle cash

Healthcare

Organisational structure: Physicians, nurses, administrative staff, billing staff
Critical roles: Only physicians can prescribe medications; only nurses can administer
Access control: Billing staff cannot see patient medical records

Retail

Organisational structure: Store managers, cashiers, warehouse staff, loss prevention
Critical roles: Only managers can approve returns; only cashiers can ring sales
Access control: Cashiers cannot view inventory data; warehouse staff cannot access sales system

Organisational Architecture Best Practices

Maintain RACI matrix: Always know who is Responsible, Accountable, Consulted, and Informed.
Implement segregation of duties: Ensure no single person can approve their own work.
Review access regularly: Quarterly or semi-annual access reviews (mandatory in many compliance frameworks).
Automate provisioning: User provisioning/de-provisioning should be automated to prevent errors.
Audit everything: Log and audit all access changes for compliance.

Key Takeaways

The Who column describes organisational and people architecture: It answers "who are the people and organisational units involved?"
Six perspectives provide a complete organisational view: From executive structure to actual access in systems.
RACI matrix is critical: Ensure clear accountability and decision authority.
Access control flows from organisation: System roles should reflect real organisational structure.
Audit and review are essential: Regular access reviews catch excessive privileges and segregation of duty violations.

Next Steps

Explore When Column (timing and scheduling) to see when activities happen and who performs them.
Read Practical Application: Access Control and Security for real-world examples.
Jump to Other Interrogatives (What, How, Where, When, Why) to see the complete picture.

The Who column is fundamental for security, compliance, and organisational effectiveness. Master it, and you master access control and organisational design.

Meta Keywords: Zachman Who column, organisational architecture, roles and responsibilities, RACI matrix, access control, identity management, segregation of duties.