Tied a Little Tighter Every Year. Where Your Dependence on a Vendor Is Now, and Where It Should Be.
Each portal, plan and report an operator builds reaches its vendor's billing product in its own way, and nobody counts the ties. Here is what we found, the options, and the benchmark we would set so an operator can see its dependence, and watch it stop growing.
Marketing wants a new family plan. The head of IT lists what has to change: the care portal, the self-service app, the dealer tool and three finance reports.
Each of them reaches the billing vendor’s product in its own way, because each was written at a different time, for a different project. Each change needs the vendor, and the vendor’s first free slot is some months away.
When the plan is built, it will be built the same way: one more application reaching straight in.
The paradox: Everything the operator builds to grow its business makes it a little harder to change what the business stands on.
What We Found
For this article we went through the public record on how operators come to depend on the vendors of their old systems: one industry body’s research on the priorities of telco CIOs, one industry body’s article on the subject, one trade press account of an operator’s old billing and customer stack, and one survey of IT professionals.
Four findings stand out.
Leaving is hard, and most technology heads in one region say so. In an industry body’s research on telco CIO priorities in the Americas, 88% of the region’s telco CIOs “say migrating from closed legacy systems is difficult”, against 73% globally, and 54% name “IT modernisation and technical debt reduction” as a focus of investment. The news report gives no sample size, no size of operator and no reasons.
One industry article put the cost in strong terms, as opinion. An industry body’s article, sponsored by a vendor of equipment, spoke of “the problems associated with legacy IT paradigms, which have stunted agility, speed, innovation and ultimately growth”. It is opinion from a party with something to sell, and we quote it as that.
In one older case, the applications were many and their code had no single home. In 2019 a trade press account described a mobile operator in Sri Lanka, “a three-million customer business” whose billing and customer stack ran to “more than 60 different applications”, and said “there was no centralized code repository”. What the operator did afterwards we leave out.
Firms fear the disruption of change. In one survey of 504 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, 38% named fear of disrupting operations among their reasons for not modernising old systems.
We found no case of a vendor withholding knowledge or overcharging, and nothing in this article says vendors behave badly. Being a customer of a billing vendor is ordinary.
Our reading is that dependence grows one sensible project at a time. Reaching straight into the vendor’s product is the quickest way to deliver any one project. Each application does it its own way. Nobody counts the ties, because each belongs to one project, and nobody writes down what passes along them.
What our review does not show: We found no figure for how many applications an operator ties to its vendor’s product, what moving them costs, or how long a change waits. The industry body’s research covers the Americas, with no sample size, and gives no reasons. The article we quote is sponsored opinion. The named operator is from 2019 and outside India. The survey is cross-sector, from the US, and was run by a vendor. Contracts and licences were not researched. The opening scene is imagined. That uncounted ties are what make leaving hard is our reasoning.
What an Operator Cannot See While Nobody Counts
It cannot see how many of its own applications reach the vendor’s product. The total belongs to no project.
It cannot see what each one sends and expects back, so when the vendor upgrades its product, every application has to be checked.
And it cannot see the trend. Every launch adds a tie, and the risk register carries the same line, “dependence on a single supplier”, year after year, while more of the business comes to rest on it.
The gap we see: an operator that wants to keep its options open does not need to leave its vendor. It needs a written record, for each of its own applications, of what it sends to the vendor’s product and expects back, and a way to rebuild its own applications, one module at a time, so that each one does exactly what that record says. Then the ties can be counted, and the dependence stops growing unseen.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Stop the Ties Growing, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Renew as before, and build each new thing the quickest way | The vendor serves the firm well, and few new applications are planned | Every launch adds a tie that nobody counts, and the next change of product touches all of them |
| Switch to another vendor | The present product no longer fits the business, and the firm can fund a large move | A new dependence, a big move with its own risks, and every one of the firm’s own applications to change at once |
| Write your own record first, then decide | The firm wants to know what it has tied to the vendor before it decides anything | It costs money before anything changes, and it changes nothing in the system by itself |
| Rebuild your own applications one module at a time, against a written record | The record shows which of the firm’s own applications are old, and the firm wants them changed without one large move | It costs more per application than reaching straight in; old and new run side by side; the vendor’s product can be met only where it allows |
Our recommendation: write your own record first, then rebuild your own applications one module at a time, starting where the record shows the most risk, each one built to send and expect exactly what the specification records. Build new applications the same way from the start. You may never leave your vendor, and you may not need to; staying is a legitimate choice. We do not read, change or replace your vendor’s packaged billing product, and we have no integration product. How your applications may connect to it is set by your contract and what the product supports; we obtain nothing from your vendor and give no legal advice on it. We do not work on the network.
Where You Are Now, and Where You Should Be
A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.
For this issue, the benchmark would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Your own applications that talk to a vendor’s product, each with a written record of what it sends and expects back | Not counted; none written | Every one counted and recorded, with what it sends, what it expects and what happens when the answer does not come | The map of the applications as they stand, and the specification |
| New applications built since the record was made | Each reaches in its own way, unrecorded | Each one’s exchanges with the vendor’s product written down when it is built | The specification, kept current by an owner on your side |
| Change requests that only the vendor can scope | Not counted | Counted, and falling as your own applications are rebuilt against the record | Your own change log and the risk register |
| Code for your own applications held in your own repository | Not known; often held elsewhere, or nowhere | Held in a repository your firm controls, as your contract allows, including the code of every rebuilt module | Your own repository list (arranging it is your step) |
| Old functions matched to new ones, where an application is rebuilt | Not recorded | Each function linked to its replacement | The traceability matrix |
The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a telecom operator.
How We Work With You
- We listen: a free Reliability Review. A first conversation about what your own applications are tied to, and how. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your firm built or had built, by its vendor or anyone else, around its billing system. For a vendor’s packaged billing product, which we do not read or work inside, the specification records only what your own applications send to it and expect back. Where a vendor or an integrator holds the code of the applications built for you, arranging access to it is your step, under your own contract. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. The specification is yours, and you can take it to any supplier, including your current one. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means one of your own applications at a time, rebuilt to send and expect exactly what the specification records. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark above. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
This approach has limits. We do not read or work inside your vendor’s packaged billing product, and we do not change, configure or replace it; we record only what your own applications send to it and expect back, and where it offers no supported way in, the assessment says so. We have no integration product. We do not work on the network or the systems that run it. We obtain nothing from a vendor: code, access and the vendor’s documentation are yours to arrange under your own contract. We give no legal advice on contracts, licences or who owns code. None of this lowers what you pay your vendor, and none of it makes leaving easy; it makes your dependence visible, and gives you a choice. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.
At the end you hold the specification with every tie recorded, the risk register, the traceability matrix and code for every module we rebuilt, and the filled-in benchmark. The vendor’s product and its licence stay between you and your vendor.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | New plans and services stop adding unseen ties to the vendor every time one is launched. |
| CTO or CIO | Each of the firm’s own applications has a written record of what it sends to the vendor’s product and expects back, so a change on either side can be checked against it. |
| CFO | Money spent on the firm’s own applications builds something the firm holds: code, a specification and a matrix, module by module. |
| COO | A change to a portal or tool that touches only the firm’s own code can be scoped by more than one firm. |
| Head of regulatory affairs | The register can show, at each review, how many of the firm’s applications have a written record of what they exchange with its most important supplier. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A mobile operator in Sri Lanka, an older case (2019): a billing and customer stack of “more than 60 different applications”, and “there was no centralized code repository”. | Our part is far narrower: we do not read inside a packaged billing product, obtain anything from a vendor or say how this operator should have run its systems. For applications an operator built or had built, we record what each sends and expects, and rebuild them one module at a time. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We set the benchmark first, so that an operator can see how tied it is, and see the number stop growing.