Open APIs

 View Only
Expand all | Collapse all

TMF 620 / 637 Product Specification modelling

  • 1.  TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 16, 2021 09:21
    I would like to get you comments on product schema modelling. 
    Let's assume I have a very simple product definition with 3 properties of interest a, b and c.  Properties a and b are interesting in buying context whereas property c is important to client but only for operational purposes (e.g. it is an IP address that was assigned during provisioning). 
    I imagine 3 alternative approaches to model that:
    1. There is a single ProductSpecification for which 3 characteristics are defined. I am using this product specification as a reference in orders (TMF 622) and in inventory (TMF637).
    2. There are two interrelated product specifications. One referenced for ordering (contains only a and b), second  used in inventory, Second ones contains all 3 properties (or maybe I am not even including property b as it is not relevant after order - e.g. it is only used to infer value of c).
    3. There is single ProductSpecification which is referenced from orders and inventory. However it only models a and b. 
    For me for a very long time the only viable option was 1, but now I am not sure. To build a more realistic example lets imagine we do not deal with 3 properties but 10s or 100s where significant number of these are operational. And within this context here are my questions:
    1. Is approach 2 a valid one? 
    2.  When using approach 1 how can I indicate that a given property is operational one? In other words, how to mark these not relevant during pre-order phases? 
    3. How can you learn the full data model ("schema") for operational representation of the product in approach 3?

    Thank you in advance for all comments / hints.
    Bartosz Michalik


    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------


  • 2.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 16, 2021 11:08
    Hi Bartosz

    The TMF Open API approach is definitely 1, I think you are likely to run into trouble maintaining multiple parallel specs (2) or managing missing schemas (3).

    Suggest you take a detailed look at the ProductSpecificationCharacteristic (and PSCValue) resources in TMF620 (Product Catalog Management).
    There's quite a lot of metadata there that you could perhaps use to address your use case. And if you think that something is missing, a CR could be opened.
    Hope it helps.

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



  • 3.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 17, 2021 05:15
    Hi Jonathan.
    Thank you for the answer -  this reconfirms my understanding of TMF documentation.  Basically in approach 1, you are using the same product specification reference in order item and product in inventory. Latest, TMF 620 explains(*) how specification could be defined using characteristic- or schema- based. There are some differences in expressiveness  between json-schema and characteristics but for sake of our thread I would assume they are interchangeable. In that case I assume that "configurable" attribute on characteristics  is the same as "readOnly : true" in json-schema.  You could use "configurable" to inform that certain characteristic is operational. However, there is still some limitation of this approach.
    The json-schema "readOnly" interpretation is simpler - not used in a request and may/must (depending on required flag) used in a response.  Another thing is that you cannot specify that a certain property cannot be updated (specified in update order request). You can obviously encode it in your system and explain in the schema description - so there is definitely  way to sort it out. Finally, there are MEF considerations on product specifications - when you look at the specifications there you identify that functional context (poq, quote,order etc..) influences whether a certain property is required in request or not. This may make sense as some product aspect are not relevant for feasibility checks, etc. 
    You can perceive  it as an over-specification, but this is yet another aspect which cannot be expressed with a single product specification approach (regardless it is characteristics or vanilla json-schema based approach.

    All above are not critical issues yet I am interested in anybody thoughts on whether and how to address them using current model definitions.
    Regards,
    Bartosz 

    (*) the schema based example seems to be incorrect - how could a raise "bug" on that topic - I am happy to contribute fix for that as well.

    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------



  • 4.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 17, 2021 04:46
    I agree with your previous comments. On the other hand, some characteristics could be specific at the CFS/RFS level. In this case they could only be associated with the CFS and after the customer select the Offer/ProductSpec ... the specific CFS (with its specific characteristic) will be selected. The decomposition relationships ProductSpec/CFS could plays an important role here.

    ------------------------------
    Santiago Lorente
    Salesforce
    ------------------------------



  • 5.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 17, 2021 05:27
    Hi Santiago, 
    I do agree with would you said. But that will only work if you expose the Service Inventory  (CFSes) to API consumer. And in my scenario the API consumer is external entity. 
    In a few places TMF documentation state that CFSs are not meant to be exposed to Customers (GB922 Product, IG 1233). But my reason is more pragmatic - I might not  want to do so.
    If that case I assume the only way to go is to  have extensive Product Specifications.

    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------



  • 6.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 17, 2021 06:32
    Hi Bartosz, 
         my explanation was not in the sense of exposing CFS to the API consumer but in the sense that you can segment the characteristic to be included at ProductSpec level or at CFS level. This avoid having all of them at ProductSpec side. The link between the ProductSpec and the CFS elements will be configured at the catalog and will be critical at run time during the order decomposition.
    On the other hand, I know it is not your case, but specifically talking about exposing CFS to admin actions, I recommend you reading the doc "IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA_v2.0.0". In figure 4.9 you have:
    "The Administration operation described at CFS specification level has no correspondence at Product specification level. It permits managing directly at CFS level characteristics modifications that has no interest to be managed at product level and through a customer capture. For example, the password associated to the mailbox can be modified directly by the user with the administration operation (no order, no change at product level)."

    Hope the best


    ------------------------------
    Santiago Lorente
    Salesforce
    ------------------------------



  • 7.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 17, 2021 09:39
    Hi Santiago, 
    One again thanks for the comments. I fully agree, with what you have stated in case in terms of how data could be organized/segregated within an single SP technology stack - and this idea resonate well with my view on how abstractions and encapsulation mechanisms should be used. 
    My use case is about interacting with external party - son no admin functions are exposed. In other words, how my capabilities are exposed in kind of a single pane of glass, minimalistic data-model. I was assuming that, at the technical level,  I am exposing my specifications and offerings via an API so that a customer can learn what is available and then be able to go through all product lifecycle phases starting from pre-ordering steps. 
    Greetings,
    Bartosz

    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------



  • 8.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 18, 2021 03:28
    Hello
    I share Bartosz's view about the fact that depending on the action/operation to be performed on a productSpecification/ProductOffering the set of characteristics (and cardinality) may differ. Take any productSpecification with many characteristics and I'm sure that, from a business perspective, the subset of characteristic required to perform product qualification will differ for quote,  then from Order etc.... (Order by itself could be probably decoupled in order for acquisition from order to modify).
    @Jonathan Goldberg we have a pending jira for that for some time, and probably we could discuss this? [AP-2519] Manage operation for Catalog entities like productSpec, productOffering, etc... - TM Forum JIRA 

    Cheers
    Ludovic


    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 9.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 19, 2021 17:44
    This is an interesting discussion.  IG1233 discusses product and service modelling and would be an excellent document to capture the thoughts and advice in this discussion. @Bartosz Michalik would you or others participating in this could be interested in collaborating on an update to this document? I know I have a couple of ideas I would like to add.  If so, please let me know and we can set up a kickoff.​

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 10.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 22, 2021 03:21
    @Greg Herringer I would be happy to contribute​

    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------



  • 11.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 23, 2021 12:18
    Thank you @Bartosz Michalik!  I am a member of the End to End ODA project working group​ that meets weekly at on Thursdays at 13:30 UK time.  The best way for you to contribute would be to attend an upcoming team call.  This link describes the project and has information for the weekly call for the Transformation Guides sub-group.  On that call we can best determine how to collect contributions from various members.  Hope to speak to you then.

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 12.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 24, 2021 03:24
    Please note that the link Greg sent is from within the ODA project's confluence page, and is probably not accessible to people who haven't joined the project.
    To join the project, go here https://myaccount.tmforum.org/joinproject and click JOIN THE PROJECT on the End to end ODA line. You'll need to sign in to the TMF web page (or register if you are not yet registered), and your organization's contact for TMF will need to approve your joining the project.
    Good luck!

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



  • 13.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 24, 2021 03:50
    @Greg Herringer I am planning to  join the call tomorrow. ​​​​

    ------------------------------
    Bartosz Michalik
    Amartus
    ------------------------------



  • 14.  RE: TMF 620 / 637 Product Specification modelling

    TM Forum Member
    Posted Nov 24, 2021 13:50
    Thanks @Jonathan Goldberg for pointing that out. With the recent site re-org I wasn't sure where I should direct folks who wish to join projects - it's been a while since I have done so.​​

    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 15.  RE: TMF 620 / 637 Product Specification modelling

    Posted Jan 05, 2022 11:30
    Thanks for the answers, i was also searching for the same. get-vidmate.com instagram saver

    ------------------------------
    Carlton flores
    TO BE VERIFIED
    ------------------------------