Telecommunications organizations use Sparx EA for TM Forum Open Digital Architecture (ODA) component mapping, 5G network architecture documentation, BSS/OSS transformation programs, and digital services product architecture. The TM Forum ODA framework: with its 325+ standardized ODA Component model: provides the capability reference for telco enterprise architecture; Sparx EA is the modeling environment for implementing it in practice. BSS/OSS transformation is the dominant program type across the industry: rationalizing legacy stacks accumulated through decades of organic growth and acquisition against the clean ODA component architecture that digital services require.
Key Takeaways
TM Forum’s Open Digital Architecture defines a component model for telecommunications enterprise architecture: a standardized vocabulary of 325+ components organized into three layers:
In Sparx EA, ODA components are implemented through an MDG profile: each component type as a stereotyped element, with tagged values capturing ODA metadata (component ID, layer, functional block, ODA version), and relationship types representing ODA component interactions and dependencies.
eTOM (Business Process Framework) provides the process decomposition that ODA’s component model references for functional scope. The two frameworks are complementary: eTOM defines what business processes exist and how they relate; ODA defines the component architecture that implements them. In Sparx EA, eTOM process hierarchies and ODA component architectures coexist in the same repository: processes trace to the components that execute them, and component capability gaps are identifiable by finding eTOM processes with no supporting ODA component in the current-state portfolio.
This combined view is what BSS/OSS transformation programs need: not just a component inventory, but a process-to-component traceability map that shows where current systems support the processes they’re supposed to support, and where they don’t.
The core ODA use case in Sparx EA for any telco running a transformation program: map the existing BSS/OSS portfolio to ODA components. Every application: billing system, CRM, order management platform, service catalog, mediation engine: maps to the ODA component(s) it implements. The analysis output identifies:
ODA conformance certification requires organizations to show that a component implementation satisfies TM Forum’s Open API and functional requirements for that component. Sparx EA models serve as the conformance documentation artefact: API interface definitions in ArchiMate or UML, functional scope mapped to ODA component specifications, and traceability from ODA requirements to implementation evidence. Sparx Services configures this documentation structure as part of Connect or Amplify engagements for telcos pursuing ODA conformance.
3GPP’s 5G Core specification defines a service-based architecture (SBA) where network functions expose services over the Service-Based Interface (SBI) using HTTP/2 and JSON. The key network functions: AMF (Access and Mobility Management Function), SMF (Session Management Function), UPF (User Plane Function), PCF (Policy Control Function), NRF (Network Repository Function), UDM (Unified Data Management), AUSF (Authentication Server Function), and NSSF (Network Slice Selection Function).
In Sparx EA, 5GC network functions are modeled as ArchiMate Technology Service components or UML components: each with tagged values capturing 3GPP specification references, interface lists, and deployment configuration. The service-based interfaces (N1, N2, N3, N4, N6, N11, N12, etc.) are modeled as association relationships with tagged values for interface protocol, data format, and 3GPP TS reference.
This provides network architects and program managers a queryable model of the 5GC architecture: useful for capacity planning, vendor selection, configuration management, and integration design: rather than static diagram documentation that immediately becomes stale.
Radio Access Network (RAN) architecture documentation in Sparx EA covers the gNB (next-generation NodeB) decomposition: CU (Central Unit), DU (Distributed Unit), and RU (Radio Unit) in the disaggregated Open RAN model. Fronthaul, midhaul, and backhaul connectivity are modeled as technology infrastructure relationships. Edge computing architecture: Multi-access Edge Computing (MEC) host placement, edge application deployment patterns, and latency-sensitive service routing: extends the 5GC model to the network edge.
Network slicing defines multiple logical networks on shared physical infrastructure, each with specific QoS characteristics for different service types: eMBB (enhanced Mobile Broadband), URLLC (Ultra-Reliable Low Latency Communications), and mMTC (massive Machine Type Communications). In Sparx EA, network slices are modeled as architectural instances: each slice characterized by its service type, QoS parameters, supporting network function instances (S-NSSAI), and the use case it serves. This provides the architecture documentation for slice lifecycle management and SLA assurance.
BSS/OSS transformation is the dominant EA program type in telecommunications because legacy BSS stacks are the primary barrier to digital services delivery: and the primary source of operational cost inefficiency.
A typical Tier 1 telco’s BSS landscape: multiple billing systems (pre-paid, post-paid, convergent, wholesale) accumulated through acquisitions that were never consolidated, 3–5 CRM platforms serving different customer segments or geographies, order management systems layered on top of each other as product complexity outgrew each successive platform, and integration middleware connecting them in ways that no single team fully understands.
Sparx EA maps this landscape against ODA components, eTOM processes, and the proposed target architecture. The rationalization analysis identifies which systems can be retired, which must be replaced, which can serve as the foundation for the target state with modernization investment, and which dependencies between systems constrain the sequence of the transformation program.
OSS stacks: network management systems, service assurance platforms, fault management, performance management: have typically evolved more slowly than BSS, but face analogous rationalization challenges as 5G introduces software-defined networking principles that legacy OSS platforms were not designed for. The transition from monolithic OSS to cloud-native, microservice-based network management aligns to TM Forum’s ODA Intelligent Operation layer components. Sparx EA documents the current OSS topology and the target ODA-aligned architecture.
BSS/OSS transformation programs involve major vendor selection decisions: which platform to standardize on for convergent billing, which ODA-conformant product catalog to deploy, which order management solution can handle the complexity of the 5G service portfolio. Sparx EA supports vendor selection by maintaining the evaluation framework as an architecture artefact: capability requirements mapped to ODA components, conformance criteria, integration requirements, and the evaluation criteria matrix. The model becomes the structured input to the RFP process and the comparison framework for RFP responses.
Digital services: IoT connectivity, network slicing as a product, private 5G, edge computing services: require a product architecture that current BSS stacks were not designed to support. Product catalog design for these services in Sparx EA uses ODA’s product-service-resource decomposition: product offering → product specification → service specification → resource specification, with the technical layer mapped to 5GC network function instances and slice configurations. This architectural documentation is the design input for both the OSS/BSS systems that must implement the product and the operations teams that must support it.
The highest-value AI integration use case for telco EA programs: natural language queries against the ODA-mapped BSS/OSS architecture portfolio. “Which ODA Product Catalog components do we have, and which are covered by more than one application?” or “Which legacy billing systems have not been mapped to any ODA component and have no scheduled retirement date?” require custom reports or model-level access in a traditional Sparx EA environment. With EA GraphLink and Kernaro AI Hub, they become live queries available to transformation program leadership without requiring Sparx EA client access.
This is not aspirational: it requires the same upstream dependency as every other AI integration: an ODA-mapped portfolio with consistent MDG governance. EA GraphLink transforms what the repository contains; it cannot compensate for a repository that doesn’t contain clean, consistent data.
5G program architects working in Sparx EA repositories with full 5GC architecture documentation can use AI query interfaces for technical architecture support: “Which SMF instances serve the URLLC slice in the production deployment?” or “What are the documented N4 interfaces between the SMF and UPF in the target architecture?” The MCP (Model Context Protocol) tool integration that Sparx Services deploys for EA GraphLink supports Sparx EA client context: queries executed from within the EA modeling environment against the current model.
Telecommunications operators are inherently multi-jurisdiction: a European operator may have operations in 10+ countries with different data localization requirements. EA repository data describing network infrastructure, customer-facing systems, and operational capabilities may be subject to data localization requirements in specific operating jurisdictions. AI integration must account for where the repository data is processed, not just where it is stored.
Discover assesses data residency requirements across the operator’s jurisdictions as part of scoping the AI integration architecture. Azure OpenAI with region-specific data residency configuration, or Kernaro AI Hub on-premises, are the options that support multi-jurisdiction data residency requirements.
What is TM Forum ODA and how does it work with Sparx EA?
TM Forum Open Digital Architecture is the reference architecture framework for modern telecommunications enterprises: a component model of 325+ standardized components organized into Business Applications, Core Commerce Management, and Intelligent Operation layers. Each component represents a discrete, standardized capability with defined APIs (TM Forum Open APIs) and functional scope. In Sparx EA, ODA is implemented through an MDG profile that defines ODA component stereotypes, tagged values for ODA metadata, and relationship types for component interactions. The portfolio mapping exercise: mapping current BSS/OSS applications to ODA components: is the primary Sparx EA use case for ODA.
Can Sparx EA model 5G Core network functions?
Yes. 5GC network functions (AMF, SMF, UPF, PCF, NRF, UDM, AUSF, NSSF, and others) are modeled in Sparx EA as ArchiMate Technology Service components or UML components with 3GPP-specific tagged values. Service-based interfaces (SBI) and reference point interfaces (N interfaces) are modeled as association relationships with protocol and specification reference metadata. The model supports queries, configuration documentation, and integration design at the architecture level: complementing (not replacing) detailed engineering documentation in network management tools.
How do I map my BSS/OSS portfolio to TM Forum ODA components?
The mapping exercise follows a structured process: first, build a consistent application inventory in Sparx EA with MDG-governed application records; second, import or model the ODA component hierarchy; third, map each application to the ODA component(s) it implements using a defined relationship type and confidence-level tagged value; fourth, generate the gap and redundancy analysis from the mapped portfolio. Sparx Services helps this process as part of a Discover or Connect engagement, depending on whether the starting point is a baseline assessment or a full mapping implementation.
What is the difference between eTOM and ODA?
eTOM (enhanced Telecom Operations Map, now called Business Process Framework) defines the process hierarchy for telecommunications operations: the decomposition of telco business processes from Level 0 to Level 4. ODA defines the component architecture: the systems and capabilities that execute those processes. eTOM is process-oriented; ODA is architecture-oriented. In practice, ODA references eTOM as the source of functional scope for its components. Using both in Sparx EA provides process-to-component traceability: which processes are executed by which components, and which processes have no architectural support in the current portfolio.
Can I use SysML alongside ArchiMate for 5G network architecture in Sparx EA?
Yes. In complex 5G programs: particularly those involving detailed network function specification, interface definition at the signal/message level, or parametric modeling of QoS constraints: SysML provides the engineering precision that ArchiMate’s enterprise architecture notation lacks. The combination in a single Sparx EA repository, with traceability between ArchiMate architecture views and SysML engineering models, is the same pattern used in defense programs for DoDAF+SysML. Sparx EA’s native support for both notations in one repository makes this practical; the MDG governance challenge is the same: consistent cross-notation relationship types and traceability conventions.
How does Sparx EA help with vendor selection for BSS/OSS transformation?
Sparx EA maintains the vendor selection architecture as a structured model: ODA component requirements with conformance criteria mapped from TM Forum specifications, integration requirements defined against the existing BSS/OSS landscape, and an evaluation matrix framework that maps vendor RFP responses to requirements. This structured approach ensures vendor responses are evaluated against the same criteria, and that the selection decision is traceable to documented architectural requirements. The model then serves as the integration design input for the selected vendor’s implementation program.
What AI queries are most useful for telecom EA teams?
Portfolio-level queries during rationalization programs: coverage and redundancy analysis, retirement candidate identification, ODA conformance gap analysis. Architecture queries during 5G program planning: network function interface documentation, slice architecture retrieval, vendor integration requirement identification. Program management queries: which architectural decisions are documented vs. outstanding, which system migrations are blocking other program workstreams. These queries are most valuable when the BSS/OSS architecture is mapped to ODA with consistent MDG governance: the upstream quality dependency that Discover assesses and Deploy/Amplify establishes.
What does a Discover engagement cover for a telecommunications organization?
A telecom Discover engagement ($25K–$75K, typically 6–10 weeks) covers: BSS/OSS inventory completeness assessment, ODA component mapping baseline (what percentage of the portfolio is mapped, how consistently), eTOM process coverage analysis, 5G architecture documentation assessment (if applicable), AI integration feasibility study including data residency review across jurisdictions, MDG governance baseline against ODA profile requirements, and a prioritized recommendations report. The output scopes the Connect or Deploy engagement that follows.
Telecommunications EA programs involve ODA conformance, 5G architecture, and BSS/OSS transformation at a complexity level that generic EA architects cannot support. Sparx Services brings the TM Forum framework knowledge and the Sparx EA practice depth that telco programs require.
Discover ($25K–$75K): BSS/OSS portfolio baseline, ODA mapping assessment, AI integration feasibility scoped to your transformation program and data residency requirements.
Connect ($50K–$185K+): EA GraphLink with Kernaro AI Hub for NLQ against your ODA-mapped portfolio; MCP tool integration for 5G program architects.
Platform Support: Ongoing Sparx EA technical expertise: ODA MDG profile configuration, 5G architecture modeling, Pro Cloud Server deployment.
Start a Discover Conversation → | Platform Support → | Connect Engagement →
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.