1.515 min read
Source-of-Record Definitive Matrix
The Definitive Source-of-Record Matrix
This section provides the authoritative reference matrix for Source-of-Record (SoR) ownership across all major entities in a BSS/OSS architecture. For every entity that flows through the telco landscape — from customer records through product subscriptions to network resources — this matrix specifies who owns it, who consumes it, and why getting ownership wrong creates architectural failure.
This matrix is designed for use in architecture governance, integration design, vendor evaluation, and data quality remediation. It should be treated as a living document that is validated against your actual system landscape.
TM Forum ODA Alignment
In TM Forum Open Digital Architecture (ODA), each ODA Component is the System of Record for the data it manages. The component exposes TM Forum Open APIs for that data, and other components consume it via those APIs. This matrix aligns with ODA principles: the SoR column identifies which ODA functional block owns each entity, and the "Typical Consumers" column identifies which blocks consume it.
How to Use This Matrix
For each entity in your architecture, check this matrix to confirm: (1) your system landscape assigns the same SoR, (2) all consumers access the data via the SoR's API (not via direct database access or stale copies), and (3) no other system claims ownership of the same entity. Any deviation from these three checks is a data governance risk that should be documented and resolved.
Customer & Account Entities
Customer and account entities represent the commercial identity of the telco's relationship with its customers. These entities are firmly in the BSS domain and are managed primarily by CRM systems.
Customer & Account — Source-of-Record Matrix
| Entity | BSS / OSS | System of Record | Typical Consumers | Why Ownership Matters |
|---|---|---|---|---|
| Customer (Individual / Organisation) | BSS | CRM | COM (order context), Billing (invoice address), Self-Service Portal, Agent Desktop, Marketing, Fraud Management | Customer identity is the anchor for all commercial activity. If CRM is not the SoR, customer data fragments across systems — billing has one address, the portal has another, and compliance (KYC) becomes impossible to audit. |
| Account (Customer Account) | BSS | CRM | Billing (billing account linkage), COM (order account assignment), Self-Service Portal, Credit Management | Account hierarchy defines the commercial relationship structure (parent/child accounts, multi-site enterprises). If account ownership is unclear, billing hierarchies break and enterprise customers receive fragmented invoices. |
| Billing Account | BSS | Billing System | CRM (account view), Self-Service Portal (bill viewing), Payment Gateway, Collections, Revenue Assurance | Billing accounts control how charges are aggregated and invoiced. Billing must own these because it manages the financial lifecycle: rating, invoicing, payment application, and dunning. CRM holds a reference for display but must not modify billing-side structures. |
| Contact | BSS | CRM | COM (order contact), Trouble Ticket System (reporter), Self-Service (login identity), Notifications | Contacts are the individuals who interact with the telco on behalf of a customer account. If contacts are not centrally managed, the same person may be duplicated across systems with inconsistent permissions and communication preferences. |
Common Failure: Billing Owning Customer Data
In legacy environments, the billing system often becomes the de facto customer master because it was the first system deployed with customer records. This creates a circular dependency: CRM cannot be authoritative because billing has the "real" data, and billing cannot be replaced because it holds customer records that nothing else owns. The fix is to migrate customer master data to CRM and make billing a consumer via API.
Product Entities
Product entities span both design-time (catalog) and runtime (inventory). The catalog defines what can be sold; the inventory tracks what has been sold. Both are BSS-owned, but they serve different purposes and have different lifecycle dynamics.
Product Entities — Source-of-Record Matrix
| Entity | BSS / OSS | System of Record | Typical Consumers | Why Ownership Matters |
|---|---|---|---|---|
| Product Offering | BSS | Product Catalog | CPQ (configure and price), Self-Service (browsing), COM (order validation), Billing (pricing rules), Marketing (campaigns) | Product Offerings define what can be sold. If multiple systems maintain their own product definitions (CPQ has one version, billing has another), products will be priced inconsistently across channels and billing will not match what was quoted. |
| Product Specification | BSS | Product Catalog | COM (decomposition rules), SOM (product-to-CFS mapping), Billing (charge structure), Product Inventory (instance template) | Product Specifications define the structure and characteristics of a product type. They control how products decompose into services. If specifications diverge between catalog and fulfilment, orders will decompose incorrectly and services will be misconfigured. |
| Product Instance (Subscription) | BSS | Product Inventory / SLM | CRM (customer view of "what they have"), Billing (what to charge), Self-Service Portal, Agent Desktop, Assurance (customer impact) | Product Inventory is the commercial truth of what each customer currently has. It bridges catalog (what was offered) and billing (what is charged). If Product Inventory is not the SoR, CRM shows products that are not billed, or billing charges for products that are not active. |
| Pricing / Price Component | BSS | Product Catalog (definition) / Billing (applied rates) | CPQ (quoting), COM (order total), Self-Service Portal, Revenue Assurance | Pricing definitions live in the catalog; applied rates live in billing. Ownership confusion here causes the most visible customer-facing errors: quoted price does not match billed price, promotional discounts are not applied, or charges continue after product cancellation. |
Service Entities
Service entities represent the technical delivery of what was sold commercially. They bridge the commercial world (products) and the infrastructure world (resources). Service entities are OSS-owned and managed through service catalog and service inventory systems.
Service Entities — Source-of-Record Matrix
| Entity | BSS / OSS | System of Record | Typical Consumers | Why Ownership Matters |
|---|---|---|---|---|
| CFS Specification (Customer-Facing Service) | OSS | Service Catalog | SOM (decomposition rules), Product Catalog (product-to-CFS mapping), Service Qualification (feasibility check) | CFS specifications define how commercial products map to customer-facing services. If the service catalog is not authoritative, decomposition rules become inconsistent — different orders for the same product may produce different service configurations. |
| RFS Specification (Resource-Facing Service) | OSS | Service Catalog | SOM (CFS-to-RFS decomposition), ROM (RFS-to-resource mapping), Service Design (architecture) | RFS specifications define how customer-facing services map to resource-level implementations. They encapsulate technology choices (GPON vs HFC). If RFS ownership is unclear, technology changes require modifications across multiple systems instead of being contained in the service catalog. |
| CFS Instance | OSS | Service Inventory | SOM (lifecycle management), Product Inventory (linkage), Assurance (fault correlation), SLA Management (service-level monitoring) | CFS instances are the runtime record of active customer-facing services. They are the critical bridge for fault correlation: when a resource fails, the service inventory maps the impact to affected customers. Without a clear SoR for CFS instances, fault impact analysis is impossible. |
| RFS Instance | OSS | Service Inventory | ROM (resource orchestration), SOM (status tracking), Service Quality Monitoring, Capacity Planning | RFS instances track the technology-specific service components running on the network. They link CFS (what the customer sees) to resources (what the network provides). If RFS instances are not tracked in service inventory, the organisation loses visibility into how services are actually delivered. |
| Service Order | OSS | SOM (Service Order Management) | COM (status callbacks), ROM (downstream fulfilment), Service Inventory (instance creation), Operations Dashboard | Service orders track the fulfilment lifecycle at the service layer. SOM must own these because it orchestrates the execution sequence and manages dependencies. If service orders are owned by COM (a BSS system), the commercial/technical boundary is violated. |
Resource Entities
Resource entities represent the physical and logical infrastructure that delivers services. They are firmly in the OSS domain and are managed through resource catalog and resource inventory systems. Resource ownership is often the most contested area because network operations teams, planning teams, and IT teams may all claim authority.
Resource Entities — Source-of-Record Matrix
| Entity | BSS / OSS | System of Record | Typical Consumers | Why Ownership Matters |
|---|---|---|---|---|
| Resource Specification | OSS | Resource Catalog | ROM (provisioning templates), Resource Inventory (instance creation), Network Planning, Service Catalog (RFS-to-resource mapping) | Resource specifications define the types of resources available (port types, VLAN ranges, equipment models). If specifications are not centrally managed, different systems may use incompatible definitions for the same resource type, causing provisioning failures. |
| Physical Resource (Equipment, Port, Card, Fibre) | OSS | Resource Inventory | ROM (allocation and provisioning), NMS (monitoring), Network Planning (capacity), Field Workforce (installation), Assurance (fault localisation) | Physical resources are scarce, expensive, and shared. If resource inventory is not the SoR, double-allocation occurs (two orders claim the same port), ghost resources accumulate (inventory shows equipment that has been decommissioned), and capacity planning is based on inaccurate data. |
| Logical Resource (VLAN, IP Address, QoS Profile, VNF) | OSS | Resource Inventory | ROM (allocation), IPAM (IP management), NMS (monitoring), SDN Controller (configuration), Service Inventory (linkage) | Logical resources are dynamically assigned and recycled. Ownership clarity prevents pool exhaustion (all VLANs appear allocated but many are actually free) and address conflicts (two services assigned the same IP). IPAM and VLAN managers must synchronise with resource inventory, not replace it. |
| Network Topology | OSS | Resource Inventory (logical topology) / NMS (physical topology) | Network Planning, ROM (path selection), Service Qualification (feasibility), Assurance (impact analysis) | Topology defines how resources are connected. Ownership is often split: NMS discovers physical connectivity, while resource inventory maintains the logical model. If these diverge, path calculations are wrong, feasibility checks give incorrect results, and fault impact analysis misidentifies affected services. |
| Resource Order | OSS | ROM (Resource Order Management) | SOM (status callbacks), Resource Inventory (allocation updates), NMS/EMS (activation commands), Field Workforce | Resource orders track provisioning at the infrastructure layer. ROM must own these because it manages resource selection, reservation, activation sequencing, and rollback. If resource orders are embedded in SOM, the service and resource layers become tightly coupled. |
Operational & Revenue Entities
Operational entities support the day-to-day running of the telco: trouble tickets, invoices, usage records, and configuration state. These entities are often the most neglected in SoR governance, yet they are critical for assurance, revenue integrity, and regulatory compliance.
Operational & Revenue Entities — Source-of-Record Matrix
| Entity | BSS / OSS | System of Record | Typical Consumers | Why Ownership Matters |
|---|---|---|---|---|
| Trouble Ticket | Shared (BSS capture / OSS resolution) | Trouble Ticket System | CRM (customer view), Service Desk (agent workflow), Fault Management (technical diagnosis), SLA Management (SLA timer), Self-Service Portal | Trouble tickets span the BSS/OSS boundary: they are created in the customer context (BSS) but resolved through technical investigation (OSS). A dedicated trouble ticket system must own the lifecycle. If tickets are fragmented across CRM and NMS, resolution tracking becomes inconsistent and SLA measurement is unreliable. |
| Customer Bill / Invoice | BSS | Billing System | CRM (bill viewing), Self-Service Portal (online bill), Payment Gateway, Collections, Revenue Assurance, Finance/GL | Invoices are legal financial documents. Billing must be the sole SoR. If invoices are generated from multiple sources (billing for usage, CRM for one-time charges), customers receive partial or duplicate bills, and revenue recognition becomes unreliable. |
| Usage / CDR (Call Detail Record) | Shared (OSS collection / BSS rating) | Mediation Platform (raw) / Billing System (rated) | Charging Engine (rating), Revenue Assurance (reconciliation), Fraud Management, Analytics, Regulatory Reporting | Raw usage data is collected from the network (OSS) and rated by billing (BSS). Ownership transitions at the mediation boundary. If raw CDRs are lost or mis-routed before rating, revenue leakage occurs. If rated records diverge from raw data, revenue assurance cannot reconcile. |
| Network Configuration (device state) | OSS | Network Elements / SDN Controllers | Resource Inventory (intended state), NMS (actual state), ROM (configuration commands), Assurance (fault diagnosis) | The actual running configuration on network devices is the ultimate source of truth for network state. Resource inventory holds the "intended" state; the network holds the "actual" state. Reconciliation between these two is essential. If they diverge, provisioning succeeds in inventory but fails on the network — or vice versa. |
| SLA / Contract Terms | Shared (BSS definition / OSS monitoring) | SLA Management Platform | CRM (contractual view), Service Quality Monitoring (threshold enforcement), Billing (penalty/credit calculation), Customer Portal (SLA reporting) | SLA definitions span commercial terms (BSS) and technical measurement (OSS). If SLA ownership is split between CRM and monitoring tools, contractual commitments may not match what is actually measured — leading to disputed penalties and customer dissatisfaction. |
Consolidated Quick-Reference Matrix
The following condensed table provides a single-page reference for all entities. Use this for quick lookups during architecture reviews, integration design sessions, and vendor evaluations.
Complete Source-of-Record Quick Reference
| Entity | Domain | System of Record | TMF API |
|---|---|---|---|
| Customer (Individual/Organisation) | BSS | CRM | TMF632 (Party Management) |
| Customer Account | BSS | CRM | TMF629 (Customer Management) |
| Billing Account | BSS | Billing System | TMF666 (Account Management) |
| Contact | BSS | CRM | TMF632 (Party Management) |
| Product Offering | BSS | Product Catalog | TMF620 (Product Catalog) |
| Product Specification | BSS | Product Catalog | TMF620 (Product Catalog) |
| Product Instance (Subscription) | BSS | Product Inventory | TMF637 (Product Inventory) |
| Pricing / Tariff | BSS | Product Catalog / Billing | TMF620 / TMF670 |
| Commercial Order | BSS | COM | TMF622 (Product Ordering) |
| CFS Specification | OSS | Service Catalog | TMF633 (Service Catalog) |
| RFS Specification | OSS | Service Catalog | TMF633 (Service Catalog) |
| CFS Instance | OSS | Service Inventory | TMF638 (Service Inventory) |
| RFS Instance | OSS | Service Inventory | TMF638 (Service Inventory) |
| Service Order | OSS | SOM | TMF641 (Service Ordering) |
| Resource Specification | OSS | Resource Catalog | TMF634 (Resource Catalog) |
| Physical Resource | OSS | Resource Inventory | TMF639 (Resource Inventory) |
| Logical Resource | OSS | Resource Inventory | TMF639 (Resource Inventory) |
| Network Topology | OSS | Resource Inventory / NMS | TMF639 / TMF642 |
| Resource Order | OSS | ROM | TMF652 (Resource Ordering) |
| Trouble Ticket | Shared | Trouble Ticket System | TMF621 (Trouble Ticket) |
| Customer Bill / Invoice | BSS | Billing System | TMF678 (Customer Bill) |
| Usage / CDR | Shared | Mediation (raw) / Billing (rated) | N/A (internal) |
| Network Configuration | OSS | Network Elements | NETCONF / CLI / TR-069 |
| SLA / Contract Terms | Shared | SLA Management | TMF623 (SLA Management) |
SoR Governance Rules
The matrix above is only useful if it is enforced through governance. The following rules must be applied across all integration design, vendor selection, and data migration decisions:
SoR Governance Non-Negotiables
1
One SoR Per Entity — No Exceptions
Every data entity must have exactly one System of Record. If two systems claim ownership of the same entity, this is a governance failure that must be resolved before any integration is built. The resolution must be documented and approved by architecture governance.
2
All Writes Through the SoR
Create, update, and delete operations must flow through the SoR — either directly to the SoR's API or via a System of Engagement that delegates to the SoR. No system should maintain its own writable copy of data owned by another system.
3
Consumers Access Via API
All consumers must access SoR data via the SoR's published API (ideally a TM Forum Open API). Direct database access, shared databases, flat-file extracts, and batch synchronisation are anti-patterns that create tightly coupled, fragile integrations.
4
Reference Copies Are Read-Only
Systems of Reference (SoRef) may cache data for performance, but the cache must be treated as read-only and refreshed from the SoR. If a SoRef detects a data error, it must request correction from the SoR — it must never "fix" the data locally.
5
SoR Changes Require Architecture Review
Changing which system is the SoR for an entity is a major architectural decision. It affects all integrations, data migrations, and downstream consumers. SoR reassignment must go through formal architecture review and change management.
Common SoR Failure Patterns
Two systems both claim to be the SoR for the same entity. This typically happens when a new system is deployed alongside a legacy system without a clear migration of data ownership. Both systems accept writes, and over time their records diverge.
Example: CRM and Billing Both Own Customer
CRM has one customer address (updated by the call centre), and billing has another (updated by the payment team). When the customer moves house, they update their address on the portal (which writes to CRM), but billing still sends invoices to the old address. Neither system is wrong — they simply both think they are the master.
Source-of-Record Matrix — Key Points
- Every entity in the BSS/OSS landscape must have exactly one documented System of Record — no exceptions
- Customer, Account, Product Catalog, and Commercial Orders are BSS-owned (CRM, Product Catalog, COM)
- Service Catalog, Service Inventory, and Service Orders are OSS-owned (Service Catalog, Service Inventory, SOM)
- Resource Catalog, Resource Inventory, and Resource Orders are OSS-owned (Resource Catalog, Resource Inventory, ROM)
- Product Inventory (subscriptions) is BSS-owned and bridges the commercial and technical domains
- Some entities span the boundary: Trouble Tickets (BSS capture / OSS resolution), Usage records (OSS collection / BSS rating), SLA terms (BSS definition / OSS measurement)
- All consumers must access SoR data via published APIs — direct database access and flat-file extracts are anti-patterns
- Common failure patterns: dual masters, shadow inventories, stale caches, and ownership drift — all preventable through governance
- This matrix should be validated against your actual system landscape and maintained as a living architecture artifact