BSS/OSS Academy
2.312 min read

Relationships & Decomposition

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.

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.3 — Relationship types across catalog layers

Types of Relationships

Catalog Relationship Types

RelationshipDirectionPurposeExample
BundlingPO → POGroups offerings into packages"Triple Play" bundles Internet + TV + Voice offerings
CompositionPS → PSDefines mandatory/optional components of a productBroadband PS includes Router component PS
DependencyPS → PSOne product requires another to existStatic IP requires an active Broadband product
ExclusionPS → PSTwo products cannot coexistBudget plan excludes Premium add-ons
RealisationPS → CFSProduct is delivered by this serviceBroadband PS is realised by CFS:Internet-Access
DecompositionCFS → RFSService is implemented by these technical componentsCFS:Internet-Access decomposes into RFS:GPON-Bearer + RFS:VLAN + RFS:IP
Resource BindingRFS → ResourceTechnical service requires this resourceRFS:GPON-Bearer requires Physical:OLT-Port

Decomposition Rules

Decomposition is the most important relationship type. It defines how a higher-level entity breaks down into lower-level components. Decomposition rules are defined in the catalog and executed by order management systems during fulfilment.

Decomposition in TM Forum
TM Forum models decomposition through ServiceSpecificationRelationship (TMF633) and ResourceSpecificationRelationship (TMF634). Each relationship includes: type (composition, dependency), minQuantity, maxQuantity, and role. Conditional decomposition is handled through characteristic-based rules.

Decomposition Cardinality

Cardinality Patterns

PatternMin:MaxMeaningExample
Mandatory1:1Exactly one requiredBroadband requires exactly 1 Internet Access CFS
Optional0:1Zero or one allowedBroadband optionally includes Static IP CFS
Multi-instance1:NOne or more requiredEnterprise service requires 1-4 SIP trunks
Choice1 of NPick exactly one from a groupChoose router model: Basic OR Advanced OR Premium
Optional multi0:NZero or more allowedAdd any number of value-added services

Conditional Decomposition

Real-world decomposition is often conditional — the resulting components depend on characteristic values, customer type, geography, or technology. This is where catalog design becomes powerful but also complex.

Conditional Decomposition Example
Product: "Broadband Access" with characteristic accessTechnology. If accessTechnology = "GPON": decompose CFS:Internet-Access into RFS:GPON-Bearer + RFS:VLAN + RFS:IP-Profile. If accessTechnology = "DOCSIS": decompose CFS:Internet-Access into RFS:DOCSIS-Bearer + RFS:Cable-Modem-Config + RFS:IP-Profile. The CFS is the same — only the RFS decomposition changes based on the characteristic value.

Composition vs Aggregation

Composition means the child entity cannot exist without the parent. If you delete the parent, the children are deleted too. The child's lifecycle is fully controlled by the parent.

  • Product components that only exist within their parent product
  • CFS characteristics that are part of a specific CFS instance
  • A VLAN assignment that only exists in the context of a specific service

Dependency Management

Dependencies define ordering constraints — what must exist before something else can be created. In fulfilment, dependencies determine the activation sequence. Getting dependencies wrong leads to failed orders and rollback cascades.

Dependency-Driven Activation Sequence

1
Allocate Physical Port
Resource Inventory

Resource: OLT port must be allocated first — everything else depends on having a physical connection.

2
Configure Bearer
Network Activator

RFS: GPON Bearer is configured on the allocated port. Depends on Step 1.

3
Assign VLAN
Network Activator

RFS: VLAN is assigned on the bearer. Depends on Step 2.

4
Configure IP
DHCP/IP Management

RFS: IP profile is applied to the VLAN. Depends on Step 3.

5
Activate CFS
Service Inventory

CFS: Internet Access is marked active once all RFS components are complete. Depends on Steps 2-4.

Key Takeaways

  • Relationships are the core of catalog power: bundling, composition, dependency, exclusion, realisation, decomposition
  • Decomposition rules define how products break down into services and resources
  • Cardinality (1:1, 0:1, 1:N, choice) controls what is mandatory vs optional
  • Conditional decomposition allows different technical implementations from the same commercial product
  • Composition = lifecycle-bound children; Aggregation = independent, shared entities
  • Dependencies define activation sequence — the order in which things must be built