Vodafone Germany successfully implemented the Service Inventory Integration solution as the technical basis for several integration scenarios until 1st quarter of year 2005. The implemented solution is illustrated in the picture below. It has been used as the basis for the Service Inventory Interface between the “Topology and Use Case Repository for Services” (Tours) system which was based on HP Service Desk and the Change Mgmt. System based on ARS Remedy with a local customization from Ascom.

Other client system are already planned to be integrated in the future, like the Service Monitoring system, the SLA Management System and the Trouble Ticketing System. It is very likely that there will be a large number of additional clients in the future.

Background Information:

A general requirement of customer service oriented network and service operations is the modeling, which includes Life Cycle Management, of services and their inventory. Services offered to customers are usually built from basic technical services (means resources) delivered by infrastructure elements (E.g. mobile network services like the GSM- bearer, GPRS- bearer, UMTS- bearer, and IT – server based services like WAP, SMS, MMS, etc.). Those basic services are configured, amended with quality metrics, and bundled to address requirements of customer segments or individual (E.g. corporate) customers. This can be combined with customer specific service level expectations.

The information about the products which have been subscribed by the customers, the basic customer-facing and resource-facing services which have been composed to a product and the resources those services are built upon, is essential for many different business and operation support domains. Those domains have a need to create, update, delete, and query service inventory information. For example, the integrated service monitoring system needs to support navigation through the inventory for top-down and bottom-up analysis (from Product to Service to Resource – Level and vice versa)

The Service Inventory at D2 (a special customization of HP´s Service Desk) acts as a Service Catalogue (Master) which is not limited to a simple list of D2´s services. In addition, it contains the relationship between services and resources, as well as to the products, in line with the core of the SID model à The (Vertical) Service Topology. Furthermore, the system describes the horizontal relationship between the Service Components (so called Sequence Steps).

So, the primary objective is to document the services, which are captured in a complicated dependency graph, in a classical service tree from the product/services level to the systems, or hardware level. Secondly, it documents the horizontal dependencies in a way that shows the data flows. With this model it is possible to build a complicated dependency graph in a way that users can handle without losing information.

The picture below shows the basic principles, in which way the horizontal and vertical dependencies are modeled:

Here is an example of the instantiation of this model:

Topology

Sequence Steps

Short Description of the System:

Functionally, this interface solution provides documentation of the Service Topology. It stores products, Services and Resources along with the relationships between these objects. The relationships between the objects are stored in the service tree as well as the horizontal relationships (the sequence steps needed to deliver the service). This includes relations to service components of other service trees.

The implemented Use Cases include (1) Analysis and isolation of failures (1st and 2nd Level Support), and (2) Change Management (faster analysis of impact by faulty components and planned changes.

Benefits:

− Central data source for other (SM) Components
− Central, consistent and independent knowledge base for services (service catalogue)
         • E.g. for change management, especially for risk analyses
− Presentation of the complex dependencies in the service environment
        • E.g. for integration of new services, fault management, etc.

That means the Service Inventory is a major source for a number of other OSS applications. It delivers answers to questions. For example,

• What is the impact on the service availability for customers, when specific resources are out of order in case of failures or planned maintenance work?
• What are potentially defect resource-candidates for the problem detected by an end-to-end probing system?
• Which services can be related to a specific customer SLA?
• Etc.

So, it is essential for other OSS tools to be integrated with the Service Inventory, which enables the automation of several operational business processes via the OSS/J Inventory API.

The API itself uses a SID compliant information model to allow a standardized way of communication between all these vendor specific OSS components. All of them use (and can use) their own information model, which are (or will be) mapped onto the common SID model.

The embedding and integration of OSS/J (operations support systems through Java™) capabilities in the ToURS solution as a northbound interface will lead to additional savings. OSS/J technologies enhance new generation operations support systems and software (NGOSS) by adding technology-specific components that are re-usable at the implementation, integration and deployment levels. For example, the change management system can identify which service is impacted by the change on network resources through the OSS/J API (application program interface). Another northbound integration is to the service monitoring system for real-time service impact analysis, which is currently on its way. That means the solution interoperates between the fault management and service management systems. It lets us correlate the alarms the system generates against our service topology management, so we can see what is affected—what is the root cause of our problem and which services were impacted.

-> So there is a need for integration with other OSS/BSS components

Cost Benefits / Savings:

Comparing our first steps with NGOSS & OSS/J to former integration projects shows clear benefits from a cost perspective. Here is cost comparison between a proprietary point-to-point integration versus the OSS/J approach:

Development of a proprietary interface between Service Inventory and OSS clients like Service Monitoring and Change Management:

Using the following assumptions:

• There are costs for the development of each point-to-point interface on the server side as well as on the client side.
• X=Y=Z (means: the costs might be the same for each part of the interfaces)

Result  ->  Costs: 4*X

Below illustrates the implementation of the OSS/J Inventory API as a single server-interface to the Service Inventory system. This allows the re-use of the interface connection and the de-coupling of the OSS components. Furthermore it allows re-use of that interface for other integration scenarios, which leads to additional cost savings.

Using the following assumptions:

• There are costs for the development of each interface on the client side and only one (standardized) interface on the server side to address the needs of both clients.
• X=Y=Z (means: the costs might be the same for each part of the interface)

Result  ->  Costs: 3*X

That means a cost reduction of 25 % for this simple example.

These savings where possible by re-use of the Service Inventory Integration solution for different scenarios. Further savings are expected by re-using this solution for additional integrations with other OSS components, and potentially for the exchange of service – information between different Vodafone subsidiaries.

An important driver for cost reduction over the whole solution lifecycle is the fact that all involved parties, i.e. customer's functional and technical department, OSS vendors as well as systems integrations companies use a standard interface (the INV API), standard data models (CBE, SID) and talk the standard “language”, using the TMF’s NGOSS defined terminology and syntax.

E.g. currently other Vodafone subsidiaries are in various stages of deploying OSS/J solutions. The same implementation approach has been used for the trouble ticket interface at the Trouble Ticketing systems and the Fault Management systems. This is now going into production or in different project stages at other Vodafone subsidiaries. The service inventory API solution has the potential to be next for them. What ToURS brings together is access to the different inventories. At Vodafone D2, for example, there is an IT inventory, a network inventory, and ToURS uses both of those. Vodafone D2 values the openness of OSS/J standards. OSS/J is a TeleManagement Forum initiative that offers a suite of functional OSS APIs, which use Java, XML (extensible mark-up language) and Web Services as underlying communication protocols. The APIs are aligned with the NGOSS architecture, quickly linking OSS applications together throughout their life cycle. While protocols specifications and message formats such as XML are important to achieve interoperability, as well as cost savings and reduced risk of integration, it’s even more important to make sure the applications are prepared to exchange the same information, the same semantic, using the same interfaces. Now when faults occur, as they inevitably do, Vodafone D2 has the visibility to determine which customer services are most impacted, and can then take immediate proactive steps to minimize that impact, which translates to improved customer satisfaction—the value of which is difficult to overstate in today’s intensely competitive telecommunications environment.

Andreas Buschmann   Network & Service Management Engineering, Vodafone D2 GmbH