Direct Answer
BSS/OSS modernisation — the replacement or componentisation of monolithic billing, order management, network inventory, and service fulfilment systems with cloud-native, microservices-based components — is the defining IT transformation programme for telecoms operators in 2025–2028. TM Forum’s Open Digital Architecture (ODA) provides the target architecture: a component model with defined domain boundaries, standardised Open API interfaces, and a Canvas integration layer that makes the architecture composable.
The challenge is that ODA adoption without EA governance produces the same fragmentation it was designed to prevent — different vendors interpret ODA components differently, API conformance is claimed but not verified, and the relationship between the target ODA architecture and the existing BSS/OSS landscape is never documented. Sparx EA is where the ODA governance layer is maintained: the current-state system inventory mapped to ODA domains (via tagged values), the target ODA architecture modeled with TM Forum MDG component stereotypes, API conformance tracked per component, and the migration roadmap connected to EA GraphLink for live programme governance in Power BI and Agentforce.
Key Takeaways
- TM Forum ODA is the target architecture for BSS/OSS modernisation — defined by component domain boundaries, Open API conformance requirements, and the Canvas Integration Layer.
- The ODA component model organises BSS/OSS into bounded domains: Customer, Product, Service, Resource, Party, Common Data, Intelligence — each domain contains a set of ODA components with defined API surfaces.
- Sparx EA governs the ODA architecture: current-state systems are mapped to ODA domains via tagged values; target-state architecture uses TM Forum ODA MDG component stereotypes.
- API conformance tracking — which TM Forum Open APIs each ODA component implements, at what conformance level — is a tagged value on each Application Component, queryable via EA GraphLink.
- EA GraphLink enables natural language queries via Agentforce or Copilot: “Which BSS components are cloud-native today versus target state?” answered from the live EA repository.
The BSS/OSS Modernisation 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 business operations. BSS covers the customer-facing and commercial operations: product catalogue, customer relationship management, order management, billing and revenue management, and customer care. OSS covers the network operations side: network inventory, service provisioning, fault management, performance management, and network orchestration.
Legacy BSS/OSS platforms — from vendors like Amdocs, Comverse, CSG Systems, Netcracker, Ericsson BSS, and Nokia OSS — 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 well within their vertical, but they cannot easily participate in the cross-domain, event-driven, API-first architecture that cloud-native telecoms products require.
The business pressures forcing modernisation are concrete:
5G product complexity — 5G enterprise products (private networks, network slices, Industry 4.0 connectivity) require product catalogue and order management systems that can handle complex, service-level products with dynamic resource allocation. Monolithic product catalogues designed for simple voice and data plans cannot support this complexity without massive customisation debt.
API economy — telecoms operators increasingly expose network and service capabilities through APIs to enterprise customers and third-party developers (via the NEF, via TM Forum Open APIs). Monolithic BSS systems cannot expose composable APIs — they were not designed for it.
Time-to-market — new product launches in a monolithic BSS require months of customisation, testing, and integration work across tightly coupled systems. Cloud-native, ODA-compliant BSS components can introduce new products by configuring composable components, not by customising monolithic code.
Total cost of ownership — maintaining aging, customised BSS monoliths is expensive. The cost of customisation debt — the accumulated modifications that make every upgrade a major programme — eventually exceeds the cost of replacement.
TM Forum Open Digital Architecture (ODA)
TM Forum published the ODA specification to provide a shared architectural target for telecoms operators and vendors. ODA defines:
The Component Model — a catalogue of ODA Components, each with a defined domain, scope, and set of exposed capabilities. Each ODA Component is a self-contained, independently deployable software unit that communicates with other components through standardised TM Forum Open API interfaces.
The Domain Model — ODA organises components into domains that correspond to the major functional areas of telecoms business and operations:
- Customer Domain — components managing the customer lifecycle: Customer Management, Customer Order Capture and Delivery, Customer Problem Management, Customer Bill Management, Party Interaction Management.
- Product Domain — components managing the product lifecycle: Product Catalogue Management, Product Offering Qualification, Product Order Management, Product Inventory Management.
- Service Domain — components managing service lifecycle: Service Catalogue Management, Service Order Management, Service Problem Management, Service Quality Management, Service Design and Creation.
- Resource Domain — components managing network and IT resources: Resource Catalogue Management, Resource Order Management, Resource Inventory Management, Resource Problem Management, Resource Performance Management.
- Party Domain — components managing parties (customers, partners, suppliers): Party Management, Agreement Management, Party Role Management.
- Common Data Domain — shared data services: Document Management, Geographic Address Management, Appointment Management.
- Intelligence Domain — analytics and AI components: Data Management, Analytics, AI Gateway.
The Canvas Integration Layer — the event-driven integration layer connecting ODA components. The Canvas is not a centralised bus — it is a set of integration patterns (event streaming, API gateway, identity, observability) implemented as shared platform capabilities. Components publish events and consume events from the Canvas, rather than calling each other directly.
TM Forum Open APIs — the standardised API specifications for each ODA Component’s exposed capabilities. TM Forum has published over 50 Open API specifications (the TMF Open API catalogue), covering every major BSS/OSS function. ODA component conformance requires implementing the relevant TM Forum Open APIs at a defined conformance level (Specification Compliant, Compliant with exceptions).
eTOM (enhanced Telecom Operations Map) — the business process framework that provides the process layer above the ODA component model. eTOM organises telecoms business processes into a hierarchy of process areas (Level 0: Strategy, Infrastructure, Operations, Enterprise), process groupings (Level 1), and individual processes (Level 2 and below). The eTOM process framework connects business process design to ODA component selection — each eTOM process is realised by one or more ODA components.
BSS Transformation in Sparx EA
Current-State System Mapping
The first architecture activity in a BSS transformation is mapping the current system landscape to ODA domains. This is the assessment that reveals: which ODA components exist in rudimentary form in the current monolithic systems, which are missing entirely, and which ODA boundaries are violated by the current architecture (systems that span multiple ODA domains).
In Sparx EA, each current-state BSS/OSS system is modeled as an ArchiMate Application Component with ODA MDG tagged values:
- ODA_Domain: The primary ODA domain this system operates in (Customer | Product | Service | Resource | Party | Common Data | Intelligence).
- ODA_Components: The specific ODA Components this system partially or wholly implements (multi-value, from the TM Forum ODA component catalogue).
- ODA_Coverage: The assessed coverage level (Full | Partial | Minimal | None).
- DeploymentModel: On-premises | Private Cloud | Public Cloud IaaS | SaaS.
- CloudNative: Boolean — whether this system is natively cloud-architected (containerised, Kubernetes-deployed, 12-factor compliant) or lifted-and-shifted.
- TransformationStatus: Retain | Replace | Componentise | Retire.
- TechStatus: Current | Legacy | End-of-Life (with
EOLDateif applicable).
The ODA domain mapping exercise reveals the current-state gaps and duplications:
- Duplications: Two or more systems partially implementing the same ODA component (e.g., two product catalogues — one for consumer products in the BSS, one for enterprise products in a separate CPQ tool).
- Gaps: ODA components with no current implementation (e.g., no dedicated Service Design and Creation component — SDC function currently performed by manual engineering workflows).
- Cross-domain violations: Systems that straddle ODA domain boundaries (e.g., a billing system that also owns product catalogue data).
Target ODA Architecture
The target ODA architecture in Sparx EA uses TM Forum ODA MDG component stereotypes to define the future BSS/OSS platform:
«ODA-Component» — the primary stereotype for all ODA-compliant software components in the target architecture. Tagged values: ODADomain, ODAComponentID (the TM Forum component catalogue reference, e.g., TMF638 for Service Inventory Management), ODA_ComponentVersion, Vendor (if a specific commercial product implements this component), ConformanceLevel (Specification Compliant | Compliant with Exceptions | In Progress | Not Assessed), CloudNative (boolean).
«TM-OpenAPI» — applied to Application Interface elements representing TM Forum Open API implementations. Tagged values: TMFAPIID (the TM Forum API reference, e.g., TMF622 for Product Ordering Management), TMFAPIVersion, ConformanceStatus (Certified | Compliant | In Development | Not Implemented), ConformanceRef (link to TM Forum conformance evidence).
«ODA-Canvas» — applied to Application Services representing the Canvas Integration Layer capabilities: Event Streaming Platform, API Gateway, Identity and Access Management, Service Mesh, Observability Platform.
The target architecture diagram shows the ODA component set that replaces the current monolithic systems — with components sourced from commercial vendors (Amdocs ODA-compliant stack, Comviva, Optiva, Ericsson Intelligent Automation Platform, Nokia Cloud Band) or built as custom microservices where no commercial ODA component meets requirements.
API Conformance Tracking
TM Forum Open API conformance is one of the most important governance dimensions of ODA adoption. ODA architecture without API conformance is ODA in name only — if each component exposes proprietary APIs rather than TM Forum Open APIs, the composability promise of ODA is not delivered.
In Sparx EA, API conformance is tracked through the «TM-OpenAPI» stereotype on Application Interface elements. Each ODA Component in the target architecture has a set of Application Interfaces representing the TM Forum Open APIs it is required to implement. The ConformanceStatus tagged value on each interface indicates whether the API is certified, compliant (self-declared), in development, or not yet implemented.
EA GraphLink queries the Application Interface tagged values to produce the API conformance tracker in Power BI: a table showing each ODA component, the TM Forum Open APIs it is required to implement, and the current conformance status of each. This view is the programme governance view for API conformance — surfacing which components have gaps and which are on track.
Migration Roadmap
The BSS/OSS migration roadmap is modeled in the ArchiMate Implementation and Migration layer as Work Packages. Each Work Package represents a migration wave — a set of ODA components being deployed and legacy systems being retired. Work Package tagged values connect the migration to the ODA architecture:
- ODA_ComponentsDelivered: The ODA components that become active when this Work Package completes.
- ODA_ComponentsRetired: The ODA components (in current monolithic systems) that are decommissioned.
- eTOM_ProcessesEnabled: The eTOM Level 2 processes that are enabled or improved by this Work Package.
- APIConformanceTarget: The TM Forum Open APIs that will be implemented in this Work Package.
- TransitionDependencies: The prerequisite Work Packages that must complete before this one can begin.
OSS Modernisation: Service Orchestration and Network Automation
SONA Architecture
The OSS side of the modernisation centres on SONA — Service Orchestration and Network Automation — the architecture through which the OSS drives automated service fulfilment and network lifecycle management.
SONA in the TM Forum context is implemented through the Service Domain of ODA: specifically the Service Design and Creation (SDC) component and the Service Orchestration and Automation capability. SDC manages the service catalogue (what services the network can deliver), the service design (how those services are composed from network resources), and the automation workflows that instantiate, modify, and terminate services.
In Sparx EA, the SONA architecture is modeled as an Application layer view showing:
- Service Catalogue Management (ODA Service Domain component) — the master catalogue of network services, connected to the Product Catalogue in the Product Domain.
- Service Order Management (ODA Service Domain) — processes service orders from the BSS, decomposing them into resource activation instructions.
- Service Orchestration Engine — the automation workflow engine (examples: OSM/ETSI MANO, ONAP, Ciena Blue Planet Orchestration) that implements the NSMF for 5G and the service activation workflows for fixed and optical services.
- Resource Inventory Management (ODA Resource Domain) — the source of truth for what network resources exist and their current state.
- Resource Order Management (ODA Resource Domain) — activates resource changes as instructed by the service orchestration layer.
The OSS/BSS Decoupling Pattern
A key modernisation pattern is the decoupling of BSS and OSS. In legacy architectures, BSS and OSS are tightly coupled — order management directly calls provisioning, billing queries network inventory, and customer care accesses network trouble tickets through direct point-to-point interfaces. This coupling makes both sides of the architecture difficult to replace independently.
The ODA Canvas Integration Layer provides the decoupling mechanism: BSS components publish order events to the Canvas; OSS components subscribe to those events and act on them. The BSS does not call the OSS directly — it produces a Customer Order event, which the Product Order Management component processes, which produces a Service Order event, which the Service Order Management component processes, which produces Resource Order events, which the Resource Order Management component activates. Each domain is decoupled through the event chain.
In Sparx EA, this decoupling pattern is modeled as Application Events (representing the event types flowing through the Canvas) with Serving relationships from the publishing component to the Canvas, and Access relationships from the Canvas to the subscribing components. The event-driven architecture is explicit in the model — not hidden in integration middleware configuration.
AI Value: EA GraphLink for Natural Language Architecture Queries
EA GraphLink’s MCP Server interface enables AI platforms — Agentforce, Microsoft Copilot, Claude Desktop — to query the Sparx EA BSS/OSS transformation model using natural language.
For a telecoms operator’s transformation programme, practical AI query examples include:
- “Which BSS components are cloud-native today versus target state?” — returns a breakdown from the
CloudNativeandTransformationStatustagged values across all ODA-mapped Application Components. - “Which TM Forum Open APIs have not yet reached conformance compliance in our target architecture?” — returns Application Interface elements where
ConformanceStatusis In Development or Not Implemented. - “What are the eTOM Level 2 processes that are not yet enabled by any delivered Work Package?” — cross-queries the eTOM process model against the Work Package
eTOM_ProcessesEnabledtagged values. - “Which legacy systems are still retained with no replacement Work Package scheduled?” — surfaces Application Components where
TransformationStatusis Retain but no delivering Work Package is linked. - “Show me all ODA components in the Customer Domain that are sourced from a single vendor” — identifies vendor concentration risk in the Customer Domain.
These queries are answered from the live Sparx EA repository — accurate as of the most recent architect update, without manual data extraction or report preparation. For programme steering committees and executive sponsors, this is the difference between knowing where the transformation stands and believing the last status report.
FAQ
Q1: What is the TM Forum ODA and how is it different from eTOM?
TM Forum ODA (Open Digital Architecture) is the software architecture framework — it defines what software components should exist in a telecoms operator’s BSS/OSS estate, what each component’s responsibilities are, and how they should communicate (via TM Forum Open APIs and the Canvas Integration Layer). eTOM (enhanced Telecom Operations Map, now TM Forum Business Process Framework) is the business process framework — it defines the business processes that a telecoms operator executes, from strategy and planning through to fulfilment, assurance, and billing. The two frameworks are complementary: eTOM defines what processes must be executed, ODA defines the software components that execute those processes. In Sparx EA, eTOM processes are modeled in the Business layer, ODA components are modeled in the Application layer, and the realisation relationships between them connect process to software — giving architects and business stakeholders a shared view of how the technology estate delivers business operations.
Q2: How do we start an ODA mapping exercise if we don’t have an existing architecture repository?
The ODA mapping exercise begins with the application inventory: a complete list of current BSS/OSS systems, with basic attributes (name, vendor, version, business function, hosting model). Sparx Services conducts this inventory through a structured workshop series with BSS/OSS system owners and IT, typically over two to three weeks. Once the inventory exists in Sparx EA as Application Components, the ODA domain mapping is applied through MDG tagged values — each system is classified against the ODA domain and component model. The resulting current-state picture (which ODA components are partially covered, which are missing, which are duplicated) is the architecture foundation for the vendor selection and migration planning that follows. Discover is the right engagement for this — starting from $25,000 for a focused ODA mapping and gap assessment.
Q3: Which commercial BSS/OSS vendors have ODA-compliant products?
TM Forum runs the ODA component conformance programme, through which vendors can certify specific product versions against ODA component specifications. Major vendors with ODA conformance certifications include: Amdocs (multiple ODA components across Customer, Product, and Service domains), Comviva (Customer Management components), Optiva (Product and Customer Billing components), Ericsson (multiple OSS and BSS components), Nokia (OSS components including Network Inventory and Service Management), and a growing ecosystem of cloud-native BSS vendors including Netcracker (NEC), CSG Systems, and Salesforce Industry Clouds (Communications Cloud for BSS). The TM Forum ODA component marketplace lists certified components. In Sparx EA, vendor conformance certification evidence is stored as tagged values on ODA Component elements — enabling the architecture to reflect the actual, verified conformance status of deployed components.
Q4: How does the Canvas Integration Layer work technically and how is it modeled?
The ODA Canvas Integration Layer is a set of platform services that ODA components use for communication and integration — rather than calling each other directly. The Canvas is not a single product; it is a pattern implemented using standard platform services: an Event Streaming Platform (Apache Kafka, AWS EventBridge, Azure Event Hubs, or similar), an API Gateway (for synchronous API-to-API calls where needed), an Identity and Access Management service (for OAuth 2.0 / OIDC-based component-to-component authentication), and an Observability Platform (for distributed tracing and monitoring). In Sparx EA, the Canvas is modeled as a set of ODA-Canvas Application Services (Event Streaming, API Gateway, IAM, Observability) that ODA Components access through Application Interface relationships. The event-driven communication pattern is modeled with Application Event elements representing the event types published by each component to the Canvas.
Q5: How does Sparx EA connect to Salesforce Communications Cloud or Microsoft Dynamics 365 for BSS?
Salesforce Communications Cloud and Microsoft Dynamics 365 Telecommunications are commercial BSS platforms that implement ODA components in the Customer and Product domains. In Sparx EA, these platforms are modeled as Application Components with «ODA-Component» stereotypes applied to the specific ODA components they implement (e.g., Salesforce Communications Cloud implements Customer Order Capture, Customer Problem Management, and Party Interaction Management components). The integration between these commercial BSS platforms and the OSS estate (typically running on telecoms-specific vendors) is documented through Application Interface relationships carrying the relevant TM Forum Open API identifiers. EA GraphLink connects the Sparx EA model to the operator’s Salesforce or Microsoft tenant — enabling architecture data to surface in Salesforce Agentforce or Microsoft Copilot for natural language programme governance queries.
Q6: What is the Service Design and Creation (SDC) domain and why is it architecturally significant?
Service Design and Creation (SDC) is the ODA Service domain component responsible for the design and lifecycle management of network services — from the service concept through to the service model that drives automated fulfilment. SDC is architecturally significant because it is the bridge between the commercial BSS (which sells products) and the OSS (which activates network resources). Without an SDC capability, operators must manually translate product orders into network activation instructions — a process that cannot scale to the service complexity of 5G enterprise products and network slices. In Sparx EA, SDC is modeled as an ODA Component in the Service Domain, with upward connections to the Product Catalogue (consuming product service specifications) and downward connections to the Service Orchestration Engine (producing service design templates that drive automated activation). The SDC architecture is typically the most complex modeling challenge in a BSS/OSS transformation because it requires connecting business, application, and technology layers.
Q7: How do we track TM Forum API conformance across a large transformation programme?
TM Forum publishes a conformance programme that allows vendors to certify product releases against specific API specifications. For operators, the practical conformance governance challenge is tracking which APIs are implemented (by which component release, from which vendor) versus which are planned, versus which have been waived. In Sparx EA, the conformance tracker is built from «TM-OpenAPI» Application Interface elements on each ODA Component, with ConformanceStatus and ConformanceRef tagged values. EA GraphLink queries this tagged value set to produce the API conformance dashboard in Power BI: a grid of ODA components versus required TMF APIs, with conformance status as the cell value. Red cells (Not Implemented) where conformance is contractually required surface immediately — without waiting for vendor milestones to be manually tracked in a programme plan.
Q8: What engagement does Sparx Services recommend for BSS/OSS modernisation?
Connect is the core engagement for BSS/OSS modernisation — it delivers the current-state ODA mapping, the target ODA architecture, the Canvas integration model, and the migration roadmap Work Packages, connected to Power BI and Agentforce via EA GraphLink for live programme governance. For operators that want to embed the transformation portfolio into Salesforce or Microsoft ecosystem tooling (Agentforce queries, Teams/Copilot architecture intelligence), the Connect engagement includes the Salesforce and Microsoft MCP Server configuration that makes the EA repository queryable by those AI platforms. For operators beginning from a low-maturity architecture documentation base, Discover ($25,000–$75,000) precedes Connect to establish the current-state inventory before ODA mapping begins. Connect pricing starts from $50,000, scaling with the breadth of the ODA component scope and the number of integration targets.
Work With Sparx Services
BSS/OSS transformation governance requires architecture that evolves with the programme — tracking ODA component adoption, API conformance, and migration progress as each wave delivers. Sparx Services’ Connect engagement builds your TM Forum ODA architecture in Sparx EA and connects it to Power BI and your Salesforce or Microsoft ecosystem via EA GraphLink — giving programme managers and executives real-time visibility of where your transformation stands, and giving your AI platforms the architecture intelligence to answer it on demand.
Connect from $50,000. Contact us to discuss your BSS/OSS transformation architecture.