f product catalog definitions and mapping rules for each integration point. Needless to say, there are no industry standards for product definitions. Nor are there standard data or object models that OSS vendors follow. While many packages provide an API that allows other applications to extract information from their internal product catalogs, very few provide a mechanism to import definitions from other applications. In other words, most product catalogs speak their own language and cannot understand or interpret any other product catalog. Without a mechanism to automatically create definitions, product catalog synchronization is left as a manual process - an unsatisfactory solution. A secondary, but possibly more challenging, issue arises in trying to determine which application should be the master of the product catalog. In other words, which application should be the source of updates to other product catalogs, assuming that some mechanism exists physically to accomplish the update? In order to understand the difficulty in answering this question, it is necessary to understand that product catalogs perform different roles in different packages. To make an analogy, an internal combustion engine has pistons, crankshafts and cylinder heads. But is a lawnmower engine the same as the engine in an 18-wheeler? Is the engine in a Ferrari the same as the outboard motor on a boat? They all share common concepts and design principles, but they differ greatly in the details of their construction and in how they are used. Product catalogs work similarly. The product catalog in the SFA package is focused on presenting product information sufficient to allow the generation of quotes and the configuration of a sales order. The product catalog in the order management and provisioning system is focused on the details of the individual components that make up a product, and what is required to provision and activate them. The product catalog in the billing system is focused on rating, discount and tax calculation. Again, whil