Telco Trends Fact-Checked: Four Theses, Five Years On

Strategic decisions outlast the trends they are based on. The choice of a modernization path, for example, has a decisive influence on how quickly new offerings reach the market and how much effort changes cause during live operations.

In 2021, AOE published recommendations for the digital advancement of telecommunications companies. The guiding principles were clear: put the customer experience at the center, modernize incrementally, consolidate data, and extend standard software selectively.

Today we are taking a critical second look. Which recommendations would we still make, and where do we need to correct or qualify our statements? That also means naming prerequisites and downstream effort more explicitly. Because companies bear the long-term consequences of an investment decision even after the next trend debate has long since begun.

1. Evolution Instead of Big Bang

AOE explicitly recommended iterative modernization along a target architecture¹. TM Forum likewise describes the Open Digital Architecture (ODA) as an evolutionary path, citing the large number of legacy systems still in operation.

In telco landscapes that have grown over time, this remains a sensible approach, because a limited scope of change is easier to oversee, test, and correct than replacing core systems all at once. The prerequisite, however, is that the affected data and process dependencies are under control. Splitting a system into microservices does not by itself reduce the business risks of migration.

The price of an evolutionary transition arises between the steps: old and new systems run in parallel, data has to be synchronized, and transitional interfaces have to be operated. When errors occur, it must be clarified which team is responsible. This coexistence can extend the transition phase and tie up considerable capacity that is then unavailable for further modernization.

Planning for every interim state therefore has to include its end: which responsibility passes to the new system, and under what conditions can the legacy function and its transitional interfaces be switched off? A program that introduces new components but retires no old dependencies is not yet "evolutionary" in itself.

For clearly delimited functionality, a one-time switchover can be more economical than a long period of parallel operation. This does not contradict an overall evolutionary approach to modernization, but the decision has to match the scope and risk of the respective step.

2. Customer Experience as a Product

"Experience is the new product"²: this recommendation from 2021 has become a baseline requirement today. What providers can differentiate on is how reliably they meet that requirement across the entire customer process.

A plan change makes this concrete. A user-friendly portal supports the selection and prevents input errors. But the change only succeeds once the offer is permissible for the existing contract, the order has been processed, and the new service is available at the agreed time. After that, the invoice has to be correct as well. If any one of these steps fails, customers need information or support, even though the digital interaction appears to have been completed long before.

The success of a modernization effort therefore cannot be measured by new interfaces and additional self-service functions alone. The assessment also has to include actual cycle time and the share of transactions completed without manual rework. Clarity and ease of use remain important, but subsequent support contacts and any invoice corrections required are equally relevant metrics.

The end-to-end process chain needs a named owner, particularly when several teams and vendors are involved. Otherwise every subsystem may well meet its requirements while the actual customer request goes unfulfilled. For investments, the complete customer journey should determine success criteria and scope.

3. Centralized Data

A shared data foundation was meant to help companies understand customer behavior better and target their offerings more precisely. To that end, AOE described connecting data silos and running analysis in data warehouses or data lakes. Sound data management and the use of the resulting insights in operational processes were also considered decisive³.

Central availability of data alone, however, does not create a reliable basis for personalization. When data is consolidated, its business context has to be preserved as well. A confirmed order, a technically active service, and a billable contract describe different states, for instance. A status such as "active" is therefore ambiguous without the information about what it refers to.

Differing terms and models in sales, service, and billing can make business sense, because those areas perform different tasks. In domain-driven design, a "bounded context" accordingly limits the scope of a model and its shared domain language. When data is exchanged between different business areas, though, its meaning, origin, and required recency have to be unambiguously defined. It also has to be clear which information is authoritative for a given decision.

One example of such a decision is selecting an offer derived from usage behavior. That offer has to fit the existing contract, be available, and be genuinely orderable at the same time. Without this reconciliation, customers receive a recommendation they cannot act on in the ordering process.

Before investing in additional data infrastructure, it should therefore be clear how the insights gained will feed into the customer journey and who is accountable for putting them to use.

4. Buy-and-Build

Under buy-and-build, telecommunications companies were to use suitable standard software and add their own development wherever their business needs went beyond it. AOE associated this with the ability to implement new requirements without having to replace the entire system landscape.

The principle remains sound, but modular architecture principles alone do not create future viability. A single vendor update can require adjustments to in-house extensions and extensive testing. With several vendors, that effort can escalate quickly. Development work does not disappear through procurement, then. It shifts to integration and coordination.

For this reason, every decision between standard software and in-house development has to start from the business need. Standard software is the obvious choice when it covers that need with a reasonable amount of customization. In-house extensions have to deliver concrete value, such as the ability to develop an offering further independently of a vendor's product roadmap. The development capacity needed for maintenance and support has to be sustainable over the long term as well.

The scope of change alone is not a sufficient yardstick, however. A quick special-case solution for a single journey can make later changes harder and cause additional effort permanently.

Core systems that work can keep their responsibilities, provided they remain economical and secure to operate. For every addition, what counts alongside functional scope and integration effort is whether open standards and data sovereignty make future changes and vendor switches easier. Procurement that looks inexpensive at first can turn costly if every business change ties up developer resources and vendor lock-in prevents a later switch.

Conclusion

Evolutionary modernization and buy-and-build can help limit the scope of individual changes. They do not, however, eliminate the effort for parallel operation, integration, and coordination. And whether customer processes work end to end and data is usable in its business context is in turn decisive for the value of new interfaces and central data platforms.

Every investment decision therefore has to weigh business value, accountability, and the cost of introduction, operation, and later change together. The economic consequences of the chosen modernization path outlast the trends behind it.

1. AOE: Innovation & Sicherheit (2022) ↩
2. AOE: Trends und Herausforderungen – Fünf Handlungsempfehlungen (2021) ↩
3. AOE: Wie CSPs maximales Potenzial aus ihren Daten schöpfen (2022) ↩

‍