The “Why” and the “What”
What it is:
The High-Level Design is your strategic foundation. It is the bridge between a business problem and a technical reality. The goal of this document is to translate business requirements into a logical technical solution without dictating the underlying physical hardware or writing a single line of code. It focuses on conceptual boundaries, system integration points, and the flow of critical data.
What goes inside:
- Business Architecture (The ‘Why’): This section defines the core problem. It is the perfect home for a Goal/Objective/Business Service Diagram to show strategic alignment, alongside a Business Capability Map or Value Stream Map to prove exactly which business functions this project supports. This is also where the Business Services and Information Diagram belongs, proving to Data Owners what sensitive corporate data is being consumed or modified.
- Data Architecture (The ‘What’): This proves you understand the payload. If you are doing Custom Application Development, include a Conceptual Data Diagram here to map the core business entities. However, if this is a COTS deployment, the Playbook advises that conceptual models are generally redundant. Instead, use a Data Dissemination Diagram or a high-level Data Security Diagram to prove to InfoSec how the vendor’s payload will move or be protected.
- Application Architecture (The ‘How’): This defines the software boundaries. An Application Communication Diagram belongs here to illustrate the logical interactions between major software components. Crucial HLD Rule: At this stage, only map the logical system connections. Intentionally hold off on adding granular port numbers and protocols (e.g., do not add “TCP 3306” yet). Those details will be added to this diagram later when it evolves into the SAD.
- Strategic Decisions: Key architectural principles and constraints governing the design (e.g., “We are prioritizing a cloud-native PaaS approach for scalability”).
What NOT to put inside:
- Granular Network Details: It is generally a mistake to include IP subnets, specific firewall port numbers, or routing protocols here. Leave the Phase 4 Technology Architecture diagrams (like the Networked Computing / Hardware Diagram) completely out of this document.
- Physical Compute Sizing: Avoid exact server specifications. Stating a system requires “High-Availability Clustered Compute” is fine; detailing the Resource Sizing & Bill of Materials (BoM) with exact CPU and RAM allocations is going far too deep for an HLD.
- Code or Scripts: Configuration snippets, Software Engineering Diagrams showing code classes, or exact software patch versions should be firmly kept out of an HLD.
The Audience:
The primary consumers of an HLD are non-deployment stakeholders. This includes Project Sponsors, C-Suite Executives, Financial Controllers, Enterprise Architects, and potentially Security Governance boards who need to understand the logical risk boundaries before approving the capital to move forward.
When to use it:
- Highly recommended during project inception or when securing initial budget and executive approval. It proves you understand the business problem before the company spends money on licenses or hardware.
- Typically required during vendor selection, especially when evaluating multiple Commercial Off-The-Shelf (COTS) products to see how they fit into your logical enterprise landscape.
- Ideal for conceptualizing new, cross-domain business capabilities.
When NOT to use it:
- Generally best to omit for pure “like-for-like” infrastructure hardware refreshes (e.g., swapping aging physical switches for newer models of the exact same type). If the logical architecture and business value remain 100% identical to the legacy state, an HLD adds unnecessary bloat.
- Not advised for standard operational changes or direct “lift-and-shift” migrations where the semantic meaning of the systems does not change.
- When the deployment team asks for build instructions: If an engineer is asking you how to wire up the environment, Handing an engineer an HLD when they need build instructions does not just frustrate them; it actively introduces deployment risk through guesswork.
