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.
------------------------------
Original Message:
Sent: Aug 20, 2020 04:43
From: Carlos Portela
Subject: Product and Service Decomposition with TMF APIs
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
Original Message:
Sent: Aug 12, 2020 05:47
From: Jonathan Goldberg
Subject: Product and Service Decomposition with TMF APIs
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.
Original Message:
Sent: Aug 12, 2020 05:19
From: Carlos Portela
Subject: Product and Service Decomposition with TMF APIs
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
------------------------------