article page
| 1 | 2
| 3
| Element Managers (NEM), and ultimately, the network.
A model with an independent product catalog servicing the upstream systems and a service catalog servicing the downstream systems poses some challenges:
- The definition of a new QoS, with associated characteristics in the product catalog, requires knowledge of the network that more properly lies within the service catalog.
- To enable product catalog based management of QoS, these characteristics, and the associated rules and network knowledge, need to be replicated in the product catalog.
- Defining the availability rules for the new offering requires knowledge of network coverage, supporting technology, and available resources.
- Building all of this into the product catalog is not a viable alternative.
Conversely, if the QoS is more properly modelled in the service catalog, how does a QoS based CFS defined in the service catalog expose itself to the product catalog for use in the definition of new Product Offerings? How does the product catalog evaluate the availability rules?
The answer lies in the tight integration of the product catalog and service catalogs. The product catalog must invoke availability queries into the service catalog for each request. Product catalogs must handle volumes generated by customer browsing, quotations and orders. This volume, in a service catalog scenario of tight integration, will be transferred to the service catalog. Service catalogs are engineered to handle order volumes, only a small portion of the browsing volumes handled by product catalogs.
|
|
A model with an independent product catalog servicing the upstream systems and a service catalog servicing the downstream systems poses some challenges |
|
Bridging the Gap
With these challenges in mind, the advantages of a solution that is able to support both product catalog and service catalog functionality is readily apparent:
- A single common data model ensures consistency in product models
- New CFSs are immediately available to be used in Product Offerings
- No replication of network knowledge across product catalog and service catalog as they share the same definitions.
- A holistic, end-to-end view of the Product Offerings is available, including a view into the underlying services.
Continuing with the example, the QoS capabilities of the network, availability rules, and quotas would be defined in the Service Catalog and exposed as a CFS. These CFSs would be immediately available to the Product Manager in his definition of the new Product Offering. The net result is the ability of a Product Manager to define a new Product Offering, on-the-fly, without requiring changes to be made within another catalog.
Essential Requirements
of a Consolidated Product
Catalog/ Service Catalog Solution
A consolidated solution does not obviate the need for sophisticated Product Lifecycle Management (PLM). The catalog solution needs to provide a full featured workflow engine to manage the PLM process across multiple functional organizations, and indeed across the full supply chain and all sales channels. The solution must be able to integrate with catalogs that will inevitably exist in other applications within the CSP, channels and supply chain. With integration comes fall out and the need for robust exception management capabilities. The catalog assumes a central role in the CSP’s portfolio and needs to have the flexibility, robustness and performance of a purpose built enterprise application.
Extensibility of the catalog solution is critical. An ISV solution must be able to adapt to the unique categorization / tracking needs of the CSP with the addition of attributes that can support high-visibility placement in the user
article page
| 1 | 2
| 3 |
|
|
|
