Open APIs

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

Hi,

The best practice for SQ is described in IG1228 and in TMF645 user guide.

Actually it does. It's your POCV vendor or your own implementation that defines what visibility the component needs. You could very well implement support for any PSR catalogue API to get the visibility you need.

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

Hi Matthieu,

Thanks for your replay. Do you mean to say that POCV implementation should include the decomposition of Product instances into CFS instances and then it should call TMF645 to check the technical feasibility? Please note that in many cases specification level mapping through Product Catalog is not enough to get the Technical Feasibility. We need to actually create the CFS Payload and map all the relevant Product instance Parameters to the CFS Instance Parameters before someone can call TMF645. Please correct me if I am wrong, but I think that according to ODA, this seems to be the job of PODM and not POCV. 

Regards,

Kinshuk

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 04:10
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Hi,

The best practice for SQ is described in IG1228 and in TMF645 user guide.

Actually it does. It's your POCV vendor or your own implementation that defines what visibility the component needs. You could very well implement support for any PSR catalogue API to get the visibility you need.

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Out of curiosity, do you have a reference supporting this?

Personally, I'm not fully aligned with the TMF's approach for cFS.

If TMFC009 (the ODA Component underpinning TMF645) is really "self contained", it should be capable of determining which CFS are needed based on the provided product offering or even the PO's related ProdSpec. It's the first ODAC I've encountered that shifts this dependency to the API client.

Take IG1228, use case #2 - the BFF "magically" constructs the CFS payload for the POST checkSQ request. 

However, Inspired by UC2, we've developed our own qualification orchestration service, which we call the Composite Qualification Service (CQS).

It behaves similarly to the BFF in IG1228 UC2. The emphasis is on orchestration,  business rule evaluation remains within the appropriate eligibility services.

Our current CQS consumers include:

• Digital sales BFFs (DXP, GraphQL, etc.)

• Product Configurator

• Recommendation Engine

• POCV (before "cart2order" and before "submitOrder")

Each client must provide context, intent, party, location, product or product offer (ID or list), catalogue category - but not the CFS 😉

It's our CQS that will create the CFS. Currently, we currently store the CFS in CQS but you could use a Service Catalogue API if you have one).

PS: another option: model your product catalogue with CFS only. if you need ProductSpec, store then in a CMS.... 2 BSS vendors in that situation recommended me that that 😮

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 07, 2025 07:58
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Hi Matthieu,

Thanks for your replay. Do you mean to say that POCV implementation should include the decomposition of Product instances into CFS instances and then it should call TMF645 to check the technical feasibility? Please note that in many cases specification level mapping through Product Catalog is not enough to get the Technical Feasibility. We need to actually create the CFS Payload and map all the relevant Product instance Parameters to the CFS Instance Parameters before someone can call TMF645. Please correct me if I am wrong, but I think that according to ODA, this seems to be the job of PODM and not POCV. 

Regards,

Kinshuk

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 04:10
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Hi,

The best practice for SQ is described in IG1228 and in TMF645 user guide.

Actually it does. It's your POCV vendor or your own implementation that defines what visibility the component needs. You could very well implement support for any PSR catalogue API to get the visibility you need.

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

In IG1228 TMFS002, Engagement Management  is directly calling TMF645 Service Qualification API by passing the CFSs that needs to be qualified. But before doing that, someone has to create the CFSs from the Products before TMF645 can be called. This is where the current gap is. Does TMF679 in turn call TMF645? If not, then how Products are converted to CFSs before TMF645 can be called.

My question is more related to the TMF API being used rather than which ODA component performs it. Does TMF679 Product Qualification API play a role in Technical Feasibility? The TMF679 spec says that it does. This thread also provides some more context around it

https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=31&MessageKey=a19c1a84-00da-4499-98d4-8f32a1139a2b&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5&tab=digestviewer

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 10:43
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Out of curiosity, do you have a reference supporting this?

Personally, I'm not fully aligned with the TMF's approach for cFS.

If TMFC009 (the ODA Component underpinning TMF645) is really "self contained", it should be capable of determining which CFS are needed based on the provided product offering or even the PO's related ProdSpec. It's the first ODAC I've encountered that shifts this dependency to the API client.

Take IG1228, use case #2 - the BFF "magically" constructs the CFS payload for the POST checkSQ request. 

However, Inspired by UC2, we've developed our own qualification orchestration service, which we call the Composite Qualification Service (CQS).

It behaves similarly to the BFF in IG1228 UC2. The emphasis is on orchestration,  business rule evaluation remains within the appropriate eligibility services.

Our current CQS consumers include:

• Digital sales BFFs (DXP, GraphQL, etc.)

• Product Configurator

• Recommendation Engine

• POCV (before "cart2order" and before "submitOrder")

Each client must provide context, intent, party, location, product or product offer (ID or list), catalogue category - but not the CFS 😉

It's our CQS that will create the CFS. Currently, we currently store the CFS in CQS but you could use a Service Catalogue API if you have one).

PS: another option: model your product catalogue with CFS only. if you need ProductSpec, store then in a CMS.... 2 BSS vendors in that situation recommended me that that 😮

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 07, 2025 07:58
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Hi Matthieu,

Thanks for your replay. Do you mean to say that POCV implementation should include the decomposition of Product instances into CFS instances and then it should call TMF645 to check the technical feasibility? Please note that in many cases specification level mapping through Product Catalog is not enough to get the Technical Feasibility. We need to actually create the CFS Payload and map all the relevant Product instance Parameters to the CFS Instance Parameters before someone can call TMF645. Please correct me if I am wrong, but I think that according to ODA, this seems to be the job of PODM and not POCV. 

Regards,

Kinshuk

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 04:10
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Hi,

The best practice for SQ is described in IG1228 and in TMF645 user guide.

Actually it does. It's your POCV vendor or your own implementation that defines what visibility the component needs. You could very well implement support for any PSR catalogue API to get the visibility you need.

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

In IG1228 TMFS002, Engagement Management  is directly calling TMF645 Service Qualification API by passing the CFSs that needs to be qualified. But before doing that, someone has to create the CFSs from the Products before TMF645 can be called. This is where the current gap is. Does TMF679 in turn call TMF645? If not, then how Products are converted to CFSs before TMF645 can be called.

My question is more related to the TMF API being used rather than which ODA component performs it. Does TMF679 Product Qualification API play a role in Technical Feasibility? The TMF679 spec says that it does. This thread also provides some more context around it

https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=31&MessageKey=a19c1a84-00da-4499-98d4-8f32a1139a2b&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5&tab=digestviewer

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 10:43
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Out of curiosity, do you have a reference supporting this?

Personally, I'm not fully aligned with the TMF's approach for cFS.

If TMFC009 (the ODA Component underpinning TMF645) is really "self contained", it should be capable of determining which CFS are needed based on the provided product offering or even the PO's related ProdSpec. It's the first ODAC I've encountered that shifts this dependency to the API client.

Take IG1228, use case #2 - the BFF "magically" constructs the CFS payload for the POST checkSQ request. 

However, Inspired by UC2, we've developed our own qualification orchestration service, which we call the Composite Qualification Service (CQS).

It behaves similarly to the BFF in IG1228 UC2. The emphasis is on orchestration,  business rule evaluation remains within the appropriate eligibility services.

Our current CQS consumers include:

• Digital sales BFFs (DXP, GraphQL, etc.)

• Product Configurator

• Recommendation Engine

• POCV (before "cart2order" and before "submitOrder")

Each client must provide context, intent, party, location, product or product offer (ID or list), catalogue category - but not the CFS 😉

It's our CQS that will create the CFS. Currently, we currently store the CFS in CQS but you could use a Service Catalogue API if you have one).

PS: another option: model your product catalogue with CFS only. if you need ProductSpec, store then in a CMS.... 2 BSS vendors in that situation recommended me that that 😮

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 07, 2025 07:58
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Hi Matthieu,

Thanks for your replay. Do you mean to say that POCV implementation should include the decomposition of Product instances into CFS instances and then it should call TMF645 to check the technical feasibility? Please note that in many cases specification level mapping through Product Catalog is not enough to get the Technical Feasibility. We need to actually create the CFS Payload and map all the relevant Product instance Parameters to the CFS Instance Parameters before someone can call TMF645. Please correct me if I am wrong, but I think that according to ODA, this seems to be the job of PODM and not POCV. 

Regards,

Kinshuk

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 07, 2025 04:10
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

Hi,

The best practice for SQ is described in IG1228 and in TMF645 user guide.

Actually it does. It's your POCV vendor or your own implementation that defines what visibility the component needs. You could very well implement support for any PSR catalogue API to get the visibility you need.

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Hello Matthieu 

which oda component you are looking help for ? 
------

I cannot seem to find the person responsible for this ODA component. Anyone can help?

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Anastasios, 

the table I shared came from the latest POCV definition

so the component I was looking help for is called "TMFC002 Product Order Capture & Validation". I just wanted to invite the person into this discussion and share their insights. But maybe the right person should the person in charge of TMFC009 Service Qualification!

Hello Matthieu 

which oda component you are looking help for ? 
------

I cannot seem to find the person responsible for this ODA component. Anyone can help?

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

TMF645 is still listed as a dependent API in TMFC002 though.

https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=339784132

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

HI All,

Thanks for your inputs, but I think we are digressing a bit from my original question in the post. The question is not about which component does this but more on how the whole flow of checking the feasibility work and which APIs will be used in the flow.

To be more specific, how does Products coming from Customer Order get converted to CFSs so that we can call TMF645 for Service Feasibility. Implementation of which API does this Product to CFS conversion. In case of Order Processing, it is the implementation of TMF 622 that converts the Products to CFS before calling TMF641 for provisioning of CFSs. In case of Feasibility Check, how do we calculate the CFSs from the Products. 

Johan Ghazali provided an approach of doing this conversion in the implementation of TMF679 which seems to be the most logical place of doing it. In this thread,  @Jonathan Goldberg seems to be highlighting a similar approach. Please let me know if you have an opinion on how this is done.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 11, 2025 06:51
From: Kristian Svalheim
Subject: Technical Feasibility Check for Product Offerings

TMF645 is still listed as a dependent API in TMFC002 though.

https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=339784132

------------------------------
Kristian Svalheim
Lyse Tele AS

Original Message:
Sent: Apr 11, 2025 05:12
From: Matthieu Hattab
Subject: Technical Feasibility Check for Product Offerings

I believe there is a misunderstanding.

• TMF679 = "Product Offering Qualification" not  "Product Order Management"
  • "Product Order Management" = TMF622
• PODOM does not expose any API so you cannot make any request to PODOM
  
• PODOM has zero dependencies on TMF679 or TMF645 (POCV does)

I just checked my notes from our onsite PSR training done by TMF Education, last December, and it was said that PODOM is only an orchestration engine, it does not expose any business capabilities. it does not expose any API. This is a screenshot of the course my comment at the time (confirmed by the TMF trainer).

Also,

CC Anastasios Sarantis

TMF issued a new version of POCV a month ago and they removed SQ.

I cannot seem to find the person responsible for this ODA component. Anyone can help?

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

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS

Original Message:
Sent: Apr 09, 2025 12:42
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Got this reply from Johan Ghazali (from Telekom Malaysia) in my inbox and I would like to share here so that we can look for opinions from others as well on this approach. This is how I have also been thinking on how the solution would work as well. Requesting the experts in this forum (@Jonathan Goldberg, @Ludovic Robert) to have a look and provide their views as well.

Thanks to Johan for his valued inputs.

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

In the context of a BSS (Business Support Systems) product architecture , the best practice involves leveraging a combination of TM Forum APIs to ensure seamless integration and accurate feasibility checks. Am trying this recommendation from a colleague ..

Product Order Capture and Validation (POCV) System:

Initiate TMF679 Request: The POCV system should initiate a TMF679 Product Order Management API request to the Product Order Delivery Orchestration and Management (PODOM) system. This API manages the lifecycle of product orders and handles the decomposition of product offers into their respective CFSs (Customer Facing Services) and RFSs (Resource Facing Services).

Product Order Delivery Orchestration and Management (PODOM):
Decompose Product Offers: Upon receiving the TMF679 request, the PODOM system decomposes the product offers into CFSs and RFSs.
Service Qualification Check: The PODOM system then makes a TMF645 Service Qualification API call to the Service Qualification Management system. This API checks the technical feasibility of the CFSs and RFSs on both the CSP's own network and any required partner networks.

Service Qualification Management System:
Process Feasibility Check: The Service Qualification Management system processes the TMF645 request and returns the feasibility results to the PODOM system.
Translate Results: The PODOM system translates these results back into a product qualification response and sends it to the POCV system.

This approach ensures that the POCV system does not need direct visibility into the decomposition of product offers, as the PODOM system handles this complexity. By using TMF679 and TMF645 APIs, you can achieve a streamlined and efficient process for checking product offering feasibility.

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

In the context of a BSS (Business Support Systems) product architecture , the best practice involves leveraging a combination of TM Forum APIs to ensure seamless integration and accurate feasibility checks. Am trying this recommendation from a colleague ..

Product Order Capture and Validation (POCV) System:

Initiate TMF679 Request: The POCV system should initiate a TMF679 Product Order Management API request to the Product Order Delivery Orchestration and Management (PODOM) system. This API manages the lifecycle of product orders and handles the decomposition of product offers into their respective CFSs (Customer Facing Services) and RFSs (Resource Facing Services).

Product Order Delivery Orchestration and Management (PODOM):
Decompose Product Offers: Upon receiving the TMF679 request, the PODOM system decomposes the product offers into CFSs and RFSs.
Service Qualification Check: The PODOM system then makes a TMF645 Service Qualification API call to the Service Qualification Management system. This API checks the technical feasibility of the CFSs and RFSs on both the CSP's own network and any required partner networks.

Service Qualification Management System:
Process Feasibility Check: The Service Qualification Management system processes the TMF645 request and returns the feasibility results to the PODOM system.
Translate Results: The PODOM system translates these results back into a product qualification response and sends it to the POCV system.

This approach ensures that the POCV system does not need direct visibility into the decomposition of product offers, as the PODOM system handles this complexity. By using TMF679 and TMF645 APIs, you can achieve a streamlined and efficient process for checking product offering feasibility.

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

Hello,

I agree with Mathieu on this point - let's avoid using terminology that may not be familiar to the wider community, as it can create unnecessary confusion.

To keep things consistent and aligned with the ODA model, please refer to the components as follows:

• Product Order Capture and Validation (POCV) System → TMFC002: Product Order Capture and Validation

• Product Order Delivery Orchestration and Management (PODOM) → TMFC003: Product Order Delivery Orchestration and Management

• Service Qualification Management → TMFC009: Service Qualification Management

Clarity in naming helps everyone stay aligned and improves communication across teams and programs.

Thanks!

In the context of a BSS (Business Support Systems) product architecture , the best practice involves leveraging a combination of TM Forum APIs to ensure seamless integration and accurate feasibility checks. Am trying this recommendation from a colleague ..

Product Order Capture and Validation (POCV) System:

Initiate TMF679 Request: The POCV system should initiate a TMF679 Product Order Management API request to the Product Order Delivery Orchestration and Management (PODOM) system. This API manages the lifecycle of product orders and handles the decomposition of product offers into their respective CFSs (Customer Facing Services) and RFSs (Resource Facing Services).

Product Order Delivery Orchestration and Management (PODOM):
Decompose Product Offers: Upon receiving the TMF679 request, the PODOM system decomposes the product offers into CFSs and RFSs.
Service Qualification Check: The PODOM system then makes a TMF645 Service Qualification API call to the Service Qualification Management system. This API checks the technical feasibility of the CFSs and RFSs on both the CSP's own network and any required partner networks.

Service Qualification Management System:
Process Feasibility Check: The Service Qualification Management system processes the TMF645 request and returns the feasibility results to the PODOM system.
Translate Results: The PODOM system translates these results back into a product qualification response and sends it to the POCV system.

This approach ensures that the POCV system does not need direct visibility into the decomposition of product offers, as the PODOM system handles this complexity. By using TMF679 and TMF645 APIs, you can achieve a streamlined and efficient process for checking product offering feasibility.

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

Hello 

To help address the question of how to perform technical feasibility checks for product offerings, the following flow outlines a potential approach using existing ODA components:

TMF679: Product Offering Qualification→ TMFC027: Product Configurator→ TMF645: Service Qualification→ TMFC002: Product Order Capture and Validation→ TMF645: Service Qualification→ TMFC009: Service Qualification Management→ response to TMFC002 → response to TMFC027

That said, if this approach proves to be too complex or fragmented, I've raised the question of whether we should consider introducing a dedicated ODA component specifically designed to manage technical feasibility checks for product offerings. This could help to simplify the architecture and provide a more streamlined solution for B2B and wholesale use cases

@Sylvie Demarest @Gaetano Biancardi @Patrik Farkas @Patrik Farkas @Kristian Svalheim

------------------------------
Anastasios Sarantis
CityFibre

Original Message:
Sent: Apr 15, 2025 05:03
From: Anastasios Sarantis
Subject: Technical Feasibility Check for Product Offerings

Hello,

I agree with Mathieu on this point - let's avoid using terminology that may not be familiar to the wider community, as it can create unnecessary confusion.

To keep things consistent and aligned with the ODA model, please refer to the components as follows:

• Product Order Capture and Validation (POCV) System → TMFC002: Product Order Capture and Validation

• Product Order Delivery Orchestration and Management (PODOM) → TMFC003: Product Order Delivery Orchestration and Management

• Service Qualification Management → TMFC009: Service Qualification Management

Clarity in naming helps everyone stay aligned and improves communication across teams and programs.

Thanks!

------------------------------
Anastasios Sarantis
CityFibre

Original Message:
Sent: Apr 08, 2025 03:27
From: Johan Ghazali
Subject: Technical Feasibility Check for Product Offerings

In the context of a BSS (Business Support Systems) product architecture , the best practice involves leveraging a combination of TM Forum APIs to ensure seamless integration and accurate feasibility checks. Am trying this recommendation from a colleague ..

Product Order Capture and Validation (POCV) System:

Initiate TMF679 Request: The POCV system should initiate a TMF679 Product Order Management API request to the Product Order Delivery Orchestration and Management (PODOM) system. This API manages the lifecycle of product orders and handles the decomposition of product offers into their respective CFSs (Customer Facing Services) and RFSs (Resource Facing Services).

Product Order Delivery Orchestration and Management (PODOM):
Decompose Product Offers: Upon receiving the TMF679 request, the PODOM system decomposes the product offers into CFSs and RFSs.
Service Qualification Check: The PODOM system then makes a TMF645 Service Qualification API call to the Service Qualification Management system. This API checks the technical feasibility of the CFSs and RFSs on both the CSP's own network and any required partner networks.

Service Qualification Management System:
Process Feasibility Check: The Service Qualification Management system processes the TMF645 request and returns the feasibility results to the PODOM system.
Translate Results: The PODOM system translates these results back into a product qualification response and sends it to the POCV system.

This approach ensures that the POCV system does not need direct visibility into the decomposition of product offers, as the PODOM system handles this complexity. By using TMF679 and TMF645 APIs, you can achieve a streamlined and efficient process for checking product offering feasibility.

------------------------------
Johan Ghazali
TM Technology Services Sdn Bhd

Original Message:
Sent: Apr 05, 2025 09:06
From: Kinshuk Kulshreshtha
Subject: Technical Feasibility Check for Product Offerings

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request to Product Order Delivery Orchestration and Management (PODOM) that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------

A very interesting discussion so far. In my working environment, we have already invested some effort in using the process described by Matthieu.

I'm a little surprised that people are now asking for a dedicated component for technical availability. I am not aware of any suitable entity for this in the context of the TMF. We could certainly talk about a resource qualification.

I have always understood the TMF645 API to be exactly that, a functional, technical statement about availability. The production domains of a CSP provides this interface to inform the commercial domain whether a service is available, with what properties.

If the TMF645 responds with a "qualified" state, it means for us in any case: Technically, the service can be provided and from that point on the commercial domain can use the statement to determine commercial product availability. It is then a commercial decision as to whether we also want to make a statement to the customer.

Even in a wholesale context, I think I would never offer the other CSP the TMF645 directly, but the TMF679 instead. After all, the CSPs is also a customer and I have to make a commercial statement to them.

Regards,
Jan

Technical Feasibility Check is a very common scenario in a B2B landscape where we are dealing with complex connectivity services (MPLS VPN, ELAN etc. ) across multiple customer sites. Before we can offer the service to a customer, we need to check if a particular service is feasible or not and if it could be delivered over CSPs own network or it would require a partner network as well. We do have TMF645 to address this Technical Service Qualification request, that would check the feasibility of CFSs and/or RFSs on CSPs own network or partner network. 

Now the Product Order Capture and Validation (POCV) system does not have visibility into how a particular Product Offer is decomposed into CFS/RFS to directly call TMF645 to check the technical feasibility. I would like to understand the best practice and the relevant API that should be used by CRM system to check for Product Offering Feasibility that would eventually translate into TMF645 request on the Service Qualification Management layer. Would POCV make a TMF679 request that will decompose the Product Offers to the CFS/RFSs and then make a TMF645 call do Service Qualification Management system to check the technical feasibility of the components and then translate it back to the Product Qualification? Or there is any other best practice to accomplish this use case

------------------------------
Kinshuk Kulshreshtha
Oracle Corporation

My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
------------------------------