What it shows:
A high-level mapping of the key actors (e.g., “Engineering Team,” “Business Stakeholder,” “External Vendor”) and the core business activities or value streams they need to execute within the boundary of the new system (e.g., “Provide Requirements,” “Review KPIs”).
Why it’s needed:
Persona definition and license justification. This proves to the business exactly who needs access to the platform and what their business mandate is. It prevents scope creep by locking down the authorized user base and is the foundational blueprint for designing Role-Based Access Control (RBAC) later in the project.
When to use it:
Highly recommended for High-Level Designs when deploying complex platforms (both COTS and Custom Dev) that serve multiple distinct user groups with different permission levels. If the software requires different licensing tiers (e.g., expensive “Creator” licenses vs. cheaper “Reviewer” licenses), this diagram is required to justify those costs to the business.
When NOT to use it:
Generally best to omit for “headless” systems, backend middleware, or pure infrastructure deployments (e.g., deploying a new NTP server, upgrading a storage fabric, or installing a Splunk forwarder). If the system has no direct human interaction, or if all users perform the exact same generic function, drawing stick figures adds zero architectural value.
Example:
