TM Forum Community

 View Only
Expand all | Collapse all

GB922 Product - Composite & Atomic ProductSpecifcations

  • 1.  GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 06, 2023 22:07

    Hi Experts

    I want your opinions on the below , I was reading through GB922 SID model for product and it has this concept of a Product being an instantiation of a Product Oferring Or Product Specfication.

    As shown in the class diagram below .

    Now ijust to quote a few things from the document .

    1. "For example, a composite high-speed internet ProductSpecification may include email and personal web pages atomic ProductSpecifications which are not instantiated as separate offerings but still must be instantiated as Products. This is also necessary if a ProductSpecification not instantiated as a ProductOffering has configurable characteristics or prices associated with one or more characteristics."
    2. "There are typically a number of ProductOfferings associated with a single ProductSpecification, for example to reflect offers to the market for different time periods. In cases where a ProductSpecification's value to the business is solely as a component part of a CompositeProductSpecification, it does not have a ProductOffering associated with it as it is not be sold on its own. Cases where these items are supplied to the Customer separately as 'spares', e.g., under warranty, are covered under Product below."

    Now here is the question reading through the document it seems it is possible to have Product Specs which are not related to any offering but exists only as a atomic product specs insode a Composite Spec (which is related to an Offering), however this atomic product spec can still be instantiated as a Product .

    If that is case I am hoping once a Atomic Product Spec is instantiated as product and is part of the customer's subscription inventory , it allows MACD operation on that product instance .

    A very simple example below , We have a SIP Product offer which is what is sold to the end customer containing a SIP PS(Composite) and a Number Range (Atomic) , the SIP PS is associated to the SIP Product Offer , where as the Number Range PS is not associated to any offer , so when sold the below structure will create twp product instances one for SIP and the other one for the Number Range and will allow MACDs separately on the Number Range instance .

    Your inputs on this will help clarify the context on the GB922 Product doc .

    Thanks in advance .


    #General

    ------------------------------
    ANKIT MADAN
    Infosys
    ------------------------------


  • 2.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 07, 2023 04:17

    Have a look at this best Practice Guide based on BT and Orange experiences

    IG1233 Product & Service Modelling Best Practices – Conforming to ODA v2.0.0



    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 3.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 07, 2023 13:14

    Hi Ankit

    The construct that you refer to, a composite product specification, allows the definition and instantiation of complex product structures within an offering. But this does not imply that you can do MACD orders on a product inside the substructure. In my understanding, an inventory product can be the target of a MACD product order only if it was instantiated from a product offering. Certainly this is true if the order will have commercial impact, which is encapsulate in the product offering and associated prices.

    Possibly, in your example, it might make sense to allow a MACD order on the number range, but what, exactly, would such an order do? Expand the range would surely have a pricing impact, no?



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 4.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 07, 2023 17:34
    Edited by ANKIT MADAN Mar 07, 2023 17:42

    Hi Jonathan

    Thanks for your response , to extrapolate this further I am potentially looking at use cases where in you might want to define something as product spec but not necesaarily as a product offering as it is not sold independently in the market , the case in point I took here which is a SIP offering with offcourse number ranges .

    Now in example I gave the intention is SIP PS will have all voice trunk related features like CLI , Overstamping , NUmber of channels etc whereas number ranges is primarily about the numbers associated with the SIP Trunk , business wants the flexibility to be able to order "n" number of ranges independently from the lifecycle of the Trunk ,which is even when a Trunk product is with a status of in progress I should be able to order number ranges as a MAC action , currently the product defintion is tightly coupled and hence it doesnt allow us to do the same , and thats the reaosn to be able to separate this out into two product specifications .

    Now again quoting the GB922 Product guide 

    "For example, a composite high-speed internet ProductSpecification may include email and personal web pages atomic ProductSpecifications which are not instantiated as separate offerings but still must be instantiated as Products. This is also necessary if a ProductSpecification not instantiated as a ProductOffering has configurable characteristics or prices associated with one or more characteristics"

    This gives me the feeling GB922 allows such a construct(potentially by defining order actions on the PS level) and hence the reason of my query .

    Thanks !!



    ------------------------------
    ANKIT MADAN
    Optus
    ------------------------------



  • 5.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 08, 2023 04:07

    The referenced IG1233 has an Orange email worked exemplar which addresses some of the points you raise .



    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 6.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted Mar 08, 2023 21:11

    Hi Dave

    Thanks for your response I will have a look and probably bother you if I will have further queries .



    ------------------------------
    Ankit Madan
    Optus
    ------------------------------



  • 7.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 30 days ago

    @David Milham @Jonathan Goldberg and other experts - wish to get your view on a topic ...  IG1233  recommends not to use Composite Product Specification and i believe rational for this could be lack of support / introduction of cardinality at Composite Product Spec layer and also TMF 620 and TMF 622.  

    Currently composability is  recommended at Offering layer with support of cardinality at this layer by TMF however this enforces indirectly  for not composing PS and rather creating Offering for every atomic PS to achieve flexibility of composition but this results into many technical ( non - sellable Offers).

    Many modern COTS packages have been extending TMF SID and APIs to enable cardinality at Composite Product Spec as this gives more flexibility and agility with a choice of composition at both PO and PS layer.

    Wanted to know your perspective about this and what's the reason for TMF not introducing cardinality at Composite Product Spec layer and is there any plan / possibility of introducing it in future?

    Thanks in advance,

    Regards, Ashish



    ------------------------------
    Ashish Maheshwari
    Infosys
    ------------------------------



  • 8.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 30 days ago

    My recollection of the discussion  was input from both BT and Orange. The rationale was that making Product specs a restriction of a service spec (CFSS) and allowing composition solely at the product offering and CFS level meant that the Product Factory  e.g.  network designer propose a service - which when  a composed CFS - means they will have designed and tested that the combination of Networks, Compute and storage do work together at the required scale. Moreover operational responsibility for the correct operation of the network service lies solely with the networks designer/ ODA Production. If you compose network services across the Core Commerce Production boundary the product manager has to take responsible for the end to end operation of the individual network parts and this complicates the operational  repair/ assurance  responsibility it is shared and generally the product neither have the skills nor the tools to establish which part of the composed product is not working . That being said this is a best practice not a mandated  principle.

    @Milind Bhagwat  @Sylvie Demarest  may wish to add their perspective.



    ------------------------------
    Dave Milham
    TM Forum, Chief Architect
    ------------------------------



  • 9.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 29 days ago

    Thanks for your inputs David however this practices document also doesn't recommend composition even at CFSS layer so i assume mostly the reason for no recommendation could be lack of cardinality support in TMF SID & Open APIs  at Composite Product Spec level.

    Do you see any chances of enhancing TMF SID to bring cardinality at Composition of PS level so that it gives flexibility of choosing the right level of composition at  the three levels ( Offers, Product Spec and CFSS)?

    May be a bit of survey for this capability (not sure if it is possible) around major COTS layer in this space may also give a bit of indication of the need of industry - specially those selling & supporting Complex B2B Products.



    ------------------------------
    Ashish Maheshwari
    Infosys
    ------------------------------



  • 10.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 27 days ago

    @Ashish Maheshwari asks about composability as described in IG1233. The guidance there are recommended best practices of the authors, and do not represent a restriction. At SigScale we have a much smaller catalog, and so different stakeholder concerns, and we chose to reuse Characteristic Specification definitions through composition.

    I am not following your concern about "cardinality".  A composite Product Specification would have a 0..1 association with other (bundled) Product Specifications. The Characteristic Specifications do provide control of cardinality with the minCardinality and maxCardinality properties. Maybe the concern is reusing the same Characteristic names in Product Specifications?



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 11.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 27 days ago

    Hi Vance – in TMF Open API (620) or even in SID framework ... there is no mention of cardinality at composition layer of Product Spec so it makes the perception that all Product Spec under Composite Product Spec has to be mandatory and hence the recommendation by some of the authors for not composition at Product Spec and rather use it at Product Offering layer as TMF has clearly  defined cardinality capability. My question was to understand why TMF has not enabled cardinality at Composite Product Spec and any plans to extend that in coming future.

     

    Hope my question is clear enough to now make sense?






  • 12.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 17 days ago

    Hi Ashish,

    If it is recommended to use the Composite / Atomic ProductOfferingSpecification to describe the composition, it is because it provides much better flexibility to change and improve the offers.

    Indeed, the offer layer has all the capacity to support the cardinality in the composition of offers.

    But if we don't have this capacity at the Product level, it's because the choices of "is it mandatory or not?", "how many can be ordered?"… are commercial choices as well as the price and commitment. All the commercial choices must be described at offer level.

    If you would implement the composition at a Product level adding the capacity to support cardinality, for Hankit example of SIP, you would have:

    ·         1 instance of ProductOfferingSpecification,

    ·         1 instance of CompositeProductSpecification

    ·         2 instances of AtomicProductSpecification

    So you have a total of 4 instances.

    If you simply use SID model with its current capacities at offer level, you would have:

    ·         1 instance of CompositeProductOfferingSpecification,

    ·         2 instances of AtomicProductOfferingSpecification,

    ·         2 instances of AtomicProductSpecification

    So you have a total of 5 instances.

    In my opinion, I don't think that having 5 instances instead of 4 instances is a big deal today.

    And the main point is that you describe commercial constraint at offer level.

    Contrary to what you said, the AtomicProductOfferingSpecifications are not technical offers and are completely sellable in many CompositeProductOfferingSpecifications.

    One of the main advantages of the clear separation between Offers and Products is the fact that you can sell the same ProductSpecification through many ProductOfferingSpecifications with different constraints and prices, such as having an offer for the mass market and another one for B2B or even a specific one for employees.

    I can tell you there isn't any plan to introduce cardinality at product level.

    Of course, you can attend SID calls to propose an evolution for this. In this case, you would need examples that justify the need of evolution.

    See you,

    Cécile Gérardin (previously Ludwichowski)

    SID Learder

     



    ------------------------------
    Cecile Gerardin
    Cécile Gérardin
    ------------------------------



  • 13.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 17 days ago

    Hi Hankit,

    As @Sylvie Demarest said, you are working on an old version of the SID.

    In the current version, the text and examples you refer to have been removed as it has been considered incorrect and inconsistent with what is prescribed.

    It is true that, at one moment, a ProductSpec might not be marketed by any ProductOfferingSpecification. The fact is that you specify what you want to sell (ProductSpecification) before specifying how you sell it (ProductOfferingSpecification). Later you will define one or many ProductOfferingSpecifications to sell it or perhaps never if the cost of the ProductSpecification is too high to sell it at a good price for customers.

    As an important reminder, a ProductSpecification can't be sold without a ProductOfferingSpecification! It means that each product, to be sold, needs a ProductOfferingSpecification except for AtomicProductSpecification included in CompositeProductSpecification. Only the ProductOfferingSpecification can specify the price and the commercial conditions.

    The price carried by a ProductSpecification is only here to specify the minimum and maximum price at which the CSP wants to sell its ProductSpecification.

    About the aim of Composite / Atomic ProductSpecification, it is used when several ProductSpecifications were provided separately at one moment and later are always provided together.

    For example, some years ago, voicemail was provided independently from the mobile line and had a specific price and so a specific ProductOfferingSpecification.

    Today, we never provide a mobile line without voicemail. In this case, it's interesting to create a CompositeProductSpecification containing the two ProductSpecifications mobile line and voicemail.

    Note that in its composition a CompositeProductSpecification contains all its AtomicProductSpecifications one time and only one. In the same way, a CompositeProduct contains each AtomicProduct only once.

    For example, a CompositeProductSpecification "SIP Product" containing an AtomicProductSpecification "SIP trunk" and an AtomicProductSpecification "Number of ranges", it means that when you order a ProductOfferingSpecification marketing the CompositeProductSpecification "SIP Product", you won't be able to get more than one "SIP trunk" and one "Number of ranges".

    About how you could implement your example of one SIP trunk and several Number of ranges:

    ·         You consider having a CompositeProductSpecification "SIP Product" containing  an AtomicProductSpecification "Number of ranges"

    • It means that when you order a ProductOfferingSpecification marketing the CompositeProductSpecification "SIP Product", you will have one "SIP trunk" and won't be able to get more than one "Number of range".
    • Note: it looks strange to have a Composite containing only one element.

    ·         In addition, you would need a ProductOfferingSpecification to market the CompositeProductSpecification.

    The issue is that you won't be able to get more than one "SIP trunk" and one "Number of ranges".

    To instantiate correctly your example, you simply need to have:

    •  A ProductSpecification "SIP trunk" and a ProductSpecification "Number of ranges"
    • Each of them being respectively marketed by an AtomicProductOfferingSpecification "SIP Trunk Offer for Middle Market" and "Number of ranges Offer"
    • And finally, having a CompositeProductOfferingSpecification containing the 2 AtomicProductOfferingSpecification. Like this you can specify the minimum and maximum of "Number of ranges Offer".
    • Having a clear separation between ProductSpecification and ProductOfferingSpecification is very important for ODA Functional Architecture.

    SID model provides all the flexibility needed to describe clearly products and offers.

    See you,

    Cécile Gérardin (previously Ludwichowski)

    SID Learder



    ------------------------------
    Cecile Gerardin
    Cécile Gérardin
    ------------------------------



  • 14.  RE: GB922 Product - Composite & Atomic ProductSpecifcations

    TM Forum Member
    Posted 27 days ago

    Hi Ankit, the SID view you refer to is an old one. In SID 24.0 and 24.5 improvments have been introduce to clarify this part, and the up-to-date diagram is this one:

    May be all the views in the SID documentation are not yet updated. If you can share the SID version, document and chapter where you find the initial view we could check.

    The introduction of ProductOfferingSpecification and ProductOfferingInstance, as we have ProductSpecification and Product, permits to clarify all that we have in the Product Inventory. The related Product Inventory API is not yet updated but a JIRA ticket has been raised to trace the needed evolution in the resource model of this API (as in the Product Catalog API).

    Best Regards

    Sylvie



    ------------------------------
    Sylvie Demarest
    Orange
    ------------------------------