Is AI a digital transformation bridge or noose? (part 4 – Autonomy Hazards)

I’ve never achieved true autonomy in an end-to-end, complex telco environment. What follows is a hypothesis. I’d love to hear your thoughts and clarifications.

What I have achieved are small autonomous solutions that did work nicely, until a single baseline parameter changed. Then assumptions broke, dependencies surfaced and entire solutions + datasets had to be rebuilt rather than adapted.

In fact, the “extra cleverness” that I’d designed into the data model didn’t make those systems more elegant or resilient. They introduced additional failure points that had to be unwound. A case of the KISS principle whacking me over the head (yet again!!).

That experience fundamentally changed how I think about autonomy.

This article builds directly on the previous three parts of this series:

• Part 1 explored the paradox that today’s AI initiatives often reinforce legacy OSS and BSS through complex entanglement
• Part 2 showed that whether AI becomes a bridge or a noose depends on the transformation model we choose
• Part 3 argued that before we can subtract anything safely, we must first quantitatively understand the full web of entanglement

Together, those articles set up an uncomfortable question.

What if autonomy doesn’t arrive by adding more / “smarter” algorithmic layers?

I could well be proven incorrect, but I feel that our ability to achieve/approach ambitious objectives (eg Autonomous Networks, Autonomous Operations, etc) can only emerge when there are drastically less variants / complexity to manage.

In this article, I want to challenge the dominant autonomy narrative and share the lesson I learned the hard way.

.

What my “autonomous” project got right, briefly

The autonomy initiative discussed earlier wasn’t a failure from day one. In fact, it worked extremely well, helping a client team with almost no telco experience to provision complex services for their customers.

Within a narrow scope, decisions were faster. Manual effort was negligible. Outcomes improved [as an aside, if the outcome we sought was to teach the client team more about telco networks and services, then we totally failed at that because the systems we built took all of the design responsibility out of their hands].

We progressively added more logic / intelligence to cover additional edge cases / variants.

It was going beautifully…. until it failed catastrophically!

The network engineers made one change in the network topology and the whole autonomous system collapsed like a deck of router cards / SFPs.

The conditions that made it work were too specific and it was all undone by a change in baseline.

What followed wasn’t a small fix. It was a rebuild. The logic were no longer valid. The data model needed to be totally rebuilt (and drastically simplified), which caused many downstream impacts (starting with the discovery engine).

It took months to fix it all.

.

The lesson I learned the hard way: autonomy needs fewer things, not smarter ones

The hardest lesson for me to accept was that my multi-layered, elegant data model was central to the fix taking so long and bringing other dependent systems down with it.

I’ve tried hard ever since to work on the principle of MVD – Minimum Viable Data.

Fewer variants (ie less data, fewer systems, fewer integrations, fewer decisions that need to be coordinated, etc).

It seems intuitive to me that autonomy is only achievable in an environment of maximised simplicity (at all stages of design) and quality data.

.

An autonomy example from outside telco

To my knowledge, we haven’t achieved full autonomy of any complex systems in the telco industry yet. As such, I’m going to lean on a fascinating autonomy story from outside the telco industry altogether.

Tesla’s Full Self-Driving (FSD) version 12 represents one of the most radical architectural changes in autonomous vehicle software to date. Instead of relying on hundreds of thousands of lines of traditional, hand-coded logic (rules and explicit C++ control code), Tesla progressively evolved toward an end-to-end neural network approach that dramatically reduces the amount of explicit code required to produce driving behaviour.

Over time, Tesla removed large volumes of hand-coded rules and replaced it with learned behaviour identified in massive data sets.

Autonomy didn’t emerge because the system became more sophisticated in the traditional sense. It emerged because the entanglement of logic was removed.

That example makes me uncomfortable about the way I’m seeing telcos designing autonomous systems today. It also runs counter to how most autonomy programmes are structured, where intelligence is layered on top and / or meshed in ever-growing complexity.

Tesla also collects massive amounts of coherent data, unlike telco, which often has dozens / hundreds of siloed data sets.

.

Why this example is inspiring but not directly copyable

Obviously telco networks are not vehicles. The environments, constraints, and safety models are different.

And I’m clearly not enough of an expert to claim that the Tesla approaches establish any form of precedent for the Telco industry.

But to me at least, the principle seems to matter directionally.

The Tesla example hints at something deeper for telcos to consider when autonomy is discussed. The ability to progressively remove explicit logic at scale, and replace it with neural networks trained on massive quantities of data. We’ll discuss this further in Part 5.

We’ll also look into some other useful autonomy examples. What does seem apparent is that autonomy succeeds when learning systems are built on radically simplified foundations

What are your thoughts? What other precedents are applicable (more applicable) for us to achieve AN / AO?