Catalog-Driven Architecture
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.
Catalog-Driven Architecture — All downstream systems derive behaviour from the catalog chain
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 — CommercialDefines 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 DomainDefines 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 DomainDefines physical and logical resources: network elements, ports, VLANs, IP addresses, equipment. Maps RFS specifications to the actual resource types needed.
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 |
|---|---|---|
| Sales / 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) |
Catalog-Driven vs Hard-Coded
Catalog-Driven vs Hard-Coded Approaches
| Aspect | Hard-Coded (Legacy) | Catalog-Driven (Modern) |
|---|---|---|
| New product launch | Requires code changes across 5+ systems | Configure in catalog, propagate automatically |
| Time to market | Weeks to months | Days to weeks |
| Validation rules | Scattered in application code | Centralized in catalog specifications |
| Product retirement | Risky, requires audit of all systems | Lifecycle managed in catalog with deprecation rules |
| Cross-system consistency | Drift between systems over time | Single source of truth drives all systems |
| Testing | End-to-end testing per product | Catalog validation + standard flow testing |
The Golden Rule of Catalog Design
Think of the catalog like a recipe book for a restaurant. The kitchen (OSS) does not decide what dishes exist — the recipe book (catalog) does. When the restaurant wants to add a new dish, they write a new recipe. The kitchen follows the recipe. The waiters (BSS) present what the recipe book offers.
Catalog-driven architecture requires loose coupling between systems. Each system reads the catalog at runtime to determine behavior. This means the catalog must be highly available, versioned, and support real-time queries.
Key TM Forum APIs for catalog access: TMF620 (Product Catalog), TMF633 (Service Catalog), and TMF634 (Resource Catalog). These APIs allow any system to query the catalog for specifications, rules, and relationships.
Achieving true catalog-driven architecture requires solving several hard problems: catalog versioning (how to evolve without breaking live orders), cross-catalog consistency (product-to-service-to-resource alignment), and catalog governance (who can change what, and how changes are validated before deployment).
Many telcos achieve "catalog-aware" but not truly "catalog-driven" — their systems reference the catalog but still contain hard-coded logic for complex scenarios. The gap between these two states is where most transformation effort goes.
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