Open APIs

 View Only

  • 1.  TMF620: How to model a choice?

    Posted May 15, 2023 04:14

    Let's assume we'd like to offer a composite product comprised of multiple components

    1. Mandatory internet access
    2. Optional router hardware
    3. Optional security software
    4. Optional IP-TV software

    From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

    Part 1: Option:
    From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

    So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

    Does this seem like a reasonable way to model this so far?

    Part 2: Choice
    Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

    Let's then say we'd like to offer a choice of 3 types of router:
    a) default router for 5/month
    b) deluxe router for 10/month
    c) no router for free (customer has its own router already)

    What would be a good way to model the requirement of having to make a choice? My thoughts are:


    A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.


    Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.


    Are there other/better options I failed to think of, or is there official guidance, or … ?



    ------------------------------
    Oliver Büechi
    Ergon Informatik AG
    ------------------------------


  • 2.  RE: TMF620: How to model a choice?

    Posted May 15, 2023 10:57

    From SID/TMF620

    • If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
    • for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
    • for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
      Notes:
      • "selection Group" will be added to API620 V5 (although with a different name, I heard)
      • that should fit very well with your example of routers
    • You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
    • in a wider sense, product eligibility/compatibility rules may also be use to some extend.
    • for complex scenariso, Policy can also be used.

    for guidance, general information about product modelling:

    TMF communities

    • search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

    TMF WIKI
    Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

    TMF publication

    • GB922 - Product
    • IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
    • IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
    • IG1228 How to use ODA – Using Open APIs to realize Use Cases
      • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)


    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 3.  RE: TMF620: How to model a choice?

    Posted May 15, 2023 11:57

    Hi
    In version 5 of the TMF620 API we have introduced the concept of a Product Offering Group, which will allow semantics (for example) of choosing between 3 and 5 items out of a list of 20.
    You can see a preliminary version of this in the beta Open API table https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=128855518 . Since then, following valuable input from @Lutz Bettge of Deutsche Telekom, we made additional changes. I cannot share here yet, since we are still in an internal team review process. Watch this space.



    ------------------------------
    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.
    ------------------------------

    Original Message


  • 4.  RE: TMF620: How to model a choice?

    Posted May 15, 2023 12:02

    so "product Offering Group" is the new name for "Selection Group"?



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------

    Original Message


  • 5.  RE: TMF620: How to model a choice?

    Posted May 15, 2023 12:08

    Selection Group is an informal name for a set of common use cases that the model enables.
    The formal name in the model is BundledGroupProductOffering, and it has cardinalities in a sub-entity called BundledGroupProductOfferingOption.



    ------------------------------
    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.
    ------------------------------

    Original Message


  • 6.  RE: TMF620: How to model a choice?

    Posted May 16, 2023 04:54

    For people who are members of the Open API project, you can see more details in these change requests:

    https://projects.tmforum.org/jira/browse/AP-4271 is Lutz's improvement
    https://projects.tmforum.org/jira/browse/AP-3827 is the original enhancement suggestion



    ------------------------------
    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.
    ------------------------------

    Original Message


  • 7.  RE: TMF620: How to model a choice?

    Posted May 17, 2023 11:47

    @Jonathan Goldberg Thank you, the Product Offering Group example semantics you gave sound very promising! Do you have an idea when v5 could be released (weeks/months/years/…)? Using a beta version is probably not recommended for anything other then testing purposes.

    @Matthieu Hattab Thank you, the "selection group" (or "Product Offering Group") sounds very promising for this purpose indeed.

    You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)

    I'm aware of at least some of the possibilities of using characteristics, though I couldn't think of a suitable way to model the "mandatory choice of router" example I gave. From my understanding, a ProductSpecificationCharaceristicValueUse allows choosing a subset of the ProductSpecificationCharaceristicValues defined on a ProductSpecification, either on ProductOffering or ProductOfferingPrice level. The semantics (from my possibly flawed understanding) is that the given PO or POP then has all the characteristicValues selected in the Use. How could this be used to enforce the choice of one of the values?

    We do intend to use characteristics for a choice of bandwidth in the mandatory internet product in the example I gave, which uses exactly one of the all available bandwidths. I assume other bandwidths would have different prices, and thus (I think) would have to be modeled in separate product offerings. The choice would then be between one of the product offerings.

    in a wider sense, product eligibility/compatibility rules may also be use to some extend.

    Product eligibility/compatibility I didn't find within the TMF620 v4.1 spec, is that something new (v5?), or in a different API?

    for complex scenario, Policy can also be used.

    When looking for "policy" in the TMF620 v4.1 spec I found ConstraintRef for POPs, which I haven't looked at in detail yet. Is that what you meant? The docu says "The Constraint resource represents a policy/rule applied to ProductOfferingPrice". I suppose one could make a "MustHaveOneOfThese" constraint and apply it to the 3 router-options, which the ordering system would then have to know how to follow. Though that seems similarly cumbersome as using self-defined POPRelationships.

    ----

    I'll have to search this forum some more to hopefully find more inspiration/info, and continue to be grateful to all pointers.



    ------------------------------
    Oliver Büechi
    Ergon Informatik AG
    ------------------------------

    Original Message


  • 8.  RE: TMF620: How to model a choice?

    Posted May 17, 2023 13:33
    Edited by Matthieu Hattab May 17, 2023 13:34

    for characterics:
    your understanding of ProductSpecificationCharacteristicValueUse is correct. We use it for bandwidth, mobile data etc.
    we have 5 offers, each mapped to a single bandwidth value (those PO are typically put in a bundle).
    Then we have a 6th offer and you can choose one bandwidth values. (This PO is typically use to sell internet as a stand-alone offer an customer can change speed at any time)

    For a router, it's not recommended but possible. Honestly, today, we should use BundledGroupProductOfferingOption or equivalent. If you can't wait V5, develop it in your own copy of TMF620. Jonathan's Wiki URLs is a good guidance. When V5 is out, just switch to V5.

    policy

    policy is an well known SID entity and it will replace ConstraintRef in V5. GB922, has great (and complex) examples of price policies. Policy is needed for modelling rating and charging for usage products (like minutes on voice or GB on mobile data). TMF620 is not only used for pre-sales and sales processes but also for rating, charging billing.

    It can also be used for pre-sales and sales process. For policy is great for tiered volume discount, which you can use to show discounted prices in shopping carts etc or even in the catalogue (pre-pick pricing) if you're ambitious!

    Product eligibility/compatibility

    you wouldn't find these terms. "eligibility" is a bit of a umbrella term and anyone has a defintion for it. The entity is called ProductOfferingRelationship.

    so you could create a relationship that require, exclude, recommend, depends on... requiredIfTodayIsChristmas! whatever verb fits your needs. the catalogue only stores the rule, it's dumb.
    the interpretation of the rule is done elsewhere (TMFC0027 and its 2 APIs: TMF679, TMF760)

    I believe IG1228 and GB922 (Product guide) answer all your questions. this is an old post of mine

    Now it's time for you to draw the product model and share with us :-)

    Here is an example from IG1228, I can get you the giffy source file that you can import in your own giffy instance or in your personal page at TMF WIKI and you can change it.

    Note: In this diagramme, "BOX" is the BundledGroupProductOfferingOption entity.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------

    Original Message


Related Content