🗺️

Section 8.1

TM Forum Framework Overview

The Business Process Framework (eTOM), Functional Framework (TAM), and Information Framework (SID) — what they are, how they relate, and why they matter.

The TM Forum Framework Suite

TM Forum publishes a suite of interrelated frameworks that together define how a communications service provider should operate, what data it manages, and what application capabilities it needs. These frameworks are not academic exercises — they are the common language used across the industry for vendor evaluation, transformation planning, and architectural governance.

The three core frameworks form a triad, each answering a different architectural question:

The TM Forum Framework Triad

Framework	Formal Name	Question It Answers	Published As
Business Process Framework (eTOM)	GB921	What processes does a CSP perform?	Frameworx / ODA
Information Framework (SID)	GB922	What data entities does a CSP manage?	Frameworx / ODA
Functional Framework (TAM)	GB929	What application capabilities does a CSP need?	Frameworx / ODA

Figure 8.1 -- 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.

Business Process Framework (eTOM)

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

Figure 8.1 — 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.

BPF Level 0 Process Areas

Area	Mode	Scope	Cadence
Strategy, Infrastructure & Product (SIP)	"Build"	Market strategy, product lifecycle, service/resource development, supply chain	Weeks to months
Operations (OPS)	"Run"	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
Billing	Charge for what was delivered	Billing & Collections, Charging & Rating, Revenue Assurance, Balance 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 formalised in the ODA Component Inventory (TMF-ODA-CI).

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.

Functional Framework (TAM)

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
Product Domain	Product lifecycle and portfolio	Product Portfolio Management, Product Design & Specification, Product Offering Management
Customer Domain	Customer relationship and experience	Customer Management, Loyalty & Retention, Customer Interaction Management
Service Domain	Service lifecycle and orchestration	Service Catalog Management, Service Order Management, Service Inventory, Service Quality Management
Resource Domain	Infrastructure and network	Resource Catalog Management, Resource Order Management, Resource Inventory, Network Management
Supplier/Partner Domain	External party management	Partner Management, Supply Chain Management, Partner Settlement
Enterprise Domain	Corporate support functions	Financial Management, HR Management, Knowledge Management

How TAM and BPF Relate

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

BPF Process: Order Handling

BPF Level 2

The process of receiving, validating, and managing a customer order

TAM: Customer Order Management

TAM Level 2

Application function for capturing and managing commercial orders

TAM: Product Catalog Management

TAM Level 2

Application function for looking up eligible products and pricing rules

TAM: Customer Management

TAM Level 2

Application function for retrieving and validating customer context

Common Mistake: 1:1 Process-to-Application Mapping

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.

Information Framework (SID)

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.

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

BPF defines the process

Business Process Framework

Identify which Level 2 process you need (e.g., Order Handling)

SID defines the data

Information Framework

Identify which entities the process creates, reads, updates, or deletes (e.g., ProductOrder)

TAM defines the application function

Functional Framework

Identify which application function is responsible (e.g., Customer Order Management)

TMF Open APIs define the contract

TMF Open API Suite

Select the API that exposes the SID entity (e.g., TMF622 Product Ordering)

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.

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.

Common Mistakes

Common Framework Mistakes

Mistake	Why It's Wrong
Treating BPF as an org chart	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.

TM Forum Frameworks — Key Points

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