This solution addresses the needs of a cable system operator who needs to perform capacity management on a multi-service digital cable network.

Definition of the business problem

In today's market, service providers aim to ever increase the time-to-market of new and enhanced services in a cost-conscious manner. As a consequence, the need arises for existing OSS/BSS infrastructure components to adapt in an ever increasing pace. This affects not only OSS applications themselves, but also increasingly their integration. An integration strategy built upon standards and common off-the-shelf (COTS) middleware presents a solution to this challenge.

Today, there is a growing demand for automation of business processes at service providers, especially in the area of network/service operations to improve operational efficiency. This leads to the need for improved integration of operational support systems. The integration of Service Inventory systems with other OSS components, such as Change Management, Service Monitoring, and SLA Management is a common demand from various service providers.

       
  Typical Integration Scenario

Most of the existing integrations between Service Inventory systems and other OSS systems are based on proprietary point-to-point interfaces although vendors offer “standard” interfaces such as SNMP, CORBA, etc., which are adapted to their applications. In a real integration scenario these interfaces need a lot of customization to fulfill the business requirements and to allow the communication between different proprietary OSS systems because each of these applications follow its own business process, internal logic and semantic. Usually application (A) needs to know a part of the business logic of system (B) (and vice versa) to be able to implement the interface. This situation ends with the implementation of very specific interfaces with dependencies on the integrated OSS systems. This means, re-use of interfaces or dedicated parts of the interfaces in other integration scenarios is not possible. So, there is a need for a standardized interface, which delivers the semantic connectivity and not only the underlying transport mechanisms, which helps to provide out-of-the-box interoperability and more flexible integration.

IT operations together with ITIL had been using service model based approach to Service Management. The products which were developed for IT using ITIL oriented configuration Management Database (CMDB) had the required functionality and were mature enough to use in a carrier grade Service Management solution. IT to Telco convergence which is driven by next generation services, and has been instrumental in “cross pollination” of Telco and IT approaches to solutions that support these next generation services.  Prosspero Service Inventory is a prime example of this!
The Service Inventory Solution Package shows a standardized way to integrate the Service Inventory, by using the OSS/J Inventory API.  It allows to publish and query single objects and relationship information, as well as various dependency analysis (direct/indirect, bottom up/ top down, in-/excluding objects etc.). This integration is a key for client systems to complete their functionality without implementing redundant, unsynchronized databases and functions. Using this API improves the cost efficiency by delivering a standard facade for any other OSS application that needs information about the service topology (e.g. incident, problem, change, or service level management). 


 

Scope of the solution  

Implementation of a standardized, re-useable “Service Inventory Integration solution” which offers a standard Service Inventory Interface for the integration with other Operational Support Systems (OSS) acting as clients to the Service Inventory (server) system.

Typical clients of the Service Inventory are Service Monitoring Systems as well as Change or Workflow Management systems.

The solution package can be used as a logical link between the generic TMF specifications in the Inventory domain and the real world implementations (the OSS products) in that area. It shall help to understand the way from abstract specification work to concrete projects, using the deliverables of the TMF programs. The intention is to offer a starting point for these projects, by the description of the business scenario, things to consider, needed artifacts and potential contact partners which can be helpful to start further, more detailed work.     

 

This solution package uses the OSS/J Inventory API (especially the Service Inventory part of the API) as a core component to reduce the cost and complexity of integrating inventory components with other OSS components. The API provides a solution for managing cross-component inventory relationships, which is a complex task in a typical OSS system, due to incompatible APIs and different information models.
The focus of this package is in the Service Inventory part of the OSS/J API in distinct to resource or product inventory interfaces, because each of these domains have (and need) a specific set of functions, managed entities, relationships and support different business processes. That means also, that the service inventory will interact with a set of clients which is different to resource or product inventories (but they have to interact between each other).

Value Proposition

The Service Inventory Solution Package:
- Provides an implementation starting point for Service Inventory integration projects, removing uncertainty and risk.

• How to integrate with other OSS
• Who / which vendor/integrator has experiences with it
• What has to be considered from project
• How to implement and use the (which) standards

-  Benefit from broad industry support and know how for implementable and certifiable TMF standards, proven in real Service Inventory integration projects.

• Instead of re-inventing the wheel with proprietary local solutions
• Supported by test-tools, design guides, reference code, cook-books, etc.

 
- Enable mass market adoption of Service Inventory standards à Adopters become part of a community and supporting ecosystem. Within this community, they share the investment and the risk to collectively eliminate common pain points.