Reducing risk and minimising transformation pain

When calculated risks are successful, revenue and customer loyalty increase, and C-level executives get big rewards. This TMF report looks at both sides of risk and assesses different options for transforming BSS based on potential risk and rewards. The good news for operators is that there are many options for transformation, and they can choose a path that best suits their existing support system environments.

Read this report to understand:

  • What the risks are in digital transformation and how to navigate them
  • Why edge computing could be a key part of telcos’ digital transformation strategies
  • How CSPs are using, digital BSS solutions to launch in new markets
  • Why using a microservices-based overlay can be a good strategy
  • Why best-of-breed solutions are making a comeback
  • How TM Forum’s Open Digital Architecture can help CSPs transition to cloud-based BSS

Ericsson under pressure to sell Iconectiv operations – report

Ericsson is reportedly under pressure from activist investors to sell OSS/BSS business unit Iconectiv, a deal which could be worth more than $1.5 billion.

According to Bloomberg, activist investor and Ericsson’s largest shareholder Cevian Capital is kicking up a fuss. Several new ideas have been presented to the management team, as well as demands to sell Iconectiv, a business unit which provides solutions for network and operations management, numbering, registry and fraud prevention.

Ericsson has said it would not be able to provide confirmation or comment for market rumours.

With 5G deployment plans being slowed in recent months thanks to the on-going COVID-19 pandemic, vendors are starting to feel the pinch. Although Asian radio equipment vendors seem to be surviving the slowdown, European rivals are seemingly under pressure.

Nokia recently said COVID-19 had a €200 million negative impact on the business, with revenues for the Networks unit down 6% year-on-year, while Ericsson reported a group revenue decline of 2%.

Ericsson CEO Börje Ekholm has put a brave face on the situation, and it did appear investors were rallying around the Swedish telecom infrastructure vendor. The divestment rumours would suggest otherwise, however.

While there has been a positive reaction from the financial markets following Ericsson’s most recent earnings call, share price has dropped 4% the weekend albeit there has been a minor recovery today (May 4).

Under Ekholm, Ericsson has been stripping back investments in areas which would be considered outside core competencies. Mobile telecoms infrastructure is front and centre of the business, which might please some of the more traditional investors who wear the scars of attempted diversification, but there is such a thing as going too far.

Such a move is certainly in-line with the slash and crash Ekholm strategy to double down on network infrastructure, but it still remains to be seen whether such a restrictive and finite approach to business is sustainable in the long-term.

Best of breed, not best of suite periodically invites third parties to share their views on the industry’s most pressing issues. In this article, Martin Morgan, VP Marketing, at Openet, looks at how the BSS market is evolving.

For all operators around the world, cost continues to be a big concern—whether that be the cost of 5G infrastructure, or the cost of maintaining or increasing their subscriber base. Any potential cost saving operators achieve can have a big impact on their overall profitability. This is forcing operators to rethink old ways of working. It is propelling operators towards a more open, collaborative way of working that is seeing smaller, independent network vendors displacing major NEPs. Change is happening across the entire network – in the core, in the RAN and in supporting OSS and BSS.

The emergence of open RAN is a key example of this change. The trend of operators embracing and deploying general-purpose, vendor-neutral RAN hardware and software is changing the game. Moving away from vendor-centric RAN solutions is presenting massive cost savings to operators—savings few can ignore.

As always, intelligent business practice means optimising all available efficiencies on offer to deliver maximum value to shareholders. Operators that innovate most expansively when it comes to new approaches will reap the benefits. The rise of network and digital transformation projects has encouraged operators to experiment and reinvent themselves. In many cases, this new culture of freedom and experimentation is at loggerheads with the agenda of the major NEPs. Open RAN is an example of this freedom to think and act differently and there is a similar trend taking place with BSS.

Putting the operator first

BSS has traditionally been made up of large, costly systems that are slow to move, and difficult to upgrade. These were often offered by large vendors, as part of mega contracts to deliver multiple solutions across an operator’s network. While this approach may have seemingly made the process of technology procurement more “convenient”, the reality is that it has also left operators with solutions that are incapable of keeping pace with market dynamics and meeting subscriber expectations. Luckily, the move to more open architecture and adjunct systems are overcoming these limitations and offering the speed and agility to evolve with new technologies, like 5G, and enable operators to launch and monetise new services in super quick time. Digital BSS now very much exists for operators to maximise the digital 5G age.

This new approach is changing how vendors view their operator customers, and how operators perceive their vendors. We’re seeing more and more vendors work together, as opposed to against each other, with different vendors bringing their best “assets” to the operator table. We’re also seeing the creation of multi-vendor ecosystems and environments within operator networks that encourage the open RAN principles of innovation, performance and standardization in a way that the traditional ‘best of suite’ approach simply didn’t.

So what’s changing for vendors? Well, quite simply, they’re having to focus on things that were once deemed less important, for example: quality, efficiency, and flexibility around integration. They’re now having to think about what operators want from them, rather than what they have to offer. We’re also seeing a push towards adopting open APIs and open architectures, that are helping operators drive lower integration costs for BSS software, lower cost to serve and reduce the length of development cycles.

What being open truly means

For operators, this move towards a new way of working is very good news. Today, more than ever, operators need to have the agility to deploy new services quickly and easily. The days of waiting for months for a new service, feature or offering to be deployed are now over. Operators need to be able to act fast and build new offers to react to changing consumer trends. Doing so will not only ensure they are able to monetise their current and future network assets, but can also play an important role in boosting subscriber engagement, preventing the operator from being seen as a utility or a “dumb pipe”.

Operators around the world are already reaping the rewards of embracing this open, agile way of working. For example, in Indonesia, leading operator Telkomsel built and launched an entirely new sub-brand targeting its growing Gen-Z population in just 18 weeks. Telkomsel built by.U using open digital APIs, open digital architectures and an ecosystem of vendors all working together to implement an end-to-end BSS suite. This kind of agility helps operators innovate quickly and react to changes and trends occurring across their subscriber base—in this case, Telkomsel knew it needed a new, different offering to appeal to a younger audience and for that a new brand was critical.

The fact that Open RAN and its principles are being applied to other parts of the network has many upsides for operators. What may have once been seen as a risky approach to deploying new technologies, may today be a safer alternative. In an open, multi-vendor environment, managed by an SI, an underperforming vendor can easily be swapped out without placing strain on the rest of the operation. This gives operators the freedom to choose and select who they work with and on what terms, and reduces the cost and headache associated with being stuck in lengthy impractical vendor-operator relationships.

Ultimately, this open collaborative approach is all about giving operators the right tools to become the digital providers of tomorrow.


Martin Morgan is the VP Marketing at Openet. With 30 years’ experience in mobile communications software, Martin has worked in mobile since the early days of the industry. He’s ran the marketing teams for several BSS companies and served on trade association and company boards. In that time, he’s spoken at over 50 telecoms conferences worldwide and had a similar number of articles published in the telecoms trade press and served on trade association and company boards. At Openet Martin is responsible for marketing thought leadership and market interaction.

Is your legacy charging system ready to monetize 5G? periodically invites expert third parties to share their views on the industry’s most pressing issues. In this piece Marc Price, CTO at Matrixx, looks at how operators need to adapt to cash in on the 5G era.

5G networks will change the way we live and experience the world, with nearly instantaneous speeds, new services such as Mixed Reality (MR), Augmented Reality (AR) and Virtual Reality (VR), and most importantly an expanding ecosystem of enterprise solutions, involving network services that can be scaled and right-sized for wholesale business-to-business-to-customer or enterprise (B2B2x) solutions.

Despite the hype, however, the first 5G services won’t arrive with much fanfare: changes will be rolled out slowly and some customers might not even notice the initial differences.

It might be tempting to think that 5G changes are incremental, and while major network investments are required, business systems won’t require big changes. Nothing could be further from the truth. In addition to changing our lives and habits, 5G will revolutionize business models for consumer devices, smart cities, factories, agriculture, and venues. Not only will 5G deliver a massive increase in the volume of transactions, it will involve a massive variety of transactions – which raises a fundamental question: how should customers be charged for these services?

Traditional telco billing/charging systems were built for a simpler world, where services are often measured in minutes and megabytes. What happens when new pricing schemes are needed for millions of users making small transactions with thousands of different services? How can service providers spur interactions and automate new functions harnessing rich analytics across a breadth of new network functions? If a charging system isn’t built for a 5G environment, it will fail in all these aspects, which means another year of flat revenue for communication service providers (CSPs) and a few more steps along the march toward being a dumb pipe.

5G Requires Cloud Natives – Not Cloud Tourists.

5G isn’t just another “bigger and faster” network. Yes, 5G networks will offer exceptional speed and scalability, but it’s not just a bigger bit pipe. The next generation network is positioned to empower CSPs as digital service providers, harnessing a flexible, automated, cloud-based architecture to launch new services quickly and employ the same web-scale efficiencies as digital leaders like Amazon, Facebook and Google. This requires a cloud native approach.

Cloud native is a specific set of architectural requirements defined by the Cloud Native Computing Foundation (CNCF) that includes the use of containers, microservices, dynamic orchestration, and the separation of stateful and stateless services, among other things. Updating an existing legacy solution to run in a virtualized environment is not cloud native. It would be more appropriate to call this a cloud tourist, as it can exist in a cloud environment, but isn’t adapted to it. Cloud tourists will still face many of the same performance and scalability limitations in a cloud environment as their non-virtualized counterparts.

Cloud native solutions are optimized for distributed environments, regardless of the platform infrastructure. Well-designed applications running in distributed systems are central to the promise of 5G and will enable an evolving ecosystem of massive new IoT devices, slices for enterprise and new business models.

Software solutions like these run natively in containers (e.g., Docker) with container orchestration (e.g., Kubernetes), are designed as loosely coupled microservices that use shared resources, use lightweight APIs to collaborate with other solutions, and handle elastic and resilient deployments as only a truly distributed and dependable architecture can.

Charging and Billing Must Be Cloud Native, Too.

5G is revolutionizing the kinds of digital transactions that will happen over many new emerging devices. These could be billions of tiny transactions from smart meters installed in our homes or in cities. Or they may be dozens of transactions processed through our smartphones as instant transactions or digital shopping carts. 5G will not only bring an increase in the volume of transactions; it will involve a massive variety of transactions.

Some 5G transactions will be stateless, such as “one and done” transactions like buying a movie. Other transactions will be stateful – for example, paying a per-minute charge for a live video chat with a healthcare professional. Some may require extremely low latency (e.g. virtual reality experiences), while others may need to be scaled up and torn down quickly (e.g. augmented reality services at a live event).

Because of the demands of differentiated services, 5G networks are fundamentally different by design. With 4G, monetizing the network means charging more for data and video services. In 5G, however, CSPs will need to be creative. They’ll need to slice their network to provide very different experiences for their customers: one slice for low-cost, high-latency IoT traffic, another slice for high-cost, low-latency emergency response services. In addition, CSPs will need to be able to create, deploy and tear down services quickly if they expect to create value in an ecosystem involving their agile, over-the-top (OTT), digital-native competitors.

Charging and billing systems must adapt to this new world. As new network slices are created, new billing and charging services will need to be created to support those slices. These charging services should be designed to scale up and down seamlessly, move out of the core network and into the network’s edge for lower latency, apply different policies for security and quality, and a myriad of other considerations. In short, charging and billing needs to behave like a cloud native so it can be easily integrated into and meet the performance requirements of 5G services.

Monetizing 5G Is Different by Design.

The business models for 5G will be radically different than those for 4G services. New services will be more immediate and transparent, providing incremental value via “networks on demand” and through tailored services, with nuance and scale not available in legacy networks. These distinctions will impact both enterprise and consumer pricing as 5G matures. In turn, solutions are needed that are ideally suited to support billions of stateful transactions at the scale and speed that 5G services require.

Design principles for 5G charging systems must evolve likewise, both with respect to application and database design. In order to understand why a new database may be needed for 5G scenarios, one must consider where other databases fail. To begin with, telecommunications networks are very different than most computer networks. For example, most networks can sustain some level of packet loss, re-sending the lost packets at a later point without losing the integrity of the session. Any kind of loss is intolerable in real-time revenue bearing networks, however.

Similarly, most computer networks consist of stateless transactions, in which the state of the session can be lost without impacting the transaction itself. A stateful transaction is a different story. It requires that the state of the session be maintained with resilience, so data is not lost when failures inevitably occur.

To ensure stateful transactions in a 5G world, one needs a database with exceptional elasticity and resilience. The majority of industry databases use eventual consistency or asynchronous replication, neither of which provides the accuracy or performance required. An option involves an all-master data store architecture allowing each transaction to be simultaneously committed to multiple masters. If a transaction does fail, it will still be maintained by other masters and may be accessed seamlessly to provide service continuity. 100% accuracy and near instant performance are both required when charging and billing 5G services in a modern environment.

5G charging systems should also harness the full power of open source tools from the Cloud Native Computing Foundation to achieve much greater scale in distributed systems. However, careful design choices must ensure both the performance and consistency of telco transactions in such an environment. Without this level of performance, the charging system cannot act as a reliable management service in 5G networks, coordinating millions of valuable transactions every minute, delivered instantaneously and seamlessly to customers, and enabling new streams of revenue for the operator.

5G’s Payoff Depends on More Than Just the Network.

5G offers a world of opportunity for CSPs, particularly in the way that network services will be created, deployed and most importantly, monetized. Where the revenue focus in the past has been on direct-to-consumer services and, to some extent, direct-to-enterprise services, a new revenue focus for 5G will ultimately be on B2B2x (consumer or enterprise) services. In this new landscape, CSPs will no longer simply be technology providers, but business partners that help other businesses innovate, create and deploy exciting new services.

A legacy billing and charging system has no place in a 5G network. It can slow down revenue streams, create frustrating customer experiences and ultimately compromise CSPs’ ability to compete with native digital service providers. To win in a 5G world, a cloud native charging system delivering scalability, performance and reliability is what CSPs need to successfully stand up and monetize new 5G services. It is a key investment that will pay off for years to come.


As Global Chief Technology Officer, Marc Price accelerates MATRIXX Software’s worldwide growth through key software and solutions delivery initiatives. He works closely with the MATRIXX executive leadership, engineering and product management teams to drive industry-leading technology into the market and spearheads strategic engagement with key customers and partners. With almost thirty years of experience in the telecommunications market, Marc has held pivotal roles during the establishment of the real-time charging model, the changing landscape of digital transformation and the move to hybrid clouds and IoT. Prior to joining MATRIXX, he worked for Openet serving as CTO for the Americas where he led initiatives for software development, systems consulting and business development.

Huawei makes a number of bold claims at MWC replacement event

Huawei released a string of new products at its MWC replacement event in London and claimed to be number one in every field.

At its product and solution launch event, dubbed “5G, Bring New Value”, Huawei unveiled a number of new products including a new chipset, an updated 5G core, new solutions for private networks and optical transmission, a new IP router, and a new software suite.

These products were launched one by one after Ryan Ding, Huawei’s President of Carrier Business Group, already unveiled the 64T64R Massive MIMO 5G base station during his keynote, when he reiterated the claim he made a year ago that Huawei enjoyed 18 months’ leadership over its competitors. When asked to substantiate the claim in a subsequent analyst briefing, Huawei simply said its leadership is in all technologies.

Similar claims, if not down to the specific number of months of its leadership, were repeated in the other product launches. After the new flagship base station and other 5G solutions (Blade AAU, 5G X-Haul for higher network slicing precision, a new optical module for ultra-broadband transmission) were introduced in more details by Yang Chaobin, Huawei’s 5G Product Line President, Henk Koopmans (pictured), CEO of Huawei’s R&D UK, took the stage to unveil the new 5G chipset, called 5G pre-module. It has a 2/3/4/5G-in-one baseband that will work on frequency bands from sub-6GHz to mmWave.

Huawei stressed the reference design that comes with it which will make it easier for Huawei’s customers to onboard the platform and design and make their products. What is puzzling is Koopmans’s claim that this chipset, on a 7nm process, is the world’s most advanced design, and is the world’s first to support both standalone (SA) and non-standalone (NSA) 5G modes, clearly undeterred by the fact that the new Qualcomm 5G chipset launched two days earlier does exactly that, and is designed on a 5nm process.

Huawei’s new private network solutions, called HiCampus, include LAN switch and fibre. It focuses on providing its customers with full wireless connectivity, full fibre, and full AI. The AI capability is highlighted in the context of fast detection of root causes for network errors. Huawei claims that over 85% of its customers’ network errors can be automatically resolved.

Other new products introduced at the event include Huawei’s new 5G core, with highlight on what it calls “deterministic networking” (including E2E network slicing, service & topology awareness, and resource orchestration); intelligent optical network solutions, called OptiX, to deliver enhanced experience for home use (especially supported by embedded AI) and private networks (with passive optical LAN); NetEngine 8000, Huawei’s new IP router for data communications which the company claims to be the world’s first to be able to deliver service level agreement (SLA) assurance. Huawei’s new billing system, called Huawei 5G CBS R20, was the final launch at the event. The company claimed that the billing system has achieved the first live 5G SA implementation, with STC Kuwait.

Another key theme that threads all the product launches at the event was Huawei’s stress on the “green” advantage of its new products, with different percentages of energy consumption reduction attached to the feature introductions. This is assumed to not only demonstrate the power consumption efficiency that can save OPEX for its customers, but also echo the message from the GSMA representative at the event that telecoms industry is the first sector to comply with the United Nations Sustainable Development Goals (SDGs).

The Path to Cloud-Native Applications

The cloud-native approach describes a way of modernizing existing applications and building new applications based on cloud principles, using services and adopting processes optimized for the agility and automation of cloud computing. This e-book describes detailed steps as a part of a successful journey from where you are today to adopting a cloud-native application approach.



What are the IT investment essentials for 5G monetisation? periodically invites expert third parties to share their views on the industry’s most pressing issues. In this piece Francesca Greane, Marketing, Content and Community Lead for 5G World 2020, reviews where service providers should be looking to invest for profitable 5G monetisation.

As communications service providers (CSPs) start to roll out 5G networks, they first face the challenge of figuring out how to go to market with new industry partners and business models.

Existing legacy IT systems that support traditional products are not designed for dynamic 5G service.

As a result, questions such as: What are the key use cases and services that will drive new revenue, and what IT capabilities are needed to support new 5G services are dominating the conversation. As a report by McKinsey put it, operators today are keenly aware that they have to increase their infrastructure investments in 5G technology; something that fills them with both anticipation and resignation.

The main question and source of contention is where these investments should lie.

To help guide the conversation, Ovum’s recent report – IT Essentials for 5G Monetisation – examines the market dynamics and areas of CSP IT investment for 5G monetisation. As the report discusses, many of the high-profile features of 5G such as multi-access edge computing and network slicing will not be immediately available. Instead, 5G network capabilities will arrive in three phases, the final phase beginning in 2022.

However, CSPs that have started deploying their 5G networks cannot afford to wait until the full capabilities of 5G are available to begin monetizing the network. CSPs will need to invest in upgrading revenue management systems so that they are able to charge and bill for 5G services, in policy control for quality of service (QoS) and network slices, and in customer management tools to improve the customer experience and create more opportunities for monetization.

The report also examines the full 5G ecosystem; looking towards the vendors with whom these CSPs will be looking to partner as they invest in their IT capabilities. The report thus outlines key recommendations for vendors, such as focusing on the impact of customer experience on monetisation, vendors are urged to demonstrate their cloud readiness and provide use case-guided transformation techniques, in order to secure new partnerships with these investing CSPs.

You can download the full report – and gain access to all of Ovum’s market recommendations and business-critical insights, by clicking here.

To gain more insights around where you should be investing for your 5G roadmap, claim your FREE ticket to 5G World 2020 (9-11 June, ExCel, London).

With access to three days of content from industry-leading speakers, networking opportunities and 5,000+ tech and telecoms professionals, and the opportunity to meet with hundreds of service providers looking to invest in a new partner, don’t miss out on claiming your free ticket now by clicking HERE.

What we talk about when we talk about digital transformation

Digital transformation is one of the core buzzwords used in the telecoms industry and beyond, right up there with 5G, cloud computing, and artificial intelligence. What sets digital transformation apart from the others is the sheer number of different things it can stand for.

Here we are sharing the opening section of this Intelligence special briefing to look into how the industry practitioners have undertaken the tasks of digitally transforming their businesses, what are the key success factors as well as the main obstacles to the success of these endeavours, and which approaches they prefer to adopt to tackle the challenges.

The full version of the report is available for free to download here.

In its broadest sense, digital transformation has been used in the socio-economic context by organisations like the United Nations. The 2019 Digital Strategy of United Nations Development Programme (“UNDP”) sees in digital transformation the pathways to the UN’s sustainable development goals. Although it heavily relies on the communications industry to help make the strategy happen, e.g. “digitally deliver policy and programme support”, UNDP’s strategy scope goes beyond that.

When it comes to the communications industry, digital transformation is often cited as an overarching theme to encapsulate all the telecom operators’ efforts to expand their role from mere connectivity provider to that of a digital service platform. However, there are so many components in such a context that one would likely get a different definition of digital transformation from every industry person one asked.

To start with, certain quarters of the industry, still occasionally conflate digitisation with digitalisation. It is therefore necessary to clarify the concept from outset. Digitisation refers to the change from analogue to digital. For example, the process can be called digitised when the application form to open a mobile account can be filled out on the computer instead of in paper form. Digitalisation refers to the change of processes, often focusing on automating previously manual processes, using digital technologies. In the example of opening a mobile account, the process can be viewed as digitalised when the whole application process is done online. Digitisation is therefore a prerequisite for digitalisation.

In the mobile telecoms world, digitisation was completed when 2G replaced (the retrospectively named) 1G networks. Digitalisation, on the other hand, is still an ongoing process and by all accounts will be with the industry for a long time, not the least because digital transformation is so much more complex than digitising the radio signal.

Despite that telecom operators may not agree with one another what digital transformation means to them individually, almost all of them agree collectively that they must undertake the transformation. This is both a strategic imperative and a competitive necessity. It is also widely agreed that the main objectives of digital transformation include:

  • To grow top line revenues as a way of sustaining the business, when the income growth from selling voice minutes, text messages, and data packages has stalled
  • To defend bottom line by improving operational efficiency
  • To develop technological and organisational capability to be more future ready

The following chapters of this report will look into the key steps the industry has taken and still needs to take, the major obstacles to overcome and the worst misunderstandings to dispel, to achieve digital transformation objectives. The discussion and analysis will draw heavily on the first-hand insight and experience from the practitioners.

Modernization of OSS/BSS with Open Source, Part 3: Integration

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.


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.


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.

Increase OSS and BSS efficiency with Red Hat agile integration

Disparate operations support systems (OSS) and business support systems (BSS) lack scalability and limit the value of network and application data. IT teams need federated access to legacy systems and data, while developers and partners need secure, easy access to systems.

An application programming interface (API)-centric approach to integration, secured via API management, addresses these issues for modern, containerized technology and application adoption. Exposing data and functionality using APIs supports reuse and modernization of legacy applications and systems, increases agility and scalability of internal and partner OSS and BSS systems, and reduces maintenance costs.

Red Hat’s API-centric agile integration solution for OSS and BSS processes and systems combines multivendor products with customer-owned systems. This Red Hat solution provides a single security framework that also supports TM Forum API specification standards and an automated, service-oriented approach.