CRM, Policy Management & Billing Solutions – FTS
News & Events

Just what is a Unified Product Catalog? Opinion Article
3G Wireless Broadband, Volume 10, Issue 15

 
  
By Alon Alter 
Click here to download article in PDF format.

Vendors have long used the term “unified product catalog” – referring to a system that sets up and manages all sellable items, including telecoms-network services, content services, billing services, physical devices, accessories and third-party products or services – but now that so many claim to offer such products, it’s critical to decipher which are genuine and which are simply look-alikes. Can a single product really enable operators to launch new services at any time, over any infrastructure and from any provider without costly integration projects, as many vendors say? Or are there still limitations? And what does a genuinely unified product catalog look like from a technological perspective?

Service providers need a genuinely unified product catalog that offers the freedom to bundle products and services according to business requirements. A unified catalog can offer a single point of reference for all product-related data in a multisystem environment, composed of customer-relationship-management systems, billing systems and third-party value-added-services.

Part of the problem is that many vendors have grown by acquisition, leaving them with multiple systems with interfaces that weren’t designed to communicate with one another. Moreover, catalogs that are not designed to accommodate external catalogs with different structures and taxonomies will need to be adapted and customized for each external catalog. But the flexibility of a genuinely unified product catalog, offering sophisticated relationships between products and automatic transformation and substitution rules, can be achieved only with a system that is developed from the ground up to be unified, with an inherent architecture that clearly separates the catalog layers, enabling easy integration with external catalogs.

Three-layer architecture
A three-layer architecture – consisting of a component layer, a product-specification layer and a product-offering layer – enables an operator to offer cross-technology service bundles, multi-play packages and varying commercial pricing.

The component layer consists of services and tangible products that customers use, such as network services, content services, handsets, accessories and billing services. The product-specification layer is made up of marketing packages that include one or more components offered to users. For instance, the latest Nokia model can be bundled with an ADSL service to provide a broader telecommunications offering. Finally, the product-offering layer is a commercial representation of a single product specification, and it defines prices and customer eligibility by market segment, channel, time period and other relevant variables.

A product specification can be associated with more then one product offering, each with different pricing and discounts and targeting different market segments. Additionally, product offerings can be used for time sensitive campaigns.

The architecture is the most important factor in enabling a genuinely unified product catalog. The need for a system to treat data retrieved from external catalogs in the same way as data stored internally is as much an architectural problem as a technological one. But using the right technologies helps.

Other technologies
Technologies such as J2EE Connector Architecture (JCA) provide a foundation that supports unified catalogs. JCA defines a standard for communicating with external systems, enabling integration of multiple, heterogeneous catalogs into a single and coherent view. XML-deployment-descriptor elements are then used to dynamically map internal entities to external connectors, which are responsible for calling external systems for retrieval and updating purposes.

Combined, the architecture and technologies can create a metadata layer responsible for referencing the actual data, separating the internal mechanisms and the logical entities from the physical location of the data storage.

Vendors have developed connectors that call external systems without needing to change the logical entities and mechanisms of the unified catalog’s core engine. Retrieving an external catalog then requires just the creation of a connector to that catalog so that service providers can connect new product offerings to charging elements and price plans in the billing system, with no need for complex synchronization processes, data duplication or the costly engineering that would be required to make changes to the core engine.

The ability to make changes immediately and in-house is crucial and is generally possible only with inherently unified product catalogs. Service providers need to be wary of only partially integrated product catalogs, which require modification of the core catalog and its logical entities and which need complex synchronization processes to accommodate third-party catalogs or a variety of internal catalogs. It is a risky and costly approach, and the delays such a system would cause in launching new products and services can seriously harm a service provider’s competitiveness.

Alon Alter is senior product manager at billing-, CRM and business-process-control-software vendor FTS.

OSS/BSS Analyst continuous research service is published by Informa Telecoms & Media and is essential reading for anyone in the OSS/BSS industry, providing readers with an independent, insightful source of analysis, news and comment.
 

 

Formula Telecom Solutions