TM Forum Community

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.

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.

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.

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.

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

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