e these two catalogs have similar concepts and share a significant amount of common information, they are not identical. Chapter 6 - Integrating the OSS Platform Which application or product catalog should be the master? There are two potential answers. In some OSS configurations, a particular package may contain a sufficiently robust product catalog, possibly because it was designed to support multiple roles, e.g., a combined order entry and billing package. Its range allows it to be used, to some extent, as the master. This is an area where highly integrated packages have a clear advantage over "best- of-breed," because they tend to consolidate more functions a comprehensive product catalog. The second solution is to deploy a completely independent product catalog that sits outside of all systems, typically in the middleware, and contains a complete view capable of supporting all subordinate catalogs. Both approaches have been attempted with varied success. The challenge with the former approach becomes the comprehensiveness of the master definition. Since the product catalog is being stretched, does it really support all of the roles it needs to? The challenge with the latter approach is the constant process of maintaining the rules and definitions external to the applications. It is here that a third issue can kick-in. Returning to our engine analogy, if we have the "universal engine," how do we hook it up to the different vehicles? If we do not connect the engine to the transmission, electrical, and cooling systems, we are not going anywhere. For example, if we import the product catalog into the OM and provisioning application, but fail to connect the product definition to the appropriate provisioning flows, is it sufficient? If not, how much of the OM and provisioning application's functionality do we have to import into the Universal Product Catalog to achieve integration? Do we end up replicating a good deal of the billing, SFA and OM configuration functionality in the Universal Product Catalog and in th