Is AI a digital transformation bridge or noose? (part 2 – Transformation Planning)

In Part 1 of this series, we explored an uncomfortable paradox. AI is being excitedly positioned as the key to telco transformation, yet many initiatives are quietly reinforcing the same legacy digital landscapes they would love to replace.

That leads to a more fundamental question.

Before choosing AI models, architectures, or tooling, must we actually decide what kind of transformation we want – Evolution or Revolution?

Do we want revolution – a future that’s finally moved on from today’s (yesterday’s / last decade’s) core OSS/BSS? Or are we unwittingly making it harder to ever move to entirely new solutions?

That choice matters more than most AI roadmaps acknowledge. Because the same AI “quick wins” can either act as a bridge to transformation or tighten a noose around legacy systems, depending entirely on the transformation model they’re attached to. We’ll discuss those models below.

.

Why AI “glue” projects are attracting the funding

Over the last few years, I’ve noticed a clear shift in funding. (I’d love to hear whether you’ve noticed the same shift within your organisation or clients)

AI initiatives appear to be attracting budget that might have previously been earmarked for OSS/BSS transformation. When you think about it, this isn’t hard to understand.

The basic / additive AI projects we discussed in Part 1 tend to be:

• Buzzworthy for project sponsors (to say they’re working on AI projects)
• Easier to justify (because they’re generally quite small in scope as most implementers are still in the early learning stages)
• Faster to deliver (because scope is generally simpler), and
• Less risky than touching core operational systems that have to run 24x7x365.

Many of these are “glue” projects. They sit between systems, smoothing rough edges, filling gaps, and delivering immediate operational impact. They often produce visible results in weeks or months, not years. Compared to large-scale OSS/BSS programmes, they feel pragmatic and achievable.

They’re effectively moving from the System #2 end of the continuum below towards the System #1 end. They’re adding more nodes and/or cross-linking between existing systems and data sources.

.

There’s another, less comfortable truth underpinning this shift to doing small, incremental uplift using AI technologies.

To my knowledge, apart from some of the most recent AIOps platforms, there is no truly AI-centric, off-the-shelf OSS or BSS product available today to replace nodes on existing OSS/BSS architectures.

Despite plenty of marketing claims, AI almost always arrives as a wrapper around existing systems, or as a home-grown incremental addition, not a replacement for any of the monolithic, current/legacy OSS/BSS. That makes AI inherently additive. And additive investments, by definition, increase the surface area of what already exists (as implied in the differences in meshing between Systems #1 and #2 above).

.

Transformation models and how well they suit AI-led change

But let’s face it, AI is not a transformation strategy. It’s an opportunity for massive re-framing about the way we think about digital systems and their transformations. It’s potentially an accelerant. But how transformative it is in the long-term depends almost entirely on the transformation model it is attached to.

So let’s discuss some of the possible transformation models (please leave me a note if I’ve left any alternatives out):

1. Big-bang or rip-and-replace transformation offers maximum clarity and minimal coexistence cost. In theory, this suits AI well because there is a clean end state. In practice, the operational and political risk is so high that AI is usually avoided. Big-bang programmes already carry enough uncertainty without introducing probabilistic decision-making
2. Parallel build looks more AI-friendly. New stacks are built alongside legacy and AI is often used to streamline coexistence and reduce operational pain. But we need to be very careful that coexistence is only a temporary state. The risk is that dual running becomes tolerable and one system becomes two (we’ve all seen that before!!)
3. Strangler fig transformation or incremental change approach is frequently cited as an ideal model for AI-led change. Progressive interception and replacement should, in theory, work well with intelligent routing and decision-making. In practice, AI is often attached to legacy systems to optimise them rather than intercept or replace them. The challenge discussed in part 1 is like the strangler fig, but without any definitive strategy for removing the original host
4. Federated models (what I refer to as data-bridge approaches), suit AI for insight generation. Legacy systems generally remain authoritative while data is unified through shared models or views. This works well for human decision-making and analysis. Without an explicit next step, however, federation stabilises the legacy estate rather than preparing it for removal
5. Platform insertion (a more functionality-specific version of a big-bang or parallel build) introduces a horizontal system of engagement across multiple OSS and BSS. AI thrives here, especially in areas where a legacy system like Fault Management is replaced by AIOps, scripted activation is replaced by modern AI-assisted orchestration, etc. The danger again with this approach is that success is likely still reliant on underlying systems instead of abstracting them away (think integrations to legacy, often proprietary network or systems interfaces)
6. Greenfield transformation is the cleanest model for revolutionary change. AI can help re-shape processes, systems and decisions devoid of legacy constraints. But there are two limitations here. We almost never get an entirely new / greenfield estate to play with as they tend to only occur during the systems build of an entirely new telco. For existing telcos greenfield avoids legacy entirely, which many organisations are unwilling or unable to do. There’s too much sunk cost to discard
7. Carve-outs, or greenfield enclaves, a bit like standalone POC environments, are excellent for AI experimentation. They optimise speed and learning and allow new ways of working to be trialled (using the inertia principle (F = ma)). But carve-outs must still coexist with the parent organisation
8. Process-first transformation (aka  Business Process Reengineering or BPR-led transformation) aligns conceptually with AI. Redesigning end-to-end processes before tooling is what we call the moving house analogy. The downside is that visible system change is delayed whilst process transformation happens. BPR can be a significant challenge and is a topic for a whole other series of articles. So much so that we even developed our own workflow capture tools
9. Finally, we’re starting to see some nascent AI-first transformation approaches such as AI bridges (a federated decision layer rather than the data / system bridge of the federated model above) or intent driven abstraction. In both of these cases, decision-making and optimisation layers are added without significantly altering core systems. This delivers fast value and is often described as transformational. In reality, unless there are clear subtraction projects planned, chances are they’ll only increase the operational value of legacy OSS/BSS and makes them harder to replace / disentangle

Just a couple of distinctions here:

Greenfield and carve-out are often treated as interchangeable, but they aren’t. Greenfield avoids legacy entirely. Carve-outs must coexist politically, operationally, and architecturally with the parent organisation, which radically changes how AI dependencies form.

Similarly, AI-led and federated approaches are easily conflated. Federation unifies data and user interfaces for human involvement. AI-led approaches unify decisions, often in machine-to-machine loops. One prepares systems for change. The other often entrenches them.

.

Using AI to plan AI-led transformation

So, when you decided what kind of transformation you wanted above, which did you choose – Evolution or Revolution?

If we’re choosing to use AI projects as a way of evolving existing systems, then we can simply plan each project in relative isolation.

However, if we’re seeking radical, revolutionary change, we need to establish a full programme made up of multiple projects.

At PAOSS, we use the WBS capabilities within DivvAI to plan major programmes of work like this. The WBS snippet below shows a default AI-led transformation programme that we use as a base to help customers plan their projects. It’s based around the TM Forum Transformation Project Framework.

You’re welcome to navigate around the full WBS below by logging into DivvAI here (or clicking on the image below). Alternatively, we’d be delighted to give you a walkthrough.

One of the great ironies of current AI programmes is that AI is rarely used to plan transformation itself. Most transformation planning remains assumption-driven and manual, relying on experience, intuition, and static diagrams.

There is a growing opportunity to use AI to explore transformation scenarios before committing to them. To analyse dependencies, map as-is process flows and calculate cost / risk pathways from current data rather than guessing. Tools like DivvAI are aimed at this gap, not as automation engines, but as decision-support for transformation planning.

.

Bridge or noose? Project or Programme? Revolution or Evolution?

AI amplifies the choices you make on the Cross-Linking / Complexity continuum above. When transformation intent is incremental, localised, small or vague, AI is quite likely to increase legacy system entanglement. In those conditions, AI becomes a noose.

Revolutionary change requires a LOT more effort, including subtraction and anti-entanglement planning!

Subtraction projects remain rare (across my 25 years of experience at least). In Part 3, we’ll focus on the missing capability behind every failed subtraction project I’ve been aware of.

In Part 4, we’ll looking into a reframe towards autonomous networks via subtraction rather than addition.
Then finally in Part 5, we’ll discuss some design principles that allow OSS to be unplugged… eventually.