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

Thank @Jan Lemmermann! I think there is no doubt that TMF645 will provide the technical feasibility and I am 100% aligned with what you mentioned above. You have beautifully summarized the  core gap that we seems to have that I have raised in my question

While we do have TMFC009 Service Qualification Management in Production to decompose CFS into RFS to find the Technical feasibility and availability, we don't have a corresponding Service Qualification Management component in Core Commerce to take the Product Qualification Request and decompose Products into CFS to call the TMF645 for technical feasibility. In absence of that, people are trying to use PODOM for that purpose, but as @Matthieu Hattab highlighted, PODOM does not expose any API. So, its not the right place. I see someone using Product Configurator to do this conversion as well. 

Essentially what we are missing is a bonafide Product Qualification Management Component in ODA that will expose TMF679 Product Qualification API and will decompose Products into CFSs to call TMF645 for Technical Feasibility of the component services in a Product Bundle. This component will also be responsible for doing commercial feasibility by doing credit check etc. and then aggregate everything to determine the overall feasibility of a Product Offering or Bundled Product Offering for a given customer. 

Please let me know what everyone think on this proposal and if you agree, we can propose this component to be added to ODA component directory.

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

Hi @Kinshuk Kulshreshtha,

Completely agree with your assessment - you've captured the gap perfectly.

We also proposed a new ODA component to handle this functionality, but the ODA Components team wasn't too keen. That said, I strongly believe it's needed.

In the Wholesale Broadband Standardisation Program, we have a clear B2B pre-order use case where the seller must inform the buyer: "These are the product offerings I can support at this location," with technical feasibility already validated per offering. Currently, there's no dedicated component in Core Commerce to decompose product offerings into CFS and invoke TMF645 Service Qualification API, and using Product Configurator for this is not a clean solution.

I fully support formalizing this as a  TMFC XXX Product Qualification Management component and proposing it for inclusion in the ODA Component Directory.

Best,
Tassos Sarantis

Thank @Jan Lemmermann! I think there is no doubt that TMF645 will provide the technical feasibility and I am 100% aligned with what you mentioned above. You have beautifully summarized the  core gap that we seems to have that I have raised in my question

While we do have TMFC009 Service Qualification Management in Production to decompose CFS into RFS to find the Technical feasibility and availability, we don't have a corresponding Service Qualification Management component in Core Commerce to take the Product Qualification Request and decompose Products into CFS to call the TMF645 for technical feasibility. In absence of that, people are trying to use PODOM for that purpose, but as @Matthieu Hattab highlighted, PODOM does not expose any API. So, its not the right place. I see someone using Product Configurator to do this conversion as well. 

Essentially what we are missing is a bonafide Product Qualification Management Component in ODA that will expose TMF679 Product Qualification API and will decompose Products into CFSs to call TMF645 for Technical Feasibility of the component services in a Product Bundle. This component will also be responsible for doing commercial feasibility by doing credit check etc. and then aggregate everything to determine the overall feasibility of a Product Offering or Bundled Product Offering for a given customer. 

Please let me know what everyone think on this proposal and if you agree, we can propose this component to be added to ODA component directory.

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

Thank @Jan Lemmermann! I think there is no doubt that TMF645 will provide the technical feasibility and I am 100% aligned with what you mentioned above. You have beautifully summarized the  core gap that we seems to have that I have raised in my question

While we do have TMFC009 Service Qualification Management in Production to decompose CFS into RFS to find the Technical feasibility and availability, we don't have a corresponding Service Qualification Management component in Core Commerce to take the Product Qualification Request and decompose Products into CFS to call the TMF645 for technical feasibility. In absence of that, people are trying to use PODOM for that purpose, but as @Matthieu Hattab highlighted, PODOM does not expose any API. So, its not the right place. I see someone using Product Configurator to do this conversion as well. 

Essentially what we are missing is a bonafide Product Qualification Management Component in ODA that will expose TMF679 Product Qualification API and will decompose Products into CFSs to call TMF645 for Technical Feasibility of the component services in a Product Bundle. This component will also be responsible for doing commercial feasibility by doing credit check etc. and then aggregate everything to determine the overall feasibility of a Product Offering or Bundled Product Offering for a given customer. 

Please let me know what everyone think on this proposal and if you agree, we can propose this component to be added to ODA component directory.

------------------------------
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 17, 2025 05:00
From: Jan Lemmermann
Subject: Technical Feasibility Check for Product Offerings

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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 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 @Jan Lemmermann,

Thanks for your thoughtful response. I agree with your interpretation of TMF645 Service Qualification API as a technical availability check provided by production domains to support commercial decisions.

To clarify, we are not suggesting exposing TMF645 directly to the CSP. Instead, we're looking to expose TMF679 Product Offering Qualification as the storefront to the CSP. Each product offering should be validated for technical feasibility per location using TMF645, behind the scenes.

Currently, the only place where TMF679 and TMF645 are used together is TMFC002 Product Order Capture and Validation, but TMF645 is not a dependent API in TMFC027 Product Configurator, which is where this logic ideally belongs in the pre-order phase.

Since we don't have an engagement layer or portal, we're considering three options:

1. Use TMFC002 and adapt it to handle product offering qualification via process flow API.

2. Extend TMFC027 to use TMF645 as a dependent API (this was declined by the ODA team).

3. Propose a new ODA component to link product offerings from the catalog with technical feasibility via TMF645, especially relevant in wholesale use cases (e.g., different bandwidth offerings depending on location capabilities).

This isn't about exposing TMF645 externally, but addressing a real gap in how technical feasibility is handled for product offerings in B2B/wholesale contexts.

Would love your thoughts on whether this gap justifies a new component or if you see an alternate solution.

Best regards,
Tassos

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

Original Message:
Sent: Apr 17, 2025 05:00
From: Jan Lemmermann
Subject: Technical Feasibility Check for Product Offerings

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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 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 alignment on the need of a new Product Qualification Component. Based on the above discussion, I have created a new Jira issue TAC-1075 to track this request. Let's work together to push this through with TMF to get it accepted. Please feel free to update the Jira issue and add your inputs in that.

Hi @Jan Lemmermann,

Thanks for your thoughtful response. I agree with your interpretation of TMF645 Service Qualification API as a technical availability check provided by production domains to support commercial decisions.

To clarify, we are not suggesting exposing TMF645 directly to the CSP. Instead, we're looking to expose TMF679 Product Offering Qualification as the storefront to the CSP. Each product offering should be validated for technical feasibility per location using TMF645, behind the scenes.

Currently, the only place where TMF679 and TMF645 are used together is TMFC002 Product Order Capture and Validation, but TMF645 is not a dependent API in TMFC027 Product Configurator, which is where this logic ideally belongs in the pre-order phase.

Since we don't have an engagement layer or portal, we're considering three options:

1. Use TMFC002 and adapt it to handle product offering qualification via process flow API.

2. Extend TMFC027 to use TMF645 as a dependent API (this was declined by the ODA team).

3. Propose a new ODA component to link product offerings from the catalog with technical feasibility via TMF645, especially relevant in wholesale use cases (e.g., different bandwidth offerings depending on location capabilities).

This isn't about exposing TMF645 externally, but addressing a real gap in how technical feasibility is handled for product offerings in B2B/wholesale contexts.

Would love your thoughts on whether this gap justifies a new component or if you see an alternate solution.

Best regards,
Tassos

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

Original Message:
Sent: Apr 17, 2025 05:00
From: Jan Lemmermann
Subject: Technical Feasibility Check for Product Offerings

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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

@Kinshuk Kulshreshtha,

when I recommended you to read IG1228, did you also check other use cases?  I just notice Use case 8 has an interesting notes section and the first one says this:

• translationRules are a proposed API extension. This resource represents the rules used to translate product characteristics into the corresponding CFS and resource characteristics. See section 6 for related JIRA issue. 

That describes perfectly what I do with our composite qualification component. We store this translationRules in our component database and it is used to construct CFS based on requested PS.
We maintain it manually (for now). Whenever there is a change in Service Catalogue or Product Catalogue (happens rarely, though), we also update our "translationRules"

also, if you make important progress with your endeavour, would you mind to share your findings in this community?

Hi All,

Thanks for your alignment on the need of a new Product Qualification Component. Based on the above discussion, I have created a new Jira issue TAC-1075 to track this request. Let's work together to push this through with TMF to get it accepted. Please feel free to update the Jira issue and add your inputs in that.

Hi @Jan Lemmermann,

Thanks for your thoughtful response. I agree with your interpretation of TMF645 Service Qualification API as a technical availability check provided by production domains to support commercial decisions.

To clarify, we are not suggesting exposing TMF645 directly to the CSP. Instead, we're looking to expose TMF679 Product Offering Qualification as the storefront to the CSP. Each product offering should be validated for technical feasibility per location using TMF645, behind the scenes.

Currently, the only place where TMF679 and TMF645 are used together is TMFC002 Product Order Capture and Validation, but TMF645 is not a dependent API in TMFC027 Product Configurator, which is where this logic ideally belongs in the pre-order phase.

Since we don't have an engagement layer or portal, we're considering three options:

1. Use TMFC002 and adapt it to handle product offering qualification via process flow API.

2. Extend TMFC027 to use TMF645 as a dependent API (this was declined by the ODA team).

3. Propose a new ODA component to link product offerings from the catalog with technical feasibility via TMF645, especially relevant in wholesale use cases (e.g., different bandwidth offerings depending on location capabilities).

This isn't about exposing TMF645 externally, but addressing a real gap in how technical feasibility is handled for product offerings in B2B/wholesale contexts.

Would love your thoughts on whether this gap justifies a new component or if you see an alternate solution.

Best regards,
Tassos

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

Original Message:
Sent: Apr 17, 2025 05:00
From: Jan Lemmermann
Subject: Technical Feasibility Check for Product Offerings

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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

@Matthieu Hattab,

Yes I have been very close for Use Case 8 right from its early days and contributed with my inputs to it as well many years back. I think Product/Service Catalog is the right  place to store these transition rules. We already have Product Spec to Service Spec relationship  in TMF620 and Service Spec (CFS) to Service Spec (RFS) relationship in TMF633. I think the best place to put those transition rules would be the API extensions to TMF620 and TMF633. The proposed Product Qualification component will call the TMF620 API to convert the Products to CFSs including the characteristic mapping extensions to create the CFSs, so that it can call TMF645 for the technical qualification and then translate it back to the Product Qualification.

Are you also doing a similar flow in your composite Qualification Component or is it something different? Would you agree with the  flow that I described above?

@Kinshuk Kulshreshtha,

when I recommended you to read IG1228, did you also check other use cases?  I just notice Use case 8 has an interesting notes section and the first one says this:

• translationRules are a proposed API extension. This resource represents the rules used to translate product characteristics into the corresponding CFS and resource characteristics. See section 6 for related JIRA issue. 

That describes perfectly what I do with our composite qualification component. We store this translationRules in our component database and it is used to construct CFS based on requested PS.
We maintain it manually (for now). Whenever there is a change in Service Catalogue or Product Catalogue (happens rarely, though), we also update our "translationRules"

also, if you make important progress with your endeavour, would you mind to share your findings in this community?

Hi All,

Thanks for your alignment on the need of a new Product Qualification Component. Based on the above discussion, I have created a new Jira issue TAC-1075 to track this request. Let's work together to push this through with TMF to get it accepted. Please feel free to update the Jira issue and add your inputs in that.

Hi @Jan Lemmermann,

Thanks for your thoughtful response. I agree with your interpretation of TMF645 Service Qualification API as a technical availability check provided by production domains to support commercial decisions.

To clarify, we are not suggesting exposing TMF645 directly to the CSP. Instead, we're looking to expose TMF679 Product Offering Qualification as the storefront to the CSP. Each product offering should be validated for technical feasibility per location using TMF645, behind the scenes.

Currently, the only place where TMF679 and TMF645 are used together is TMFC002 Product Order Capture and Validation, but TMF645 is not a dependent API in TMFC027 Product Configurator, which is where this logic ideally belongs in the pre-order phase.

Since we don't have an engagement layer or portal, we're considering three options:

1. Use TMFC002 and adapt it to handle product offering qualification via process flow API.

2. Extend TMFC027 to use TMF645 as a dependent API (this was declined by the ODA team).

3. Propose a new ODA component to link product offerings from the catalog with technical feasibility via TMF645, especially relevant in wholesale use cases (e.g., different bandwidth offerings depending on location capabilities).

This isn't about exposing TMF645 externally, but addressing a real gap in how technical feasibility is handled for product offerings in B2B/wholesale contexts.

Would love your thoughts on whether this gap justifies a new component or if you see an alternate solution.

Best regards,
Tassos

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

Original Message:
Sent: Apr 17, 2025 05:00
From: Jan Lemmermann
Subject: Technical Feasibility Check for Product Offerings

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

------------------------------
Jan Lemmermann
OSS Lead Architect
EWE TEL GmbH

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