What it shows:
A map of the specific, real-world “triggers” (Events) that force the business to act, and the subsequent processes or services that respond to them. It connects a cause (e.g., “New Client Contract Awarded,” “Quarterly Security Audit,” “System Outage Detected”) to its operational effect.
Why it’s needed:
SLA validation and capacity planning. This proves an understanding of the business’s operational rhythm. It highlights exactly what real-world scenarios will place demand on the deployed system. This justifies high-availability requirements and operational Service Level Agreements (SLAs).
When to use it:
Highly recommended for SADs when deploying event-driven architectures, complex integration hubs, or systems with strict regulatory response times. For COTS deployments (like an ITSM tool), use this if the system is explicitly required to react to external business triggers (e.g., automatically generating compliance reports when an “Audit Event” is declared).
When NOT to use it:
Generally best to omit for “always-on,” passive infrastructure or static data stores (e.g., replacing network cabling, deploying a standard file server, or upgrading an OS). If the system just sits there waiting for generic user input and does not orchestrate responses to specific business events, this diagram adds no value.
Example:
