Operations support systems and business support systems are being rewritten or refactored to cloud-native, microservices-based apps capable of running on hybrid cloud and multicloud computing and storage infrastructure. This is creating a new commercial cooperative development model between software vendors and CSPs that promises the long sought after fast, inexpensive customization to fit changing local operational needs.
Customization of the software systems that support the network, especially the business operational needs of communications service providers (CSPs), have long required customization that greatly increased the time and cost of initial implementation. This came about because the architecture of a business support systems (BSS) or operations support systems(OSS) had to be tightly controlled, with all the parts carefully created to fit together. Then, they needed to be tested together and delivered together. However, even more important in the current fast-changing business environment is that it also greatly slowed the evolution of the systems and their support for the new services as any changes in the software had ripple-through effects throughout the entire software system. This has hindered CSPs’ business experimentation and growth. The new cloud-native software architectures based on microservices that are becoming de facto requirements by CSPs are intrinsically broken up into a set of semi-independent software microservices that can be created, evolved, and run separately. This creates the possibility of a new business and operational model for cooperation between the vendors and CSPs that tackle these fundamental issues.
Cloud-Native Development Model
A simplified sketch of the cloud-native software development model is shown in Figure 1. The software is broken down architecturally into a set of microservices that are then developed separately (usually by small teams using agile processes). They each go through the development stages of Needs, Code, Test, Deliver and Support. They can be delivered and re-delivered separately since they are only loosely coupled using the principals of Service Oriented Architecture with defined APIs.
Figure 1: Basic Cloud-Native Development Process Model (Source: ACG Research, 2020)
With each microservice having a defined set of APIs, there is no reason that all the microservices must be developed by the vendor, as shown in Figure 2, where microservice A1 and D1 developed by the CSP are bound into a multicompany software deliverable, replacing the original ones (A & D) from the vendor.
Figure 2: Cooperative Development Model (Source: ACG Research, 2020)
In use cases that have been shared privately with me by leading vendors, typically, the A1 and D1 microservices would be different algorithms (for example, a SON optimization algorithm for an RF network) or a user interface that fits the standards and desires of the CSP. Theoretically, there are no limitations to the mix-and-match of CSP and vendor-provided microservices. In general, I would expect that the vendor is most likely to provide the majority of the heavy lifting microservices in which they are expert.
Cloud-Native Run-Time Model
The multicloud nature of cloud-native software also admits the possibility that the vendor’s software could run on one cloud and the CSP’s software on another cloud, effectively allowing the vendor to offer the functionality of its microservices-based software as a service. A typical arrangement might include:
- Data stored on a private cloud if particularly sensitive or require by regulations,
- Massive data collection (telemetry data from a network) collected on-premises or in MEC arrangements from existing physical network elements,
- Vendor-provided applications run on a public cloud, provided as a service,
- User interfaces run on a distributed cloud with multiple users accessing from many sites.
The transition of BSS and OSS systems to cloud-native software architecture is bringing many benefits to the speed, quality, cost, and agility of vendors. The emergence of cooperative development models, where CSPs develop some of their own microservices that are bound with those from a vendor represents a possible sea change in the way that OSS and BSS software is designed, built, delivered, and run.
 This is another example of the massive changes in the power structure of the telecoms market. See https://www.vanillaplus.com/2020/06/23/53410-software-eating-telecom-virtualisation-open-source-upending-entire-industry/ for a discussion of how open source and virtualization is changing the industry dynamics.
 If the APIs are exposed, it places some limitations on the changes to those APIs. This is not a decision to be taken lightly by a vendor. The use of an API gateway can help the situation. It provides the normal security and logging capabilities that are used for external APIs as well as proxy services that help isolate changes to the APIs even more than the cloud-native, microservices-based architecture intrinsically provides.
 There are, however, some major issues in mixing and matching microservices from multiple sources. The necessity of the same or compatible data models is the stickiest issue among a list of others. These issues will severely limit the ability of CSPs to mix-and-match microservices from multiple vendors.
 The first example I saw of this was a vendor who supported recording conversations between a customer service representative and a customer. The capability was offered as a service to vendors of overall customer care systems.