On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.
I am very surprised by this statement. Why wouldn't we want to take advantage of the ability to define complex product specifications. IMHO it would be an abuse to do this with product offerings, except when the composite structure has commercial implications; e.g. a sub-product is optional, or has a separate price attached.
Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."
IG1233 essentially serves as a guide from Orange's perspective and experience.Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.
While it remains a valuable resource, it's advisable not to follow it verbatim.
It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.
Hi Mahesh, Jonathan and Matthieu
IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.
I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.
We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.
If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases
And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.
When considering your design choices here you should also look at other use cases.
By having an atomic ProductOffering for each atomic ProductSpecification, the catalog can also be defined in such a way that IFRS 15 revenue recognition can easily be correctly implemented.
For a bundle of Internet, voice and TV. IFRS rules require you to report on revenue for each of these "performance obligations" seperately. If each of Atomic ProductSpecification has its own ProductOffering, product managers are forced to correctly allocate the price for each of these performance obligations. This makes sure that you don't have to build hardcoded rules in a revenue recognition engine.
Thanks for the usecase. But what if the atomic product specification is purely for provisioning purpose and doesn't have any effect on pricing ? Do we still need to create respective product offering for the same ? If the answer is no, should there be some identifier which forces the product managers to create respective product offering for any product spec that has price impact ? Let me know your thoughts pls.
Under TMF modeling guidance, you cannot have a top-level product specification (atomic or composite) that is not offered for sale by some product offering. You can certainly create such a spec, but it will not be made available for customers outside the context of a product offering.
A non-top-level product specification that doesn't have pricing or other commercial implication does not need a product offering, in fact it's not technically possible to associate a product offering with a product spec that's contained within another product spec.
If the product spec does have commercial implications and yet you don't want to have it as a top-level spec referred to from within an offering, you'll have to find another way to reflect the price impact. We're currently working on a TMF620 enhancement for table-driven price amounts, which would allow you to have price values vary according to characteristic values from anywhere in a product tree.
Hope it helps.
Yes we need to describe in the catalog all the product specifications that corresponds to functionalities perceived by the customer and associate each of them to a product offering, even if they are provided for free.
It is useful for the delivery of these products, for the customer assistance and customer knowledge, and for marketing concerns.
atomic product specification is purely for provisioning purpose
I'm afraid, that's not a product specification.
The product spec represents "what the marketing operator wants to sell at a functional level"each product spec can have a reference to a service spec or a resource spec, which are used in Service Order and Resource order from BSS to OSS.Also keep in mind that you can create "empty" product spec, I mean, product spec without characteristics and just reference a service spec which would have enough information on its own to provision something.I would recommend you read GB922, 3 separate guides talks about specfications: Product, Service Ressource. The first guide (product) also talks about about Service and Resource spec.