What my Chiropractor Taught me about the Future of Telco

I recently went to my chiropractor with wrist pain.

I assumed it was from years of playing tennis and typing on keyboards. That seemed fairly logical but my assumption was wrong.

It didn’t take my chiropractor long to identify the source of the problem. Not my wrist, but tightness deep under my pectoral (chest / armpit) muscle was the referral point. A deep (and painful) manipulation there resulted in the wrist pain just melting away.

Now, because I seem to look at almost everything through “OSS-coloured glasses,” that immediately made me think about the analogy of referred pain in OSS and telcos.

It made me wonder whether one of the most valuable things an OSS can know isn’t where it hurts, but what’s the real cause of the pain (and I’m not just thinking of our typical root-cause analysis algorithms here, though that is part of the story).

If set up properly, can our OSS/BSS understand more about the deeper anatomical connections within a telco to understand where all the pains are really coming from. Let’s explore this concept together!

.

Is telemetry the equivalent of pain?

My wrist was providing perfectly useful telemetry. It hurt. He could’ve tried manipulating my wrist based on that telemetry. But he quickly realised that wasn’t going to help (don’t ask me how he knew, but he did).

More sophisticated telemetry / sensing might have told us more about under what conditions it hurt, how intensely it hurt, which movements triggered it and whether it was getting better or worse. But none of that necessarily identified the referral point.

The chiropractor had something else. He understood anatomy. He knew how different parts of the body connect and interact. He understood that a restriction or problem in one place could create symptoms elsewhere. His deep training and knowledge gave him a map of other plausible places to look.

And that’s where the OSS analogy starts to get interesting.

Most modern Assurance or AIOps tools are extraordinarily good at gathering and analysing detailed telemetry (ie pain / symptoms): alarms, events, logs, traces, metrics, tickets and performance measurements.

We seem to have a focus on improving the telemetry. But clearly, knowing ever more about where it hurts isn’t necessarily the same as understanding why it hurts.

.

What is the detailed anatomy of a telco?

The next most logical next step after the telemetry is to think about assembling the network’s topology. It’s the first layer of connectivity / dependency between the nodes.

That’s important, but topology is only part of the anatomy. In human terms, topology might be equivalent to knowing the skeleton. But that’s probably where most assurance platforms stop today (telemetry plus topology).

That’s roughly equivalent to a chiropractor who knows every bone in a skeleton but nothing about muscles, nerves, tendons, joints or movement. They’re left with a rather incomplete diagnostic model.

If we look a bit deeper, telco has the same problem. Its anatomy crosses many different dimensions:

• A network resource connects to other resources, but it may also support logical connections and services
• Those services support products and customers
• Resources are represented in inventory systems
• Inventory is populated by discovery and reconciliation processes
• Those processes depend on collectors, adaptors, APIs and data mappings
• Topologies are continually updated by projects, network changes, fault fixes and new orders arriving
• Processes are performed by people interacting with other people, systems and resources
• Users operate systems through permissions and workflows
• Policies and design rules influence configurations
• Orders reserve capacity
• Historical decisions leave behind workarounds and exceptions (especially when the underlying data has faults)
• Firewall burns change which systems can connect
• Patches change the behaviours of systems, integrations and workflows
• I really could go on with a million more examples of dependencies couldn’t I?

All of those things have the potential to be connected in myriad ways – the referred pain-point – an operational problem can propagate across any of those connections.

A few examples I’ve experienced (the telco equivalents of my sore wrist):

• The cause of an orchestration problem might result from a spurious inventory relationship or an unnecessary inclusion of an obscure product attribute
• The cause of an inventory / billing problem might be a mis-configuration in a separate gateway device [As an aside, I experienced an example of this earlier this week. I only just realised that when I cut over from the old FTTN service to FTTP a few months ago, the FTTN wasn’t properly disconnected by my service provider and I’d been being billed for two services the whole time]
• The cause of a customer experience problem might be a resource allocation or a secondary failover path that nobody even realised was there, causing a high-priority service to fall over
• The cause of repeated manual intervention might be a process constraint or a faulty reconciliation automation
• The cause of apparent network capacity exhaustion might be stale reservations left behind by cancelled orders that never relinquished spare resources

It’s the chessboard analogy in all its glory.

.

What are the broader adjacencies / dependencies / proximities within a telco’s anatomy?

In the earlier article “Proximity and Root-Cause,” we explored the idea that root-cause relationships aren’t only topological. They can also be geographic, temporal, hierarchical or contextual.

Two things might be nowhere near each other in network topology but still be related because they were changed at the same time, run the same software version, belong to the same project or rely on the same underlying, shared system.

In The 12 Core Principles that Explain almost Everything in OSS, we discuss a number of underlying primitives of OSS.

Physical containment, physical connectivity, logical connectivity, service composition, resource consumption, protection, dependency, geography and customer-to-service relationships are all different forms of connective tissue.

Taken together, it starts to look less like a topology map and more like a telco anatomy.

.

Who are our telco chiropractors?

In your network, who “just knows” that a sore wrist can be fixed by rebooting a network pec? Our chiropractors are what I refer to as our network ninjas. They deeply know every part of a telco’s anatomy, as we discussed in this article – Network Operations Ninja Academy (NONA).

Over many years / decades, they’ve simply learnt how their particular telco anatomy works:

• They learn that when this alarm appears, look over there
• When this workflow stalls, check that record in the database
• When that team makes a particular type of change, keep an eye on this seemingly unrelated system
• They remember the strange integration implemented nine years ago and spurious results that popped up in interop testing
• They know which inventory source can be trusted for a particular attribute and which secondary source is always trying to overwrite it
• They know which data can be trusted and which gets a vote of no confidence
• They know which process looks simple on the diagram but has a truckload of undocumented exceptions (side eddies off the main flow)
• They know that two applications supposedly aren’t related, except for the nightly batch job everyone has forgotten about.

In other words, the ninja has learnt the full anatomy – the network + system + service + process + people + project +++ of the anatomy of their telco.

They’ve effectively constructed an enormous dependency graph inside their head.

It seems like intuition, but it’s actually accumulated relational / dependency knowledge.

.

Our ninjas will be incredibly difficult to replace (but possibly not impossible??)

I should point out here that for chiropractors, every human body is more or less constructed from the same bits. In our industry, every different telco has a different anatomy or collection of bits. That’s why local or tribal knowledge is so valuable within each telco.

In doing so, we’ve created an unexpected and undervalued dependency in telecommunications:

• We build highly redundant networks
• We build highly available software
• We build disaster recovery environments and duplicated infrastructure

Yet we still have a multitude of single points of failure – the operational knowledge of individuals.

When that person retires, is retrenched, changes companies or is unavailable during an incident, part of the telco’s operational anatomy becomes invisible.

We try to solve this with documentation and systems. But remember before when I mentioned that we typically only know about the central nervous system and skeleton (ie the telemetry and topology), not the other connective tissues?

.

How can we externalise the full extent of anatomical knowledge?

This is where we have to go beyond telemetry and topology. We have to build much deeper / richer dependency knowledge graphs. Luckily the database technologies and digital twins are starting to evolve to a level where we just might be able to pull this off before all the ninjas disappear into retirement.

We’ve previously discussed using knowledge graphs for Dependency Visibility, particularly to understand the complex entanglement between OSS, BSS, networks, data, interfaces, projects, processes and other parts of a transformation environment or telco anatomy.

This is where we need to take that idea much further. Instead of just thinking about a network topology graph, we need to imagine a massively cross-dimensional dependency graph.

The graph doesn’t stop at telemetry and topology.

It might connect a customer to a product, a product to a service, a service to logical and physical resources, those resources to inventory representations, those representations to source systems, those systems to APIs and adaptors, those adaptors to data mappings, those mappings to releases, those releases to projects, those projects to changes, those changes to users, teams and processes.

This is the holy grail of what I think about when people talk about telco digital twins (although I know that most people have a far narrower view of what a digital twin should accomplish).

If we can track the entire anatomy in a knowledge graph, then we just might not need to worry that a next generation of network ninjas is largely disappearing.

.

The OSS becomes the chiropractor

This may be where AI becomes particularly powerful to overcome any next-gen ninja shortfall.

• Giving AI more telemetry gives it better senses
• Giving it APIs or MCP tools gives it more ways to interact with the topology / environment
• Giving it powerful reasoning models makes it better at interpreting information

For decades, we’ve rightly celebrated the operational ninja who can connect all of these dots. They’re extraordinarily valuable.

But requiring a ninja to solve every difficult problem is evidence of a deficiency (or short-sightedness) in the OSS and BSS we’ve built until now.
If a critical diagnostic relationship exists only in someone’s head, then the system doesn’t know the full extent of its own anatomy.

If we can build powerful knowledgeable dependency graphs and sufficiently rich digital twins, we can begin making that anatomy an attribute of the system, not only of the talent operating it.