In this blog post, we extend our discussion on OSS that we commenced in the blog post “What is OSS (Operational Support System)”, where we provided an overview of OSS in general. In this post we take a step further by offering a brief historical overview of OSS and, more importantly, analyzing how OSS will evolve in the future with the Open Digital Architecture (ODA).
Traditional View of BSS and OSS
Until recently, the mainstream architecture of management functions in telecoms consisted of BSS and OSS. The main idea is viewing telecom’s management operations as consisting of front-office and back-office. The front-office includes activities and functions that are customer-facing, such as sales, customer interactions, customer care, and strategy.
These functions are generally supported by a set of applications belonging to the Business Support System (BSS).
On the other hand, the back-office is concerned with actions and functions that deal with providing customers with what they want and need.
The back-office is thus focused on fulfilling the promises made when the customer signs an agreement: providing services (fulfillment) and ensuring those services maintain their quality (assurance), among other things. This generally involves network and engineering-oriented functions and applications belonging to the Operations Support System (OSS).
Traditional view of OSS and BSS
This division of tasks ensures that the customer experiences a seamless and satisfying journey from the initial sale to ongoing service—or at least this is what the industry thought until recently, before problems with such a setup began accumulating. As we will see when we start discussing ODA, one of the major disadvantages is the lack of ability to quickly introduce new digital services, change the offering, and many other things.
The History of OSS
The traditional view of BSS/OSS architecture described in the previous section is the result of decades of development of technologies that supported daily network operations. This development was highly influenced by network technology itself, as well as the evolution of computing technology at the time.
The origins of OSS can be traced back to the public switched telephone network (PSTN) and plain old telephone service (POTS) provided in the 70s. At that time, the prevailing technology was analog telephony, backed by the then-modern technology of all-relay exchanges based on electromechanical switches called relays. Much of the operations were highly manual back then.
As the number of subscribers exploded, so did the complexity of operations, leading to a need to introduce at least some automation to help reduce complexity and operational costs.
The first shapes of what we today understand as OSS were founded in the 80s with the introduction of electronic relays and digital networks. For a long time, what is today known as OSS required highly customized solutions, with almost no interoperability capabilities among suppliers.
Many standardization organizations naturally attempted to introduce concepts and standards, with ISO (the International Organization for Standardization) being one of the first with its FCAPS (fault, configuration, accounting, performance, security) model introduced in recommendation ISO 10040.
In the late 80s, ITU-T started developing a new series of standards called the Telecommunications Management Network (TMN) series (M.3000 – M.3599, with over 80 different standards). In particular, ISO 10040’s FCAPS was incorporated and refined in ITU-T’s recommendation M.3400.
ITU-T made a considerable contribution to OSS resource assurance with definitions of alarm classification and management in general. ITU-T X.733 standard defines the Alarm Reporting Function that remains today the de facto standard for all fault management systems, including UMBOSS.
TM Forum (TeleManagement Forum) was established as an industry association in the late 80s and in the 90s introduced concepts that we recognize today as key elements of modern OSS, such as eTOM (enhanced Telecom Operations Map) and SID (Shared Information and Data Model).
In the 2000s, and especially in the 2010s, there was significant development of OSS that exploited IP-based connectivity to bring IP networks and OSS together. There was substantial development in supporting cloud networks, Network Function Virtualization (NFV), and Software-defined Networks (SDN). Finally, in the 2020s, we saw significant development of support for AI and 5G mobile networks.
All these standardization efforts and technological developments have significantly helped in bringing telecoms and the industry together, providing frameworks and vocabulary that helped telecoms and suppliers (vendors) work more efficiently in constructing viable OSS solutions for the last 20 years.
The Future of OSS: Open Digital Architecture (ODA)
In the late 2020s, with the emergence of new cloud and network technologies, AI, and other advanced innovations, as well as the evolving demands and expectations of today’s customers, it became clear that the traditional three-layer OSS/BSS architecture was inefficient and a new approach was necessary.
This new approach requires both cultural and technological shifts, adopting new business models and novel ways of interacting with customers, favoring interactions via chatbots and other non-human interfaces, and completely automated actions. Modern OSS/BSS needs much more flexibility and new methods for more efficient and standardized integration, embracing cloud-native architectures and Open APIs.
For this reason, TM Forum devised a brand-new, promising architecture called TM Forum ODA, which provides an improved customer experience, data transfer, and enhanced SLA. ODA embraces customer-centricity and service excellence as its main philosophy, driving the cultural shift. It also incorporates AI technologies, especially generative AI, thus facilitating the automation of actions that telecoms currently execute poorly.
The new approach enables the provisioning of digital services by having all the components of the new BSS/OSS working together. This innovative new approach already offers faster time to market, lower operating costs, vendor neutrality, scalability, flexibility, and improved interoperability compared to traditional BSS/OSS systems.
Explaining a complex concept like ODA in a blog post is nearly impossible, so we will limit ourselves to an explanation using two illustrative representations as presented in the following sections.
Introducing ODA by using the lifecycle representation
The intention of ODA is to set key design principles, language, standards, and methodologies for transforming traditional BSS/OSS systems into modern open, cloud-native, enterprise IT systems that can sustain the new business challenges of modern CSPs.
This is how ODA defines itself: "ODA is a living, breathing architecture blueprint, designed to support our [telecom, CSP] industry into the cloud-native era, setting the framework for CSPs to unlock growth, profitability, and deliver a cutting-edge customer experience.”
It is an agreement and collaborative effort of more than 50 of the world’s leading telecoms (CSPs) and technology vendors to drive industry-wide transformation through software-based, automated, intelligent networks.
ODA is an ever-developing concept. Teams of experts are continuously refining it to create the first viable framework covering all aspects of CSP business. However, it will continue to change as technology and markets evolve. Even though it is constantly evolving, it always follows two main objectives: openness and digital dexterity.
The figure below depicts the lifecycle representation of ODA. It is the view of building, enhancing, and operating BSS/OSS by emphasizing the need to satisfy constantly changing CSP business requirements. It emphasizes a very strong handshake of BSS/OSS with CSP’s core business!
The lifecycle is reflected in the constant translation of identified business needs into a set of processes, then information objects, and then technical components, their interactions, and finally deployment methodologies and the runtime environment.
Lifecycle representation of ODA
It is important to know that the bedrocks of ODA, and key elements of this particular representation, are the core frameworks of TM Forum: eTOM, SID, and Functional Framework. However, there are other frameworks that are being added and are ODA-centric.
ODA lifecycle representation starts with the Business quadrant. It is a suite of building blocks used to identify CSP’s business needs, build the repository of required business capabilities, and map them to the business processes of eTOM. This is a crucial step as it dictates all further BSS/OSS development and functionalities.
For instance, if a business does not want to support mobile services, then BSS/OSS will not include components supporting that business capability. But if they do, then this requirement will add to BSS/OSS complexity. To achieve this goal, the business quadrant introduces frameworks of Business Architecture and Business Capability Map.
Once identified, business processes and requirements are further mapped to information objects that need to be managed as well as the functionalities that need to be supported. This is part of the Information Systems quadrant. Of course, SID and Functional Framework are the key components here. However, the Information Systems quadrant also introduces the Functional Architecture—the framework that in itself represents a separate ODA representation.
The third quadrant is the Implementation quadrant, and it is about how you realize the functionalities and data models that stem from information models identified in the second quadrant. The quadrant introduces three frameworks: Technical Architecture & Components, REST Open APIs, and Data Models.
The focus of these three frameworks is on implementation patterns—the reusable technology artifacts called ODA Components. Frameworks focus on how Components are combined in the technical architecture, what data models should be in place, and how they all interact through Open APIs.
Currently, there are over 50 Open APIs defined, and new ones are constantly being evolved. The quadrant also provides numerous use cases that demonstrate how these concepts are used to build BSS/OSS applications.
The Deployment and Runtime quadrant provides a set of frameworks that are essential to operationalize the architecture built in the Implementation quadrant. It is a sort of guidance on how to bring enterprise architecture to the actual working software solution.
This quadrant contains Operations Frameworks that introduce guidance on how to transform operational processes to be ODA compliant and to support automation by use of AI. The quadrant provides the Reference Implementation that is yet another product of TM Forum that represents a fully functional instance of ODA to be used for development and testing.
Finally, the quadrant contains ODA Canvas—the actual instance of Kubernetes environment with extension and management application to be used by TM Forum members.
The lifecycle is very important to the industry to have the handshake between both the business part of the CSP and the technology part of the CSP. However, it also ensures that there is a handshake between those who build the technology and those who operate the technology. It helps understand how you bring ODA into CSP’s environment.
It is a billboard of the digital transformation that goes from business to technology and then back to business.
Introducing ODA by using Functional Architecture Representation
ODA Functional Architecture resides in the Information Systems quadrant and provides the best alternative to traditional three-layered BSS/OSS/Network architecture that lacks flexibility, modularity, and reusability. ODA embeds its modular, reusable components’ philosophy as its key value.
The Functional Architecture is the normative standard for grouping enterprise-level functions to support the implementation of next-generation BSS/OSS. It represents a single-page view of ODA functions grouped into six (6) ODA Function Blocks, each comprising different ODA functions. The following are simplified definitions of the six blocks.
- Engagement Management is a grouping of functions that handle all CSP’s interactions with customers, customer organizations, and users - the people.
- Party Management is a grouping of functions that relate to how CSP handles people and organizations (parties including partners) that are interacting with CSP through different processes. It identifies WHO and WHY it is interacting with the CSP, regardless of whether it is a customer, partner, or employee.
- Core Commerce Management is a grouping of functions that deal with the commercial aspects of delivering value to parties. It handles the WHAT part of value fulfillment. Therefore, it deals with commercial exchange, product offerings, catalogs, buying, selling, order handling, order capture, rating, billing, and business assurance.
- Production is a grouping of functions that are related to providing parties with the expected services. It deals with services and resources delivery and operation, the technical view of processes, resources, functions, and information. It provides the HOW part of providing value to parties.
- Intelligence Management is concerned with analytical processes that produce insights on business activity and functions that allow interaction with operational processes through intelligent automation.
- Decoupling & Integration function block can be regarded as a sort of messaging backend that allows software components in different functional blocks to interact directly with each other. This means that functions and services provided by ODA can be combined in a flexible way, without any restrictions that might be implied by the processes that originate in any specific block. This is clearly a completely new approach compared to traditional BSS/OSS architecture where you had to go through different layers to make such interaction possible.
Functional architecture representation of ODA
The functional grouping reveals the intentions of ODA’s designers, highlighting several interesting aspects. First, no business activities or processes are executed within the Engagement Management block; these activities occur within the Party and Core Commerce Management, Production, and Intelligence Management blocks.
Further investigation of the Engagement Management block shows that it represents the architecture’s front-end, while all other blocks essentially represent the back-end. It functions as a kind of viewport architecture.
Since the Decoupling & Integration allows all components to communicate directly, it is apparent that Engagement Management block functions cannot use Open APIs, as no CRUD actions are allowed, and CRUD is at the heart of Open APIs. For this reason, TM Forum develops specific APIs for the Engagement block to interact with the other functions.
Perhaps the most interesting perspective is the systems grouping view. In this context, systems are application elements (software applications) that deliver certain functionalities:
Systems grouping view of ODA
Engagement Management is comprised of Systems of Engagement. These are the user interaction systems based on fast evolving technologies and therefore must evolve in a quick and agile way to catch up the new customer experience trends, ergonomics and social networking.
On the other hand, Party Management, Core Commerce Management and Production hold processes, functions and data that require stability over time, but need ability to interact with the fast-evolving systems of Systems of Engagement.
Therefore, these blocks are considered Systems of Records as they need to maintain data records stability and integrity over time.
Similar to the Engagement Management, Intelligence Management also contains fast evolving systems, primarily due to use of technology that are on the fast track of evolution in terms of big data and artificial intelligence (AI). Therefore, these systems are separated into a separate group of Systems of Insights.
Of course, there is much to say about the ODA Functional Architecture, but in this post, we only introduced the very basic concepts. However, our readers can use the following TM Forum resources to further investigate the subject:
- IG1167 ODA Functional Architecture (v5.0 or above): Appendix A: ODA Implementation Scenarios, Appendix B: Mapping to Functional Framework
- GB1022 ODA Functional Architecture Guidebook (v1.1.0 or above)
- IG1167 ODA Functional Architecture Exploratory Report (v6.0.0 or above)
UMBOSS - Enhancing Your OSS
UMBOSS is an umbrella network and service assurance platform that directly addresses functionalities of assurance in OSS. Its numerous functions cover assurance tasks such as Resource and Network Performance Management, Resource Trouble Management, Service Quality and Performance Management, and Service Problem Management. It thus covers many functions of systems of records and systems of insights, as defined in the last section.
Have any questions? Want to learn more? Get in touch and let us know how we can help. Send us a message or book a demo today.
