# High-Level Design: [Solution Name]

**Version:** [x.y] · **Date:** [YYYY-MM-DD] · **Author:** [Name] · **Status:** Draft | Under Review | Approved

## 1. Purpose & Scope

What this solution does — and just as important, what it explicitly does
*not* do. Scope creep usually starts with an HLD that never drew this line.

## 2. Business Context

The business driver behind this solution, linked to its business case. Who
are the stakeholders, and what outcome are they actually expecting from it?

## 3. Current State (As-Is)

Brief description (or diagram reference) of what exists today, if anything.
If this is greenfield, say so explicitly rather than leaving the section
blank.

## 4. Target State (To-Be)

### 4.1 Architecture Overview

A diagram plus narrative of the major components and how they relate to
each other.

### 4.2 Component Descriptions

| Component | Responsibility | Owner / Team |
|---|---|---|
| | | |

### 4.3 Data Flow

Narrative or sequence diagram of how data moves through the solution for
the primary use case(s).

### 4.4 Integration Points

| System | Direction | Protocol / API | Data Exchanged | Notes |
|---|---|---|---|---|
| | | | | |

## 5. Non-Functional Requirements

| Category | Requirement |
|---|---|
| Performance | |
| Availability | |
| Scalability | |
| Security | |
| Compliance | |

## 6. Alignment to Reference Frameworks

- eTOM process(es) addressed:
- SID domains touched:
- ODA components used:

## 7. Migration / Transition Approach

Big-bang, phased, or strangler pattern? If this is a multi-phase
programme, reference the transition state architecture it belongs to.

## 8. Risks & Assumptions

| Risk / Assumption | Impact | Mitigation |
|---|---|---|
| | | |

## 9. Open Questions

-

## 10. Approvals

| Role | Name | Date |
|---|---|---|
| | | |