Where BSS/OSS Workloads Run
Last updated 12 Oct 2026
At a glance
The order chain placed on the hosting spectrum. Commercial workloads at the top are the easiest to run as a service; the bottom of the chain is the network and cannot leave the operator’s footprint. The answer usually changes at SOM, and where the estate crosses that line is a design decision.
The picture
How it works
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. SaaS and public cloud are normal here.
- 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 policy rarely lets public cloud reach, and the network elements themselves sit on operator sites.
Network and connectivity
A hybrid chain only works if its hops can reach each other safely. The building blocks are the same in every cloud; what matters is where each one sits in the chain.
| 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 17.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-premise 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
Choose the store by the question it answers: records in relational databases, events in streams, bills in object storage.
| 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 |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Network topology between cloud and sites (VPCs, subnets, routes, private links) | Infrastructure-as-code repository (Git) | — | Cloud provider control plane, network team’s IP address management | Hand-made routes and peering are the usual source of drift |
| Firewall rules and security groups | Infrastructure-as-code repository (Git) | Change management (ITSM) | Security team | Approved through change, applied by pipeline |
| DNS records per environment | DNS service, configured as code | — | Integration configuration | Integrations should use names, not IP addresses, so failover works |
| Business records (orders, customers, catalog, inventory) | The owning application’s relational database | — | Data platform | Hosting changes where the record lives, not which system owns it |
| Order and service events | Event streaming platform (as the durable log) | — | Data platform, consumers | The log of what happened; the records stay in the owning systems |
| Bills and migration extracts | Object storage | — | Billing, migration programme | — |
In practice
In many estates COM, CPQ and the catalog have moved to public cloud or SaaS while SOM, inventory and activation stay on private infrastructure. That is a reasonable shape, provided the line is drawn deliberately and private connectivity carries the traffic across it.
The failure that recurs is SOM moving to cloud while activation stays on-premise with no private link. Every activation then crosses the internet through a VPN, which becomes the slowest and least reliable component in the chain, and the one nobody owns.
Hard-coded IP addresses in older integrations are a quieter problem: they work until the first failover, when DNS switches and the integration keeps calling the dead site. Inventory data that describes the physical network may also be subject to national rules that stop it leaving the country, which can decide SOM’s placement on its own.
The trade-off
What it solves
Drawing the hosting line at the SOM boundary lets commercial workloads use cloud elasticity and SaaS, while network-facing workloads stay where they can reach the management plane with acceptable latency and policy.
What it does not solve
- It does not remove the dependency between the two halves: every order still crosses the line.
- It does not make inventory data portable where sovereignty rules bind it.
What it adds
- Private connectivity, a jump zone and allow-lists to design, pay for and operate.
- Two hosting models in one chain, with failover that must work across both.
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.
Takeaways
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.
- Integrations should use DNS names, not IP addresses, or failover will not work.
- Choose the store by the question it answers: records in relational, events in streams, bills in objects.
Check yourself
COM and the catalog run well on public cloud. Why does the same argument not automatically carry SOM with them?Show answerHide
SOM touches inventory and activation: it needs low latency to the network, reach into the management plane, and it handles data about the physical network that may be bound by policy or residency rules.
After a failover test, orders reach SOM but activation calls fail. What is a likely cause?Show answerHide
An integration with a hard-coded IP address, or a missing private path from the new site to activation. DNS switched, but the integration kept calling the old address or had no route.