After 21 years of reviewing High-Level Designs across financial services, pharmaceutical, healthcare and automotive programmes - a pattern emerges. The same mistakes appear, in different organisations, on different programmes, with different vendors. Here is what I find almost every time.
1. The design is written to justify a decision already made
The most common HLD failure is not technical - it is political. By the time a formal HLD is produced, the vendor has usually been selected, the commercial agreement is in place, and the architecture is effectively locked. The HLD is then written to document that decision, not to evaluate it.
A genuine HLD should explore options. It should compare approaches, document the rationale for choices made, and acknowledge trade-offs. When every section says "the proposed solution is X" without any consideration of why X was chosen over Y or Z, you are not reading a design document - you are reading a sales proposal with an HLD cover sheet.
2. Scalability is assumed, not designed
Almost every HLD I review states that the solution is "scalable." Very few of them define what scalable means in the context of that specific organisation, or demonstrate how scalability will be achieved.
Scalability is not a feature of a vendor platform. It is a property of a specific design, in a specific environment, against specific growth assumptions.
A credible HLD should define current state traffic volumes, projected growth over the programme lifecycle, and demonstrate through architectural choices - not vendor marketing claims - how the design accommodates that growth without fundamental re-architecture.
3. Resilience is described at component level, not system level
HLDs routinely describe component redundancy - dual uplinks, HA pairs, RAID arrays. What they rarely describe is system-level resilience: what happens when multiple components fail simultaneously, how failover behaves under real traffic conditions, and whether recovery time objectives are actually achievable with the proposed design.
Component redundancy and system resilience are different things. A design with fully redundant components can still produce a single point of failure at the system level if those components share a common dependency.
4. Security is an afterthought bolted on at the end
Security sections in HLDs are frequently one page long, written last, and describe controls at a generic level that could apply to any organisation. Firewall policy: "traffic will be controlled by firewall rules." Encryption: "data in transit will be encrypted." These statements are not design - they are intentions.
Security architecture should be woven through every section of the HLD, not confined to a single section at the end. Segmentation, access control, inspection points, logging and monitoring should all be visible in the network diagrams and architecture choices - not described generically in a separate section.
5. There is no HLD-to-LLD validation plan
The HLD is approved. The LLD is written. Nobody checks whether the LLD actually delivers what the HLD promised. In my experience, this is where programmes most commonly go wrong - the gap between what was agreed at HLD stage and what is actually specified in the LLD.
Every HLD should define how its requirements will be traced into the LLD, and who is responsible for validating that trace. Without this, the HLD becomes a contractual document that no one is responsible for delivering.
What good looks like
A well-written HLD makes reviewers' jobs boring. Every architectural choice is explained. Trade-offs are acknowledged. Scalability and resilience are demonstrated, not claimed. Security is integrated, not appended. And there is a clear path from HLD to LLD to implementation.
If your HLD makes for interesting reading - if reviewers are discovering things - it is not ready for approval.
- The design has only been reviewed by the team that wrote it. Internal review is not independent review. The same assumptions, the same blind spots, the same vendor relationships.
- Scalability is based on current load, not projected growth. Most HLDs are designed for today. Few account for the traffic, user or data growth that will arrive within 18 months of go-live.
- Security is a layer, not a design principle. Firewall rules and access control added at the end of the design process rather than built into the architecture from the start.
- Vendor recommendations favour the integrator's margin. The design almost always leads to the product the delivery partner already knows, already has stock of, and already makes the most margin on.
- The LLD diverges significantly from the approved HLD. By the time implementation begins, the HLD is often a historical document - evolved without a formal record of what changed and why.