E2E Data Lineage
Last updated 12 Oct 2026
At a glance
Data lineage answers where did this come from, what happened to it, and where did it go? In a catalog-driven estate it is structural: every order creates linked entities from customer to network, each referencing its parent and its specification by ID. TM Forum SID supplies the shared meaning that lets those links cross the BSS/OSS boundary.
The picture
What Good Looks Like
This is the ideal BSS → OSS data lineage — from customer to network. Remove components like lego blocks to see the cascading impact on your architecture & business processes.
Complete Data Lineage
- ✓Orders validated against catalog before fulfilment
- ✓CFS/RFS decomposition is catalog-driven
- ✓Product inventory tracks current customer state
- ✓ITSM/CMDB receives post-activation updates
- ✓Billing driven by accurate SLM subscription state
- ✓Lead-to-Cash and Trouble-to-Resolve connected
How it works
Lineage by design
Each layer creates its entities with explicit references: the product order item to its Product Offering, the service order item to the product order item, the service instance to the product instance, the resource to the RFS that uses it. The links are made at order time, not rebuilt later by reconciliation jobs or fuzzy matching.
- Downward: decomposition, product to service to resource.
- Upward: completion and state updates, resource to service to product.
- Across: links between related entities, such as product instance to billing account, or resource to the services that depend on it.
What SID is
The Shared Information/Data model (SID) is TM Forum’s logical, vendor-neutral information model. It defines which entities exist, what they mean and how they relate. It does not prescribe database schemas, API payloads or products. Two operators can both be SID-aligned while running entirely different products; what they share is the semantics. That is what makes SID the integration contract.
SID domains along the lineage chain
| SID domain | Example entities | Usually owned on |
|---|---|---|
| Party / Customer | Party, PartyRole, Customer, Agreement | BSS |
| Product | ProductOffering, ProductSpecification, Product (instance), ProductOrder | BSS |
| Service | CustomerFacingService, ResourceFacingService, ServiceSpecification, ServiceOrder | The BSS/OSS boundary |
| Resource | Resource (logical and physical), ResourceSpecification, ResourceOrder | OSS |
| Customer billing (within Customer) | BillingAccount, charges and bills | BSS |
The CFS is the seam
The CFS is the contract between commercial and technical worlds. BSS references it by ID from the order item; OSS owns the running instance and links resources to it through RFS decomposition. The boundary is referential: BSS does not hold a copy. Both sides must point at the same service entity, and this seam is where most catalog leakage and broken lineage happen.
What structural lineage makes possible
- Fault to customer in a few hops: resource, RFS, CFS, product instance, customer.
- Impact analysis as a query: "which customers does this router maintenance affect?" is a graph traversal.
- Safe catalog change: BSS references CFS specifications only by ID, so new offerings, new RFS decompositions or a replaced controller do not ripple into BSS.
- Easier multi-vendor integration: a product exposing TMF Open APIs slots into the same semantic shape.
- Audit: the commercial decisions behind a charge can be traced end to end for revenue assurance, regulators and disputes.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product instance | Product Inventory (SLM) | — | Product Catalog | TMF637. References its offering and the order item that created it. |
| CFS instance | Service Inventory | SOM | COM / Product Inventory (by ID) | TMF638. Owned by OSS; BSS holds only the reference. |
| Resource and its assignment to an RFS | Resource Inventory | ROM | Service Inventory | TMF639. The link that lets an alarm reach a service. |
| Billing account | Billing | CRM | Product Inventory | Linked across to the product instances it pays for. |
| Entity definitions and relationships | The operator’s information model, aligned to SID | — | — | SID is a reference model; the operator owns its own aligned version. |
In practice
"SID-aligned" is a claim worth testing. Products can expose TMF Open APIs and still use different meanings for Service or Order internally. The test is whether a service instance in OSS carries the same identifier the BSS order item referenced, and whether a fault can be walked back to a customer without a matching job.
Without that alignment, the cost shows up as data quality issues, long integration projects and revenue leakage that grows with every product launched on top.
The trade-off
What it solves
It makes lineage a by-product of ordering: every entity is linked to its parent and specification when it is created, so tracing, impact analysis and audit become queries.
What it does not solve
- Lineage for the installed base created before the model existed.
- Divergence between inventory and the live network, which needs discovery and reconciliation.
- Products that expose TMF APIs without sharing SID semantics.
What it adds
- Every system must keep and honour references it does not own.
- Identifiers must stay stable across migrations, product swaps and catalog versions.
- A governed information model that all projects align to.
Architecture decision
How do you get lineage for customers who already exist?
Migrate and link the installed base
Choose when legacy platforms are being retired, and product, service and resource records can be matched with acceptable effort.
Structural lineage for new orders only
Choose when migration is planned by product or segment, and the legacy base will be moved in waves with a defined end.
Inferred lineage via reconciliation
Choose when legacy stays for years and assurance needs a customer view now, accepting matches that are probable rather than certain.
Breaks if Links are left to "clean up later". Two populations with different data quality persist, and every report, fault and dispute has to know which one it is dealing with.
Takeaways
Key Takeaways
- In a catalog-driven estate lineage is created at order time, not reconstructed afterwards
- Lineage runs downward (decomposition), upward (completion) and across (related entities)
- SID is logical: it aligns meaning, not schemas or products
- The CFS is the seam: BSS references it by ID, OSS owns the instance, and this is where lineage most often breaks
- Existing customers provisioned outside the model have no structural lineage until they are migrated and linked
Check yourself
A PE router needs maintenance. What chain of references must exist to list the affected customers?Show answerHide
Resource to the RFS using it (resource inventory), RFS to CFS (service inventory), CFS to product instance, and product instance to customer. Break any one and the list becomes a manual investigation.
Two vendors both claim SID alignment, yet their integration needs a large mapping layer. How can both claims be true?Show answerHide
SID is logical. Both can use SID entity names while meaning different things by them, or link them differently. Alignment is proven by shared semantics and identifiers, not by API names.
Why should BSS hold a CFS reference rather than a copy of the CFS?Show answerHide
OSS owns the running service. A copy in BSS goes stale; a reference by ID keeps one truth and lets OSS change the decomposition without touching BSS.