Driving the agility flywheel: the stepwise journey to agile

Agility is front of mind, now more than ever

Telecoms operators today face an increasingly challenging market, with pressure coming from new non-telco competitors, the demands of unfamiliar B2B2X business models that emerge from new enterprise opportunities across industries and the need to make significant investments in 5G. As the telecoms industry undergoes these changes, operators are considering how best to realise commercial opportunities, particularly in enterprise markets, through new types of value-added services and capabilities that 5G can bring.

However, operators need to be able to react to not just near-term known opportunities as they arise but ready themselves for opportunities that are still being imagined. With such uncertainty, agility, with the quick responsiveness and unified focus it implies, is integral to an operator’s continued success and its ability to capitalise on these opportunities.

Traditional linear supply models are now being complemented by more interconnected ecosystems of customers and partners. Innovation of products and services is a primary function of these decentralised supply models. Ecosystems allow the disparate needs of participants to be met through highly configurable assets rather than waiting for a centralised player to understand the complete picture. This emphasises the importance of programmability in maximising the value returned on your assets, both in end-to-end solutions you deliver, and in those where you are providing a component of another party’s system. The need for agility has never been stronger, and this has accelerated transformation initiatives within operators in recent years.

Concepts of agility have crystallised in meaning

In 2015, STL Partners published a report on ‘The Agile Operator: 5 key ways to meet the agility challenge’, exploring the concept and characteristics of operator agility, including what it means to operators, key areas of agility and the challenges in the agile transformation. Today, the definition of agility remains as broad as in 2015 but many concepts of agility have crystallised through wider acceptance of the importance of the construct across different parts of the organisation.

Agility today is a pervasive philosophy of incremental innovation learned from software development that emphasises both speed of innovation at scale and carrier-grade resilience. This is achieved through cloud native modular architectures and practices such as sprints, DevOps and continuous integration and continuous delivery (CI/CD) – occurring in virtuous cycle we call the agility flywheel.

The Agility Flywheel

agility-flywheel

Source: STL Partners

Six years ago, operators were largely looking to borrow only certain elements of cloud native for adoption in specific pockets within the organisation, such as IT. Now, the cloud model is more widely embraced across the business and telcos profess ambitions to become software-centric companies.

Same problem, different constraints

Cloud native is the most fundamental version of the componentised cloud software vision and progress towards this ideal of agility has been heavily constrained by operators’ underlying capabilities. In 2015, operators were just starting to embark on their network virtualisation journeys with barriers such as siloed legacy IT stacks, inelastic infrastructures and software lifecycles that were architecture constrained. Though these barriers continue to be a challenge for many, the operators at the forefront – now unhindered by these basic constraints – have been driving a resurgence and general acceleration towards agility organisation-wide, facing new challenges around the unknowns underpinning the requirements of future capabilities.

With 5G, the network itself is designed as cloud native from the ground up, as are the leading edge of enterprise applications recently deployed by operators, alleviating by design some of the constraints on operators’ ability to become more agile. Uncertainty around what future opportunities will look like and how to support them requires agility to run deep into all of an operators’ processes and capabilities. Though there is a vast raft of other opportunities that do not need cloud native, ultimately the market is evolving in this direction and operators should benchmark ambitions on the leading edge, with a plan to get there incrementally. This report looks to address the following key question:

Given the flexibility and driving force that 5G provides, how can operators take advantage of recent enablers to drive greater agility and thrive in the current pace of change?

Enter your details below to request an extract of the report


 

 

Table of Contents

  • Executive Summary
  • Agility is front of mind, now more than ever
    • Concepts of agility have crystallised in meaning
    • Same problem, different constraints
  • Ambitions to be a software-centric business
    • Cloudification is supporting the need for agility
    • A balance between seemingly opposing concepts
  • You are only as agile as your slowest limb
    • Agility is achieved stepwise across three fronts
    • Agile IT and networks in the decoupled model
    • Renewed need for orchestration that is dynamic
    • Enabling and monetising telco capabilities
    • Creating momentum for the agility flywheel
  • Recommendations and conclusions

NFV and OSS: Virtualization meets reality

Introduction: New virtual network, same old OSS

The relationship between NFV and OSS

This report discusses the relationship between NFV (Network Functions Virtualization) and OSS (Operations Support Systems), and the difficulties that operators and the developer community are facing in migrating from legacy OSS to NFV-based methods for delivering and managing services.

OSS are essentially the software systems and applications that are used to deliver services and manage network resources and elements in legacy telecom networks – such as, to name but a few:

  • Service provisioning: designing and planning a new service, and deploying it to the network elements required to deliver it
  • Service fulfillment: in its broader definition, this corresponds to the ‘order-to-activation’ (O2A) process, i.e. the sequence of actions enabling a service order to be logged, resourced on the network, configured to the relevant network elements, and activated
  • Service assurance: group of processes involved in monitoring network performance and service quality, and in proactively preventing or retrospectively repairing defective performance or network faults
  • Inventory and network resource management: managing the physical and logical network assets and service resources; keeping track of their utilization, condition and availability to be allocated to new services or customers; and therefore, closely related to service fulfillment and assurance.

As these examples illustrate, OSS perform highly specific management functions tied to physical network equipment and components, or Physical Network Functions (PNFs). As part of the migration to NFV, many of these PNFs are now being replaced by Virtualized Network Functions (VNFs) and microservices. NFV is developing its own methods for managing VNFs, and for configuring, sequencing and resourcing them to create, deliver and manage services: so-called Management and Orchestration (MANO) frameworks.The MANO plays a critical role in delivering the expected benefits of NFV, in that it is designed to enable network functions, resources and services to be much more easily programmed, combined, modified and scaled than is possible with PNFs and with OSS that perform isolated functions or are assigned only to individual pieces of kit.The problem that operators are now confronting is that many existing OSS will need to be retained while networks are transitioning to NFV and MANO systems. This is for a number of reasons.

 

  • Executive Summary
  • Next Steps
  • Introduction: New virtual network, same old OSS
  • The relationship between NFV and OSS
  • Potential solutions and key ongoing problem areas
  • Conclusion: OSS may ultimately be going away – but not anytime soon
  • OSS-NFV interoperability: three approaches
  • OSS-NFV integration method Number 1: use the existing BSS / OSS to manage both legacy and virtualized services
  • OSS-NFV integration method number 2: Use a flexible combination of existing OSS for legacy infrastructure and services, and MANO systems for NFV
  • OSS-NFV integration method number 3: Replace the existing OSS altogether using a new MANO system
  • Three critical problem areas: service assurance, information models, and skills
  • 1. Closed-loop service fulfillment and assurance
  • 2. A Common Information Model (CIM)
  • 3. Skills, organization and processes

 

  • Figure 1: Classic TMN BSS / OSS framework
  • Figure 2: Telcos’ BSS / OSS strategy for NFV
  • Figure 3: Transition from BSS / OSS-driven to NFV-driven service management as proposed by Amdocs
  • Figure 4: NFV / SDN functions as modules within the Comarch OSS architecture
  • Figure 5: Closed-loop network capacity augmentation using Netscout virtual IP probes and a common data model
  • Figure 6: Service-driven OSS-MANO integration according to Amdocs
  • Figure 7: HPE’s model for OSS-MANO integration
  • Figure 8: BSS and OSS still out of scope in OSM 1.0
  • Figure 9: Subordination of OSS to the MANO system in Open-O
  • Figure 10: Vodafone Ocean platform architecture
  • Figure 11: Vodafone’s VPN+ PoC
  • Figure 12: Operators’ main concerns regarding NFV
  • Figure 13: Closed-loop service fulfillment and assurance
  • Figure 14: Relationship between Information Model and Data Models

The Devil’s Advocate: SDN / NFV can never work, and here’s why!

Introduction

The Advocatus Diaboli (Latin for Devil’s Advocate), was formerly an official position within the Catholic Church; one who “argued against the canonization (sainthood) of a candidate in order to uncover any character flaws or misrepresentation evidence favouring canonization”.

In common parlance, the term a “devil’s advocate” describes someone who, given a certain point of view, takes a position they do not necessarily agree with (or simply an alternative position from the accepted norm), for the sake of debate or to explore the thought further.

SDN / NFV runs into problems: a ‘devil’s advocate’ assessment

The telco industry’s drive toward Network Functions Virtualization (NFV) got going in a major way in 2014, with high expectations that the technology – along with its sister technology SDN (Software-Defined Networking ) – would revolutionize operators’ abilities to deliver innovative communications and digital services, and transform the ways in which these services can be purchased and consumed.

Unsurprisingly, as with so many of these ‘revolutions’, early optimism has now given way to the realization that full-scope NFV deployment will be complex, time-consuming and expensive. Meanwhile, it has become apparent that the technology may not transform telcos’ operations and financial fortunes as much as originally expected.

The following is a presentation of the case against SDN / NFV from the perspective of the ‘devil’s advocate’. It is a combination of the types of criticism that have been voiced in recent times, but taken to the extreme so as to represent a ‘damning’ indictment of the industry effort around these technologies. This is not the official view of STL Partners but rather an attempt to explore the limits of the skeptical position.

We will respond to each of the devil’s advocate’s arguments in turn in the second half of this report; and, in keeping with good analytical practice, we will endeavor to present a balanced synthesis at the end.

‘It’ll never work’: the devil’s advocate speaks

And here’s why:

1. Questionable financial and operational benefits:

Will NFV ever deliver any real cost savings or capacity gains? Operators that have launched NFV-based services have not yet provided any hard evidence that they have achieved notable reductions in their opex and capex on the basis of the technology, or any evidence that the data-carrying capacity, performance or flexibility of their networks have significantly improved.

Operators talk a good talk, but where is the actual financial and operating data that supports the NFV business case? Are they refusing to disclose the figures because they are in fact negative or inconclusive? And if this is so, how can we have any confidence that NFV and SDN will deliver anything like the long-term cost and performance benefits that have been touted for them?

 

  • Executive Summary
  • Introduction
  • SDN / NFV runs into problems: a ‘devil’s advocate’ assessment
  • ‘It’ll never work’: the devil’s advocate speaks
  • 1. Questionable financial and operational benefits
  • 2. Wasted investments and built-in obsolescence
  • 3. Depreciation losses
  • 4. Difficulties in testing and deploying
  • 5. Telco cloud or pie in the sky?
  • 6. Losing focus on competitors because of focusing on networks:
  • 7. Change the culture and get agile?
  • 8.It’s too complicated
  • The case for the defense
  • 1. Clear financial and operational benefits:
  • 2. Strong short-term investment and business case
  • 3. Different depreciation and valuation models apply to virtualized assets
  • 4. Short-term pain for long-term gains
  • 5. Don’t cloud your vision of the technological future
  • 6. Telcos can compete in the present while building the future
  • 7. Operators both can and must transform their culture and skills base to become more agile
  • 8. It may be complicated, but is that a reason not to attempt it
  • A balanced view of NFV: ‘making a virtual out of necessity’ without making NFV a virtue in itself