🏗️

Section 1.2

Commercial vs Technical Domains

The critical split between what the customer sees and what the network delivers.

The Fundamental Split

Every telco architecture has a fundamental divide between the commercial domain (what the customer sees, buys, and is billed for) and the technical domain (what the network actually builds, activates, and monitors). This split runs through every layer: catalog, order management, inventory, and APIs.

Understanding this split is critical because it defines who owns what data, which system is the source of truth, and where integration boundaries exist. When this is unclear, organisations end up with duplicated data, conflicting records, and integration spaghetti.

Commercial Domain (BSS)

Technical Domain (OSS)

Catalog

Product Catalog

Offers & Pricing

defines

Service Catalog

CFS Specs

Resource Catalog

RFS / RS Specs

Order

COM

Commercial Orders

decomposes

SOM

Service Orders

ROM

Resource Orders

Inventory

Product Inventory

Subscriptions

maps to

SLM

Active CFS Instances

Resource Inventory

Network Assets

Mgmt

Revenue Mgmt

Billing & Mediation

correlates

Fault Mgmt

Trouble Tickets

Performance Mgmt

SLA & KPI

Each layer mirrors across the BSS / OSS boundary

Figure 1.3 — The commercial/technical domain split across all layers

Commercial Domain

The commercial domain represents the customer's view of reality. It deals in products, pricing, bundles, contracts, and billing. The commercial domain answers: "What did the customer buy, and on what terms?"

Commercial Domain Entities

Layer	Entity	Description	Owner
Catalog	Product Offering	The sellable package as presented to the customer	Product Management (BSS)
Catalog	Product Specification	The structure and characteristics of a product type	Product Management (BSS)
Order	Product Order	The customer's request to buy/change/cancel a product	Commercial Order Mgmt (COM)
Inventory	Product Instance	The customer's active subscription / installed product	Product Inventory
Revenue	Bill / Invoice	The charge statement generated from product usage and subscriptions	Billing (BSS)

Technical Domain

The technical domain represents the network's view of reality. It deals in services, resources, configurations, and network elements. The technical domain answers: "What is actually running on the network, and how is it configured?"

Technical Domain Entities

Layer	Entity	Description	Owner
Catalog	CFS Specification	Customer-Facing Service — the service the customer experiences	Service Catalog (OSS)
Catalog	RFS Specification	Resource-Facing Service — the technical service implementation	Service Catalog (OSS)
Catalog	Resource Specification	Physical or logical resource type (port, VLAN, device)	Resource Catalog (OSS)
Order	Service Order	Request to create/modify/delete a service instance	Service Order Mgmt (SOM)
Order	Resource Order	Request to allocate/configure/release a resource	Resource Order Mgmt (ROM)
Inventory	Service Instance	A running service on the network	SLM
Inventory	Resource Instance	An allocated resource (IP, port, VLAN, device)	Resource Inventory

The Translation Point

The critical handoff between commercial and technical happens during order decomposition. A commercial Product Order is translated into one or more Service Orders using the catalog's decomposition rules. This is often the most complex integration in any BSS/OSS landscape.

Commercial → Technical Translation

Product Order Created

BSS — COM

Customer orders "Premium Broadband 200" through a sales channel. COM validates and captures the order.

Catalog Lookup

Product Catalog

COM queries the product catalog for the Product Specification and its linked CFS specifications.

Decomposition to Service Orders

SOM (OSS)

The product decomposes into CFS instances: CFS:Internet-Access, CFS:WiFi-Management. Service Orders are created for each.

Further Decomposition to Resource Orders

ROM (OSS)

Each CFS decomposes into RFS and Resource requirements: GPON port allocation, VLAN assignment, IP address allocation, ONT configuration.

Activation

Network / OSS

Resources are provisioned on the network. Service instances are created in service inventory. Product inventory is updated.

Why Both Views Must Coexist

Common Mistake: Merging Commercial and Technical

Some organisations try to use one system for both commercial and technical inventory. This always fails at scale because: (1) a single product can map to multiple services, (2) services can be shared across products, (3) commercial changes (price change) don't require technical changes, and (4) technical changes (resource swap) shouldn't affect billing.

The customer sees: "Premium Broadband 200" — a single product with a monthly price of $99, including internet access and WiFi management. They don't know or care about GPON ports, VLANs, or IP profiles.

Product: Premium Broadband 200
Speed: 200 Mbps download / 50 Mbps upload
Includes: WiFi management app
Price: $99/month
Contract: 24 months

TM Forum Alignment

The commercial/technical split maps directly to TM Forum SID domains. Product domain (commercial) is connected to Service and Resource domains (technical) through well-defined relationships. TMF620 (Product Catalog) and TMF633 (Service Catalog) represent the two sides of this split. The ODA component model enforces this separation at the architecture level.

Key Takeaways

Commercial domain = what the customer bought. Technical domain = what the network delivers.
The same product can map to completely different technical implementations.
Order decomposition is the critical translation point between commercial and technical.
Both views must coexist — merging them into one system always fails at scale.
A product change (e.g., price update) should not require a technical change, and vice versa.
TM Forum SID enforces this separation through distinct Product, Service, and Resource domains.