Cloud-Native BSS/OSS Architecture: TM Forum ODA and Sparx EA in Practice

BSS/OSS modernization, the replacement or componentizing of monolithic billing, order management, network inventory, and service fulfillment systems with cloud-native, microservices-based components, is a defining IT transformation program for telecoms operators. TM Forum's Open Digital Architecture (ODA) provides the target: a component model with defined domain boundaries, standardized Open API interfaces, and a Canvas integration layer that makes the architecture composable.

ODA adoption without architecture governance produces the same fragmentation it was designed to prevent: vendors interpret components differently, API conformance is claimed but not verified, and the relationship between the target architecture and the existing landscape is never documented. Sparx EA is where the ODA governance layer is maintained.

The architect on this program has to show how the existing estate maps to ODA, which components and APIs are conformant, and what each migration wave delivers and retires. By hand, that is a stack of spreadsheets and slides that never agree with each other. AI-augmented, the architect decides the mapping rules, the conformance questions and the wave structure, and AI does the mechanics in the tool and the model. The skill that asks of the architect is judgment about what a correct mapping and a credible conformance claim look like, and the habit of checking the draft against both.

The BSS/OSS modernization imperative

Why monolithic BSS/OSS must be replaced

Telecoms BSS (Business Support Systems) and OSS (Operations Support Systems) are the software estate that runs telecoms operations. BSS covers commercial operations: product catalog, CRM, order management, billing, and customer care. OSS covers network operations: network inventory, service provisioning, fault and performance management, and orchestration.

Many legacy platforms were built as integrated monoliths. A billing system contains product logic; a provisioning system contains network inventory; CRM contains order management. These monoliths delivered vertical integration at the cost of horizontal composability. They work within their vertical but cannot easily join the cross-domain, event-driven, API-first architecture that cloud-native telecoms products require.

The business pressures forcing modernization are concrete:

• 5G product complexity: private networks, network slices, and Industry 4.0 connectivity need product catalogs and order management that handle service-level products with dynamic resource allocation. Monolithic catalogs designed for voice and data plans cannot, without massive customization debt.
• The API economy: operators increasingly expose network and service capabilities through APIs (via the NEF, via TM Forum Open APIs). Monolithic BSS was not designed to expose composable APIs.
• Time-to-market: new product launches in a monolith take months of customization and integration; ODA-compliant components introduce products by configuration, not custom code.
• Total cost of ownership: accumulated customization debt makes every upgrade a major program and can exceed the cost of replacement.

TM Forum Open Digital Architecture

TM Forum published ODA to give operators and vendors a shared architectural target. It defines a Component Model (a catalog of independently deployable ODA Components, each with a defined domain, scope, and capabilities, communicating through standardized Open APIs), a Domain Model (organizing components into functional domains), the Canvas Integration Layer (event-driven integration patterns, event streaming, API gateway, identity, observability, implemented as shared platform capabilities rather than a central bus), and the TM Forum Open APIs (published specifications covering the major BSS/OSS functions). Above all of this sits eTOM, the business process framework, where each process is realized by one or more ODA components.

A working domain classification

TM Forum has published ODA's functional decomposition in more than one form. The table is an illustrative classification that current-state mapping can use; align it to the ODA release your program follows.

A working domain classification

ODA domain	What it manages	Representative components
Customer	Customer lifecycle and interactions	Customer Management, Order Capture & Delivery, Problem Management, Bill Management, Party Interaction
Product	Product lifecycle	Product Catalog, Offering Qualification, Order Management, Inventory Management
Service	Service lifecycle	Service Catalog, Service Order Management, Service Problem & Quality, Service Design & Creation
Resource	Network and IT resources	Resource Catalog, Order, Inventory, Problem, Performance Management
Party	Customers, partners, suppliers	Party Management, Agreement Management, Party Role Management
Common Data	Shared data services	Document Management, Geographic Address Management, Appointment Management
Intelligence	Analytics and data services	Data Management, Analytics, AI Gateway

BSS transformation in Sparx EA

Current-state system mapping

The first architecture activity is mapping the current landscape to ODA domains. The assessment reveals which ODA components exist in rudimentary form in current monoliths, which are missing, and which ODA boundaries the current architecture violates. In Sparx EA, each current-state system is modeled as an ArchiMate Application Component with ODA MDG tagged values:

• ODA_Domain: the primary domain (Customer, Product, Service, Resource, Party, Common Data, Intelligence).
• ODA_Components: the specific components this system implements (multi-value).
• ODA_Coverage: assessed coverage (Full | Partial | Minimal | None).
• DeploymentModel: On-premises | Private Cloud | Public Cloud IaaS | SaaS.
• CloudNative: whether the system is natively cloud-architected or lifted-and-shifted.
• TransformationStatus: Retain | Replace | Componentize | Retire.

Lifecycle status, end-of-life dates and contract data are not typed into the repository. AI connects to the systems that already hold them and the model joins them to these components. The mapping surfaces duplications (two systems implementing the same component: say, two product catalogs), gaps (components with no implementation, such as a missing Service Design and Creation capability), and cross-domain violations (a billing system that also owns product catalog data).

Target ODA architecture

The target architecture uses TM Forum ODA MDG Technology component stereotypes:

«ODA-Component», the primary stereotype for ODA-compliant components. Tagged values: ODA_Domain, ODA_ComponentID (the TM Forum catalog reference), ODA_ComponentVersion, Vendor, ConformanceLevel (Specification Compliant | Compliant with Exceptions | In Progress | Not Assessed), CloudNative.

«TM-OpenAPI», applied to Application Interface elements representing Open API implementations. Tagged values: TMF_APIID (e.g. TMF622 for Product Ordering Management), TMF_APIVersion, ConformanceStatus (Certified | Compliant | In Development | Not Implemented), ConformanceRef.

«ODA-Canvas», applied to Application Services representing Canvas capabilities: Event Streaming, API Gateway, Identity and Access Management, Service Mesh, Observability.

The target diagram shows the ODA component set that replaces the monoliths, sourced from commercial vendors or built as custom microservices where no commercial component meets requirements.

API conformance tracking

Open API conformance is a central governance question in ODA adoption. If components expose proprietary APIs instead of Open APIs, the composability promise is not delivered. In Sparx EA, conformance is tracked through the «TM-OpenAPI» stereotype on Application Interface elements. Each target component has interfaces representing the Open APIs it must implement, and the ConformanceStatus tagged value records whether each is certified, compliant (self-declared), in development, or not yet implemented. The result is a queryable conformance picture, a grid of components against required TMF APIs, that shows which components have gaps and which are on track.

Migration roadmap

The roadmap is modeled in the ArchiMate Implementation and Migration layer as Work Packages, each representing a migration wave. Work Package tagged values connect the migration to the architecture: ODA_ComponentsDelivered, ODA_ComponentsRetired, eTOM_ProcessesEnabled (the eTOM Level 2 processes improved), APIConformanceTarget, and TransitionDependencies (prerequisite Work Packages).

Keeping the picture current

The modern way to report on the program is to leave wave status, spend and risk out of hand-edited tagged values. AI connects to the project and portfolio management, IT service management, governance, risk and compliance, and IT financial management systems, and the model stitches that data to the components and Work Packages. Dashboards in Prolaborate or Power BI then show the program as it stands. The effort is lower, the result is easier to maintain, and the insight is always current. The architect decides what the board needs to see and checks that the model underneath is right.

OSS modernization: service orchestration and network automation

Service orchestration architecture

The OSS side centers on service orchestration and network automation (often shortened to SONA), through which the OSS drives automated service fulfillment and network lifecycle management. In an ODA estate this sits in the service and resource components, including Service Design and Creation (SDC) and the orchestration capability. SDC manages the service catalog (what the network can deliver), the service design (how services compose from network resources), and the workflows that instantiate, modify, and terminate services. In Sparx EA, the SONA architecture is an Application-layer view connecting Service Catalog Management, Service Order Management, a Service Orchestration Engine (such as ONAP or Blue Planet), Resource Inventory Management, and Resource Order Management.

The OSS/BSS decoupling pattern

A key modernization pattern is decoupling BSS and OSS. In legacy architectures the two are tightly coupled: order management calls provisioning directly, billing queries inventory, customer care reaches network trouble tickets through point-to-point interfaces. That coupling makes both sides hard to replace independently. The Canvas provides the decoupling: BSS components publish order events to the Canvas; OSS components subscribe and act. A Customer Order event is processed into a Service Order event, which is processed into Resource Order events, each domain decoupled through the event chain. In Sparx EA, this is modeled with Application Event elements, Serving relationships from publishers to the Canvas, and Access relationships from the Canvas to subscribers, so the event-driven architecture is explicit in the model instead of buried in middleware configuration.

Frequently asked questions