A practical method for the high-level architecture (HLA) of a large BSS programme: key decisions, architecture levels, coexistence with legacy, information models and traceability.
| Section | Purpose |
|---|---|
| Context and scope | Business goals, releases, what is in and out |
| Key architecture decisions | Each decision with options, rationale and impact |
| Architecture views (L1, L2, L3) | From one-page overview to detailed component interactions |
| Day-1 and end-state | What goes live first and where the architecture ends up |
| Coexistence and bridging | How new and legacy systems work side by side |
| Layers and APIs | Channel, API, service and connector layers, with rules |
| Information models | Customer, account, order, payment, identity and supply chain |
| Open items and change log | What is not decided yet, and what changed |
Moving customers in phases means old and new systems run together.
Find which system holds a customer and route each request there.
Keep shared data in step with events between systems.
Send usage to the right billing system for each customer.
Compare both sides regularly and fix differences.
Channels call APIs; APIs call services; services call connectors to back ends.
No channel calling a back end directly; no business logic in connectors.
Enterprise APIs hide whether old or new systems answer.
Who the customer is, who pays and who uses the service.
Individual, corporate and split liability for charges.
Forward and reverse logistics, stock codes and shipping.
Users, roles, organisations and privileges.
What the business needs, numbered.
How the solution meets it, per feature area.
Deliverable pieces mapped back to requirements.
Detailed design and test cases linked to stories.
This page describes generic industry practice and public standards. It is not based on, and does not describe, any particular vendor's product or operator's systems.