The “Golden Thread” and The Physical Reality
What it is:
The Solution Architecture Document is the definitive, authoritative baseline for your project. It is the “Golden Thread” that connects the strategic business concepts of the HLD to the physical realities of the IT estate. While the HLD stops at logical boundaries, the SAD crosses the line into physical deployment, detailing exactly where components will live, how they will securely communicate, and what physical resources they require.
What goes inside:
- The Visual Heavyweight: First and foremost, this is where the vast majority of your diagrams will live. It absorbs the Business, Data, and Application Architecture from your HLD, but elaborates on them. For example, your Application Communication Diagram should now be updated to include specific network protocols and ports (e.g., adding “TCP 3306” or “HTTPS 443” to the integration lines).
- Technology Architecture (The ‘Where’): This is where Phase 4 of the Playbook enters the document. You should include the Environments and Location Diagram to show geographical or cloud placement, and the Networked Computing / Hardware Diagram to map strict, zone-based network topologies and firewall perimeters. If dealing with WAN links across multiple sites, a Network and Communications Diagram belongs here.
- Platform & Processing Logic: The Platform Decomposition Diagram should be included to deconstruct the technological stack from physical hardware up to the end-user interface.
- Resource Sizing & Bill of Materials (BoM): Explicit compute, memory, and storage specifications. This provides the exact CPU, RAM, and OS requirements needed to provision the environments.
What NOT to put inside:
- Step-by-step Build Instructions: It is generally a mistake to include literal CLI commands, mouse-click instructions, or installation wizard screenshots. The SAD explains what to build, not how to type it.
- Granular Build Matrices: Do not paste massive, 500-row spreadsheets of exact VLAN port assignments, literal firewall rule matrices (Source/Dest/Port/Action), or granular script variables. That level of mass-execution data belongs in the Low-Level Design (LLD) or Configuration Spreadsheet. (Note: Passwords and secure credentials should never be in any design document, period).
- Day-to-day Runbooks: Operational procedures (like how to restart a service or perform a backup restoration) belong in a Service Design or Operations Manual, not the SAD.
The Audience:
The SAD is highly cross-functional. It is read by Project Sponsors (for the executive summary and business capability mapping), InfoSec and Governance boards (for compliance and security perimeters), and Lead Engineers (for the structural boundaries, hardware sizing, and networking constraints).
When to use it:
- Highly recommended for major capital expenditure projects, introducing new enterprise capabilities, or heavy infrastructure modernization that crosses multiple technical domains.
- Typically required when multiple distinct engineering disciplines (e.g., the Network team, the Storage team, and the Cloud Compute team) must coordinate to build a single, unified solution.
- Ideal for establishing a formal, agreed-upon technical baseline before handing the project over to dedicated deployment engineers, internal build teams, or external vendors for the actual construction phase.
When NOT to use it:
- Generally best to omit for short-lived Proof of Concepts (PoCs), or isolated sandbox R&D environments that are designed to be destroyed after testing.
- Not advised for localized, single-server utility deployments that have no integration with wider enterprise systems.
