Eventually, Every Telco AI Project Becomes an OSS/BSS Project

In the first two articles in this “Shadow AI” series, we looked at two problems: fragmented AI investment and the rush across organisations to get involved in AI before they feel left behind.

Both are exciting and create plenty of activity.

But sooner or later, it’s almost inevitable that the AI activity will to connect to the systems that actually run the telco – the OSS and BSS stack.

That’s where things get harder. And potentially more entangled, as suggested in the link above. [side note: Entanglement has become one of my most commonly used words in recent times. It just seems to keep popping up as a root source behind so many problems we face bringing new and transformed OSS/BSS into reality]

Once the AI tools and capabilities connect with foundational OSS and BSS tools, the level of entanglement risks making them pseudo-monoliths again.

.

A pilot can hide a lot of complexity

An AI proof of concept can look remarkably self-contained. You can demonstrate a tightly specific agent, chatbot or prediction model using a limited data set and a small number of integrations.

The demonstrated outcomes can be demonstrated quickly, leading to elation from the speed of achievement and “time to market.”

There’s just one problem. You haven’t actually got it “to market” yet. Nicely isolated pilots are one thing, but it rarely stays that simple when getting the same functionality into production.

That’s when the entanglement happens!

The moment an AI solution needs to understand a customer’s products, check their service status, diagnose a fault, recommend an offer, change a configuration, trigger an order or take an operational action, it starts depending on OSS and BSS. And in doing so, it also depends on shared services, security, and layers of policy / governance. Eeek!

Databases. Product catalogues. Billing. Inventory. Assurance. Orchestration. Service models. APIs. You can almost guarantee that one or more of these foundational building blocks will need to be invoked and integrated.

Suddenly, the success of the AI initiative depends on much more than the model, some dummy data and integration stubs.

.

AI can expose the architecture underneath it

This is one of the reasons AI projects can look much easier in a demonstration than they do at scale.

The AI might be new, but the data and systems it relies on often aren’t. It seems that AI is being used more for agents to overcome lots of small inconveniences rather than replacing or reinventing the foundational pieces. This only serves to increase the entanglement, like we discuss in the chess analogy.

Fragmented data, inconsistent service models, duplicated inventories or brittle integrations don’t disappear because we’ve put an AI layer above them.

In some cases, AI simply makes those underlying issues more visible.

A useful rule to consider is:

AI can easily hide architectural complexity or poor underlying data quality during a pilot. It can’t make that complexity disappear when you scale.

.

AI, AN and AO start to converge

This also explains why AI, Autonomous Networks and Autonomous Operations can’t be treated as completely separate transformation programmes. We see them as inextricably linked via 3 conjoined OpsModels.

They may have different sponsors, implementers, timelines and business cases. In fact, you can almost guarantee they’re currently separated.

As your “Shadow AI” pilots mature to production, they increasingly depend on the same overlapping / entangled building blocks: trusted data, event flows, service and resource models, APIs, orchestration, policy, assurance and the ability to take controlled action across the OSS / BSS environment.

As mentioned in the first article in the series, if each programme creates AI tools and those foundations independently, we risk reproducing exactly the fragmentation we’re trying to remove… whilst also creating greater entanglement and monolithism [that’s definitely just a word I made up], which we say we’re trying to avoid.

As also mentioned, the objective isn’t to force everything into one giant programme under the OSS/BSS budget and control. As much as I love OSS, I’m not silly enough to suggest that!

However, I am suggesting centralised planning / strategy to identify the capabilities that should be shared, which should be separated, then plan them all coherently… And do so under a model that allows for ongoing changes and re-prioritisation to handle a world that’s evolving rapidly.

New opportunities are popping up all the time, so AI / AN / AO development pipelines need the flexibility to quickly review and re-prioritise if a new opportunity is better than those already in the pipeline.

.

Build once, benefit many times

This brings us back to the principle from the previous article.

Every AI project / initiative should make the next one easier. Standing on the shoulders of AI giants.

If you’re already designing and building with AI, are you deliberately designing for reuse and amplification? Kudos if you are!

.

Next, we’ll come back to centralised planning again, but from a different angle.

As more systems begin to make decisions, take actions, and close loops independently, we also need to think about what happens when individually sensible automations interact.

That’s the subject of the next article: the thermostat problem, and why AI / AN / AO transformation needs both guardrails and combined planning.

Download our AI / AN / AO flyer for an overview of the challenges we’re exploring throughout this series. At the end, we’ll bring the different perspectives together into a practical take-home pack for transformation planning.

PS. The headline is intentionally (slightly) tongue-in-cheek, but scarily not so as well  😉