Where BSS/OSS Workloads Run
The chain placed on a hosting spectrum: what is SaaS, what is cloud-native, what stays private, and why the network end is different.
The order chain placed on the hosting spectrum. The top of the chain is the easiest to buy as a service; the bottom cannot leave the operator’s footprint, because it is the network. Every estate crosses this line somewhere, and where it crosses is a design decision.
Why the answer changes at SOM
- Above SOM the workloads are commercial. Customer, quote, offer, order: stateful but portable, with no dependency on where the network is. This is where SaaS and public cloud are normal.
- At SOM the workload touches inventory and activation. Latency to the network, access to the management plane, and data that describes the physical network all pull it towards private infrastructure.
- Below SOM the workload is the network. Activation reaches device management planes that are rarely reachable from public cloud by policy; the network elements themselves are on operator sites.
Network and connectivity
| Concept | What it is | Where it matters in the chain |
|---|---|---|
| VPC / VNet | Your private network inside a cloud region | One per environment; the BSS zone of Security 15.1 |
| Subnets and routing | Segments inside the VPC and the rules between them | Public subnet for the gateway; private for COM and its database |
| Firewalls / security groups | Allow-lists per component | SOM may reach inventory; nothing else may |
| Load balancer | Spreads traffic and hides instances | In front of every API; the point of entry for active/active |
| Private connectivity | A dedicated link from cloud to your sites | The only acceptable path from cloud-hosted SOM to on-prem activation |
| DNS | Names to addresses, per environment | Failover switches DNS; a hard-coded IP in an integration defeats it |
| Cloud-to-network | Reaching the management plane from cloud | Usually via private connectivity to a jump zone — never directly |
Storage and databases
| Store | Fits | BSS/OSS use |
|---|---|---|
| Relational database | Transactions, joins, consistency | Orders, customers, catalog, inventory — the records |
| NoSQL (document, key-value) | Flexible schema, horizontal scale | Session state, product configurations, event sourcing |
| Object storage | Large, cheap, immutable | Bills as PDF, migration extracts, data-lake raw zone |
| Cache | Sub-millisecond reads | The published catalog view; eligibility lookups |
| Event streaming | Durable, ordered, replayable | Order and service events; the input to the joined-up view in E2E Data Lineage |
| Data platform | Analytical, batch and streaming | Reconciliation, reporting, AI training |
Architecture decision
Should SOM and inventory move to cloud with the rest of the stack, or stay close to the network?
Move with the stack
Choose when private connectivity to the sites is in place, activation is reached through a jump zone, and the vendor supports the platform.
Stay close to the network
Choose when activation latency or management-plane policy forbids cloud reach, or the inventory holds data that may not leave the country.
Breaks if SOM moves and activation does not, with no private link: every activation crosses the internet through a VPN that becomes the estate’s slowest and least reliable component.
Key Takeaways
- Commercial workloads are portable; network-facing ones are not. The line between them is a design decision.
- Private connectivity is what makes a hybrid estate work; without it, the hybrid is a VPN.
- Choose the store by the question it answers: records in relational, events in streams, bills in objects.