High-Level Design (HLD) - Table of Contents

I recently completed a short assignment, where my focus was to deliver a High-Level Design (HLD) document using the client's template, for an Enterprise Resource Planning (ERP) replacement/implementation project at the delivery stage of the project lifecycle.

Before you ask - yes, this artefact was pushed 'down the road' to the delivery phase of the project and yes, this is not best practice - but that's material for another blog.

Let's start by stating that a High-Level Design (HLD) document should NOT be confused with a Solution Design (SD) document, as both have purposes that provide specific lenses for their audiences, who require different views and level of detail.

The HLD presents the high-level view for senior stakeholders (business and technical), who wish to understand the drivers for change, a view of the proposed system, its components, costs, and the resources required to achieve the desired outcome to name but a few.

As one would expect the HLD inherits information from the programme business case and the current capabilities found in the technology ecosystem together with any supplementary project initiation documents supporting the desired project outcomes.

The HLD, in most cases, will be the first major architectural deliverable in the programme or project and as such is the first artifact presented to the internal IT governance forums to capture early insights from the organisational technical community. 

This is a living document and updated, as and when additional information becomes available through the project life cycle.

It is most likely and depending on the time to market and size of the project the HLD will spawn several solution designs, which should be referenced in subsequent versions of the HLD. The HLD could be structured as follows:

The above diagram illustrates, what I consider,  the main sections with basic mapping to the 'who, what, why, when, where and how' found in a HLD which is summarised in the table below:

Main Topics/  Headings	Sub Sections	Comment
Document Controls	· Status · Version · Stakeholders /Reviewers · Document Purpose	This should be a formality and a standard document hygiene function in which we track simple meta data e.g. version number and any approvals.
Management Summary	The Management Summary section is targeted stakeholders who wish a condensed  high-level view of the document with emphasis placed on any salient points. One can adopt the 5W1H (why, who, what, when, where and how) framework to complete this section. However, this section should at a minimum, encapsulate the drivers for change and a high level ‘short’ description of how the solution will meet the needs and requirements with any available  costs. Information can be extracted from the Business Case and other project initiation documents that provide the overview of the problem being solved, the funding model and any resources required to achieve the desired outcome.
Project Overview	This section provides a overview of the desired outcomes, project structure and the realisation of any savings. Examples of elements to capture here may be Return on Investment(ROI) , project structure , milestones, value enablers being introduce, any savings (process efficiency, software licence savings etc). It would be prudent to include a roles & responsibilities in the form of a project RACI table.
Business Context	· Drivers for Change · Capabilities · Financial information	This section should address any available macro view of processes, inefficiencies and accompanying practices that have resulted in the solution being considered. Highlighting the problem, business blast radius impact and timelines. One would expect to see major processes, information objects and associated flows documented using a standard set of diagrammatic notations.
Outcomes / Requirements	· Business Objectives · User Stories · Non-Functional · Security Posture	In this section of the document, we aim to present the desired outcomes found in the business case highlighting any formal business and technical requirements /user stories required to achieve the outcomes. The high level functional / non-functional requirements should be presented and it should be noted that the audience may not wish to view a detailed listing of all  requirements - just a simple summary. It is standard for Business Analysts to gather, structure and present requirements, user stories using various tools and links to these requirements should referenced  here.
Current – As-Is Solution	· Capabilities · Business Processes · Component Model · Data Flows · Operational Controls	In this section of the document the focus will be on capturing information relating to the system in its 'current state' in which we highlight the major components, interactions and security controls in place. The initial section should depict the current capabilities in relation to the domain or systems under consideration. Any major issues / problems that arise from deficiencies, should also be highlighted
Future State / Target Solution	· Business Architecture · System Architecture · Data Architecture · Security / Operation Controls (Posture) · Integration	This section should emulate the previous section reflecting the ‘to- be’ target systems state. Where possible the target should show any deltas from the current state and the associated impacts. It would be prudent to present a diagram that shows all integrations and the flow of data both in and out of the ecosystem with system protocols highlighted.
Testing / Transition into Service	· Test Strategy · Tools · Reporting  ·Post  Implementation Support	Prior to any deployment into production the system or systems must be fully tested for usability, functionality, performance, resilience and security . This data is most likely captured in a test strategy document which should be referenced The test strategy may be a comprehensive document hence it would be prudent to highlight ant key points in  the HLD. The plan for transition into service and any support requirements should also be highlighted.
Supporting Documentations / Additional Material	Here one should provide URLs to 3rd party resources or documents referenced in this HLD e.g. the Requirements Documents, Product Information and any material that supports the solution.

The above the TOC could be adapted to suit the problem and is presented to provide generic items to consider - This will be be expanded in my new book "Enterprise Solutions Architecture" - I will place URL when Book released in late 2026/27 .