Relationships & Decomposition
Last updated 14 Oct 2026
At a glance
A catalog’s value comes from the relationships between its entities, not the entities themselves. Relationships say how offerings bundle, how products compose, which combinations are allowed, and how a product decomposes into services and resources. Decomposition rules held as catalog data are what let order management fulfil a new product without new code.
The picture
Catalog relationship types — how entities connect across product, service, and resource layers
Product Offering
BSSProduct Specification
BSSCustomer-Facing Service
OSSResource-Facing Service
OSSResource
OSSHow it works
Relationships carry the logic
An offering, a specification or a CFS on its own says little. What a catalog-driven architecture runs on is the set of relationships between them: what goes with what, what requires what, what cannot coexist, and what is delivered by what. Order capture reads the top relationships to validate a basket; order management reads the lower ones to fulfil it.
Catalog relationship types
| Relationship | Between | Purpose | Example |
|---|---|---|---|
| Bundling | Offering → Offering | Groups offerings into a package | Triple Play bundles Internet, TV and Voice offerings |
| Composition | Specification → Specification | Mandatory and optional components | Broadband includes a Router component |
| Dependency | Specification → Specification | One product requires another | Static IP requires active Broadband |
| Exclusion | Specification → Specification | Two products cannot coexist | A budget plan excludes premium add-ons |
| Realisation | Product Specification → CFS | The product is delivered by this service | Broadband is realised by CFS Internet Access |
| Decomposition | CFS → RFS | The service is implemented by these components | Internet Access → GPON bearer + VLAN + IP profile |
| Resource binding | RFS → Resource | The component needs this resource | GPON bearer requires an OLT port |
Commercial rules and technical rules
The first four relationships are commercial: they govern what may be sold together, and they are enforced at order capture by CPQ and COM. The last three are technical: they govern how something sold is delivered, and they are executed in fulfilment by SOM and ROM. The boundary between the two is the realisation link from Product Specification to CFS. It is the single point where the commercial catalog hands over to the service catalog.
Cardinality
Composition and decomposition carry cardinality. A mandatory component is 1:1, an optional one 0:1, and a repeatable one 0:n or 1:n (additional phone lines, extra IP addresses). A choice group says pick exactly one of several (one router model from three). Cardinality is what lets a single specification describe every valid configuration rather than one specification per configuration.
Decomposition, step by step
How an order is decomposed
Product to CFS
COM → SOMThe realisation relationships on the Product Specification name the CFS that deliver it. COM sends them to SOM as a service order.
CFS to RFS
SOMSOM applies the service catalog’s decomposition rules, including any conditions, to choose the RFS set for each CFS.
RFS to Resource
ROMResource binding names the resource specifications each RFS needs. ROM reserves and allocates matching resources from inventory.
Sequence and activate
SOM / ROMDependencies between components set the order of work: the bearer before the IP profile, the IP profile before the service is tested.
Conditional decomposition
The same CFS can produce different RFS depending on technology, geography or customer characteristics. Internet Access decomposes into GPON-based RFS for a fibre address and DOCSIS-based RFS for a cable address. The product and the CFS are unchanged; only the implementation differs. The condition is evaluated at order time against facts the order carries or that SOM looks up, typically the serviceability result for the address.
Rules as data, not code
When these relationships are held in the catalog, a new product built from existing CFS and RFS is a catalog change: new specifications and relationships, no new workflow. When they are held in order management code, every new product is a development project. This is the practical meaning of catalog-driven. It is also why runtime order management has to be built to read the catalog; a catalog with no runtime consumer stores rules that nothing executes.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Bundling, composition, dependency and exclusion rules | Product Catalog | CPQ / COM | — | TMF620. Enforced at order capture. CPQ tools often hold their own copy of compatibility rules, which then drifts. |
| Realisation (Product Specification → CFS) | Product Catalog | — | Service Catalog, COM | Usually held on the product side as a reference to the CFS specification. Some estates hold the mapping in COM or SOM configuration instead. |
| Decomposition rules (CFS → RFS) | Service Catalog | — | SOM | TMF633. Where the orchestration product has its own design environment, the rules may live there in practice. |
| Resource binding (RFS → Resource Specification) | Service Catalog | — | Resource Catalog, ROM | The binding sits on the RFS; the resource specifications it points to are owned by the resource catalog (TMF634). |
| Instance relationships (which service realises which product) | Service Inventory | — | Product Inventory, Resource Inventory | Created at fulfilment. Each inventory records links to the instances above and below it. |
In practice
Most commercial catalogs model bundling and composition well, because order capture needs them. Dependency and exclusion are less consistent: some sit in the catalog, some in CPQ rules, some in channel code. The realisation link is the weakest point in many estates. Where it is missing, COM or SOM holds a hard-coded table from product codes to service work, and every new product edits that table.
Vendor service catalogs and orchestration products differ in how they express conditional decomposition. Some use declarative rules on the specification; others use decision tables or workflow branches inside the orchestrator. The second approach works, but the rules are then readable only by the people who maintain the orchestrator, and the catalog no longer describes the whole decomposition.
The trade-off
What it solves
New products assembled from existing services become catalog changes rather than development projects, and every delivered resource can be traced to the product that needed it.
What it does not solve
- Order management that cannot read the rules. The catalog only describes decomposition; SOM and ROM have to execute it.
- Missing lineage in the installed base, which was never decomposed this way.
- Rule sprawl. Hundreds of special-case conditions make decomposition as hard to reason about as the code it replaced.
What it adds
- Rules split across product catalog, service catalog, CPQ and orchestrator, each with its own owner and release cycle.
- Testing: a change to one CFS decomposition affects every product realised by it.
- Versioning: in-flight orders and live instances refer to rule versions that later change.
Architecture decision
Where should conditional decomposition logic live?
Declarative rules in the service catalog
Choose when conditions are few and well understood (technology, region), and you want one place that describes the whole decomposition.
Decision logic in the orchestrator
Choose when conditions depend on live network state or complex sequencing that a catalog rule language cannot express.
Breaks if both are used without a stated boundary. Part of the decomposition is then in the catalog and part in the orchestrator, and nobody can say from either one what an order will produce.
Takeaways
Key Takeaways
- Relationships, not entities, carry the catalog’s logic
- Bundling, composition, dependency and exclusion are commercial rules, enforced at order capture
- Realisation, decomposition and resource binding are technical rules, executed in fulfilment
- Conditional decomposition lets one CFS take different technical forms without changing the product
- Rules held as catalog data only pay off when order management reads them at runtime
Check yourself
Static IP can only be ordered with an active broadband service. Which relationship is that, and where is it enforced?Show answerHide
A dependency between Product Specifications. It is a commercial rule, enforced at order capture by CPQ or COM against product inventory.
A new broadband product reuses the existing Internet Access CFS. What has to change in SOM?Show answerHide
Nothing, if decomposition is catalog-driven: the new Product Specification is realised by the existing CFS, whose decomposition is already defined. If SOM needs a change, the rules are in code.
Why is the realisation link the most important relationship to get right?Show answerHide
It is the hand-over from the commercial catalog to the service catalog. Without it, product to service mapping is hard-coded somewhere, and catalog-driven fulfilment stops at the product layer.