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.

#General

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

Can you provide a bit more explanation of you model?  are you composing multiple products into Product offers?
You might want to look at the best practice guide

Product & Service Modelling Best Practices – Conforming to ODA v2.0.0 (IG1233)  which has examples from BT and Orange

which suggest composition best practice of products into Product Offering and composing CFS into explict services exposed from ODA production .
It recommends not doing composition across the CFS Product specification  boundary. ( which is not prohibited in either SID or open APIs) It recommend that product spec are a restriction of CFS Specs

The rationale is that the factory producing  ODA Production services needs to be able to fully test them ( particularly important for Networks as critical infrastructure) and this avoids the Product Managers have to worry about compatibility of various combination of CFS.  

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

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

Thanks for getting back @Dave Milham, @Raghu Meda

I went through IG1233 document. It was very helpful. It took me some time to get back as was analysing the data shared. 

Raghu, the issue is similar in nature, but it is not a common CFS. Its just a bunch of attributes that are common and needed for configuration of multiple CFS. 

I have tried to create a simple diagram to elaborate the ask and possible solution options. 

As per my reading of the guide shared above, it feels like Solution Option 1 is the way to go. It would be helpful to confirm that we're aligned on proceeding with this direction OR does Solution Option 2 has some merit? 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------

Original Message:
Sent: May 08, 2025 04:53
From: Raghu Meda
Subject: Best Practice for Product Attributes Modeling. Multiple CFS decomposing from different Product having same char.

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

Hello Trust Brains, 

Can anyone pls help with above. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------

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.

------------------------------
Manu
------------------------------

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

Hello Trust Brains, 

Can anyone pls help with above. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------

Hello Guys, 

Real world view that might help to understand. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------

Original Message:
Sent: May 23, 2025 16:46
From: MMH HH
Subject: Best Practice for Product Attributes Modeling. Multiple CFS decomposing from different Product having same char.

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.

------------------------------
Manu
------------------------------


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

Hello Trust Brains, 

Can anyone pls help with above. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited

I wonder if this should be modelled by a serviceSpecRelationship/serviceRelationship such that the UNI CFS is dependent on the related Internet Offer but doesn't repeat the definition of the Internet Offer?

------------------------------
Gordon Bolt
Ciena Corporation
------------------------------

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

Hello Guys, 

Real world view that might help to understand. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------


Original Message:
Sent: May 23, 2025 16:46
From: MMH HH
Subject: Best Practice for Product Attributes Modeling. Multiple CFS decomposing from different Product having same char.

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.

------------------------------
Manu


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

Hello Trust Brains, 

Can anyone pls help with above. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited

Hi Anurag,

How about having a common CFS holding common attributes and associating to the Internet and UNI CFSs?

The common CFS will be updated from time to time when either internet or UNI CFS are updated which may be visible to parent CFSs

Have you already explored this option?

Regards,

Sivaji Venkat

Ciena Blue Planet

------------------------------
Sivaji Venkat
Ciena Corporation
------------------------------

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

Hello Guys, 

Real world view that might help to understand. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited
------------------------------


Original Message:
Sent: May 23, 2025 16:46
From: MMH HH
Subject: Best Practice for Product Attributes Modeling. Multiple CFS decomposing from different Product having same char.

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.

------------------------------
Manu


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

Hello Trust Brains, 

Can anyone pls help with above. 

------------------------------
Anuraag Gupta
Singtel Optus Pty Limited