Vendor View

Modernization of OSS/BSS with Open Source, Part 4: Transforming OSS/BSS from Monoliths to Cloud-Native Applications

This article is sponsored by Red Hat

This is the final article of a four-part series, summarizing a set of four webinars[1]. In the first article, we describe how open-source software can speed the evolution of OSS and BSS to a modern cloud-native microservices-based architecture. In the second article we explain how open source can be used to automate business, network and IT to provide initial quick hits that rapidly bring value to a CSP and, eventually, lead to fully automated operations. In the third article, we describe how open-source integration tools and frameworks can be used to integrate existing and new systems for quick-hit benefits and serve as a basis of the cloud-native architecture of the future. In this article, we share with the developers of OSS/BSS systems, CSPs, ISVs, and SIs how they can move their current monolithic software systems toward modern, containerized cloud-native architectures and automate their overall IT operations.

Introduction

Communications service providers (CSPs) today are transforming into the digital service providers (DSPs) by digitizing their networks, operations and services (see Figure 1). Although these transformations are often parallel efforts, they should align around common business imperatives and should be tightly integrated. Open source is the proven underlying technology that can generate synergies across those transformation efforts.

Figure 1. Open Source Enables Digital Transformation

Becoming a DSP requires modernizing operations support systems (OSS) and business support systems (BSS). CSPs must work closely with independent software vendors (ISVs) and systems integrators (SIs) to move current OSS/BSS solutions to the cloud-native, common, open-software technology base of the future.

Cloud-Native OSS and BSS is the future

CSPs usually have hundreds, if not thousands, of OSS and BSS. Modernizing those systems should proceed in steps to mitigate business disruption and generate quick wins. ISVs and SIs must keep in lockstep with CSPs to provide the solutions and support they require. It is realistic to expect that some systems will be retired, some will continue in their monolithic form, and others will in some cases evolve to keep up with business imperatives. Still other systems will evolve along a stepwise trajectory and will ultimately become cloud based, or at least synergistic with a cloud-based environment. Figure 2 shows the alternatives for OSS and BSS evolution.

Figure 2. Transitioning to a Cloud-Based OSS and BSS

This transformation will likely be several years in the making. ACG projects that by 2025, approximately 10% of the systems will remain monolithic, while about 60% will be cloud-native based, with the remainder 30% being partially refactored.

OSS/BSS Modernization Strategies

CSPs that develop their own systems and ISVs and SIs that sell these systems to CSPs have a number of strategies to consider for modernizing them. Each approach has business and operational considerations and tradeoffs. Although these options are not unique to OSS and BSS, the level of complexity is compounded for them by the sheer number of such systems (which can reach into the thousands) interwoven at most CSPs.

Figure 3. OSS and BSS Modernization Alternatives

  • Rehost: Also referred to as lift and shift, involves repackaging the existing system and porting it to a new environment, typically a container, with minimal changes. Although this approach is the lowest risk, lowest cost option, it comes up short in delivering the true promise of a cloud-native system in terms of service velocity and elasticity.
  • Replatform: Also known as tinker and shift, requires a larger effort because it may necessitate software modifications to adapt to the operating system, to a portion of or the entirety of the application to optimize it before moving it to the cloud. Although this approach can be more costly and typically requires more time and effort, some cloud optimization can deliver meaningful benefits without the cost and risk of a full repurchase approach. Furthermore, by enabling the reuse of some of the existing resources, replatforming requires less retraining and fewer changes to methods and procedures.
  • Refactor: This approach entails making more significant changes to the application, but provides the most significant benefits, making it the preferred path in many cases. The degree of changes to the application code necessitates that the CSP ensures that this upgrade does not result in business disruption. But it also provides a good opportunity to modernize the existing operational framework, which may necessitate possible changes to the methods and procedures, as well as retraining. This approach can result in the application delivering the true benefits of a cloud-based environment in flexibility, velocity and elasticity. Re-factoring can also be taken in steps or can be done partially.

Given the significant benefits of fully cloud-native software combined with the agility and velocity derived from DevOps for operations and CI/CD, most applications should be refactored over time to reap those full benefits.

OSS/BSS Modernization and Overall Digital Transformation

The strategies recommended for modernizing the OSS and the BSS can also be used to modernize the other pillars of digital transformation: network resources and digital services. Modernizing all software infrastructure using the same underlying technologies and methodologies allows CSPs to migrate to cloud-based architectures and to enable consistent DevOps processes and CI/CD delivery methodologies across the CSP, maximizing their benefits and smoothing the way to digital transformation. The following are some examples of how these enable network and service modernization.

Modernizing network resource provisioning and automation

Until recently, network infrastructure was built using proprietary solutions that had software running on specialized hardware. This infrastructure needed to be created, managed, scaled, and decommissioned as the needs of the business changed. Because of its hardware foundation, it was subject to limitations similar to those we described for OSS and BSS, such as rigidity, long development cycles, and high cost. Today, Network Functions Virtualization network infrastructure is becoming software-based running on off-the-shelf hardware and becoming increasingly agnostic to the particular VMs and containers deployed. Since these virtualized network resources will be managed by the modernized, flexible OSS and BSS, it is essential that they too be implemented, scaled, and continuously audited for compliance with standard implementations using open source tools. They also should be automated for optimal allocation of network resources. Some of the tools that are best for these capabilities:

  • Red Hat OpenShift Container Platform for container selection, instantiation, and implementation of the necessary software for OSS, BSS and network resources.
  • Red Hat Ansible Automation Platform for automating the system configuration and the regular system compliance checks against corporate standards.
  • Red Hat Process Automation Manager, Red Hat Decision Manager and Red Hat Ansible Automation Platform, for task and process automation.
  • Red Hat Integration for a flexible, distributed approach to integrationand process automation.

Delivering digital services

The services of the future will be software-based. Virtual network functions, delivering software-based enterprise solutions, such as firewall and WAN optimization, are forecast to generate about $7 billion for service providers in 2023, and IoT services will serve both the consumer and business markets. These services require the agility and flexibility that only a software-based infrastructure can deliver. Because these services will be delivered and managed by the same infrastructures (OSS and BSS), it behooves the service provider to use the same underlying technologies and solutions to develop these services or to source them from vendors that have adopted open source as the foundational technology in their solutions.

Conclusion

The transformation of CSPs into DSPs requires multiple, coordinated transformations of the network (from hardware based to cloud-native software based), the operations (from people-based operations supported by OSS and BSS to automated operations using a containerized cloud native software platform), and digital services (provided by a cloud-native microservices-based architecture). Delivering all of these using modern DevOps and CI/CD processes helps achieve the business agility and cost structure critical to competing in the transformed environment. Although, in some cases, it is advantageous to start afresh with the new software architectures and development and delivery processes, it is not necessary. Multiple paths for moving from monolithic systems to cloud-native systems, based on open source, have been proven.

This transformation requires that the network, digital services, and operations processes be automated to the greatest extent possible. Current open-source software tools and platforms, again, have proven to match exactly what is required for this transformation.

The future of networks is open source.

[1] For the webinars, see:
Introduction to modernizing OSS/BSS with microservices-based, cloud-native architectures,
Automate OSS/BSS to drive innovation and reduce operating costs,
Agile integration for OSS/BSS flexibility, reusability and scale,
Transforming OSS/BSS from monoliths to cloud-native applications.

Tags: ,

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Polls

How important is the greenfield network deployment for Rakuten?

Loading ... Loading ...