TM Forum Community

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

Thanks Pieter,

This is super useful, this clarifies things a bit better. I see what you mean about the benefits of decomposition in service design.

It makes sense that a service order should target a single SOM and that deconstruction should then enable orchestration as required to fulfill that higher level product facing capability.

Keeping that distinction de-couplig between implementation concerns and product facing ones does sound valuable.

So then a SOM might conceivably create more service orders when decomposing a CFS

Thanks,

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

If you haven't come across it, we do have a Product Modelling Playbook, which you can find under our Code+framework menu. Howver over "How to apply ODA" and when the submenu appears, select Member toolkits.  When the page loads, scroll down the Playbooks and the 2nd to last says "How can i use ODA to enhance and accelerate new product innovation and delivery?"

In that Playbook you'll see a series of steps that refer out to videos, webeinars, technical guides like the one Dave Muilham has posted, etc.

We also have a series of Product Modelling workshops, and if you would like to know more then drop a line to your Engagement Manager, Harry Wang, hwang@tmforum.org, and we can chat about those.

Dave

Thanks Pieter,

This is super useful, this clarifies things a bit better. I see what you mean about the benefits of decomposition in service design.

It makes sense that a service order should target a single SOM and that deconstruction should then enable orchestration as required to fulfill that higher level product facing capability.

Keeping that distinction de-couplig between implementation concerns and product facing ones does sound valuable.

So then a SOM might conceivably create more service orders when decomposing a CFS

Thanks,

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

Thanks Pieter,

One more question. Do you know where I might see examples for more complex decomposition examples? Ones you've described above that will help me align my thinking with better service design and orchestration

Thanks

------------------------------
Adam Moyes
Aussie Broadband Limited

Original Message:
Sent: Mar 12, 2025 04:56
From: Pieter Eksteen
Subject: Service Order Modelling across domains

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

------------------------------
Pieter Eksteen
CIENA Blue Planet

Original Message:
Sent: Mar 11, 2025 00:34
From: Adam Moyes
Subject: Service Order Modelling across domains

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

#OpenDigitalArchitecture

------------------------------
Adam Moyes
Aussie Broadband Limited
------------------------------

Have a look at Product & Service Modelling Best Practices – Conforming to ODA v2.0.0 (IG1233) – TM Forum  which was a best practice developed by BT and Orange with examples

------------------------------
Dave Milham
TM Forum, Chief Architect

Original Message:
Sent: Mar 13, 2025 20:27
From: Adam Moyes
Subject: Service Order Modelling across domains

Thanks Pieter,

One more question. Do you know where I might see examples for more complex decomposition examples? Ones you've described above that will help me align my thinking with better service design and orchestration

Thanks

------------------------------
Adam Moyes
Aussie Broadband Limited

Original Message:
Sent: Mar 12, 2025 04:56
From: Pieter Eksteen
Subject: Service Order Modelling across domains

Hi Adam,

Really good set of questions.

I think it is important to state up front that the examples and scenarios in most of the documents are constructed the way the are for simplicity, not completeness.

For example: TMFC007's example has a single RFS per CFS, but there is absolutely no reason why you couldn't have a CFS relating to 2 or more RFSs - in fact - there is no reason to assume that a CFS could even decompose to another CFS or CFSs (which in other circumstances would be requested directly).

TMFS008 correctly states that you would have to direct your Service Orders (for CFSs) to different domain Service Order Managers in those instances where the individual CFS's that compose the products being ordered are fulfilled by different systems. This is not an unusual situation in many service providers.

It is very easy to fall into the trap of turning every RFS into a CFS, and every CFS into a product. This approach is responsible for slowing down implementations and increasing the costs of implementation and training in the order capture domain systems (like CPQ). The benefits of using decomposition are often understated - not only in the standards documents, but in the use cases too. 

Obviously for simple, transparent (in terms of visibility and understanding by customers) services - it doesn't make much difference. But for complex, multiple resource and service comprised services - leveraging decomposition (with propogation of inputs during decomposition) can make a substantial difference in terms of cost of implementation, flexibility in service and product creation in the future.

------------------------------
Pieter Eksteen
CIENA Blue Planet

Original Message:
Sent: Mar 11, 2025 00:34
From: Adam Moyes
Subject: Service Order Modelling across domains

I am modelling a single product that is fulfilled by interaction with two separate operational domains. One is an upstream provider and the other is our centralised Network Configuration and CMDB service.

So there are two service factory domains and associated RFSs:

1. Service Access - provisioning with an upstream provider's service API to fulfil the request for the customer's service
2. Network Connectivity - configuring our network (and related services) via an internal service API to enable connectivity by the customer to their new service

Initially I had two RFSs linked to a single CFS - but after reading through case studies and TMFC007 I'm seeing different approaches (References at the bottom)

TMFC007 - Service Order Management v1.2.1
- Seems to imply only 1 RFS per CFS

TMFS008 - Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0
- Mentions 1 service order per service factory

TMFS004 Order Delivery – Fiber contract v1.0.0
- Also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Question:

Would we be better off modelling these two RFSs as two CFSs being handled by two service orders?

That seems to be a common theme. Or, given that we don't actually sell 'Network Connectivity' and this probably doesn't make sense to be customer/product facing then perhaps this is better handled further down as part of the offered service's RFS 
Given there are two distinct operational domains and two distinct domain authorities then they will have dependencies and separate lifecycles so the solution should allow for that.

References:

TMFC007 - Service Order Management v1.2.1

Seems to imply only 1 RFS per CFS

"To achieve delivery of a CFS, the SOM orchestrates the service order delivery process which:
- Identifies the possible technical solutions (RFS level) and chooses one, using the catalogue rules of choice, the technical inventory and the configuration of the service order."

TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.4.0

"The product order orchestration and management component decomposes the product order in two new orders:

...

• A service order that contains the CFS specifications associated with the product specifications in the catalog. The grouping of all CFS order items in a single CFS order rests on the implicit assumption that all the CFS based products are delivered by a single "CFS factory". If several factories were involved, several orders would be needed and processing of these service orders would be orchestrated by POOM."

TMFS004 Order Delivery – Fiber contract v1.0.0

This also has a 1:1 relationship between Service Orders, Product Specs, CFSs and presumably RFSs as they align with the Service Factories on page 6

Thanks

#OpenDigitalArchitecture

------------------------------
Adam Moyes
Aussie Broadband Limited
------------------------------