Products are things (tangible or intangible) which enterprises, such as service providers, market, sell or lease to customers to create profit.  In a changing world, monopoly telcos with a custom-built portfolio have been replaced by a value network of Suppliers and Service Providers offering complex communications-based Products. The way in which those Products have to be specified is not as simple as it used to be.  <br/>A product serves as a window for customers and users into the world of the services and resources used to realize the product. <br/>Customer/user always deals with products, unless the individual/organization they represent is playing the role of a service technician or some similar role. A user uses a Product to obtain its value promise, e.g. to make a phone call<br/>Neither the Product User nor the Customer can see the CustomerFacingService. They only can see the Product.<br/>A ProductSpecification may be simple (atomic) or a composition of other ProductSpecifications [Fowler-Specification]. A ProductSpecification may represent a tangible object or something intangible provided to customers, realized as a ‘service’ but not to be confused with a network service here. The SID modeling of a CompositeProductSpecification covers both the physical build of more than one ProductSpecification and one or more ProductSpecifications supplied together in a collection. ProductSpecifications may also exist within groupings, such as product categories or product lines or product types.<br/>Enterprises may assemble products themselves or they may buy them in from other suppliers (through contractual agreements where the enterprise takes the role of customer - see SID Common Domain guide book); or they may do a combination of these things.<br/><b>Product Specification Example - The "3G Mobile super saver pack"</b><br/>This is sold via intermediaries ("Dog-n-Bones-R-Us" phone shops) as a "BigTelephone" branded product.  Nokia supply the phones and provides a 2-year guarantee. The "BigTelephone" network is used for voice and they supply a phone number and a SIM card.  The SMS function is provided by "Best Messaging”, as "BigTelephone" doesn't have an SMS function.  The customer signs the contract with "Dog-n-Bones-R-Us" for 2 years with minimum monthly calls and Dog-n-Bones-R-Us bills the customer directly.  Dog-n-Bones-R-Us has a separate contract with “Best Messaging” to cover the use of their SMS function. In looking at the detail of ProductSpecification, the following concepts are modeled by the figure below:<br/>        • Relationships between different ProductSpecifications for bundling or composite specifications;<br/>        • Different attributes for different types of ProductSpecification; for example, some Products the customer can take home with them, others they experience as a Service; for example, one delivered across a network;<br/>             • Atomic ProductSpecifications which cannot be broken down further. <br/>             • CompositeProductSpecifications which comprise a number of other ProductSpecifications, any of which may provide more than one instance per CompositeProductSpecification.<br/><i>Note:  A ProductSpecification cannot contain itself, but it can reference other ProductSpecifications.</i><br/>At least one action is allowed for a ProductSpecification (AllowedProductAction) such as create, update…that might be limited to one or many SalesChannels. An AllowedProductAction has a type represented by a ProductTypeAction.<br/>For ProductOffering a Customer could upgrade their offering on the web, but to downgrade they need to come into a store or contact a service representative.<br/>An AllowedProductAction might imply changes from one ProductConfigSpec to one or many ProductConfigSpec.<br/>Thus, it is possible to define actions such as upgrade or downgrade and specify which SalesChannel enables these actions.<br/><br/>In all combinations of products, there must be clearly defined relationships between the products in order to ensure consistency of service to the customer.  Some examples of such ProductSpecificationRelationships would be migration, exclusivity, dependency and substitution, as indicated in the Figure below.<br/><br/>Often it becomes essential to group product specifications. SID supports following two ways in which product specifications can be grouped<br/>        • Based on how the product specs are organized in a product portfolio<br/>        • Based on common characteristics<br/>These groupings are supported by ProductSpecificationType entity and its two subclasses Product Line (Based on how the product specs are organized in a product portfolio) and Product Category (Based on common characteristics). Product Line represents the coarsest form of grouping of product specifications.<br/><br/>“ProductSpecificationType” is a specialization of “EntitySpecificationType” and as such it inherits the recursive association “EntitySpecificationTypeRelationship”. This can be used to represent how a Product Line is associated to multiple Product Categories. For example, ProductLine “Home Security” is composed of different Product Categories “Door Alarms”, “Security Lights”, “GPS & Tracking” etc.<br/><br/>Same Product Category can also be used across different Product Lines. For example, same set of “Mobile phones” Product Category reused across Product Lines “Mobile Residential” and “Mobile Enterprise”.<br/>The decision regarding when to model a ProductLine or ProductCategory is often left to the discretion of the Product/Marketing managers.<br/><br/>There are also costs associated with creating, developing and maintaining a ProductSpecification; the enterprise records these against the ProductSpecification.  There is an implied link between the ProductSpecificationCost entity and business information, but this has not been explored in this area of the SID model.<br/>