Purpose

The HLD bridges the gap between business requirements and detailed technical design. It provides enough detail for stakeholders to understand and approve the approach, and for development teams to begin planning their work.

When to Use

Produce the HLD during alpha once the solution approach is validated. It precedes the Low-Level Design and serves as input to sprint planning.

How to Build

Start with the business context — what problem is being solved and for whom. Reference the business case or user research that drives the need.

Define the system boundary clearly. Use a context diagram to show what is inside scope and what is external. Identify all actors that interact with the solution.

Decompose the solution into its major components or services. For each, describe its responsibility, key interfaces, and technology platform. Use a component or container diagram to visualise this.

Document the key data flows through the system for the primary use cases. Sequence diagrams or data flow diagrams work well here.

Address cross-cutting concerns at a high level: security approach, error handling strategy, logging and monitoring approach, and deployment model.

Tips

  • Keep it high-level — resist the urge to specify class structures or database schemas.
  • Use consistent diagram notation throughout.
  • Include a decision log or reference ADRs for key technology choices.
  • Get the HLD reviewed by both technical and non-technical stakeholders.
  • Version the HLD and track changes as understanding deepens.

Common Mistakes

  • Going too deep into implementation detail.
  • Omitting the business context, making it unclear why the system exists.
  • Not showing integration points with external systems clearly.
  • Producing a static document that is never updated.
  • Using inconsistent or unclear diagram notation.

Government Context

In UK government, the HLD is often required for Architecture Review Board submissions and spend control cases. It should demonstrate alignment with the Technology Code of Practice, particularly around using cloud, open standards, and shared platforms. For GDS service assessments, the HLD helps demonstrate that the team has thought through the technical approach (Service Standard point 8).

Related Artifacts