The product catalog is a repository where operators define, blend, bundle, price and retire their service offerings.
The importance of the product catalog cannot be overstated. It determines what the operator can sell, to whom, for how much and under what terms. It is a key factor in determining how quickly an operator can define new products and respond to competitive offerings. It is where operators differentiate themselves. It is a fundamental execution element behind the operator's product and market strategy.
Traditionally, the product catalog resides wherever the master customer account information is kept. In most cases this means within billing systems. But more recently, operators have been implementing the catalog within CRM. Coupling the customer database and the product catalog makes sense because of the close relationship between a customer account (where purchases are recorded) and the product database.
However, a number of factors in contemporary operator environments suggest that the product catalog should be decoupled from billing or CRM and given first-class status in the OSS. The idea here is to locate master product information in a stand-alone system and provide integration points for the various BSS and OSS systems to access relevant product information as needed.
The following factors are, in my view, the top drivers for an adjunct catalog.
Product bundling
In the consumer market, just about every wireline and cable operator is committed to a triple-play strategy. And most expect to add mobility and other entertainment elements to the bundle over time.
The success of an operator to blend, bundle, package and customize these service classes depends on being able to create offerings that span each service model and network technologies. The problem is that existing BSS/OSS were developed and optimized to support each of these product families (voice, data, video and others) individually—instead of across multiple service categories, which is the direction of the business.
The reality is that it is nearly impossible to take legacy voice/circuit product models and provide the level of abstraction needed for multiple product sets spanning voice, video and data services. The work-around has been to have each BSS manage its respective element of the product bundle (i.e., a distributed catalog). The problem is that this approach requires some fancy methods to glue the systems together for bill production, activation, and so on, thereby creating a synchronization nightmare. A centralized catalog is inevitable in this environment.
New service offerings
The second issue is that, within each bundled element, services themselves are becoming increasingly sophisticated. Wireless providers have the most aggressive plans, which include audio/video streaming (e.g., V Cast), messaging, presence, location, gaming and other entertainment products (discussed in detail in the next section). Likewise, wireline/IP operators are pursuing equally compelling products that include home security, smart home/car services, remote storage, on-demand software, IPTV, audio/video conferencing, click-to-dial, multi-party gaming, picture sharing, web collaboration, on-demand bandwidth and more.
In reality, no-one knows for sure which (if any) of these applications will be the killer app, which ones will just make it in the market simply as an incremental service, and which ones will be losers. But what is clear is that the IP community (SIP, IETF, 3GPP) is working very hard to develop the infrastructure and standards to support rapid development of just about any conceivable application.
Unlike past telecom generations, the OSS/BSS can't take years to productize a new IMS or SIP service. Today's winners are the ones that innovate. The product catalog must be able to keep up with the rapid service creation and have the agility to support the vast array of mainstream and niche applications that are contemplated, as well as the range of corresponding business models. These requirements are well beyond most legacy catalogues.
Third-party Products
Beyond transport and bearer-oriented services, another key driver is third-party content, applications, services and the like. The wireless industry has, by far, the most mature products in this respect. For example, consider Table 1—which shows the major categories in SK Telecom's 20 million content offerings (5,000of which are added daily).
Category Content Service
Category
Example
WAP
WAP Contents (v1.0, v2.0)
Location-based Service (LBS)
Mail, Personal Manager
Auto Navigation
Lottery, Stock, Ticketing
Mobile Banking, mCommerce
e-Business Card
Mileage Manager
Civil Affair Service
Download
Ring Tone
Logo, Animation, Photo
Java Virtual Machine (SK-VM)
Game Virtual Machine (GVM)
Karaoke
WITOP/WIPI (Terminal Platform)
Multimedia
Video Streaming
MP3 Music/Ring Tone
Media On Demand (MOD)
Video On Demand (VOD)
Wavelet
Multimedia Message Service (MMS)
Photo Mail
Video Conference
IMS
Push to Talk (PTT)
Instant Messenger (IM)
Others Coloring (Ring-Back Tone)
PDA Service
Table 1. Major content offerings supported by SK Telecom
The top brands and "Hollywood" producers want to market directly to the consumer. Therefore, if the operator wants to offer compelling content, it must be able to open up its billing system and product catalog to allow content suppliers direct access to manage their products and pricing (whether bundled, or a la carte). This type of functionality is foreign to traditional OSS/BSS infrastructure and catalogs. Certainly, it cannot be supported in a stagnant, legacy catalog.
Product, offer customization
Product managers are keenly focused on segmenting their customer base, and creating customized offerings for each. This is particularly true for the Tier 2/3 mobile operators and independents—how else are they going to differentiate themselves against the national operators? (Not by price.)
The approach today is to build on current generic "teenage" and "family plans," and focus on local communities, communities of interest and personalization. For example, a mobile operator (or MVNO) might develop packages centering on a particular league, team or even athlete. These packages might include content developed specifically (and exclusively) for these segments. They might also include special benefits such as discounted rates to other members or special rewards (for example, 100 minutes free when your local football team wins, or your favorite driver places first).
You can also imagine similar plans for TV shows ("American Idol"), games, music, hobbies, poker rooms or custom packages for enterprise customers (the "road warrior" plan), as well as plans tailored for specific industries (such as construction, health care, transportation).
These market strategies require a product catalog that not only can combine any set of products and services in an arbitrary fashion, but also can handle eligibility, "limited time," "try it/buy it" and other elements of promotions. This is a very tall order for legacy, embedded catalogs.
Specialized OSSs
As service environments become more complex to support next-gen offerings, "end-to-end" billing systems have given way to an ecosystem of highly specialized OSS subsystems. As illustrated in Figure 1, many of these OSSs require product information in order to do their job.
- CRM/ordering needs to understand what products are available to sell, to whom and on what terms, as well as who has purchased what.
- Billing needs to know what the customer purchased to accurately bill for it.
- Mediation needs to know what service usage information to collect.
- Rating needs to know what plan the subscriber is on, and product codes in order to price the usage.
- Service provisioning needs to map products into services, and in turn into network activation commands.
- Inventory needs to correlate resources with products and services.
- Care needs to understand product information in terms consistent with the product definition.
- Revenue assurance needs product information to audit.
- Service assurance need to know what products are sold and to whom, to correlate QoS/SLA violations for service credits.
- And more.
The problem is that each OSS must keep a local, duplicate copy of the product information. As a result, each OSS is expensive to maintain (as specialists are needed to statically configure each OSS), slow to implement and prone to high error rates. This in turn drives up order times, customer dissatisfaction and churn, and other issues.
A centralized catalog with open, robust interfaces that each OSS can synchronize against periodically, or in a cached manner, is the only way to address this problem.
Operations Costs
In addition to the functional issues discussed above, operators must continue their pursuit to improve efficiency and lower operations costs. Michelle Hankins's article in the November 2003 Billing World provides excellent coverage of this area, and reviews the operational impact of initiatives at Verizon and Sprint to centralize the product catalog.
The challenges, and what vendors are doing about them
The issues above offer a fairly compelling argument for an adjunct catalog, whether in a legacy, stand-alone or greenfield environment. However, as with any OSS, nothing is easy—and the adjunct product catalog is particularly problematic. In particular:
• How do you deal with integration (the No. 1 cause of death for an adjunct OSS)?
• How do you provide a sufficiently flexible product definition model that can represent both today's products and those not yet conceived of?
• How do you normalize product data and definition models across multiple, disparate OSSs—each of which have their own view of what product information should look like?
• How do you control access and deal with security?
• How do you deal with availability and provide OA&M mechanisms that make operating an adjunct catalog less difficult than replication?
• Since there are no standards in this area, how do you get the other OSS subsystems to conform?
These are the tough questions I asked DST Innovis, a leading vendor in the OSS/BSS industry that has an adjunct product catalog offering. The following is DST's response.
Implementing an Enterprise Product Catalog
By Michelle A. Nowak, DST Innovis
A major roadblock for service providers is that having more systems causes an introduction of fragmented product catalogs scattered across the enterprise for various purposes—increasing the complexity and lengthening the time of product launches.
The advent of the centralized product catalog that resides adjunct to existing applications—providing a minimally invasive solution to extend the enterprise systems—holds the promise of launching new offers with less effort. When a centralized product catalog does not exist, service providers face the challenge of determining where the complex product offerings are mastered. Original systems were designed for much more stable and simple products in a single, vertical market. As the market continues to dynamically transform and grow, the complexity of the offerings has imposed new requirements on existing product models. This emergence has placed further constraints on systems that are code-based (USOC, FID, S&E, Rate Code, etc.).
The Enterprise Product Catalog (EPC) has to be designed to be service- and market-agnostic, basically a unified portfolio management solution for convergence across all lines of the service providers' business. Using an EPC approach, there is no longer a need for a team of specialists to update legacy tables with codes, or for software developers to change an application in order to get the new offering to market. Products and bundles can be created and configured in a matter of minutes by product managers.
Inherent EPC capabilities must focus on rapid and flexible configuration of products and ease of assembling them into bundles, by using independent and reusable catalog items with a customer-centric context. That means it must innately provide for the definition of products that are to be charged, provisioned, or both; the addition of new information (without any software changes); the separation of pricing elements from the creation and configuration of a product; the designation of prerequisites; and classifications. Employing a rules engine enables complex, customizable decisions, including:
• Where are the products or bundles sold?
• Which customers can purchase the product?
• Through which sales channels can they be purchased?
In order to satisfy the requirement of communicating with data legacy applications and third-party applications, the EPC must have a built-in reference infrastructure that facilitates ease of integration, eliminating the need for laborious maintenance of cross-reference tables between the centralized product catalog and the external systems that require the information. Once in the catalog, edge systems can easily leverage the catalog contents, and catalog changes can be propagated to CRM, billing, provisioning and other OSS system catalogs though API mechanisms. This avoids data redundancy and issues of integrity, latency and synchronization, while providing security and ultimate end-to-end accountability of the process.
Architecture
From the onset, the EPC has to be architected and engineered to enable a harmonious coexistence with multiple systems and databases. To provide the flexibility that allows reusing and combining business processes and the underlying services to address changing business requirements, a Service Oriented Architecture (SOA) is implemented.
Three key architectural concepts are implemented in the EPC as part of its overall J2EE SOA. The first is extensible public XML APIs, where system business-level transactions are exposed in a request-response set of services employing industry standard technologies (XML, HTTP, SOAP). The request-response APIs can be extended through configuration to pass customer- and product-defined elements into any transaction, since all functionality has the ability to be exposed. For example, a "get eligible products and prices" API can return the product offering to the CRM application based on customer attributes that are not inherent to the catalog.
The second architectural concept is event notifications, whereby the system publishes significant events from the EPC to other applications that subscribe to the system's events. The information contained in the event message can be extended by the customer. An example is "add product." When the product is added to the catalog, downstream billing applications can be notified and updated accordingly.
The third architectural concept is import-export. This is the most simplistic concept of file-based data exchange or data replication between the EPC and legacy applications that do not support open standards or interoperability through the two previously mentioned concepts.
Solution Integration
Before an organization can embark on the integration of an enterprise product catalog, the service provider must complete three main areas of assessment: business scenarios and processes, identification of system-to-system transactions, and definition of data requirements for system-to-system transactions. The result is an executable architecture and strategy that fits the service provider's unique operations.
Two common problems we experience during EPC implementation involve synchronizing product information across systems, and obtaining data from databases that reside outside the EPC in order to create more complex business transactions required by enterprise systems. To address these problems, an Enterprise Architecture Integration (EAI) layer and business flow engine are often introduced into the enterprise (see Figure 2).
The EAI is the enterprise services bus that acts as the integration backbone to perform data transformation and intelligent routing of product catalog information, reliably connecting and coordinating it with the underlying systems that span the enterprise. It treats all applications as services, regardless of how they are connected to the bus. Where the EPC is the master product catalog, one or more product catalogs will likely need to be kept current when there is a change to the EPC (add product, discontinue product, and so on). Through a publish-and-subscribe method, the EAI can listen for the notification and, when it receives one, transforms the EPC data and moves it to the one or many systems that need to be updated.
A business flow engine is used to flexibly determine the specific set of business logic steps and coordinates the transactions, including those to accomplish an EPC transaction. It presents a higher-level interface across the enterprise when multiple applications must cooperate to accomplish a business function. A call to the EPC API is routed through the engine, invoking the pertinent business flow.
In order to create more complex business logic or obtain data from a database not resident to the EPC data model, the business flow is customized. By altering the XML file that defines the API, you can add steps into the EPC API call. For example, you may want to check inventory when service is ordered (MTA, a set-top box). As the inventory information is not resident to the EPC, the API can be customized by adding a "check inventory" step. That step verifies stock availability with the inventory system. It returns information to the API that is used to ensure the item is in stock for orders requiring customer premises equipment. This verification can occur during the "prerequisite product check," after the EPC has found the "eligible products and prices" for the customer.
Standards
Currently, no published industry standards specify the APIs or data structures for exchanging product information. An expert group has been formed as part of the OSS/J forum to establish a Pricing API to build on the OSS Common API and supporting technologies. The API will promote product offerings and pricing within the enterprise systems environment. OSS, CRM, and other edge systems will be seen as the subscribers to this information, as opposed to being the owners. The Java Specification Request 251, Pricing API, is gaining momentum in the Java Community Process; the development and approval of this specification is expected to continue into the second quarter of 2005. In the interim, the best practices are to deploy standard technologies, implement an SOA, and ensure that all functionality needed to manage products and their availability is readily exposed.
A true standalone enterprise-class application must be developed from its inception to work as an adjunct solution within the service provider's existing environment, and to contain the frameworks and leverage the technologies that make possible integration to vendor-provided or internally built legacy systems and third-party software. Implementing a true SOA adjunct EPC solution that closely follows the architectural and design principle of J2EE eliminates obstacles to success by removing fragmented, underpowered, and slow-to-launch tools and practices for product management.
A robust product catalog is a critical element of the modern, converged service provider's systems. It enables providers to rapidly roll out new service offerings, across multiple legacy line-of-business systems, while allowing a holistic enterprise view of the offering. Strong enterprise product catalog capabilities may be a key element for providers who are dealing with the rapidly changing communications industry. The EPC provides the focal point for managing product information for any organization desiring a centralized product repository to maintain a pure product focus with seamless extensibility—across the enterprise and all lines of business.
Note: In a future issue of Billing World & OSS Today we will hear from Intec, an OSS/BSS company that also has a leading edge adjunct product offering, to get its opinions on the tough integration and standardization issues.
About the authors:
Michelle A. Nowak is vice president of product management for DST Innovis, a software provider of products and services for the communications industry. The DST Innovis Collabrent solution contains an enterprise product catalog component built using J2EE/SOA architecture.
Dr. Matthew Lucas is vice president of TeleStrategies, and focuses on the OSS/BSS industry. He founded RateIntegration in 1999 and served as the firm's president and CEO through 2002. He co-founded IPDR.org and served as president through 2001. He holds a doctorate in computer science from the University of Virginia and can be reached by e-mail at: mlucas@telestrategies.com.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article