ODA in a Box Exploring BSS Implementation in Standard Way with Low Cost

Imperative Demand of Meeting Complexity Issue

An obstacle to modernizing IT is lying in front of the Communication Service Providers (CSPs), especially CSPs in the emerging market. Most of the CSPs are haunted by the specter of the complexity of the ever-changing IT system.

The reason for this difficulty is not elusive. In today's fast-paced business environment, the CSPs face a unique set of challenges. They must constantly adapt to new technologies and customer demands while maintaining the reliability and security of their networks. One of the key challenges facing CSPs is the need to build and manage complex BSS (Business Support Systems) solutions that can support the ever-changing operations.

BSS products are critical to the success of CSPs. They provide the tools and processes required to manage customer relationships, revenue management, call centers, settlement, and many routine businesses. It can be a complex and time-consuming process to build and manage BSS. This is especially true for the operators in emerging markets, who may lack the integration and development capabilities to assemble the components as one system effectively.

In the beginning, this phenomenon may be faint or not so obvious that the IT designer does not look at it. Gradually this issue will burgeon and grow, and it becomes so notable that most of the IT investment will be absorbed in the system revamp or liquidation of technical debts. With rich experiences in scores of BSS projects, a principal can be concluded that the successful transformation should be based on the distinctly defined architecture and technical stack from the aspect of the business target.

Having a look at the cost of the BSS transformation project, the cost of integration is high, sometimes extremely astoundingly. The complexity of assembling the components has been acknowledged as a dilemma that cannot be bypassed in any way and imposes such heavy obstacles on the way of improving BSS efficiency.

Standardization via ODA Component

The ODA components are designed to meet the crucial ICT trend in this turning point. It has provided pragmatic pathways for the journey from maintaining monolithic, legacy software solutions, towards managing nimble, cloud-based capabilities that can be orchestrated using AI and open API. The key principles of ODA components have been followed effectively so the rich reusable component assets are now available to the CSPs and IT vendors. The ODA components have been built to allow lower cost of operation automation, flexible business models, multi-vendor compatibility, and ecosystem capable.

In BSS and OSS, ODA has made it possible the effective integration of multiple IT suppliers and systems integrators, and the integration with a legacy environment. Using a common language and standard approach for integration of new capabilities, CSP now can compete on a much larger stage, with the ability to integrate components developed outside. Since this new way of interacting with customers has become available, CSP is eager to embrace ODA and implement the telecom industry-level stack of ODA.

When the architecture is ready for implementation, the problem facing everyone is how this design can be done in a practicable way. It is comparatively easy to interpret the world and to conceive the theory, but the more imperative challenge will be the action of changing the world.

From Modularity to Dynamic Integration of BSS Architecture

Both modularity and dynamic integration are the initial principles of ODA. As is known to all, the purposes of ODA are multifold, including the modularity by applying microservice and more dynamic integration of the BSS stack.

The existing ODA component defines a language to accurately describe a component in terms of its functions, the information it acts upon, and other characteristics. It has evolved to the industry standard definitions for the key components.

Modularity and microservices principles have been applied to the construction of the components in the ODA. Microservice architecture is a design pattern used to build software systems composed of multiple reusable services that interact with each other to provide a business capability. These modular components are designed to be deployed independently, with design, build, test, and release isolation enabling continuous delivery and reduced time to market and time to value as change is isolated to a specific business function.

However, it is important to remember that modularity is not an end. The goal is to deliver end-to-end business availability, faster time to market, and greater flexibility so that future-proofing and flexible BSS architecture can accommodate new products and business models. Beyond this, the business demands will include reducing costs, increasing speed, and enhancing customer experience. This is the widely recognized principle of dynamic integration of ODA.

Collaboration of ODA Components (ODA-in-a-box)

Although some BSS solutions are following the ODA concepts internally today, they are still the occasional phenomenon in the ICT market. To fully realize the business requirement of multi-vendor solutions, the essential principle needs to be clarified that collaborative ODA component stack (i.e. ODA-in-a-box) to “glue” the individual components need to work as the prerequisite of the orchestrated business services.

A whole box of ODA components is integrated in a loose-coupled but business-oriented way. The simple integration between the two components has been regulated by the TM Forum Open API, but the more important thing is to guide how these components, as a whole body, can serve the ever-changing business.

The need for assembling differentiated operations is deeply rooted in the telecom industry. The different CSPs opt for different operation processes, operation modes, and market strategies, which, in some respects, contribute to the competitive advantages of each CSP.

The idea behind the “box” is to improve the current dilemma and adopt an approach to build BSS. This approach involves using a unified design to conceive and sketch the blueprint of the IT system with the necessary components, rather than relying on a random selection of some of them only when the business demand becomes so emergent that the involvement of a new module is imminently disposed of in the short term and in haste.

Delve into Box: Domain-oriented BSS Box

Let’s change the angle of the observation, the ODA box will play an important role in the vertical domain. Most of CSPs face B2B and B2C. In these two different but intertwined domains, most of the company executives and IT leaders are familiar with consumer business but may feel not so confident with enterprise-oriented business, at least they will hesitate when facing all kinds of various vertical industrial businesses.

Comparatively, it is easy for managers to elaborate the consumer-facing offerings, processes, devices, and even network capabilities. Different from the consumer market, the enterprise market is composed of distinctly different industries, such as Medicare, Transportation, Energy, Government, Education, Finance, and many other ramifications of the modern industry.

The telecoms operator’s role in the value chain is also changing – from connectivity provider to participant within, or orchestrator of, a platform or marketplace, to end-to-end solutions provider. Such complexity of this realm places certain obstacles for CSP to explore.

The complexity of B2B services imposes the relevant complexity in BSS which is rooted in its diversified and fragmented characteristics. A B2B BSS should cater to these different enterprise customer segments and business models. B2B market segments are a blend of the different sizes of enterprises –from SME to medium and large enterprises, multinational corporations, and the public sector. B2B BSS also needs to manage both “human” and “machine”.

Considering these factors, CSPs often build and invest in their IT system for the vertical enterprise market, such as IoT lines of business. This effort can be meaningful only when ODA components and standards are applied. Most CSPs prefer to see a comprehensive ODA stack (box) since their expectation is such an IT system will enable an overall suite of various enterprise services that can be sold to their vertical industrial customers.

ODA box design is meant to help CSP achieve such ODA-driven transformation and finally succeed in the advent of new network technology including AI, cloud, and IoT, when the amount of connectivity on the devices is going to expand dramatically. The distinct conclusion is a holistic picture of ODA components to build B2B BSS.

Maturity Measurement of Box:

Any proven methodology in practice can also be measured quantitatively. Inherited from previous TM Forum maturity design, a maturity model should be an often-adopted business tool that can be used to assess the IT system from a variety of dimensions. The intention is to provide a reference to improve the overall IT performance by improving the specific aspects within and across those dimensions.

Such a maturity model is often represented as a matrix, with major dimensions of the IT capabilities listed on the horizontal axis and levels of maturity on the horizontal axis. In the illustration, the individual cells contain various objects relevant to the intersection of the dimension of the maturity level, including the descriptions, definitions, criteria, issues, capabilities, and measurements.

Benefits: An ODA Component Box Suitable for Business Innovation

If the ODA-driven BSS as the planned “box” is implemented, it may bring a brand-new cloud-native architecture and promote the TM Forum ODA standards. With lower cost and technical barriers, CSPs can utilize standardized product capabilities featuring efficiency, agility, openness, intelligence, safety, and trustworthiness. This could be the approach to enable digital operations capabilities and provide flexible digital transformation paths for various customers.

Currently, CPSs are bravely moving from “telco” to “techco” and technical drivers of IT systems are emerging rapidly, such as cloud-native, AL/ML, omnichannel customer experience, vertical industrial scenario, and privacy protection. ODA-in-a-box layered architecture is also the foundation of many such innovation possibilities with pre-designed guidance. This holistic ODA implementation methodology for BSS will also be continuously developed and updated considering the everlasting practices.

Even CSPs only plan to reconstruct some non-core and non-real-time experience services, such as marketing or sales components. This type of transformation can still be made ODA-box-based following the layered approach and gradually piloted. CSPs could choose the necessary components and build the required capabilities in each “box layer”. The new services or components can be integrated with the legacy core modules through standard TM Forum APIs to ensure a coherent user experience. It is another proof of the extensibility and adaptability of the ODA-in-a-box idea.

To summarize the conclusion, the benefits of the ODA-in-a-box approach are clear. By adopting the “top-to-bottom” methodology, the CSPs can reduce the complexity of their BSS and improve their ability to respond to changing market conditions. This approach also helps to reduce the risk of vendor lock-in, as the solution consists of the ODA-compliant components so CSPs are not tied to a single vendor when making the technical decision on the architecture evolution.

Furthermore, the benefits of the ODA-in-a-box approach go beyond just reducing complexity. By adopting a holistic thought on BSS design, the CSPs can obtain their ability to innovate and respond to new market opportunities. This is because the business operations based on the components organized from the full BSS aspects are often more agile and responsive than purchasing one or several components. It can also empower CSPs with the tools and processes needed to launch new products and services quickly.

To fully realize the benefits of the ODA-in-a-box approach, the system architects still need to work closely with its component owners or the vendors with the aspiration of ODA-based architecture. This includes forging a common purpose in the team, including all the developers and participants of BSS components. It is also helpful to develop strong relationships with the vendors, share knowledge and expertise, and collaborate on the development of new products and services.

Looking forward, the ODA-in-a-box concept represents a new way of thinking about BSS transformation. Promoting openness and agility can help CPSs build and manage complex IT foundations and ecosystems more effectively. As the industry continues to evolve, this concept will play an increasingly important role in shaping the future of BSS. By embracing this approach, CSPs can unleash the potential of software applications to business agility and stay ahead of the competition.