1
Autonomous networks vary by operational domain, with progress determined less by technology than by data quality, integration readiness and governance foundations. Nemanja Prekovic, head of delivery TMT at Avenga, explains.
Most Telco operators sit at autonomy Level 1 or 2 across their operational domains. They have scripts, monitoring tools, and perhaps some event-driven automation in production. Detection happens and even some remediation. A human still sits between detection, diagnosis, and the action that closes the incident and remains responsible for root cause analysis (RCA). That is the realistic baseline for the industry, and anyone who has worked in operations, or alongside it, knows this.
What gets less attention is that the baseline is not uniform within a single operator. Monitoring might be ready to move ahead while fulfillment is still wrestling with inventory issues, or assurance is constrained by integration debt. The reality inside most operators is uneven, which is why autonomy progresses differently from one domain to the next. A single org-wide target like “reaching Level 3 by 2027” assumes a uniformity that does not exist in the environments where this work must land.
A recent program at a European fiber operator illustrates the point. Monitoring reached Level 3 autonomy because the necessary foundations were already in place: governed APIs, consistent inventory data, and version-controlled configuration. Other domains, including fulfilment, remained at lower maturity levels because those conditions did not yet exist. The lesson was clear: autonomy maturity is domain specific.
The reasons one domain runs ahead while another stalls explain where most autonomy programs get stuck.
Why legacy complexity slows autonomy
Any operator that has been around for more than five years, regardless of size, has accumulated years of hardware and software layered on top of one another. Different vendors, different acquisition cycles, and different teams have all left their mark on the environment. In many cases, systems have changed ownership multiple times and the people who originally built the integrations are long gone.
Anything meaningful at scale requires understanding how the environment actually works today, not how it was originally designed. After years of patches, workarounds, and modifications, that understanding is often incomplete.
The cost of vendor dependencies
A monitoring or assurance stack usually touches dozens of vendors. Nothing in this environment changes in isolation. A seemingly straightforward improvement can end up involving network vendors, OSS platforms, ticketing systems, inventory tools, and data teams. Progress often depends on somebody else’s roadmap, API implementation, or bug fix. Operators wait quarters for capabilities they need now. When features do arrive, they arrive on the vendor’s timeline.
Spend enough time around these environments and the pattern becomes familiar. Operators have effectively spent years co-developing vendor products. They define requirements, fund professional services engagements, participate in design workshops, and help shape roadmaps. Yet the resulting intellectual property typically remains with the vendor.
Why modernization rarely gets funded
Every operator has platforms that should have been modernized years ago. Everybody knows which systems are causing trouble. They have usually been patched, extended, and repurposed so many times that replacing them feels riskier than keeping them. Funding the fix is usually the harder part.
The cost of modernization is visible and immediate. The benefits are often framed as reduced risk, cleaner foundations, and smoother future delivery. It is difficult to compete with initiatives that have a direct revenue story attached to them.
Nobody starts the year planning a technical-debt program. Usually, the conversation begins after a major incident, a delayed delivery, or a project that turns out to be far more complicated than expected.
That is usually where autonomy programs slow down. Not at the architecture level, but much further down in the foundations they depend on. Closed-loop designs are rarely the difficult part. The inventory is unreliable. The integrations are fragile. The data model is inconsistent. In many cases, autonomy is not creating new problems. It is making long-standing ones harder to ignore.
Governance is often the real bottleneck
Nobody owns a closed loop end-to-end. In practice, one team owns part of the platform, another owns the process, another signs off the budget, and someone else ends up carrying the operational risk.
The pattern most people will recognize: ambitious top-down objectives, cautious middle-management decision-making, and pilots that run for years without going places.
The technology is rarely the obstacle.
When and where the conditions finally align
The argument so far has been that domains progress at different rates because the foundations between them differ. The legacy weight, the integration debt, and the governance maturity behind each one are different.
When those factors do align, however, a credible Level 3 closed loop becomes possible.
A recent program at a European fiber operator provides a useful example.
The starting point was a fragmented monitoring environment with multiple tools, inconsistent data, and years of accumulated workarounds. The program consolidated those systems and established a common operational foundation. Monitoring reached Level 3 because the necessary conditions were in place. Fulfillment remained at a lower maturity level because those conditions did not yet exist.
Forcing fulfillment to meet the same maturity target would have introduced risk without creating equivalent value. This is precisely the trap created by org-wide autonomy targets and avoided through domain-level assessment.
The takeaway
A single org-wide autonomy target is the wrong unit of measurement.
A better starting point is to look for the domain that is already closest to being ready. Does it have reliable data? Are the integrations under control? Is there clear ownership of automated actions?
That is usually the place where Level 3 becomes realistic first.
Leave the others where they are until the foundations are ready.
Autonomous networks do not mature uniformly. They mature where clean data, governed integrations, and operational accountability already exist. The operators making the most progress understand that reality and focus on one domain at a time.
Nemanja Prekovic is Head of Delivery TMT at Avenga and has spent more than ten years working with telecommunications operators on OSS/BSS platforms, service delivery, and technology transformation. He has worked across engineering, architecture, and delivery leadership roles and focuses on helping telecom operators modernize complex technology environments while continuing to run live services at scale.
