Insights

Blog

Thanks, OSS, It’s been fun.

Contributed by Robert Curran, Consulting Analyst, Appledore Research

Followers of FutureNet World need no convincing of the case for greater automation in network evolution strategies. Indeed, large scale automation is the defining characteristic of what constitutes future networks and network operations. Whether these are focused on introducing 5G-enabled applications, intelligent edges or cloud-based networks, complete automation is a Day-1-essential requirement.

But not everyone agrees. At least, not everyone who really needs to.

Automation-from-Day-1 isn’t only a technical objective. It represents a new challenge not only to a CSP’s network teams, but also operations, IT, architecture, procurement and executive management. And if they aren’t also adopting new mindsets, overturning traditional practices and established norms, the automation objective is probably already in jeopardy.

Progress comes not only from creating new things, but also consciously setting aside concepts and systems that are no longer fit for a new purpose or context. As an industry, it makes no sense to aspire to the benefits of revolutionary thinking in networks, while simultaneously procuring on the basis of backward-looking business concepts, structures and working practices. Sooner or later, we must consign previously useful constructs to the past. Respectfully, graciously, but nonetheless (and with apologies to UK readers) “irreversibly”.

One of those concepts is the category of software we know as Operations Support Systems, and its downstairs neighbour, Network Management Systems. In the last 15 years, many of these have been “transformed” in various ways. But in many cases, they perform essentially the same functions as before – broadly circumscribed by “FCAPS”: Fault Management, Configuration Management, Accounting, Performance and Security. Within CSPs, there has been some consolidation, rationalisation, replatforming and upgrades – and no doubt some cost savings and efficiency improvements as a result. But as long as CSPs hold on to the concept of “support” systems, they will miss the greater opportunities – and yes, challenges – of re-envisioning all software in terms of automation systems.

In the light of the rapid changes in software-defined networks and cloud, CSPs’ future budgets assigned to categories such as network management and OSS should be re-formulated. Without challenge, planned expenditure on “OSS” is likely to delay the real change that is now required.

But what, in practical terms, replaces OSS and NMS? As categories of future spend, how do the business and commercial parts of CSPs translate the technical language of cloud, open APIs and automation into cells on a 3-year budget spreadsheet?

Appledore recently published a new reference model for the telecom network automation software market. Not a technical architecture, but a reflection of the emerging categories of spend that we believe are already (and will increasingly) replace EMS, NMS and OSS.

A Market Transformed

“Network Automation Software” is software that automates the qualification, test, deployment, healing, scaling, monitoring, and intelligent management of networks and services, from pre-deployment through turn-down.

Based on conversations with CSPs, vendors and ongoing research on industry trends (especially in disaggregation and software-ization), the market for network automation software is now divided into seven categories (and not an “OSS” in sight):

  • Artificial Intelligence Operations (“AIOps”) – the applications that use network (and other) data to drive decisions and processes.
  • Service Orchestration – end-to-end control of network services and functions.
  • Domain Management – the management and control of classical network facing functions
  • Distributed Cloud Infrastructure – software used to automate and optimize network inventory, place workloads.
  • Network Data Management – collection, storage, presentation of network data of all kinds.
  • Component Lifecycle Management (LCM) – software for automation of test, validation, onboarding and retirement of (software-ized) network functions.
  • Cloud-native Network Functions – newly re-architected network functions, built for horizontal scaling on cloud platforms, but also extending into functions for test and measurement, security and even third party functions.

Appledore Telecom Network Automation Market Taxonomy

Source: Appledore Research

Rather than reflect obsolete OSS categories (such as provisioning, assurance, order management) this new taxonomy identifies functional blocks that may be re-arranged to achieve different automated processes – some for services, others for network function technologies, etc.

Moreover, they are more aligned with public cloud and enterprise IT thinking, and better reflect the scope of future buying decisions. For example, the platforms required to turn myriad network (and non-network) data into operational decisions – including collection of that data, normalization storage, etc.  In the end, this data will be put to many uses, from understanding which customers are worst affected by equipment failures, to understanding traffic flow patterns and customer usage and buying behaviors.

There has historically been a strong relationship between network equipment and the software required to operate networks, which has given incumbent equipment vendors a strong advantage.

However, this is a weakening advantage, for several reasons:

  1. CSPs are keen to break out of the historically long product release cycles of major vendors.
  2. CSPs want to leverage more software-defined networking and operate across multiple vendors’ kit.
  3. Industry bodies such as the TMForum, Open Networking Foundation and TIP are actively advocating ways to reduce dependencies on proprietary hardware – through open interfaces and disaggregated network architectures.
  4. Governmental concerns about the safety of some vendors have prompted measures to support diversification of the telecom supply chain.

Telecom network automation software has changed far more rapidly in the last two years than in any period in the history of EMS, NSM and OSS. Both vendors and CSPs should look to re-align their offerings (and scope their procurements) against a new, forward-looking model of this transformed market.

Find out more about Appledore’s Network Automation Software: A Market Transformed here.