E2E Data Lineage
How catalog-driven architectures create structural data lineage β linking every entity from customer order through to network activation β and what breaks when links are missing.
Data lineage answers a simple question: where did this data come from, what happened to it, and where did it go? In a catalog-driven telco, this is structural β entities are linked by design at creation time, not reconstructed after the fact. Every order creates a chain of linked entities from customer through to network, and every entity carries explicit references to its parent, children, and catalog specification.
The structural backbone that makes this lineage possible is the TM Forum Shared Information / Data model β SID. SID defines the entities, their attributes, and their relationships across the full BSS/OSS estate, and it is the reason a network alarm in OSS can be traced back to a billing account in BSS in milliseconds rather than via a reconciliation job.
The SID Model β Logical Backbone of BSS/OSS
The TM Forum SID is a logical, vendor-neutral information model. It does not prescribe how an operator implements its catalog, inventory, or billing β it specifies what entities exist, what they mean, and how they relate. Adopting SID does not require adopting a TM Forum-aligned product; it requires aligning the operator's own data definitions to a common semantic, so that integrations between products (and across the BSS/OSS boundary) speak the same language.
SID organises entities into six logical levels that mirror the L2C lifecycle. Some levels are entirely BSS-owned (commercial intent, customer agreement, billing), some are entirely OSS-owned (resource state, activation, performance), and one level β Service Management β sits on the boundary, where the customer-facing service (CFS) is the contract between commercial and technical worlds.
SID logical levels and key entities β with BSS/OSS scope
| Level | Purpose | Key SID entities | Scope |
|---|---|---|---|
| 1. Engagement (Market / Sell) | Engage parties, discover needs, create offers, agree terms | Party (Customer), PartyRole, Agreement (Contract), ProductOffering | BSS |
| 2. Order (Customer Order Mgmt) | Capture customer intent and translate into services | CustomerOrder, OrderItem, Service (CFS β referenced) | BSS |
| 3. Service Management | Define, compose, and manage services and their specifications | Service (CFS), ServiceSpecification, ResourceFacingService (RFS) | BSS / OSS boundary |
| 4. Resource Management | Inventory, topology, configuration and state of resources | Resource (logical/physical), ResourceSpecification, ResourceRelationship, ResourceCharacteristic, ResourceConfiguration | OSS |
| 5. Activation / Assurance | Realise and monitor services and resources in operation | ServiceConfiguration (deployed CFS), ResourceConfiguration (deployed resources), ServiceRelationship (DependsOn / Uses / Supports), Performance (KPIs, alarms, measurements) | OSS |
| 6. Billing / Revenue Management | Monetise services and resources | BillingAccount, BillingItem (chargeable item) | BSS |
BSS-specific scope
Levels 1, 2, 6 β commercial intent, order capture, monetisation
- Owns the commercial truth β customer identity, contract, chargeable items
- Does not directly know device configuration, network state, or topology
BSS / OSS boundary
Level 3 β Service Management, where CFS lives
- The CFS is the contract between commercial and technical worlds
- Referenced by BSS (via OrderItem), owned by OSS β the boundary is referential, not custodial
- Most catalog-leakage incidents happen here
OSS-specific scope
Levels 4, 5 β resources, configuration, runtime state, assurance
- Owns the technical truth β what is deployed, where, in what state, with what KPIs
- Does not own commercial context or chargeable-item definition
Why SID Alignment Matters
- Lineage is structural, not derived. Every entity references its parent and its specification by ID. A trouble ticket on a Resource traverses to ServiceConfiguration, to CFS, to OrderItem, to Customer in single-digit hops β no reconciliation, no batch jobs, no fuzzy matching.
- Impact analysis becomes computable. "Which customers are affected by this PE router maintenance window?" is a graph traversal, not a manual investigation. SID-aligned inventories make this query routine.
- Catalog evolution stays safe. Adding a new product offering does not break the OSS, because BSS only references CFS specifications by ID. Renaming a CFS, adding new RFS decompositions, or replacing a controller does not propagate into BSS.
- Multi-vendor integration becomes tractable. A new vendor product that exposes SID-aligned APIs (TMF Open APIs) can integrate without rewriting the inventory model β its data slots into the same semantic shape.
- Regulatory and audit traceability. "Show me every commercial decision that led to this customer being billed for this service in this state" is traceable end-to-end β useful for revenue assurance, regulatory reporting, and dispute resolution.
The interactive diagram below shows the lineage chain in practice. Orders flow down the main column β CRM β CPQ β COM β SOM+SLM β ROM β each layer creating SID entities that reference their parent. The product and service catalog feeds validation and decomposition rules into each layer. Billing branches from SOM+SLM, and ITSM/Assurance branches from ROM via lifecycle events.
Click any block to remove it and see the cascading impact on your business processes.
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
Common SID Misalignments
SID anti-patterns and what they cost
| Misalignment | What it looks like | What breaks first |
|---|---|---|
| BSS owns its own copy of Service | CRM/COM defines a "service" object that does not reference the OSS-owned CFS | BSS and OSS drift; same product appears differently per system; impact analysis becomes a reconciliation job |
| Catalog detail leaks across the boundary | BSS OrderItem carries device-level config (VLAN IDs, route-targets); OSS receives commercial pricing in payloads | Catalog change in OSS forces BSS code change; commercial change in BSS forces OSS code change; coupling explodes |
| Resource entities without ResourceSpecification linkage | Resources created from CSV imports or device discovery without binding to a catalog spec | No lineage from resource back to product; assurance cannot compute customer impact; topology is descriptive but not actionable |
| Billing not bound to ServiceConfiguration | BillingItem references a SKU directly, not the deployed service | Service downgrade/upgrade does not flow to billing automatically; revenue leakage; manual reconciliation between billing and service inventory |
| Performance entities not linked to Service / Resource | KPI streams stored against device IDs only | Customer-impacting alarms cannot be classified; SLA breach detection becomes manual |
SID and Data Lineage β Key Principles
- SID is the logical backbone β it defines the entities and relationships that make end-to-end lineage structural rather than derived.
- BSS owns Levels 1, 2, 6 (engagement, order, billing). OSS owns Levels 4, 5 (resource, activation/assurance). Level 3 (service management) is the boundary, with CFS as the shared contract.
- The CFS link is the most failure-prone seam in any BSS/OSS estate β break it and lineage breaks. BSS references CFS by ID; OSS owns the runtime instance.
- Data lineage flows in three directions: downward (order decomposition), upward (completion updates), and across systems (linking related entities).
- In a SID-aligned, catalog-driven architecture, lineage is created at order time β not reconstructed after the fact via ETL or fuzzy matching.
- Lineage enables instant traversal: a network alarm can be traced back to the affected customer in seconds; a billing dispute can be backed by service evidence; a maintenance window can compute customer impact before it starts.
- SID is logical, not physical. Two operators can both be "SID-aligned" while running entirely different products β what matters is the shared semantics of Service, Order, Resource, and Configuration.
- Without SID alignment, organisations experience widespread data quality issues, multi-month integration projects, and revenue leakage that compounds with every product launch.