The TM Forum ecosystem: ODA as the umbrella, with eTOM, SID, the Functional Framework and the Open APIs as its assets — and the Academy guides built on them.
TM Forum is the industry association where communications service providers and their suppliers agree how BSS and OSS should be described, structured and connected. Its frameworks cover business processes (eTOM — also called the Business Process Framework, BPF), information (SID), functions (the Functional Framework, formerly TAM — the older name the tables on this page still use) and interfaces (the Open APIs), and since 2019 it has published all of them under one reference architecture, the Open Digital Architecture (ODA). Most of what this Academy calls "the architecture" — Product / Service / Resource, CFS and RFS, COM / SOM / ROM, source of record — is TM Forum vocabulary.
It is a membership organisation: the framework assets (eTOM, SID, Functional Framework) need a membership to read in full, while the Open API specifications and the ODA Canvas are open source. It does not reach into the network — radio, transport and devices are 3GPP, ETSI and ITU-T territory — and it is not a standards body in the formal sense: its outputs are industry agreements, adopted because vendors and operators choose to, not because a regulator requires it.
TM Forum now presents ODA as four parts — Business Architecture, Information Systems, Implementation, Deployment & Runtime — with eTOM, SID, the Functional Framework and the Open APIs as assets inside them. Conceptual, per TM Forum's current ODA material.
The three framework assets, by document number
The TM Forum Framework Triad
Framework
Formal Name
Question It Answers
Published As
Business Process Framework (eTOM)
GB921
What processes does a CSP perform?
ODA (formerly Frameworx)
Information Framework (SID)
GB922
What data entities does a CSP manage?
ODA (formerly Frameworx)
Functional Framework (TAM)
GB929
What application capabilities does a CSP need?
ODA (formerly Frameworx)
Open Digital Architecture (ODA)
TM Forum·Reference architecture
Open Digital Architecture (ODA)
What is it?
TM Forum's reference architecture for BSS/OSS: a set of standard components with defined APIs, the Canvas they run on, and the business, information and functional frameworks that give the components their meaning. ODA is the umbrella under which eTOM, SID, the Functional Framework and the Open APIs are now published.
What problem does it solve?
Lets operators and vendors describe, buy and assemble BSS/OSS as interchangeable components instead of monoliths, so that a system can be replaced without redesigning everything it touches.
What does it cover?
•Business Architecture — value streams, the Capability Framework and the Process Framework (eTOM)
•Information Systems — the Functional Framework, Functional Architecture and the Information Framework (SID)
•Implementation — Open APIs, data models and ODA Components
•Deployment & Runtime — the ODA Canvas and how components are operated
What does it NOT cover?
•Not a vendor product or a prescriptive implementation blueprint.
•Does not say which components an operator should buy, or in what order to migrate.
•Does not cover the network itself — radio, transport and devices belong to 3GPP, ETSI and ITU-T.
ODA was created to solve a specific problem: telco stacks had become monolithic, tightly coupled, and vendor-locked. Replacing one component meant re-integrating everything around it. ODA provides a standardised way to decompose the stack into independent components with well-defined API boundaries.
The ODA Component Model
An ODA Component is a self-contained unit of business capability. Each component is defined by three things: (1) the business capability it implements (e.g. product ordering, service orchestration), (2) the Open APIs it exposes (e.g. TMF622 for ordering), and (3) the Open APIs it consumes from other components. If two components expose and consume the same APIs, they are interchangeable.
TM Forum's own ODA functional architecture names six blocks — Engagement Management, Party Management, Core Commerce Management, Production, Intelligence Management, and Decoupling & Integration. This Academy uses the COM / SOM / ROM layering as shorthand for the fulfilment chain that runs through Core Commerce Management and Production. The table below is that Academy mapping, not TM Forum's list.
Resource Order Management, Resource Inventory, Activation
Engagement Management
EM
Channel and partner management — digital channels, partner portals, API exposure
Channel Management, Partner Management, API Gateway
Intelligence Management
IM
Analytics, AI/ML, and data management — reporting, data lakes, recommendation engines
Analytics, Data Management, AI/ML Services
💡COM, SOM, ROM — the Core Triad
The COM → SOM → ROM chain is the architectural backbone of ODA. COM handles commercial intent (what the customer wants), SOM translates it into service-level actions (what services need to be created), and ROM executes at the resource level (what network elements need to be configured). This separation is what enables independent component replacement and best-of-breed stacking.
ODA Canvas
The ODA Canvas is the runtime platform that hosts ODA Components. Think of it as a telecom-aware extension of Kubernetes. While Kubernetes handles container orchestration, Canvas adds: (1) automatic API discovery and registration — when a component deploys, Canvas discovers its exposed APIs and makes them available to other components via NRF-style service discovery, (2) security policy enforcement — Canvas controls which components can call which APIs, (3) component lifecycle management — deploy, upgrade, scale, and decommission components with standardised lifecycle operations, and (4) observability integration — standardised logging, metrics, and tracing across all components.
⚠️Canvas Maturity
As of 2025, ODA Canvas is still maturing. Most operators run ODA Components on standard Kubernetes without a full Canvas implementation. The component model and API contracts deliver value even without Canvas — Canvas adds operational automation on top. Do not wait for Canvas maturity before adopting ODA component design principles.
ODA: Theory vs Brownfield Reality
ODA describes a target state. Most operators are not there. The gap between ODA theory and brownfield reality is where transformation programmes live:
No vendor fully implements ODA -- most vendors claim ODA alignment for specific components, but no single vendor delivers a complete ODA-compliant stack with all API contracts honoured
Legacy systems do not have ODA API boundaries -- wrapping legacy systems with TMF API facades creates a translation layer that often leaks abstraction (see Section 10.1 on conformance vs semantic interoperability)
Component boundaries are debated -- where does COM end and SOM begin? Different vendors draw the line differently, which means "ODA-compliant" components from two vendors may overlap or leave gaps
Data sovereignty across components is hard -- ODA assumes each component owns its data, but legacy stacks share databases. Splitting shared data into component-owned stores is a major migration challenge
Partial adoption is common and valid -- many operators adopt the ODA component model conceptually (clear COM/SOM/ROM boundaries, API-first integration) without deploying Canvas or achieving full conformance
💡ODA as a Design Principle, Not a Certification
The most practical value of ODA is as a design principle: define clear component boundaries, expose standardised APIs, and keep business logic inside domain components rather than in integration middleware. You can apply these principles today, on any stack, without waiting for ODA Canvas or vendor certification.
How ODA Relates to eTOM, SID, and TAM
ODA does not replace the other TM Forum frameworks — it builds on them:
ODA and the TM Forum Framework Stack
Framework
Role in ODA
Relationship
eTOM (Business Process Framework)
Defines the business capabilities that ODA Components implement
Each ODA Component maps to one or more eTOM process areas (e.g. COM maps to Fulfilment L2 processes)
SID (Information Framework)
Defines the data models that ODA Component APIs use
TMF Open API data models are derived from SID entities — this is what makes APIs interoperable
TAM (Functional Framework)
Defines the functional building blocks that ODA Components realise
TAM functions map to ODA Component capabilities — TAM is the "what", ODA is the "how"
Open APIs
Define the contracts between ODA Components
Every ODA Component exposes and consumes Open APIs — the APIs ARE the component boundaries
ODA in one breath
ODA is TM Forum's reference architecture for modular, API-first BSS/OSS — not a product or certification
ODA Components are defined by business capability + exposed APIs + consumed APIs
COM, SOM, and ROM are the core functional domains — their separation enables best-of-breed stacking
ODA Canvas extends Kubernetes with telecom-aware component lifecycle management, but is still maturing
No vendor fully implements ODA — partial adoption of the component model and API principles is the pragmatic path
ODA builds on eTOM (processes), SID (data models), TAM (functions), and Open APIs (contracts)
Business Process Framework (eTOM)
TM Forum·Business process framework
Business Process Framework (eTOM)
What is it?
A hierarchical classification of every process a communications service provider runs, from three Level 0 areas (Strategy, Infrastructure & Product; Operations; Enterprise Management) down through domains, process groupings and Level 3 tasks. It is the shared vocabulary for "what the business does".
What problem does it solve?
Gives business, IT and vendors one process map to point at, so that a requirement, a system, a KPI or a gap can be located unambiguously.
What does it cover?
•Process decomposition from Level 0 to Level 3 (Level 4 flows in some domains)
•The Operations vertical groupings: Fulfilment, Assurance, Billing & Revenue Management, plus Operations Support & Readiness
•Horizontal domains: Market/Sales, Product, Customer, Service, Resource, Business Partner, Enterprise
•End-to-end process flows such as Lead-to-Cash and Trouble-to-Resolve, assembled from its elements
What does it NOT cover?
•Not an application architecture or a system inventory.
•Does not prescribe how a process is implemented, sequenced or automated.
•Does not define data — that is the Information Framework (SID).
Where does it fit?
BusinessBSSOSSOperationsTransformation
When would an architect use this?
•Process analysis and as-is / to-be mapping
•Capability mapping and scoping a transformation programme
•Locating where a vendor product actually sits, by the processes it supports
•Defining KPIs against a process the whole organisation recognises
The Business Process Framework, historically known as the enhanced Telecom Operations Map (eTOM), is the most widely adopted process framework in telecommunications. Published as GB921, it provides a standardised vocabulary and hierarchical structure for describing every process a CSP performs — from strategic planning to network fault resolution.
Think of the BPF as the blueprint for how a telco operates. It does not prescribe implementation details or specific technologies. Instead, it defines what processes exist, how they relate to each other, and where boundaries should fall between different operational domains.
📖Business Process Framework (BPF / eTOM)
A comprehensive, industry-standard business process framework (TM Forum GB921) that defines all the enterprise processes required by a communications service provider. The BPF is hierarchically decomposed across Levels 0-4, with Level 2 being the most architecturally relevant for system mapping and vendor evaluation.
The BPF matters because it solves one of the biggest challenges in telco IT: everyone uses different names for the same things. When a CRM vendor says "order management," they may mean something very different from what an OSS vendor means. The BPF provides the shared language that eliminates this ambiguity.
BPF Decomposition Levels
The BPF is organised as a hierarchical decomposition of processes, starting from the broadest categories and drilling down to individual process activities:
BPF Decomposition Levels
Level
Name
Description
Example
Level 0
Process Areas
Three top-level groupings that divide all CSP activity
Operations
Level 1
Process Groupings
Major functional groupings within each area
Fulfilment
Level 2
Process Flows
End-to-end processes that deliver specific outcomes
Order Handling
Level 3
Process Tasks
Individual tasks within a process flow
Validate Order
Level 4
Process Steps
Detailed steps within a task (often implementation-specific)
Check Credit Limit
Most architectural discussions and vendor evaluations focus on Level 2 processes, as these represent the actionable process capabilities that can be mapped to systems. Levels 3 and 4 are typically defined during implementation and vary by organisation.
eTOM Framework — Level 0 and Level 1 Process Areas
The Business Process Framework at Level 0 and Level 1, showing the three major process areas and their primary process groupings
The Three Major Process Areas (Level 0)
The BPF divides all CSP activity into three process areas — fundamentally different modes of operation with different timescales and stakeholders. For BSS/OSS, Operations is where you spend 80% of your time.
Selling, delivering, and maintaining services — fulfilment, assurance, billing
Real-time to daily
Enterprise Management (EM)
"Support"
HR, finance, legal, IT management — standard corporate functions (ERP, not BSS/OSS)
Ongoing
Operations: The Vertical Process Groupings
Operations is structured as a matrix: vertical groupings (what you are doing) crossed with horizontal layers (CRM, SM&O, RM&O, Supplier/Partner). The three verticals represent the major operational outcomes:
Operations Vertical Process Groupings
Vertical
Purpose
Key Processes
Fulfilment
Deliver what the customer ordered
Order Handling, Service Configuration & Activation, Resource Provisioning, Service/Resource Testing
Assurance
Keep what was delivered working
Problem Handling, Service Quality Management, Resource Trouble Management, Performance Management
Imagine a restaurant: Fulfilment is taking orders and preparing food. Assurance is checking that the food is good and handling complaints. Billing is presenting the bill and taking payment. The horizontals are like different staff: the waiter (CRM), the chef (SM&O), and the kitchen equipment (RM&O).
Each cell in the BPF grid maps to one or more system capabilities. For example, "Order Handling" at the CRM layer maps to the Commercial Order Management (COM) system. "Service Configuration & Activation" at the SM&O layer maps to the Service Order Management (SOM) system. This grid is the foundation for process-to-system mapping.
The horizontal layers also correspond to TM Forum SID domains: CRM maps to Party/Customer SID entities, SM&O maps to Service SID entities, and RM&O maps to Resource SID entities.
In TM Forum ODA (Open Digital Architecture), each BPF Level 2 process maps to an ODA functional block. The COM functional block implements CRM-layer fulfilment processes. The SOM functional block implements SM&O-layer fulfilment processes. This mapping is catalogued in the ODA Component Directory.
ODA Canvas deployment maps BPF Level 2 processes to specific microservices or components, each exposing TM Forum Open APIs. This is how the Business Process Framework translates from a process model into an implementable architecture.
Information Framework (SID)
TM Forum·Information / data model
Information Framework (SID)
What is it?
A shared information model for the telecom business: the entities (Customer, Product, Service, Resource, Party and so on), their attributes and the relationships between them, organised into the same domains as eTOM. The Product / Service / Resource split that runs through this Academy comes from here.
What problem does it solve?
Stops every system inventing its own meaning of "customer" or "service", so that data can flow between systems and be reconciled when it does not.
What does it cover?
•Business entity definitions across the Market/Sales, Product, Customer, Service, Resource, Engaged Party, Enterprise and Common Business Entities domains
•The Aggregate Business Entities that group them (ProductOffering, ProductSpecification, CustomerFacingService, ResourceFacingService…)
•Relationships and inheritance between entities — the basis of catalog decomposition
•The vocabulary the Open APIs' payloads are built from
What does it NOT cover?
•Not a physical database schema.
•Does not define processes or which system owns each entity — that is a design decision the model leaves open.
•Does not dictate a canonical message format; the Open APIs do that in practice.
Where does it fit?
InformationBSSOSSData
When would an architect use this?
•Information modelling for a catalog, inventory or integration layer
•Defining source-of-record ownership per entity
•Data migration and reconciliation — agreeing what a record means before moving it
•Reviewing whether a vendor's data model can be mapped without loss
The Shared Information/Data Model (SID), published as GB922, is the TM Forum's Information Framework. SID defines the canonical data entities that flow between processes and applications. While BPF says what you do and TAM says what applications you need, SID says what data those applications must share.
📖Shared Information/Data Model (SID / GB922)
A comprehensive information model that defines all the data entities, attributes, and relationships required by a CSP. SID is organised into domains (Party, Customer, Product, Service, Resource, etc.) and provides the canonical data definitions that underpin TM Forum Open APIs.
BPF Process to SID Entity Mapping
BPF Process
Key SID Entities
Direction
Order Handling
ProductOrder, Customer, ProductOffering
Consumes ProductOffering, Creates ProductOrder
Service Configuration & Activation
ServiceOrder, CustomerFacingService
Consumes ProductOrder, Creates ServiceOrder
Resource Provisioning
ResourceOrder, LogicalResource, PhysicalResource
Consumes ServiceOrder, Creates ResourceOrder
Problem Handling
TroubleTicket, Customer, Service
Creates TroubleTicket, References Service
Billing & Collections
CustomerBill, AppliedCustomerBillingRate
Consumes usage, Creates CustomerBill
💡Process-Data-Function Alignment
When designing integrations, check all three frameworks: the BPF process flow (what happens), the TAM application function (what system is responsible), and the SID data model (what data crosses the boundary). If any of the three is misaligned, your integration will be fragile.
Functional Framework (formerly TAM)
TM Forum·Functional framework
Functional Framework (formerly TAM)
What is it?
A map of the functions BSS/OSS systems must provide — catalog management, order handling, inventory, billing, assurance and the rest — grouped into functional domains, independent of any product. Known for years as the Telecom Application Map (TAM); TM Forum now publishes it as the Functional Framework within ODA's Information Systems.
What problem does it solve?
Gives a product-neutral checklist of functions, so that portfolios can be rationalised and vendors compared by what they do rather than what they are called.
The material below was written when TM Forum called this the Telecom Application Map (TAM), and the industry still says TAM. TM Forum now publishes it as the Functional Framework inside ODA's Information Systems. Same thing; read TAM as Functional Framework throughout.
The Telecom Application Map (TAM), published as GB929, is the TM Forum's Functional Framework. While the BPF defines what processes a CSP performs, TAM defines what application functions are needed to support those processes. TAM is the bridge between process architecture and system architecture.
📖Telecom Application Map (TAM / GB929)
A standardised map of application functions required by a communications service provider. TAM decomposes the application landscape into functional domains, functional areas, and individual application functions — providing a vendor-neutral reference for what software capabilities a CSP needs.
TAM answers the question that BPF alone cannot: if I know what processes I need, what application functions do I need to build or buy? This makes TAM essential for vendor evaluation, portfolio rationalisation, and build-vs-buy decisions.
TAM Structure and Decomposition
TAM is structured as a hierarchy of application functions, organised into domains that align with the BPF process areas:
TAM Decomposition Levels
Level
Name
Description
Example
Level 0
Application Domains
Top-level groupings aligned with BPF process areas
Operations Support & Readiness
Level 1
Functional Areas
Major application areas within each domain
Customer Management
Level 2
Application Functions
Specific application functions that support processes
Customer Order Management
Level 3
Sub-Functions
Granular functional capabilities within an application
Order Validation, Order Enrichment
TAM Functional Domains
TAM organises application functions into domains that mirror the operational structure of a CSP. The key domains for BSS/OSS are:
Key TAM Functional Domains
TAM Domain
Scope
Key Application Functions
Market/Sales Domain
Customer-facing commercial functions
Product Catalog Management, Customer Order Management, Sales Management, CPQ
The relationship between TAM and BPF is many-to-many: a single BPF process may require multiple TAM application functions, and a single TAM application function may support multiple BPF processes. This is a critical distinction that many organisations get wrong.
BPF → TAM Mapping Example: Order Handling
1
BPF Process: Order Handling
BPF Level 2
The process of receiving, validating, and managing a customer order
2
TAM: Customer Order Management
TAM Level 2
Application function for capturing and managing commercial orders
3
TAM: Product Catalog Management
TAM Level 2
Application function for looking up eligible products and pricing rules
4
TAM: Customer Management
TAM Level 2
Application function for retrieving and validating customer context
Organisations often assume one BPF process maps to one application. This leads to fragmented vendor selections and integration gaps. A single "Order Handling" process touches catalog, CRM, billing, and order management application functions. TAM makes these cross-cutting dependencies visible.
TAM for Vendor Evaluation and Portfolio Rationalisation
TAM's greatest practical value is in vendor evaluation and application portfolio rationalisation. By mapping each vendor's capabilities to TAM functional areas, you can immediately identify:
TAM-Based Assessment Outcomes
Assessment
What It Reveals
Action
Coverage gaps
TAM functions with no vendor coverage
Identify build-vs-buy decisions or additional vendors needed
Overlaps
Multiple vendors covering the same TAM function
Rationalise — pick a source of record per function
Misalignments
Vendor functions that span TAM boundaries
Assess integration complexity and data ownership risks
White spaces
TAM functions the organisation has never addressed
Evaluate whether these gaps represent real operational risk
Most BSS/OSS vendors publish their own TAM mapping — showing which TAM functional areas their products cover. When they do not, it is a useful exercise to create one yourself during evaluation. A vendor that cannot articulate its TAM coverage may not have a clear understanding of its own functional boundaries.
Open APIs
TM Forum·API standard / framework
Open APIs
What is it?
A suite of REST API specifications — TMF620 Product Catalog, TMF622 Product Ordering, TMF641 Service Ordering, TMF639 Resource Inventory and over sixty more — with payloads built on SID entities. Published under the Apache 2.0 licence and used as the contract between ODA Components.
What problem does it solve?
Makes BSS/OSS systems from different vendors interoperable at defined seams, so that integration is configuration against a known interface rather than a bespoke project every time.
What does it cover?
•Catalog, ordering, inventory, party, billing, assurance and NaaS API families
•Conformance certification for implementations
•The Operate APIs used in the GSMA Open Gateway federation layer
What does it NOT cover?
•Not a complete end-to-end application architecture.
•Does not define the orchestration between calls — sequencing, compensation and error handling are yours.
•Does not guarantee two "conformant" products interoperate on the optional parts of a payload.
Where does it fit?
ApplicationBSSOSSAPIs
When would an architect use this?
•Integration design between BSS and OSS domains
•API design for channels and partners, and BFF layers over them
This entry places the Open APIs in the TM Forum ecosystem. Everything about the individual APIs — the catalog, ordering, inventory and assurance families, the order-to-activation chain, conformance — lives in Section 10, TM Forum Open APIs.
The TM Forum Framework Suite: ODA wraps three core frameworks (eTOM, SID, TAM) connected by Open APIs
💡Why All Three Matter
You cannot evaluate a BSS/OSS vendor using only one framework. A vendor may implement the right processes (BPF) but store data in a proprietary model that ignores SID. Or it may align with SID entities but package them into application functions that do not match TAM boundaries. All three frameworks must be used together for a complete architectural assessment.
How the Three Frameworks Connect
The power of the TM Forum framework suite is in how the three frameworks interlock. Each framework constrains and informs the others:
Framework Alignment Chain
1
BPF defines the process
Business Process Framework
Identify which Level 2 process you need (e.g., Order Handling)
2
SID defines the data
Information Framework
Identify which entities the process creates, reads, updates, or deletes (e.g., ProductOrder)
3
TAM defines the application function
Functional Framework
Identify which application function is responsible (e.g., Customer Order Management)
4
TMF Open APIs define the contract
TMF Open API Suite
Select the API that exposes the SID entity (e.g., TMF622 Product Ordering)
5
ODA defines the component
Open Digital Architecture
Package the process, data, function, and API into an ODA Component
This alignment chain is the foundation of TM Forum's Open Digital Architecture (ODA). ODA Components are defined by the BPF processes they implement, the SID entities they manage, the TAM functions they provide, and the TMF Open APIs they expose. Without all three frameworks, ODA component definitions would be incomplete.
Academy guides built on eTOM
The three pages below are Academy interpretation, not TM Forum standards. They take eTOM and apply it — to the Lead-to-Cash flow, to the systems that implement each process, and to a capability-by-capability reference — with system ownership and gap analysis that TM Forum deliberately leaves to you.
🔍Lead-to-Cash Flow
The complete L2C process mapped to eTOM, with system ownership at each step. Open 11.9 →
🔍Process-to-System Mapping
eTOM processes mapped to BSS/OSS systems, with coverage matrices and gap analysis. Open 11.10 →
🔍Capability Reference
Every eTOM Level 1 domain through Level 2 capabilities to Level 3 tasks, with system ownership. Open 11.11 →
Practical Applications
When a BSS vendor says "order management" and an OSS vendor says "order management," they often mean very different things. The BPF provides precise definitions: Order Handling (BPF 1.1.1.6) at the CRM layer is commercial order capture. Service Configuration & Activation (BPF 1.1.2.1) at the SM&O layer is service-level orchestration. Without BPF, you are comparing apples to oranges.
BPF defines processes, not departments. Multiple teams participate in one process; one team contributes to many processes.
1:1 process-to-system mapping
A CRM may cover multiple BPF processes; a single process like "Order Handling" may span COM, Product Inventory, and Catalog.
Ignoring TAM during vendor selection
Without TAM, you evaluate vendors on their own terms. TAM provides the neutral reference grid that makes comparison meaningful.
Ignoring SIP processes
Strategy, Infrastructure & Product defines WHAT gets sold and HOW. Without SIP, Operations has nothing to operate.
Using only one framework
BPF without SID produces processes with unclear data contracts. TAM without BPF produces applications without clear process justification. All three are needed.
Section 11.2 Key Takeaways
TM Forum publishes three core frameworks: Business Process Framework / BPF (GB921), Information Framework / SID (GB922), and Functional Framework / TAM (GB929)
BPF (historically called eTOM) defines processes hierarchically across Levels 0-4, with Level 2 being the most architecturally relevant
TAM defines application functions needed to support BPF processes — essential for vendor evaluation and portfolio rationalisation
SID defines the canonical data entities shared between processes and applications — the foundation of TM Forum Open APIs
The three frameworks interlock: BPF says what you do, TAM says what applications you need, SID says what data they share
In ODA, all three frameworks converge: each ODA Component is defined by its BPF processes, TAM functions, SID entities, and TMF Open APIs
Use all three frameworks together for vendor evaluation, integration design, and transformation planning — using only one produces an incomplete picture
ODA is the umbrella; eTOM, SID, the Functional Framework and the Open APIs are the assets inside it, not four competing frameworks.