What it shows:
A vertical “stack” model that deconstructs the IT solution into strict technological layers. It maps exactly how the system is built from the ground up, starting with physical hardware (Layer 1), moving through virtualization, operating systems, and container engines, up to the core platform services (Layer 5) and the end-user client interfaces (Layer 6).
Why it’s needed:
Dependency mapping and support tiering. This establishes a support contract with the customer’s Service Desk. When a user reports an incident, this diagram tells the support team exactly where to look. It prevents the classic IT blame game by clearly defining the boundaries—if the VM is up but the application is down, the issue sits at Layer 4 or Layer 5, not Layer 2.
When to use it:
Highly recommended for SADs and LLDs when deploying complex, multi-tiered COTS platforms or custom enterprise applications that rely on a deep stack of underlying infrastructure technologies.
When NOT to use it:
Generally best to omit for true Software-as-a-Service (SaaS) deployments, as the vendor owns and obscures everything below Layer 6. It should also be skipped for flat, single-tier applications (like a standalone desktop utility) where there is no complex server stack to decompose.
Example:
