Where does OSS end and BSS begin, and how would you break up a monolithic BSS without stopping the business?

The boundary, and the reason it survives

Business support systems own the commercial reality: the customer and their account, the product catalogue and its prices, ordering, charging, billing, collections, partner settlement. Operations support systems own the network reality: inventory of what exists, activation of services onto it, assurance of faults and performance, and the workforce that goes out with a van. The hand-off is the service order — BSS says what was sold and to whom, OSS decides which resources realise it and makes the network do so.

Reciting those two lists is the entry-level answer. The better one explains why the line has outlived every generation of technology that was supposed to erase it. The two sides change at incompatible rates and for incompatible reasons. Commercial systems change when marketing wants a new bundle, which is weekly, and the change is a change in data. Network systems change when the estate changes, which is on a hardware and standards cycle measured in years, and the change is a change in capability. Coupling them means a tariff change waits for a network release, and a hardware refresh threatens the billing run. The boundary is a rate-of-change boundary, and that is a more durable justification than any functional taxonomy.

The industry vocabulary is worth knowing because it is what the interviewer will use. TM Forum publishes a process framework (eTOM), a shared information model (SID) and a set of Open APIs for the interfaces between these domains. Their real value is as a shared dictionary: proposing "a customer" or "a product offering" to a room of telecoms architects goes better when the terms already mean something specific to everyone present.

Catalogue-driven means the catalogue is executed, not consulted

The goal usually stated as "launching a product should not need code" rests on a decomposition inside the catalogue. A product specification describes what the customer conceptually buys and the characteristics it has. A product offering wraps that commercially with prices, eligibility, geography and contract terms, so the same specification can be sold at three price points without being modelled three times. A service specification describes what has to exist for the product to work, and a resource specification describes what the network must supply. The catalogue holds the mapping down that chain, and characteristics are typed, with units and permitted value ranges, rather than being free text.

For that model to earn its complexity, four consumers must read it at runtime rather than having it compiled into them. Ordering reads the specification to build and validate the order, so a new characteristic appears in the journey without a front-end release. Fulfilment reads the mapping to decompose the order into service and resource actions. Rating reads prices and rules from the same offering the customer bought. And eligibility and validation are evaluated from the characteristic definitions instead of being reimplemented per product.

One rule is non-negotiable and often missed: a specification that any live subscription references is immutable. Changes create a new version with its own validity interval, and subscriptions carry the version they were sold against. Edit a spec in place and you have silently changed the terms of every contract already sold under it, which shows up first as an unexplainable invoice and second as a regulatory problem.

The half-configurable product

Here is where these programmes fail, and it is worth stating flatly because it is the trap the question exists to find. A team builds a genuinely configurable catalogue, models a new offering in it in an afternoon, and then discovers that provisioning still has a hand-written branch per product type. The offering configures beautifully and cannot be delivered, so the launch still needs a fulfilment release, an activation release and a test cycle — which is exactly the cost the catalogue was bought to remove.

A catalogue pays back only across the whole chain. If the decomposition rules are data, a new product composed of existing service and resource specifications needs no fulfilment code at all; the orchestrator reads the mapping and issues the same task types it already supports. Genuinely new capability — a service that touches network functions you have never provisioned — needs an adapter, and it always will. The discipline is to keep those two cases separate and to be honest about which one you are in, so that "no code" is a claim about recombining existing capability rather than a promise the catalogue cannot keep.

Decomposing without stopping the business

A BSS monolith cannot be paused, because the bill run is a legal obligation and the order flow is the revenue. So the decomposition is a strangler with three commitments.

Pick the seam by data ownership, not by which module is most unpleasant to work in. The first extraction should be a domain whose data can be cleanly assigned a single writer, which in practice means the product catalogue, and then product ordering. Both are read-heavy for the rest of the system and neither holds the ledger. Billing is the last thing you move, not the first, however tempting it is, because it is stateful per cycle, it is the system of record for money, and every downstream financial process is calibrated to its output.

Put a facade in front of the monolith and make everything new speak to that, translating between the monolith's model and the target model. This is the piece teams skip to save time and then pay for permanently: without it, the new services inherit the monolith's data model and you finish the programme with a distributed monolith whose only improvement is more network hops.

Then move traffic by cohort, and choose the cohorts to match the statefulness. Shadow-run first: send real orders or real rating inputs through both paths and compare the outputs, treating any difference as a defect to be explained rather than tolerated, because rating differences of a penny at scale are a restatement. Then cut over new customers, who have no history to migrate and no open cycle. Then migrate the existing base one whole bill cycle group at a time, between runs, so that no subscriber's cycle is ever split across two systems — a half-migrated cycle produces two partial invoices for one month and there is no clean way to explain that to the customer or to the ledger.

The last commitment is the one most often abandoned. The strangler is finished only when the final reader of the monolith's data has moved, and the readers you forgot are the reports, the extracts and the finance spreadsheets that quietly select from its tables. Inventory those at the start and give each a replacement, because the monolith you cannot decommission is not a migration, it is a second system to maintain forever.

Extracting services is the easy half; the programme succeeds or fails on whether the data has one writer and whether every last reader has been moved off the old tables.