Relationships & Decomposition
How catalog entities relate to each other: bundling, dependencies, and decomposition rules.
Catalog Relationships
The power of a catalog-driven architecture comes not from individual entities, but from the relationships between them. These relationships define how products compose, how they decompose into services, and what constraints govern valid configurations. Understanding relationship types is essential for catalog design.
Catalog relationship types — how entities connect across product, service, and resource layers
Product Offering
BSSProduct Specification
BSSCustomer-Facing Service
OSSResource-Facing Service
OSSResource
OSSTypes of Relationships
Catalog Relationship Types
| Relationship | Direction | Purpose | Example |
|---|---|---|---|
| Bundling | PO → PO | Groups offerings into packages | "Triple Play" bundles Internet + TV + Voice offerings |
| Composition | PS → PS | Defines mandatory/optional components of a product | Broadband PS includes Router component PS |
| Dependency | PS → PS | One product requires another to exist | Static IP requires an active Broadband product |
| Exclusion | PS → PS | Two products cannot coexist | Budget plan excludes Premium add-ons |
| Realisation | PS → CFS | Product is delivered by this service | Broadband PS is realised by CFS:Internet-Access |
| Decomposition | CFS → RFS | Service is implemented by these technical components | CFS:Internet-Access decomposes into RFS:GPON-Bearer + RFS:VLAN + RFS:IP |
| Resource Binding | RFS → Resource | Technical service requires this resource | RFS:GPON-Bearer requires Physical:OLT-Port |
Decomposition
Decomposition is how higher-level entities break down into lower-level components. A commercial product decomposes into one or more CFS instances, each CFS decomposes into RFS instances, and each RFS binds to physical or logical resources. These rules are defined in the catalog and executed automatically during fulfilment.
Decomposition can be conditional — the same CFS may produce different RFS components depending on technology, geography, or customer characteristics. For example, a broadband CFS decomposes into GPON-based RFS for fibre customers and DOCSIS-based RFS for cable customers. The commercial product stays the same; only the technical implementation changes.
Key Takeaways
- Relationships are the core of catalog power: bundling, composition, dependency, exclusion, realisation, decomposition
- Decomposition defines how products break down into services and resources — driven by catalog rules, not code
- Conditional decomposition allows different technical implementations from the same commercial product
- Dependencies between components determine the activation sequence during fulfilment