TM Forum ODA Architecture
TM Forum Open Digital Architecture (ODA)
The Open Digital Architecture (ODA) is TM Forum's blueprint for how modern telcos should structure their IT systems. It is not a product or a platform — it is a reference architecture that defines what components a telco needs, what APIs they expose, and how they interact. ODA exists because the industry recognised that without a shared architectural language, every telco transformation was reinventing the wheel.
ODA matters because it provides the only industry-wide, vendor-neutral standard for decomposing BSS/OSS into interoperable components. Whether you are selecting vendors, defining integration contracts, or planning a transformation roadmap, ODA is the shared vocabulary that makes collaboration possible.
TM Forum ODA Component Architecture — Functional domains with key components and API integration
What ODA Defines
ODA is a multi-layered framework that defines three interconnected concerns: what components a telco needs, how they communicate, and how they are managed. These three concerns map to the three pillars of ODA.
ODA vs Traditional BSS/OSS Architecture
ODA vs Traditional Architecture
| Aspect | Traditional BSS/OSS | ODA-Based Architecture |
|---|---|---|
| Component boundaries | Vendor-defined, varies by product | Standardised by TM Forum, vendor-neutral |
| Integration | Custom point-to-point, proprietary APIs | TMF Open APIs, standardised event notifications |
| Vendor portability | Extremely difficult — deep coupling | Possible — components are replaceable if they conform to ODA specs |
| Architecture documentation | Vendor-specific, often incomplete | Standardised component specifications with clear responsibilities |
| Deployment model | On-premise, vendor-specific infrastructure | Cloud-native, container-based, Kubernetes-aligned |
| Lifecycle management | Manual upgrades, vendor-driven timelines | Canvas manages component lifecycle, continuous deployment |
ODA Functional Domains
ODA organises BSS/OSS capabilities into functional domains — logical groupings of related components. Each domain owns specific business capabilities and data entities. Understanding these domains is essential for mapping vendor products to ODA architecture.
Core Commerce Management
Core Commerce Components
| Component | ODA ID | Key APIs Exposed | Responsibility |
|---|---|---|---|
| Product Catalog Management | TMFC001 | TMF620 (Product Catalog) | Defines what can be sold: offerings, specifications, pricing, rules, lifecycle |
| Customer Management | TMFC020 | TMF629 (Customer Mgmt), TMF632 (Party) | Manages customer lifecycle: creation, updates, identity, accounts |
| Product Ordering | TMFC002 | TMF622 (Product Ordering) | Captures, validates, and orchestrates commercial orders |
| Product Inventory | TMFC005 | TMF637 (Product Inventory) | Tracks what each customer currently has: active subscriptions and services |
| Billing & Revenue Mgmt | TMFC010 | TMF678 (Customer Bill) | Calculates charges, produces invoices, manages payments and collections |
| Sales Management | TMFC025 | TMF648 (Quote Mgmt) | Manages sales pipeline, quoting, contract management |
Production Management
Production Components
| Component | ODA ID | Key APIs Exposed | Responsibility |
|---|---|---|---|
| Service Catalog Management | TMFC030 | TMF633 (Service Catalog) | Defines service specifications: CFS and RFS, decomposition rules, service templates |
| Service Order Management | TMFC031 | TMF641 (Service Ordering) | Orchestrates service-level fulfilment: CFS instantiation, RFS coordination |
| Service Inventory | TMFC033 | TMF638 (Service Inventory) | Tracks active service instances: state, configuration, relationships |
| Resource Catalog Management | TMFC040 | TMF634 (Resource Catalog) | Defines resource specifications: device types, logical resource templates |
| Resource Order Management | TMFC041 | TMF652 (Resource Ordering) | Orchestrates resource provisioning: allocation, configuration, activation |
| Resource Inventory | TMFC043 | TMF639 (Resource Inventory) | Tracks physical and logical resources: state, capacity, topology |
Party Management
- Party Management (TMFC020) — individual and organisation lifecycle, identity, contact details
- Party Role Management — customer, partner, supplier, employee roles assigned to parties
- Agreement Management — contracts, SLAs, partnership agreements linked to parties
- Party Privacy Management — GDPR and privacy compliance for party data
Engagement Management
- Digital Channel Management — self-service web and mobile applications
- Contact Centre Management — agent desktop, knowledge base, interaction history
- Partner Channel Management — wholesale and partner API gateways, partner portals
- Marketing Management — campaign management, next-best-offer, promotions
The ODA Canvas
The ODA Canvas is the runtime environment that hosts and manages ODA Components. Think of it as the "platform" that provides cross-cutting services — things that every component needs but should not build individually.
If ODA Components are apps, the ODA Canvas is the smartphone operating system. The Canvas provides the runtime, the app store (component deployment), security (authentication), and communication (inter-component messaging). Components focus on their business logic; the Canvas handles everything else.
The Canvas provides these cross-cutting capabilities to all hosted components:
- Component Lifecycle Management — deploy, upgrade, rollback, scale, and retire components
- API Gateway & Routing — route API calls to the correct component instance, handle versioning
- Identity & Access Management — authenticate users, enforce role-based access, manage OAuth tokens
- Event Management — publish/subscribe event bus for inter-component communication (TMF688)
- Observability — distributed tracing, logging, metrics, health checks for all components
- Secret & Configuration Management — securely store and inject configuration and credentials
In practice, the ODA Canvas maps to a Kubernetes-based platform with additional telco-specific operators. TM Forum has released a reference implementation of the Canvas based on Kubernetes, Istio (service mesh), and custom Kubernetes operators that understand ODA Component specifications. The Canvas operators watch for ODA Component Custom Resources (CRDs), provision the necessary infrastructure (database, message queues, API routes), and manage the component lifecycle declaratively.
Key Canvas Kubernetes operators include: (1) Component Operator — reconciles ODA Component CRDs, manages deployments. (2) API Operator — exposes component APIs through the gateway, handles versioning. (3) Security Operator — integrates with identity providers, enforces mTLS. (4) Event Operator — connects components to the event backbone (Kafka, NATS).
ODA Component Specifications
Each ODA Component is formally specified in a Component Specification document maintained by TM Forum. These specifications define exactly what a component must do, what APIs it exposes, what APIs it consumes, and what events it publishes and subscribes to.
Anatomy of a Component Specification
ODA Component Specification Elements
| Element | Purpose | Example (Product Catalog Mgmt) |
|---|---|---|
| Component Name & ID | Unique identifier for the component | TMFC001 — Product Catalog Management |
| Functional Block | Which ODA domain this component belongs to | Core Commerce Management |
| Core Function | Primary business capability | Manage product offerings, specifications, and pricing rules |
| Exposed APIs | TMF APIs the component must expose to other components | TMF620 (Product Catalog), TMF637 (Product Inventory) |
| Consumed APIs | TMF APIs the component calls from other components | TMF633 (Service Catalog), TMF632 (Party Management) |
| Published Events | Events the component emits when state changes | ProductOfferingCreateEvent, ProductOfferingStateChangeEvent |
| Subscribed Events | Events the component listens to from other components | ServiceCatalogChangeEvent (to validate product-service links) |
| Management APIs | APIs for component lifecycle (health, metrics) | Health check, readiness probe, metrics endpoint |
Mapping ODA to BSS/OSS Systems
ODA defines abstract components, but real deployments use vendor products. The mapping between ODA components and vendor products is many-to-many: one vendor product may implement multiple ODA components, and one ODA component may be split across multiple vendor products.
A single vendor product often implements multiple ODA components. This is normal and expected — vendors bundle related functionality.
| Vendor Product | ODA Components Covered |
|---|---|
| Cerillion Enterprise BSS | TMFC001 (Catalog), TMFC002 (Ordering), TMFC005 (Product Inventory), TMFC010 (Billing), TMFC020 (Customer) |
| Comarch BSS Suite | TMFC001 (Catalog), TMFC002 (Ordering), TMFC005 (Product Inventory), TMFC010 (Billing), TMFC020 (Customer) |
| Ericsson Catalog Manager | TMFC001 (Product Catalog), TMFC030 (Service Catalog), TMFC040 (Resource Catalog) |
ODA Compliance & Certification
TM Forum runs a formal ODA compliance and certification programme. Vendors submit their products for assessment against ODA Component specifications. This certification provides operators with confidence that vendor products will interoperate at the API level.
Levels of ODA Compliance
ODA Certification Levels
| Level | Requirement | What It Means |
|---|---|---|
| Level 1 — Self-Assessment | Vendor self-declares TMF API conformance | Lowest bar — vendor claims compliance, no independent verification |
| Level 2 — API Conformance | APIs pass TM Forum CTK (Conformance Test Kit) automated testing | APIs conform to TMF spec. Does not validate behaviour or component scope. |
| Level 3 — Component Conformance | Full component assessment against ODA Component specification | Highest bar — component covers specified functionality, APIs, events, and behaviour |
ODA-Certified Vendors (Selected)
Several vendors have achieved ODA certification for specific components. The TM Forum maintains a public directory of certified components. Notable examples include:
- Ericsson — multiple components certified, strong alignment with ODA Canvas reference implementation
- Tecnotree — early adopter of ODA certification, several commerce components certified
- Amdocs — selected components certified, ongoing certification programme
- Netcracker — SOM and inventory components undergoing certification
- Comarch — catalog and ordering components in certification pipeline
ODA in Practice: Realistic Expectations
ODA is a powerful architectural framework, but it is important to set realistic expectations about where the industry stands today. Full ODA adoption is still aspirational for most operators.
Even without full ODA adoption, the framework provides immediate value: (1) a shared vocabulary for discussing BSS/OSS architecture with vendors, (2) a component map for understanding what functional blocks you need, and (3) standardised APIs (TMF Open APIs) that reduce custom integration effort.
- ODA Canvas — reference implementation exists but production-grade Canvas deployments are rare. Most operators use Kubernetes + custom integration.
- Event standardisation — TMF688 defines event management, but standardised event schemas across all components are still evolving.
- Cross-vendor interoperability — API conformance is tested per-component, not across multi-vendor deployments. Real interop still requires integration effort.
- Non-functional requirements — ODA specs focus on functional scope. Performance, security, and operational concerns are left to implementation.
A pragmatic ODA adoption strategy for a Tier-1 operator: (1) Use ODA Component specs as the reference model for architecture decomposition — even if you do not use the Canvas. (2) Require vendors to expose TMF Open APIs as a contractual obligation, even for monolithic products. (3) Adopt the ODA Canvas incrementally — start with API gateway and event bus capabilities, then add lifecycle management. (4) Use ODA certification as a vendor evaluation criterion, not a pass/fail gate. (5) Invest in an integration team that understands ODA APIs and can mediate between vendors.
ODA Component Source-of-Record Map
Source-of-Record by ODA Component
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Offering | TMFC001 — Product Catalog Mgmt | CPQ, Sales Portal | COM, Billing, Digital Channels | All offering definitions originate here; consumers cache read-only copies |
| Customer / Party | TMFC020 — Customer Mgmt | CRM UI, Self-Service | Ordering, Billing, Service Mgmt | Golden record for customer identity; MDM integration common |
| Commercial Order | TMFC002 — Product Ordering | Digital Channels, Retail POS | Billing, CRM, Analytics | Owns order lifecycle from capture through completion |
| Product Subscription | TMFC005 — Product Inventory | Self-Service, CRM | Billing, Analytics | What the customer currently has; updated by order completion |
| Service Specification (CFS/RFS) | TMFC030 — Service Catalog Mgmt | Service Design UI | SOM, Product Catalog | Defines how services decompose; referenced during fulfillment |
| Service Instance | TMFC033 — Service Inventory | Service Management UI | Product Inventory, Billing, Assurance | Active CFS/RFS instances; created by SOM, managed over lifecycle |
| Resource Instance | TMFC043 — Resource Inventory | NOC Tools, NMS | Service Inventory, Capacity Planning | Physical and logical resources; updated by ROM and network discovery |
ODA and eTOM Alignment
ODA components map to eTOM process areas. Each component implements specific eTOM L2/L3 processes. This mapping ensures that ODA is not just a technology architecture — it is anchored in business process reality.
ODA Component to eTOM Process Mapping
| ODA Component | eTOM L1 Process Area | eTOM L2 Processes |
|---|---|---|
| TMFC001 — Product Catalog | Strategy & Commit (Product) | Product Lifecycle Management, Product Offering Management |
| TMFC002 — Product Ordering | Fulfilment | Order Handling, Order Validation, Order Tracking |
| TMFC010 — Billing | Billing & Revenue Mgmt | Bill Calculation, Bill Production, Collections |
| TMFC020 — Customer Mgmt | Customer Relationship Mgmt | Customer Data Management, Customer Interaction |
| TMFC031 — SOM | Fulfilment | Service Configuration & Activation, Service Provisioning |
| TMFC041 — ROM | Fulfilment | Resource Provisioning, Resource Configuration |
Section 8.2 Key Takeaways
- ODA is TM Forum's reference architecture for decomposing BSS/OSS into standardised, interoperable components
- The three ODA pillars are: Components (what), Canvas (runtime), and APIs (how they communicate)
- ODA defines four main functional domains: Core Commerce, Production, Party, and Engagement
- Each ODA Component has a formal specification defining exposed APIs, consumed APIs, published events, and subscribed events
- The ODA Canvas is the runtime platform — think "Kubernetes for telco IT" with component lifecycle management
- ODA certification has three levels; certification tests conformance, not real-world interoperability
- Most real deployments are hybrid: one BSS vendor for commerce, one OSS vendor for production, specialist vendors for gaps
- Pragmatic ODA adoption starts with using the component model as a reference and requiring TMF APIs from vendors