By Dr. Mark H Mortensen & Liliane Offredo-Zreik, ACG Research

This is the third article of a four-part series, companions to 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 this article, and in the corresponding webinar, we describe how open-source integration tools and frameworks can be used to integrate existing and new systems for near-term benefits and pave the way to implementing the cloud-native architecture of the future.

Introduction

To realize the agility and velocity that have become imperatives in the market environment today, communications service providers (CSPs) must transform their service delivery and management infrastructure. This means that the systems that underpin their network and service operations must evolve. These are the operations support systems (OSS) that enable the operator to manage the network and the business support systems (BSS) that facilitate the management of the customer and overall business operations.

The modernization of the OSSs and BSSs is based on three pillars:

Figure 1. Pillars of OSS and BSS Modernization

The importance of integration in OSS and BSS modernization

The CSPs’ software infrastructure has typically evolved over many years, with new systems added to support each new service or technology as needed. The result is that even a small Tier 3 CSP may have hundreds of systems while a Tier 1 CSP can have as many as 1,500 different systems (often with multiple instances of each). Attempts to replace these systems with an end-to-end pre-integrated infrastructure all at once in the past have failed and have often led to business disruption. Therefore, it is recommended that operators proceed in incremental steps, with smaller, department-sized transformations, implemented in multi-phase projects. This iterative process, while optimal, has the inherent requirement to reintegrate systems as they are updated or replaced into the evolving OSS/BSS environment. This constant integration requirement highlights the need for a strong integration architecture that is cloud-native, distributed, microservices-based and containerized.

Modernizing OSS/BSS Integration Architectures

The traditional centralized enterprise service bus (ESB) architecture, on which CSPs relied for integrating systems until recently, is ill-suited to the dynamic integration environment that is essential in the market. Therefore, operators need to move to a modern, cloud-native one, based on a distributed architecture with open Application Programming Interfaces (API) and agile teams using new DevOps development methodologies.

Figure 2. Modern Agile Integration vs. Traditional Approach (Source: Red Hat)

Traditional architectures have centralized integrations into one large platform where integrations are controlled by the team that owns the ESB platform and that has the specialized expertise to operate it. Developing new applications against the platform typically required several attempts to get everything right. The entire integration platform had to be functional for anything to work, and failures of individual components could affect totally unrelated applications. This has resulted in very long cycles to introduce or modify services.

On the other hand, cloud and container-based architectures are developed completely differently. Monolithic applications are broken up into services designed to be small, reusable and loosely coupled to refactor the original application. A container runs one and only one service usually, allowing flexibility in deployment and scalability. Integration between services and applications is distributed among the exact elements where it is needed, no more but no less than is required. Applications and services interact with APIs and expect the services implementing each API to behave as documented without needing to know the implementation detail. Service developers implement their code using whichever language and framework that make sense (and comply with corporate standards). The technical requirements are simple: the service implements the API, no more and no less than documented, allowing the services to be developed and evolved separately with little to no overall system regression testing. This enables the organization to respond more quickly to changing business requirements and priorities and to implement innovative ideas more quickly and efficiently.

The distributed nature of the architecture in Figure 2 describes not only how a cloud native application can be architected, but also how multiple old and new systems can be integrated together in a modern architecture. The distributed services can be microservices or can be wrapped, containerized legacy systems integrated with the new microservices in an overall framework. The right side of Figure 2 shows the containerized elements of an application built with a cloud-native architecture. These services within the application can be newer microservices or legacy ones wrapped with APIs for integration into the overall framework.

Tools for Integrating Systems for OSS/BSS Modernization

CSPs can implement a modern integration architecture using the following set of open-source tools and platforms for the underlying technology:

Integrating microservices inside a new system: New, cloud-native software applications built on containerized microservices require an integration platform to provide the internal communications among microservices, data sources and network elements, whether virtual or physical. Excellent examples of a distributed, cloud-native integration platform are Red Hat Fuse, part of Red Hat Integration, and OpenShift Service Mesh for inter-microservices communication.

Integrating new systems into the existing OSS/BSS complex: To interface the new cloud-native systems with the existing systems, an API management platform is needed. Red Hat 3scale API Management and Red Hat OpenShift Service Mesh are examples of integration frameworks that underpin an API first approach. They provide API visibility and control, security, rate limits, analytics, API keys and a developer portal, allowing the overall management of internal and external APIs.

If the existing systems do not provide RESTful APIs in a service-oriented architecture, they need to be wrapped to provide the APIs. Red Hat AMQ, part of Red Hat Integration, is an Apache Kafka-based platform, providing messaging-as-a service and streams operators, as well as an HTTP bridge. It supports microservice applications, provides an efficient bridge to legacy systems, and enables large-scale solutions.

Integrating and federating legacy systems: Many legacy systems duplicate functions for different work groups and systems in the various organizations, geographies, business areas or network technologies. This often requires manual intervention during provisioning, trouble management or network management processes, resulting in delays and potential errors. Quick-hit integration and federation projects using event and message-based integration technologies bring near-term benefits. A good example is the federation of multiple inventory systems, which leads to reducing database discrepancies and to mitigating the need to access multiple systems. As another example, the synchronization of trouble ticketing systems allows the free flow of information and status among them and obviates the need for manual intervention, thus reducing costs and potential errors and improving customer satisfaction.

The computing infrastructure platform supports the software/container platform with OS, compute and storage resources, creating the right containers for the software with the right computing resources at the right location. It also manages the environment for the container creation and for the management of the API wrapped legacy systems and the new microservices. Red Hat OpenShift is a popular example of such an infrastructure platform.

Conclusion

CSPs’ need for agility and velocity to compete creates requirements for constant integration as the overall OSS/BSS environment evolves piece by piece, leading vendors, systems integrators, and CSPs themselves to adopt new open-source solutions for agile integration. Adopting API led design with new software development methodologies benefits developers with shorter development times and less testing, users with faster implementation of new features and functionality, and business owners with increased business agility. Adopting standard open-source platforms across the business provides a homogeneous technology base, allowing for faster, more reliable feature development at scale. Red Hat Integration and Red Hat OpenShift solutions are ideally suited to the iterative modernization journey for OSS and BSS.

[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.