Bad OSS data has been quietly draining BAU budgets for decades. But with AI, AIOps and Autonomous Networking (AN), we’re about to discover just how expensive it can become. The biggest cost might not be fixing bad data – it could be allowing intelligent systems to act on it autonomously.
The smarter our systems become, the more damage they can do when they’re fed information that isn’t right. We’re moving from making mistakes at human speed to potentially making them at machine speed.
Introducing our new 94-page Data Foundations guide
That’s why we’re excited to announce the release of our new, free, 94-page interactive whitepaper, Build OSS Data You Can Trust.
It’s taken months to prepare, but the techniques behind it have been developed and refined over years of OSS transformation experience, drawing on lessons from approximately 100 telecommunications projects.
We’ve brought together practical methods for discovering, reconciling, repairing, migrating and continuously improving OSS data.
The guide includes a six-stage methodology (see diagram further below), 14 laws of data integrity, practical data-fixing techniques and provided five detailed programme implementation patterns.
We’ve also introduced the paired concept of:
- a Data Integrity Control Tower (CT) for visualising data health
- a Data Operations Centre (DOC) for systematically resolving every identified data fault
Importantly, it’s not just about cleaning up bad records. It’s about breaking the cycle that allows data quality to deteriorate again after each expensive remediation project.
So why is this becoming more important than ever? Here are just five reasons, but I’m sure you can think of a lot more!
5 reasons data foundations matter more than ever
1. The hidden BAU tax – you’re already paying for bad data
Poor data quality has always been a costly problem for OSS operators. The trouble is that much of the cost is hidden.
It’s buried in failed service activations, repeat truck rolls, inaccurate service impact assessments, manual reconciliations, unused network assets and engineers spending hours investigating information that should already be available.
These costs rarely appear as a line item labelled “bad data”. They’re absorbed into BAU budgets as inefficiency and accepted as normal operational overheads.
Worse, organisations often invest heavily in one-off data clean-up projects, only to see the same problems return months later.
The problem isn’t necessarily that organisations don’t invest in data quality. Of course they do. It’s that they’re repeatedly paying to fix the symptoms or one-off broken data instances rather than eliminating the underlying causes.
.
2. AI doesn’t eliminate bad data – it can amplify the damage
AI and AIOps promise faster root-cause analysis, better predictions and increasingly automated remediation.
But consider an AI system investigating a network outage using an inaccurate topology model. It might confidently identify the wrong root cause, miscalculate the services affected or recommend an inappropriate recovery action or customer notification.
Now imagine that recommendation being executed automatically through a closed-loop system.
The algorithms might be working exactly as designed. The problem is that they’re making decisions based on a flawed representation of reality.
Historically, experienced engineers have compensated for data inaccuracies using their knowledge, intuition and manual verification. They’ve been the buffer between bad data and bad actions.
As we move towards Autonomous Networking (AN) and Autonomous Operations (AO), the ambition is to make some of those human checkpoints disappear.
And while humans can make mistakes, autonomous systems can potentially repeat and propagate them far faster.
.
3. Yesterday’s data isn’t good enough for today’s dynamic networks
The networks we’re managing today are fundamentally different from those of a decade ago.
Virtualised network functions, cloud-native platforms, software-defined infrastructure and dynamic service orchestration mean that network resources and relationships can change continuously.
Traditional inventory approaches that relied on relatively static records and periodic reconciliation are struggling to keep pace. As we discussed in Inventory of the Future: Flexible, Scalable and Highly Dynamic, many operators had kicked the can down the road, getting by with their old network inventory tools. But in recent times, we’ve seen waves of investment (by operators and vendors) in re-designing their network inventory tools to handle the increasingly dynamic networks of today.
AN and AO initiatives accelerate this further, and increasingly require near-real-time information about network resources, service relationships, topology, configuration and operational state.
And it’s not just whether individual records are correct. It’s whether the relationships between them are accurate, whether they’re sufficiently current and whether automated systems can trust their provenance.
Perfect data everywhere isn’t necessarily realistic or commercially justified. But data must be fit for the decisions being made, with uncertainty recognised and managed. It takes careful planning to decide where near-perfect data is required and where less focus is necessary.
.
4. The Data Death Spiral could become an automation death spiral
One of the recurring patterns we’ve observed across OSS transformations is what we call the Data Death Spiral.
As the diagram shows below, poor data leads to unreliable processes (in terms of incorrect decisions, manual workarounds and operational inefficiencies). As processes become less reliable, the people involved lose confidence in the underlying OSS/BSS and other systems (even if the tools are actually still perfectly fit-for-purpose… apart from an inability to handle data glitches). Once confidence is lost, investment becomes harder to justify and data quality declines further.
It becomes a perpetual loop that many organisations have struggled with for years.
Now consider what happens when AI and automation are layered over these same processes.
Instead of breaking the cycle, we risk accelerating it. Bad data drives automated decisions, which can create further inconsistencies and operational problems, potentially feeding even more unreliable information back into the system. The death spiral spins even faster.
The alternative requires an intentional intervention. That intervention is the continual data improvement flywheel shown above in green, where better data supports more reliable processes, better decisions and greater confidence, encouraging further investment in data quality.
.
5. Better data foundations don’t happen by chance
After years of OSS transformation projects, one lesson stands out: sustainable data quality doesn’t come from another one-off clean-up exercise.
It requires a systematic approach to understanding the current data estate, modelling trusted information, fixing root causes, controlling incoming data and continuously monitoring / fixing data quality.
The diagram below outlines the approach in our new Data Foundations guide.
The methodology brings these activities together into a repeatable approach, supported by practical implementation techniques and even detailed work breakdown structures (WBS).
It also introduces the concept of treating data faults with the same operational discipline as network faults, using a Data Integrity Control Tower (CT) and Data Operations Centre (DOC) to detect, investigate, resolve and prevent recurring problems.
Just as we have a NOC to systematically manage network faults, we propose a DOC to systematically manage data faults.
.
Get your foundations right before accelerating
We’ve also recently updated our AIOps of the Future guide to version 1.04 to align with the Data Foundations report.
We also combine it with our Autonomous Networking and AI Strategy & Transformation Guide to provides a complementary approach to planning and delivering autonomous capabilities.
These initiatives all share a critical dependency – trusted operational data.
We’ve made our new Data Foundations guide freely available because we believe these techniques can help the industry stop repeatedly paying for the same problems and create a stronger foundation for what’s coming next.
The question isn’t whether you can afford to improve your data foundations. It’s whether you can afford to automate without them.
We’d love to hear your thoughts on the report. What other data quality techniques do you use and recommend? How do you ensure your data doesn’t fall into a state of disrepair?









