Catalog-Driven Architecture

Why modern telco systems are catalog-driven, and how catalogs control everything from sales to activation.

What Is Catalog-Driven Architecture?

In a catalog-driven architecture, the product catalog is not just a list of things you sell — it is the master blueprint that controls every downstream system. The catalog defines what can be ordered, how it decomposes into services, how those services map to resources, and what validation rules apply at every step.

This is the defining characteristic of modern BSS/OSS architecture. Without catalog-driven design, every new product requires custom development across multiple systems. With it, launching a new product becomes a configuration exercise, not a coding exercise.

Why This Matters

Catalog-driven architecture is the single biggest differentiator between legacy and modern telco platforms. If you understand this, you understand why modern telcos can launch products in days instead of months.

The Three Catalog Layers

A catalog-driven telco architecture uses three interconnected catalog layers, each owned by a different domain. Understanding these layers and their relationships is essential.

Catalog Layer Chain

Product Catalog (BSS)

BSS — Commercial

Defines what can be sold to customers. Contains Product Offerings (the sellable package), Product Specifications (the underlying structure), pricing rules, eligibility rules, and bundling logic.

Service Catalog (OSS)

OSS — Service Domain

Defines Customer-Facing Services (CFS) and Resource-Facing Services (RFS). Maps commercial products to technical service specifications. Controls service decomposition rules.

Resource Catalog (OSS)

OSS — Resource Domain

Defines physical and logical Resource Specifications (RS): network elements, ports, VLANs, IP addresses, equipment. Maps RFS specifications to the actual resource types needed.

Every downstream system derives behaviour from the catalog chain

BSS ConsumersCatalog ChainOrder & Fulfilment

CRM / CPQ

Configure & Quote

reads from

Product Catalog

CFS — Customer-Facing Services

reads from

Order Capture

COM

CFS → RFS mapping

decomposes to CFS

Service Catalog

RFS — Resource-Facing Services

reads RFS

SOM

Service Orders

RFS → RS mapping

sends RS

Resource Catalog

RS — Resource Specifications

receives RS

Activation

Orchestration

COM uses Product Catalog (CFS) to decompose orders into services — SOM and Activation read RFS/RS downstream

Figure 1.2 — How the catalog drives every stage from sales through activation

How the Catalog Controls the Flow

In a catalog-driven system, each stage of the lead-to-cash process queries the catalog to determine what to do next. No system hard-codes product logic. This is what makes the architecture flexible and maintainable.

Catalog Usage Across the Lifecycle

Stage	What the Catalog Provides	Example
CRM / CPQ	Available offerings, eligibility rules, pricing, valid configurations	Customer qualifies for "Business Fibre 200" based on location and segment
Order Capture	Required fields, mandatory components, validation rules	Order must include router selection and installation slot
Order Decomposition	Product → CFS mapping, CFS → RFS mapping	"Business Fibre 200" decomposes into CFS:Internet + CFS:VoIP
Service Orchestration	RFS decomposition, activation sequence, dependencies	CFS:Internet requires RFS:GPON-Port + RFS:VLAN + RFS:IP-Profile
Resource Provisioning	Resource types, configuration templates, allocation rules	RFS:GPON-Port requires a free port on the nearest OLT
Billing	Pricing rules, charge types, discount eligibility	Apply $99/month recurring + $0 installation (promo)

Without a Centralised Catalog

When this architecture is absent, every system holds its own partial definition of what the operator sells and delivers. Products are defined differently in CRM, billing, and provisioning. Fulfilment becomes manual and person-dependent. Billing drifts from what is actually running on the network. No system authoritatively tracks what each customer has, and routine questions like "which customers are affected by this outage?" become multi-day investigations. These are not edge cases — they are the daily reality of legacy environments, and the primary driver behind catalog-driven transformation.

Key Takeaways

Catalog-driven architecture means the catalog is the single source of truth that controls all downstream systems
Three catalog layers: Product Catalog (BSS), Service Catalog (OSS), Resource Catalog (OSS)
Every stage from sales to activation queries the catalog — no hard-coded product logic
New products are launched through catalog configuration, not code changes
TM Forum APIs (TMF620, TMF633, TMF634) standardise catalog access across systems
True catalog-driven maturity is the benchmark for modern telco platforms