An interactive map of the telecom industry: how each network technology unlocked new capabilities and services, how the industry converged, and the BSS/OSS stacks each generation left behind.
💡Why start here, before BSS and OSS?
BSS and OSS exist to sell, deliver, bill and fix telecom services — so they only make sense once you know what those services are and where they came from. Every product in a catalog, every order flow and every inventory model traces back to a network technology and the services it made possible. Seeing how telecoms evolved first — technology, then capability, then service — explains why today’s BSS/OSS estates look the way they do, before the rest of this module looks at the systems themselves.
Telecoms networks were not designed once. They were added to, generation by generation, over more than eighty years — copper voice, coax and microwave, satellite, fibre, cable, four generations of mobile, and now cloud-native and AI-driven networks. Each new technology unlocked new network capabilities, which made new services sellable — and each arrived with the systems needed to sell it, build it, bill it and fix it.
Year
Analogue voice
Digital networks
Internet & broadband
Mobile broadband
Cloud-native
AI & 6G
1940s
1950s
1960s
1970s
1980s
1990s
2000s
2010s
2020s
2030s
today
Network technologywhat was built
Network capabilitywhat it could do
Servicewhat was sold
Industry convergencechapters
BSS / OSS frameworkscontext
c. 1965 Mainframe batch billing
c. 1978 TIRKS: circuit inventory & order control
1988 TMN (ITU-T M.3010); forum that became TM Forum founded
2001 eTOM process framework
2016 TM Forum Open APIs
2018 Open Digital Architecture (ODA)
2027 UK PSTN switch-off (31 Jan)
Scroll sideways through time. Point at an entry for a preview; click it to light what it needed and what it led to. Time widens as history gets denser · c. = approximate · dashed = emerging / future · hatched = after today
Technology → capability → service, 1940s to the future. Select any entry to see what it enabled and what made it possible. Dates are the commercially relevant period; “c.” marks approximate dates.
🧠Every generation left a stack behind
Read the services lane against the BSS/OSS band beneath it. Mainframe billing and circuit-inventory systems were built for copper voice; separate stacks followed for prepaid mobile, DSL and cable broadband, IPTV and enterprise data — the frameworks meant to unify them (TMN, eTOM, Open APIs, ODA) arrived later. Almost no stack was retired when the next arrived. That is why a typical operator today runs several order, inventory and billing stacks side by side, each the source of record for its own customers. Open any service’s BSS/OSS relevance to see what it takes to sell and deliver it.
Why this matters for everything that follows
Existing customers were provisioned outside modern models. A DSL line sold in 2004 has no product-catalog lineage: it lives in the stack that was current when it was sold.
The frameworks came after the networks. TMN (1988), eTOM (2001), the TM Forum Open APIs (2016) and ODA (2018) describe how the systems should fit together — decades after many of them were built.
Catalog-driven architecture is the answer to this history. One commercial catalog decomposing to whichever network delivers the service is how an operator stops adding a stack per technology — the subject of section 1.3.
Switch-offs are transformations. Retiring the PSTN and copper (the UK’s by 31 January 2027) means migrating customers whose data was never modelled the modern way.
Key Takeaways
Networks were layered generation by generation, and so were the BSS/OSS systems behind them.
Most operators run several stacks at once because older generations were rarely retired.
Modern frameworks and catalog-driven design exist to stop the next generation adding another silo.