A legacy telco’s infrastructure often resembles a knotted rope: complicated, tangled and difficult to unravel with no clear starting point.
You can think of each individual knot as a software integration that has been bolted onto a 10 year old business support system - knots that must be untied and retied for every update. Imagine all the costs and wasted time doing this again and again for years. This is the story of legacy telco software and its jungle of integrations.
Legacy telco software is notorious for being slow, inflexible, and costly to maintain. These inefficiencies are the result of decades of outdated software development practices, vendor-led customizations, and short-term decisions made at the expense of long-term agility.
But what are some of the deeper reasons that cause this level of technical debt? What are the effects of technical debt on your telco?
The Costs of Technical Debt
Technical debt costs your telco both time and money.
To manage a large network of software vendors and integrations built up over the decades, traditional telcos dedicate a large part of their operating staff just to keep the system running. Each new feature needs to have its own APIs, data needs to be matched, and all this needs to be readable by all the older software modules - hence why this situation is lovingly called ‘spaghetti’.
In short, technical debt harms your telco in the following ways:
Slow time-to-market and low agility: Launching new services, app updates, or marketing campaigns can take six months or more due to lengthy change request processes.
In legacy telcos, even simple changes like updating a plan or bundling a new feature often require coordination across multiple tools and teams. Product and marketing teams would need to go through the IT team, who then needs to manage integrations across all the different vendors. Without a unified system, operational bottlenecks are the norm.
As McKinsey puts it:
“Any nonuniform process can slow delivery and create a potential bottleneck that hinders operators from improving their time to market.2”
For context, a new telco campaign can be launched over one weekend with the right software suite your telco can launch marketing campaigns over one weekend. Software that was built to be configurable can allow product managers and marketing managers to update the platform without waiting on engineering support.
High operating expenditure (OpEX): Engineering resources are consumed by support tickets and patchwork fixes instead of innovation. Countless hours lost communicating back and forth with software vendors and systems integrators, adding to the opportunity cost as well.
The biggest irony is that McKinsey found that telecom operators that invest in more efficient IT systems tend to be more cost-efficient than their competitors in IT spending.1
Moving away from legacy software bogged down by “spaghetti” integrations to full-stack software can raise your EBITDA margins by 10 to 16%.
The Build-Up of Technical Debt in Legacy Telco Software
Traditional SDLC Practices in Telco Software Development
The bulk of a telco’s technical debt stems from how the software was originally built, such as focusing on solving the wrong business problems to the software development methodologies employed.
Back when voice and SMS made up the majority of a telco’s revenue, system stability was more important and business agility was less of a priority.
As a result, the Waterfall model for software development was popular for its predictability and security. The Waterfall model is a linear, phase-based development lifecycle requiring all requirements to be locked in upfront, perfect for the telco industry’s previously stable environments.3
However, the rigidity of this model has made it obsolete in today’s fast-moving markets. Software built using the Waterfall model could take years to develop, and even if no changes were made along the way, the finished product could already be obsolete even before it launches.
Adding to this, legacy telcos focused on requesting custom-hard-coded applications over building configurable platforms. The result was that even the smallest feature change required engineering intervention and many new integrations. That gave legacy telcos their characteristic long delivery cycles, low adaptability, and systems that couldn’t evolve with the market.
Lack of Clarity on the Business Requirement: Solving the Wrong Problems
Not being able to make changes to your software during its development cycle is one problem, but sometimes your software vendors might not even be helping you solve the right problem at all.
Some software consulting vendors tend to focus on asking their clients for project requirements but won’t dive deeper to find out their client’s true underlying issue.
As a result, even if the new software features are built to specifications, the original issue still causes the same old problems. That leads to commissioning even more bespoke software in the future.
The Business-Driven Shortcuts That Led to Spaghetti Code
Technical debt impacts the bottom line too.
Many telcos took short cuts to focus on short-term CapEx savings over long-term scalability. Instead of rethinking their architecture, they layered new features on top of old systems.
This piecemeal approach created complex integrations between siloed tools that lead to the dreaded "spaghetti code" environment and spiraling maintenance costs. As the McKinsey report mentioned, those who invested in better IT systems ended up becoming more efficient in their IT spend compared to competitor telcos.1
These integrations extend beyond software too, with tight couplings between legacy software and the workflows and processes that telco teams use.
To make matters worse, some telcos choose to lock-in with their current vendors to get their investments’ worth from them. That means depending on bespoke vendor-specific solutions that require their own integrations with other vendors’ software. Each vendor has their own set of APIs, configurations, and processes, making cross-system changes slow and expensive.
And for telcos who stick with Waterfall models, when requirements changed mid-project, as they often do, teams would continue development without revisiting whether the original assumptions still held true. Poor alignment between product teams and market needs only deepened the gap between software output and business impact.
How Technical Debt Can Be Solved:
Understand the Problem, Understand the Market, Be Agile
Technical debt can’t be fixed with quick-fixes. You need to:
But there’s more to these solutions as this is just a whirlwind summary of our SaaS development approach.
In our next article, we’ll take you behind the scenes of how Circles builds telco software differently, from agile methodologies to our clean slate approach, and why it’s helping telcos break out of their technical debt traps for good.
Stay tuned!