Insight: The HLD Is the Bridge Between Architecture and Engineering

There is a common failure mode in architecture: the architecture is defined too abstractly, or the architect gets pulled too far into implementation.

Neither works particularly well.

Enterprise and Domain Architects typically operate above the solution level. They establish principles, standards, target architectures and broader constraints.

Engineering works below that level. Engineers need concrete technical decisions they can implement.

The High-Level Design (HLD) sits between those two worlds.

Enterprise / Domain Architecture
          │
          │ principles
          │ standards
          │ constraints
          ▼
   ┌───────────────────┐
   │        HLD        │
   │                   │
   │ boundaries        │
   │ architecture      │
   │ key decisions     │
   │ responsibilities  │
   └─────────┬─────────┘
             │
       one or more TDs
             │
     ┌───────┼────────┐
     ▼       ▼        ▼
    TD 1    TD 2      TD 3
     │       │        │
     └───────┼────────┘
             ▼
        Engineering
             │
             ▼
        Operations

The HLD is not intended to describe every technical implementation detail.

It establishes the solution boundary and the important architectural choices.

For example, an HLD can decide that:

• an integration uses an API rather than file transfer;
• an exploratory workload belongs in an isolated cloud environment;
• a specific system remains the authoritative source for a data domain;
• access must cross a defined security boundary;
• a capability is shared rather than duplicated per application.

Those decisions constrain the Technical Design without dictating exactly how an engineer implements them.

The HLD is also a decision document

A good HLD does not simply describe the preferred architecture.

It explains why that architecture was selected.

That means identifying architectural drivers, evaluating relevant alternatives, recording constraints and making the reasoning visible.

For example:

Requirement
     │
     ▼
Architectural driver
     │
     ▼
Alternatives
 ┌────┼─────┐
 ▼    ▼     ▼
 A    B     C
     │
     ▼
Decision
     │
     ▼
HLD

This becomes particularly important when the preferred design changes during review.

Architecture is rarely a straight line from requirements to approval.

Architecture review should change the design

An HLD that reaches an architecture board is not necessarily finished.

The review provides another engineering input: people with a different view of enterprise standards, security, integration patterns, operational impact or long-term consequences.

Sometimes that confirms the design.

Sometimes it exposes a missing dependency.

Sometimes an apparently good technical solution does not fit an enterprise standard.

Sometimes the recommendation itself needs to change.

The useful process is therefore iterative:

Initial HLD
    ↓
Review / challenge
    ↓
New information
    ↓
Adapt design
    ↓
Review again
    ↓
Architecture decision

This is not a sign that the original design was poor.

It is how architecture should work when decisions have real consequences.

The architect has to be able to defend a decision without becoming attached to it.

The HLD defines the space engineers can solve within

Once the HLD is agreed, the Technical Design can go deeper.

A solution may have one TD or several, depending on complexity.

For example:

                 HLD
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
   Cloud TD    Network TD   App TD
       │          │          │
       └──────────┼──────────┘
                  ▼
             Implementation

A Cloud TD might define the concrete AWS resources.

A Network TD might define routing, security groups and connectivity.

An Application TD might define service configuration and deployment.

That separation prevents a 100-page HLD from becoming an implementation manual.

It also gives engineers something important: freedom within architectural boundaries.

The architect says what the solution must look like at the architectural level.

The engineer determines the technically appropriate implementation.

Responsibility changes with the level

RACI can help clarify this, but only when the level of responsibility is understood.

The person accountable for the solution architecture does not necessarily own the technical implementation.

Likewise, the engineer who builds a component is not automatically responsible for the enterprise architecture surrounding it.

A simplified model is:

There can be overlap, and responsibilities vary by organization, but the distinction is important.

Otherwise the architect gets pulled into implementation details while engineers wait for architectural instructions that should never have been necessary.

The HLD is where architecture becomes useful

Enterprise architecture can be too high-level to guide an individual solution.

Engineering can be too implementation-focused to consider the wider landscape.

The HLD connects them.

It translates broader architectural direction into a concrete solution while preserving enough flexibility for engineers to implement it properly.

That makes the HLD more than documentation.

It becomes the interface between architecture and delivery.

Key insight: The HLD should be detailed enough to make and defend the important architectural decisions, but abstract enough to let engineers solve the implementation problem. That boundary is where the Solution Architect adds the most value.