Open APIs

Expand all | Collapse all

Product and Service Decomposition with TMF APIs

  • 1.  Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 12, 2020 05:19
    Hello,

    I am working on adopting TMF Open APIs in the OSS/BSS domains and there are a few points that are not yet fully clear to me.

    1) Aligned with TMF ODA Architecture, we would like to have BSS to order CFS via TMF641. It means that BSS should decompose the Products into CFS "internally" and, only then, submit the service order to the OSS domain. My issue is mainly related with the relationships between services that should also be submitted in the TMF641 order. At the BSS POM stage (Product Order Management), the decomposition of Product to Services should occur based on the Product Catalog (TMF620) but how can the relationships between services be found at level? The TMF620 API exposes the Product specifications and corresponding services but doesn't detail the service relationships that should be carried to SOM. I see two options here as:
    • Extending TMF620 to also expose the service relationships
    • Letting POM use TMF633 to find the service relationships before submitting the service order

    2) SID model defines a very clear mapping between Services that supports the service decomposition process (based on "characteristic translation") but this is not included in the TMF633 API. How can an service orchestrator handle the decomposition using TMF633 from a service catalog if this mapping is not exposed in the API? Should we extend the API to also expose the characteristic value translations? (this issue is similarly existing in POM with TMF620..)

    Thanks in advance

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------


  • 2.  RE: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 12, 2020 05:47
    Hi Carlos
    Please refer to other threads in the community where similar issues have been discussed:

    As you correctly noted, TMF620 does not contain sufficient information to allow decomposition into Service, it is missing the aspects of characteristic (and value) mappings that the SID encodes. But even the SID may not answer all the questions, in the case that a product needs to be decomposed to multiple services depending on rules.

    Adding @Ludovic Robert and @Kamal Maghsoudlou from Service domain in Open API, and @Dave Milham for the wider TM Forum view. Dave is spearheading an end-to-end implementation group that will hopefully come up with recipes and guidelines for decomposing from Product to Service to Resource (or ResourceFunction), as mentioned in one of the above posts.

    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: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 20, 2020 04:43
    Jonathan,

    Thanks for your reply.

    I feel that the main answer you gave was regarding point 2 but from point 1, even in your suggested links, I didn't get a clear answer.

    I will try to give a small example.
    Imagine that you ended up having two CFS's (IPTV and Internet Access) in BSS that you got from two different products via the Product Catalog.
    Now, we want to submit the service order to OSS for these two CFS's in OSS (via TMF641) but we dont know how are they related and your Product Catalog in BSS doesnt have this information (conclusion taken looking to SID or OpenAPIs). How can you know that your IPTV CFS has a relationship with Internet Access and of which type(e.g. "reliesOn")?

    If you dont submit this relationship, your IPTV on-top service will be non-sense because your OSS doesn't know which is the "on-bottom" service (in this case, internet access)...

    My feeling is that, before submitting the order to OSS, your BSS should learn the Service relationships (and other things as characteristics) from the OSS Service Catalog.
    I would foresee TMF633 to be used before the TMF641 on every order...

    What do you think?

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------



  • 4.  RE: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 20, 2020 07:47
    Hi Carlos

    I see the point, and I would definitely defer to the OSS experts, whom I tagged in my previous reply.
    Having said that, I am rather worried by the conclusion you reach, which is that basically for the BSS to successfully submit a service order it must learn about stuff in the OSS domain.
    This highlights (in my opinion, at the risk of crossing with @Kaj Jonasson, @Dave Milham, @Vance Shipley, and other ODA leaders) a challenge in the ODA architecture, and as supported by the way the Open API partitions between Product and Service.
    I​​​ think (and I stress that this is my opinion only) that the ​​demarcation between the Commerce layer and the Production layer in ODA should be drawn differently, so that the Production layer should be able to receive Product Orders as well as Service Orders. The implication is that the decomposition logic and recognition of what Services are would reside solely in Production, and Commerce needs to know "nothing" about OSS concepts. This would apply similarly for pre-ordering, in capture and discovery, when a qualification check needs to be made. The Commerce layer should be able to delegate a technical qualification check at Product level, without needing to translate into Service, or indeed translate back from Service to Product (as is currently required by the Service Qualification API).

    But I'm probably a lone voice in the wilderness here :(

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



  • 5.  RE: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 20, 2020 13:13
        Actually a discussion on this topic came up on the ODA Solution Design Blueprint call today  20 th Aug 2020. to which I invited Carlos.
    Sylvie Demarest Orange made a presentation on how Orange models  the relataonship between products and service over the ODA Core commerce to ODA produciton Boundary .
    Her slides and the recording are posted for members  on the ODA project work space at:   
      • 2020-08-20 ODA Solution Design Blueprint Meeting notes
        and is based on Product to Service decomposition in ODA Core Commerce.

        Syvlie has some further informaton on the catalog aspects of thsi which we were unable to cover but we plan to cover them on next week's call.

        The issue of where the Product Order is decomposed into Service orders has come up previously  MTOSI work and it was partially documented in the SAI interface  Service Activation - DDP BA - Part 2: Service Activation Interface (SAI)  TMF518_SA_2 Version 1.1  But I am not sure the assumptions there are corect for ODA current practices so best to revisit this topic.There was a SID Golden Nugget on this topic too.  copied below as I don't belive thisis on the current web.

        1.        Product/Service Nugget

        Here are two different viewpoints on Product and Service...there may be others and neither should be taken as the final word in how to view entities in these two related domains.  Thanks to Martin Gutzki of T-Systems for summarizing these two views based on a quite lengthy email thread among SID team members that occurred in the later months of 2008.

        • Viewpoint 1 (case study)
          • a product serves as a packaging of services by a provider that can be purchased, leased or rented by a customer
          • customers and providers commercially agree on the basis of products
          • products cannot be used because they are only packaging, e.g. you can't make a phone call with a product, but only with the service that realizes the product
          • a user uses a customer-facing service to obtain the value promise of the product, e.g. to make a phone call
          • the user experience of using a customer-facing service is created at an interface realized by an application in an end-user device
          • the application on the end-user device invokes resource-facing services by communicating over protocols with device interfaces (service access point) that constitue the boundary of the provider infrastructure
          • a user may administrate aspects that influence the behaviour of the customer-facing service (like call-forwarding) but not the commercial agreement through characteristics on the customer-facing service or by using another customer-facing service
        • Viewpoint 2 (as far as I understand it)
          • a product serves as a window for customers and users into the world of the services and resources used to realize the product. Customer/user always deal with products, unless the individual/organization they represent is playing the role of a service technician or some similar role
          • customers and providers commercially agree on the basis of products
          • a user uses a product to obtain its value promise, e.g. to make a phone call
          • the user experience of using a product is created at an interface realized by an application in an end-user device*
          • the application on the end-user device invokes resource-facing services by communicating over protocols with device interfaces (service access point) that constitue the boundary of the provider infrastructure
          • a customer-facing service represents a functionality at the boundary of the service provider infrastructure in a protocol-agnostic way, it groups a set of resource-facing services that together provide the necessary technical functionality
          • a user may administrate aspects that influence the behaviour of the product (like call-forwarding), this changes characteristics of the product

         

        * another way would be e.g. to call a hotline to get services performed by humans

        I feel that the different viewpoints are best understood with two different mindsets:Viewpoint 1 figures out the construction of a product starting from the things that a customer / user actually sees, including the end-user device. This leads to the interpretation that a CFS is functionality that can be perceived at the end-user device. Viewpoint  2 looks on what needs to be provided in the service provider's infrastructure during fulfillment, thus using the CFS as a requirement for functionality of the provider infrastructure that needs to be provided through RFS. It seems to me that the different viewpoints and interpretations come from different system boundaries.

        Examples of Product/Service/Resource and their relationships can be found at



    ------------------------------
    Dave Milham
    TM Forum CHIEF ArchItect
    ------------------------------



  • 6.  RE: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 22, 2020 03:12
    Hi Carlos and Jonathan (that referred to me)
    In the Reference Implementation group we have started to define ODA Component Candidates to form a possible architecture for a CSP. The first we addressed was Customer Order Management. I contributed a set of Components that would do the job. One of the Components is Order Validation that shall validate the customer's chosen Product Offering for a number of aspects, e.g. (in your case) compatibility, which means that the catalogs needs to have information about possible conflicts and dependencies between products and the product's services. This needs to be cleared out at the time of the order to give the customer information and a chance to select good product offering that will be possible to activate and fit well with the customer's products. When it then comes to APIs involved we have not mapped that yet, and when I have tried I have noticed similar problems as you have.
    And in addition some philosophical thinking. I have worked 20 years in IT and 20 years in Telecom and noticed an interesting difference. The traditional Telecom way is to create a standard "Protocol" and then build services to fit the "protocol". (REST is flexible the API resources are standardized ;) ). Telecom have had such success in standardizing in its traditional way that this must be the solution also for our integration problems in IT. OR?
    As you might guess I have a different view and solution (5 years experience of synchronizing internal APIs in Ericsson Charging Systems), and that's why I haven't engaged myself in the API program.

    ------------------------------
    Kaj Jonasson
    kajj@appliedbss.com
    ------------------------------



  • 7.  RE: Product and Service Decomposition with TMF APIs

    TM Forum Member
    Posted Aug 13, 2020 08:14
    Alos have a look at the ODA work at


    ------------------------------
    Dave Milham
    TM Forum CHIEF ArchItect
    ------------------------------