What Trees do we Plant for the Next 10,000 OSS/BSS Practitioners?

The old proverb above really resonates.

I love this industry. You could even say I’m Passionate About OSS.

And like many of us, I’ve been a beneficiary of trees that other people planted – frameworks, knowledge, standards, examples, terminology, APIs, architectures and shared wisdom.

But it feels like we’re now on the cusp of generational change.

The first wave of ninjas who helped build today’s network management and operations frameworks are starting to head into retirement. Ready to hand over the baton to a new generation.

So the question is no longer just what we inherited.

It’s what the next generation will inherit, where they’ll steer it next, and whether we’re willing to plant the trees that will give the next wave of OSS/BSS practitioners a forest, and its shade, to work with.

.

The 3 barriers every new OSS/BSS starter must overcome

When I think back to my earliest OSS projects, I remember feeling completely out of my depth.

That wasn’t because the people around me lacked capability. Quite the opposite. Many were brilliant telco people. Some had led huge teams and delivered major network programmes. But OSS/BSS has a way of humbling everyone when they first step into it.

The way I see it, there are three main barriers that make this industry unusually difficult to enter for new starters:

1. Knowledge and terminology: OSS/BSS is full of acronyms, layered concepts, overlapping domains and assumptions that are rarely explained from first principles. It wasn’t even clear where BSS finished and OSS began. The list of concepts that are widely “known” but totally opaque for new starters in almost endless, including (but certainly not limited to) inventory, assurance, fulfilment, orchestration, activation, automation, billing, mediation, catalogues, service models, resource models, APIs, abstraction layers, etc, etc, etc. Each one makes sense (more or less) eventually, but the early learning curve can be brutal when others are using these words like they’re obvious to everyone
2. Access to real systems: You can read about OSS/BSS, but it only really clicks when you see real operational scenarios, real workflows, real data, real integrations and real operational consequences in motion. Unfortunately, unless you work for a carrier, vendor or integrator with OSS/BSS that you’re allowed to touch, getting hands-on experience is hard. OSS/BSS tools are usually expensive, complex and deeply tied into specific operator environments
3. Access to realistic use-cases and datasets. As alluded to above, even if someone has an OSS/BSS tool or sandpit environment to play with, what do they model? A mobile network? A fibre rollout? A service order journey? A fault scenario? A field workforce process? Without credible scenarios and data, learning how to use the tools remains abstract. Moreover, a large majority of OSS/BSS tools are far from intuitive. They typically take extensive inside knowledge to learn how to drive them properly

These are not small impediments. They are gates (ie barriers to entry) into the industry.

.

The trees already planted by the industry

Thankfully, many people and organisations have been planting trees for years.

TM Forum is an obvious example. Its Open Digital Architecture brings together business, information systems, implementation and deployment guidance.

Before that, it authored Frameworx, including assets such as the Process Framework (eTOM), Information Framework (SID), and Application Map (TAM).

Now it provides Open APIs, data models, components and reference implementation concepts. Its stated implementation focus is to help evolve OSS/BSS into agile, cloud-native solutions.

But the point is not merely that TM Forum has produced frameworks, APIs and documents. The more important point is that thousands of contributors have converted private project learning into shared industry assets for us to all access. They’ve taken knowledge that could have remained trapped inside operators, vendors and consulting teams, and made it more accessible and reusable.

That is tree-planting right there!

.

The trees PAOSS is trying to plant

At PAOSS, we’re trying to plant a few trees too.

Some are obvious. The blog-roll now contains close to 3,000 articles, created to help people with #1, the Knowledge and Terminology barrier. To understand, plan, manage, simplify and de-risk OSS/BSS projects.

We’ve passionately developed many other resources to help people at different stages of their OSS journey.

The OSS sandpit series is a small attempt to lower barrier #2 and #3 to facilitate hands-on learning with open-source OSS/BSS tools. The idea was to create a step-by-step way for people to build a small-scale OSS sandpit, try realistic use-cases and do so with open-source building blocks and minimal cost. The intended building blocks included simulated multi-domain networks, fulfilment/BSS flows, assurance, inventory and data visualisation.

We felt that this is really important because reading about OSS/BSS is not the same as practising OSS/BSS.

A sandpit gives people somewhere safe to break things, model things, integrate things and see how decisions ripple across systems. It gives new starters a place to turn abstract concepts into a sense of familiarity.

In all honesty, we simply haven’t done as much as we would’ve like to with the OSS sandpit. We would’ve loved to have brought more open-source and trial tools to the surface via this series of articles. I’m sure we’ll continue to build upon it, though other projects always seem to take precedence, in part because they take a significant outlay of time to set up.

We also try to contribute through the Blue Book OSS/BSS vendor directory, as well as reports, frameworks, industry analysis, maturity tools and more (some paid, most free). Then there’s the podcast and video series.

No single article, report or tool changes the industry, but hopefully each one might become a small branch of shade for someone else.

.

The next-generation challenges that need bigger trees

The next generation is not inheriting a static industry.

This forest, and the environment it resides within, seems to be changing faster than I’ve ever known.

Our replacements will need to make sense of AI in operations, autonomous networks, intent-based operations, cloud-native OSS/BSS, API ecosystems, digital twins, network-as-a-service, service exposure, legacy modernisation, data governance, security, observability and the ongoing tension between standardisation and differentiation.

Or perhaps bypass all of those concepts entirely to solve problems in novel new ways?

They’ll also inherit complexity that our generation has not fully resolved (complexity that in many cases we’ve exarcerbated!).

We still struggle with the same challenges that I first faced 25 years ago – “exception-al” integrations with high fall-out rates, incomplete standardisation, fragmented data, unclear ownership, long transformation cycles, procurement friction, skills shortages, tools that are functional but often diabolical to learn, and the mass entanglement of legacy systems.

So perhaps the next set of trees needs to be bigger, better, faster, more robust?

But exactly what would help the next 10,000 OSS/BSS practitioners most?

To be honest, I don’t even know where to start. There so many lateral, creative questions we could be asking here to think about the evolving OSS/BSS forest, but here’s a pretty lame starter set:

• Tools that are designed with UI/UX in mind, being as easy to understand as an iPad?
• An integration model where the chess-board analogy was untangled and an unhindered, enjoyable game remained?
• A shared library of realistic telco use-cases?
• Synthetic but credible datasets for inventory, assurance, fulfilment and billing scenarios?
• Sandpits that let people test solutions, integrations, AI agents, orchestration flows and assurance patterns safely?
• A neutral place where operators, vendors, consultants and students can collaborate on problems too large for one organisation to solve alone (eg Black Swans)?

These are the kinds of trees that could change the slope of the learning curve.

.

An invitation to plant together

The best part of this industry has always been its people.

Yes, OSS/BSS can be maddening. Yes, the acronyms multiply. Yes, every transformation seems to uncover three more systems, five more stakeholders and another decade of hidden complexity.

But this industry also contains an extraordinary depth of generosity. People explain. They mentor. They share diagrams. They contribute to standards. They write guides. They publish lessons learned. They warn others about the project potholes they fell into first.

Moreover, it contains many of the cleverest people I know, trying to solve the telco-world’s most challenging problems, for the betterment of everyone who uses telecommunications services in their daily lives (ie pretty much everyone!)

That spirit is what we need more of now.
So this is an open invitation.

.

What trees should we plant next?

What would have helped you when you were starting out?

What (eg use-cases, datasets, sandpits, frameworks, explainers, tools, reports, maps or communities) would make the biggest difference to the next wave?

Or perhaps you envisage a totally different role for yourself. Maybe you don’t want to plant another tree in the current forest. Maybe you want to be the firestarter – to challenge the old assumptions, and burn it all to the ground. To burn away what no longer serves us and make room for an entirely new OSS/BSS forest to emerge from the ashes.

And which challenges are too important, too complex or too industry-wide for any one of us to tackle alone?

At PAOSS, we’re open to helping others come together around those problems. We’re certainly unable to solve them all ourselves (we’re not even doing full justice to the OSS Sandpit yet).

But perhaps that’s the point.

The best forests aren’t created by one person. They’re shaped by communities who care enough about the future to start digging, pruning, clearing or replanting before they know who will sit in the shade we initiated years before.