TM Forum Community

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

Hi Anuraag,

If I understood your question correctly, you are looking for certain common service characteristics that can be used across multiple CFS services. For eg. I can think of SLAs, Monitoring, Tests, etc which are typical CFS services which will be required for many products in general and you may want to have different flavours/variety of those CFS as separate CFS per Product Spec (hence product offer) where there can be some common service characteristics that can be used across those separate CFS flavours. 

For eg. Monitoring CFS - this is typically required for any product offer. But there could be requirements where specific flavours of Monitoring CFS are designed for some products instead of using a monolithic common CFS (to have fine grained modularity and avoid the overloading of attributes and reduce business rules complexity) whereas other products will still be using the common/generic Monitoring CFS. In that case, one can end up having different Monitoring CFS requiring the same service characteristics (eg. latency, throughput, thresholds, etc). 

For such cases, a base/foundation Monitoring CFS can be created which contains the service characteristics that are commonly used for generic CFS and as well as specific CFS flavours. Generic CFS and Specific CFS will inherit the base/foundation CFS in order to get the common service characteristics so that duplication of data in inventory will be avoided. 

------------------------------
Raghu Meda
Infosys

Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 06, 2025 19:10
From: Anuraag Gupta
Subject: Best Practice for Product Attributes Modeling. Multiple CFS decomposing from different Product having same char.

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

#General

------------------------------
Anuraag Gupta
Optus
------------------------------

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

Hello Trust Brains, 

Can anyone pls help with above. 

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

The use case is not so clear. The question I've is, why should CFS1 and CFS2 have to have the same attribute and value. What necessitates this? A real life use case sharing might be better.

Hello Trust Brains, 

Can anyone pls help with above. 

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

Hello Guys, 

Real world view that might help to understand. 

The use case is not so clear. The question I've is, why should CFS1 and CFS2 have to have the same attribute and value. What necessitates this? A real life use case sharing might be better.

Hello Trust Brains, 

Can anyone pls help with above. 

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.

Hello Guys, 

Real world view that might help to understand. 

The use case is not so clear. The question I've is, why should CFS1 and CFS2 have to have the same attribute and value. What necessitates this? A real life use case sharing might be better.

Hello Trust Brains, 

Can anyone pls help with above. 

Looking for insights on a design approach around Product attribute modeling in a TMF-compliant architecture.

In our setup (as in most), combination of CFS instances forms the customer usable service. Due to some intricacies on the network/service design, there are some common attributes which are modelled across multiple CFS and they need to have the same values. E.g. CFS 1 as attribute 1, CFS 2 also has attribute 1. Both decompose from different products and need to have same values.

To maintain attribute consistency and support new connect and modify journeys, we're evaluating two options to drive correct order journeys and Product inventories :

Option 1:
Model or derive each attribute directly on the associated Products. E.g. Product 1 has attribute 1, attribute 2. Product 2 also has attribute 1, attribute 2. 

Thus multiple Offers/Products will have same attributes.

(Rules to apply in CPQ capture journey to ensure they have same value) 

Pros: Each Product has this attribute to drive its order and inventory. 

Cons: Overhead of rules to make sure the values are consistent across different products. 

Option 2:
Introduce control flags on dependent Products/offers. When an attribute changes in one Product/Offer, flags on related Products are updated to trigger updates/modifications in corresponding CFS. 

E.g. Product 1 has attribute 1, attribute 2. Product 2 has Y/N flags that gets updated when Product 1 attribute is impacted. 

(Rules need to be written to pass values on other CFS/Service Order for all order types. )

Pros: Attribute getting captured and mastered in a single Product.

Cons: Overhead of rules to derive transaction in other Product. Not aligned with TMF principles that all CFS characteristic value should be derived from its own Product.  

Ask:
Which option aligns better with TM Forum best practices?

Personally, I favor Option 1 as it ensures alignment that all CFS char are derived from the Product it decomposes from, but keen to hear from others who've faced this pattern.