BSS/OSS Academy
2.58 min read

Visualizing Catalog Relationships

Seeing the Big Picture

One of the biggest challenges in understanding BSS/OSS catalog architecture is seeing how all the layers connect. Individual concepts make sense in isolation, but the real insight comes when you see the full chain from Product Offering down to Resource — and understand how data flows across it.

This section provides a comprehensive visual reference showing how entities across all catalog layers relate to each other. Use this as a reference map when designing catalogs or diagnosing integration issues.

Product OfferingFibre 100 HomePOFibre 200 BundlePOProduct SpecificationBroadband AccessPSManaged WiFiPSCustomer-Facing ServiceCFS: Internet AccessCFSCFS: WiFi MgmtCFSResource-Facing ServiceRFS: GPON BearerRFSRFS: IP ProfileRFSRFS: QoS ProfileRFSResourceOLT PortResourceIP AddressResourceBW PolicyResourcereferencesbundlesrealisesrealisesdecomposesrequiresRelationship TypesreferencesbundlesrealisesdecomposesrequiresLines flow top-down

Catalog relationship types -- how entities connect across product, service, and resource layers

Figure 2.5 — Complete catalog relationship map across all layers

Layer-by-Layer Walkthrough

Following the Chain Top to Bottom

1
Product Offering Layer
BSS — Product Catalog

The customer-visible catalog. Product Offerings define what is sold, at what price, through which channels. Offerings reference Product Specifications (for structure) and can bundle other offerings. This is the BSS domain.

2
Product Specification Layer
BSS — Product Catalog

The structural definition layer. Specifications define characteristics, composition rules, and crucially: which CFS types are needed to deliver this product. This is the bridge between BSS and OSS.

3
CFS Layer (Customer-Facing Service)
OSS — Service Catalog

The service outcome layer. CFS specifications define what the customer experiences, independent of technology. They link downward to RFS specifications through decomposition rules. This is the OSS service domain.

4
RFS Layer (Resource-Facing Service)
OSS — Service Catalog

The technology implementation layer. RFS specifications define how a service is technically delivered. They link downward to Resource specifications. Multiple RFS sets can implement the same CFS (technology variants).

5
Resource Layer
OSS — Resource Catalog

The physical/logical reality layer. Resource specifications define what must be allocated and configured on the network. This is the bottom of the catalog chain, directly touching network infrastructure.

Cross-Layer Relationships

Key Cross-Layer Relationships

FromToRelationship TypeCardinality
Product OfferingProduct SpecificationIs described byMany PO → 1 PS (typical)
Product OfferingProduct OfferingBundlesMany → Many (in bundles)
Product SpecificationProduct SpecificationComposes / Depends onMany → Many
Product SpecificationCFS SpecificationIs realised by1 PS → Many CFS
CFS SpecificationRFS SpecificationDecomposes into1 CFS → Many RFS
RFS SpecificationResource SpecificationRequires1 RFS → Many Resource

Reading the Diagram

How to Read Catalog Diagrams
Catalog diagrams are read top-to-bottom (commercial → technical) and follow the data flow of order fulfilment. Start at the Product Offering (what was sold), trace through to the Product Specification (what it is), then through CFS (what service), RFS (how it is built), and finally to Resource (what physical/logical things are needed). This is the same path that order decomposition follows at runtime.

Think of it as a tree: the Product Offering is the root (what the customer sees), and it branches out into increasingly specific technical details as you move down. Each branch point is a relationship. The leaves are the actual network resources.

It is critical to distinguish between catalog (design-time, specifications) and inventory (runtime, instances). The catalog defines the template: "a broadband product requires an internet access service." The inventory holds the instance: "customer #12345's broadband product is delivered by this specific internet access service instance running on these specific resources."

The catalog diagram shows design-time relationships. When an order is placed, the fulfilment engine traverses these relationships to create inventory instances at each layer.

The full catalog model forms a directed acyclic graph (DAG) — entities at higher layers point to entities at lower layers, and cycles are not permitted. This DAG property is essential for correct order decomposition: the fulfilment engine traverses the graph top-down, and any cycles would cause infinite decomposition loops.

In practice, cross-layer relationships can create a complex graph. Catalog governance must ensure the graph remains acyclic and that all leaf nodes (resources) are resolvable by the resource management system.

Key Takeaways

  • The catalog chain flows: Offering → Specification → CFS → RFS → Resource
  • Each layer has a distinct owner and purpose: commercial → service → infrastructure
  • Relationships define how order decomposition traverses the catalog at fulfilment time
  • Design-time (catalog/specifications) vs runtime (inventory/instances) is a critical distinction
  • The full model forms a directed acyclic graph — no cycles allowed
  • Use this visual map as a reference when designing catalogs or troubleshooting integration