sharkasmAT A GLANCE
- Bring service and resource inventory together with catalog and geographic context.
- Use TM Forum API-based interfaces for the inventory and catalog work documented in OneInventory.
- Connect provisioning questions to service assignments, product context, and access-network state.
- Address usage detail and consumption reporting as part of the relationship between network operations and business systems.
01 / 08
Connect the complete service lifecycle
OSS/BSS is a core discipline in the portfolio, linking telecommunications operations with business systems. The scope includes inventory, catalogs, provisioning, usage, and the interfaces through which those concerns interact. A service experience depends on this relationship: what can be offered, what has been assigned, what was provisioned, and what is happening in operation are connected questions.
The portfolio makes that connection concrete through OneInventory, the DOCSIS/FTTH work, usage architecture, observability, and configurable AI-assisted diagnostic workflows. These capabilities address different parts of the lifecycle. The architecture challenge is to keep their responsibilities clear while making the information needed by the next consumer available in an understandable form.
02 / 08
Give catalogs and inventories distinct meanings
Catalog information describes the definitions available to a service or resource process. Inventory information describes the instances and relationships that exist in the environment. Both are necessary, but they answer different questions. Confusing a definition with an installed instance can make a provisioning or support conversation ambiguous before any technical work begins.
OneInventory provides service and resource catalog capabilities alongside service and resource inventories. The portfolio uses that separation to explain how a technical service is represented. An operator can discuss the relevant definition, identify the actual service instance, and relate it to the resources that support it. This creates a clearer basis for investigation than relying on a single record to stand for every stage of the lifecycle.
03 / 08
Establish resource and service context
Resources, services, addresses, sites, locations, and IP address assignments provide the context needed to understand an operational environment. OneInventory brings these areas into a modular platform with standardized interfaces and an administration experience. Topology and history add further context about relationships and change.
The useful question is not simply whether a record exists. It is whether the record represents the right object and whether its relationships explain the service under investigation. That is why discovery and reconciliation matter alongside record management. The portfolio’s inventory work supports the broader OSS/BSS objective of making service and resource information usable by processes that depend on it.
04 / 08
Use interfaces to clarify ownership
The inventory and catalog work uses TM Forum API-based interfaces. In OneInventory, service inventory and resource inventory are exposed through their respective application boundaries, alongside catalog and geographic functions. The practical point is to give consumers a defined place to request or manage the information they need.
Standards-oriented interfaces do not eliminate the need for architectural decisions. Teams still need to agree on the authoritative owner of a fact, the meaning of a state, and the behavior expected during a change. The portfolio treats interface design and ownership as related concerns. A consistent interface becomes most useful when its operational meaning is equally clear to the producing and consuming teams.
05 / 08
Connect provisioning to the right evidence
Provisioning questions require more than an order status. A service may depend on inventory assignments, catalog context, access-network state, and customer-premises equipment. The PyBrain provisioning-fallout template demonstrates a configurable sequence across those systems, beginning with the order and events before moving to the relevant service and access checks.
This is a useful example of OSS/BSS integration because the answer is distributed. An order record describes process state; inventory describes assignments; access systems describe technical provisioning; device information describes the endpoint. Bringing those observations together supports a more precise explanation of where the process and the technical state agree or diverge. The actual system endpoints are supplied when configuring the template for an environment.
06 / 08
Keep usage connected to business interpretation
Usage data bridges network activity and the business-facing views that consume it. IPDR, CDR, and TDR processing provide source observations, while service and product context determine how those observations are interpreted. Detailed usage and consumption summaries serve different audiences and should remain clearly defined views.
The OSS/BSS perspective asks where interpretation belongs and which information is authoritative. A raw quantity does not independently define a commercial allowance, and a summary does not replace the underlying event history needed for investigation. The portfolio’s usage work develops these boundaries alongside Kafka and data-platform architecture so that consumers can use the information without losing the meaning of the original records.
07 / 08
Make modernization an incremental architectural exercise
Modernization concerns more than selecting replacement systems. A useful review identifies the capability being changed, its current consumers, the data it owns, and the integration responsibilities that must continue to work. This is the consulting perspective applied to OSS/BSS: make a change concrete enough that its dependencies and operational implications can be assessed.
The completed platforms in the portfolio provide implementation context for that discussion. Inventory, AI agents, event processing, retrieval, and observability can each be examined as a distinct responsibility. The objective is to connect capabilities deliberately rather than build a new set of tightly coupled assumptions. Environment-specific migration decisions still require their own evidence and acceptance criteria.
08 / 08
Follow a service question across domains
An illustrative investigation might begin with a service that appears ordered but not active. The team establishes the order context, checks the intended service and resource assignments, examines provisioning events, and inspects the relevant access state. If the views disagree, the next step is to identify which system owns the fact needed to resolve the discrepancy.
This pattern connects the disciplines represented in the portfolio. DOCSIS/FTTH supplies access expertise; OneInventory supplies resource and service context; PyBrain provides a configurable way to organize cross-system checks; observability explains execution; usage connects activity to consumer-facing information. OSS/BSS is the lifecycle perspective that makes these capabilities part of one service conversation rather than a collection of unrelated technology demonstrations.
LET’S MAKE THE CONNECTION
Put this experience
to work.
Bring your requirements, your operating context, and the question you want to answer.
Discuss OSS/BSS ↗