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

BSS/OSS modernization — replacing or componentizing monolithic billing, order management, network inventory, and service fulfillment systems with cloud-native, microservices-based components — is the defining IT transformation program for telecoms operators this decade. 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 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.

Legacy platforms from vendors such as Amdocs, Comverse, CSG Systems, Netcracker, Ericsson, and Nokia 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 — the accumulated customization debt that makes every upgrade a major program eventually exceeds 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 (over 50 published specifications covering every major BSS/OSS function). Above all of this sits eTOM, the business process framework, where each process is realized by one or more ODA components.

The ODA domain model at a glance

ODA organizes components into seven domains. This is the decomposition the current-state mapping classifies against.

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.
• TechStatus — Current | Legacy | End-of-Life (with EOLDate where applicable).

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, e.g. TMF638 for Service Inventory Management), 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 (Amdocs, Comviva, Optiva, Ericsson, Nokia) or built as custom microservices where no commercial component meets requirements.

API conformance tracking

Open API conformance is one of the most important governance dimensions of ODA adoption. ODA without API conformance is ODA in name only — if components expose proprietary APIs rather than 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 surfaces 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).

OSS modernization: service orchestration and network automation

SONA architecture

The OSS side centers on SONA — Service Orchestration and Network Automation — through which the OSS drives automated service fulfillment and network lifecycle management. In the TM Forum context, SONA is implemented through the ODA Service Domain, specifically the Service Design and Creation (SDC) component 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 Catalogue 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, not buried in middleware configuration.

Frequently asked questions