Open APIs

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Hi Mahesh, Jonathan and Matthieu

IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.

I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.

We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.

If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases

And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.

Best regards

Sylvie

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Hi,

When considering your design choices here you should also look at other use cases.

By having an atomic ProductOffering for each atomic ProductSpecification, the catalog can also be defined in such a way that IFRS 15 revenue recognition can easily be correctly implemented.

For a bundle of Internet, voice and TV. IFRS rules require you to report on revenue for each of these "performance obligations" seperately. If each of Atomic ProductSpecification has its own ProductOffering, product managers are forced to correctly allocate the price for each of these performance obligations. This makes sure that you don't have to build hardcoded rules in a revenue recognition engine.

Best Regards

Hi Mahesh, Jonathan and Matthieu

IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.

I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.

We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.

If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases

And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.

Best regards

Sylvie

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Hi,

Thanks for the usecase. But what if the atomic product specification is purely for provisioning purpose and doesn't have any effect on pricing ? Do we still need to create respective product offering for the same ? If the answer is no, should there be some identifier which forces the product managers to create respective product offering for any product spec that has price impact ? Let me know your thoughts pls.

Hi,

When considering your design choices here you should also look at other use cases.

By having an atomic ProductOffering for each atomic ProductSpecification, the catalog can also be defined in such a way that IFRS 15 revenue recognition can easily be correctly implemented.

For a bundle of Internet, voice and TV. IFRS rules require you to report on revenue for each of these "performance obligations" seperately. If each of Atomic ProductSpecification has its own ProductOffering, product managers are forced to correctly allocate the price for each of these performance obligations. This makes sure that you don't have to build hardcoded rules in a revenue recognition engine.

Best Regards

Hi Mahesh, Jonathan and Matthieu

IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.

I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.

We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.

If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases

And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.

Best regards

Sylvie

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Hi,

Thanks for the usecase. But what if the atomic product specification is purely for provisioning purpose and doesn't have any effect on pricing ? Do we still need to create respective product offering for the same ? If the answer is no, should there be some identifier which forces the product managers to create respective product offering for any product spec that has price impact ? Let me know your thoughts pls.

Hi,

When considering your design choices here you should also look at other use cases.

By having an atomic ProductOffering for each atomic ProductSpecification, the catalog can also be defined in such a way that IFRS 15 revenue recognition can easily be correctly implemented.

For a bundle of Internet, voice and TV. IFRS rules require you to report on revenue for each of these "performance obligations" seperately. If each of Atomic ProductSpecification has its own ProductOffering, product managers are forced to correctly allocate the price for each of these performance obligations. This makes sure that you don't have to build hardcoded rules in a revenue recognition engine.

Best Regards

Hi Mahesh, Jonathan and Matthieu

IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.

I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.

We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.

If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases

And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.

Best regards

Sylvie

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.

Hi,

Thanks for the usecase. But what if the atomic product specification is purely for provisioning purpose and doesn't have any effect on pricing ? Do we still need to create respective product offering for the same ? If the answer is no, should there be some identifier which forces the product managers to create respective product offering for any product spec that has price impact ? Let me know your thoughts pls.

Hi,

When considering your design choices here you should also look at other use cases.

By having an atomic ProductOffering for each atomic ProductSpecification, the catalog can also be defined in such a way that IFRS 15 revenue recognition can easily be correctly implemented.

For a bundle of Internet, voice and TV. IFRS rules require you to report on revenue for each of these "performance obligations" seperately. If each of Atomic ProductSpecification has its own ProductOffering, product managers are forced to correctly allocate the price for each of these performance obligations. This makes sure that you don't have to build hardcoded rules in a revenue recognition engine.

Best Regards

Hi Mahesh, Jonathan and Matthieu

IG1233 was published in April 2021, and I contributed to it at chapter 4.2 - email Service and 4.3 - email Product levels. This version also presented an example provided by BT in 4.1 - Broadband example.

I confirm that in Orange we recommend not to use composite CFS specification and composite Product specification, but of course anyone can make different choices.

We have described many CFS, Product and Product Offering specifications internally - including complex contracts and B2B products - and always succeeded to identify atomic CFS and Product specification, corresponding to the functional view of what we can commercialize and allowing to add, configurate, modify or delete each of them independently.

If you are interested in more complex catalog views, at product offering, product, CFS, RFS and resource specifications levels, don't hesitate to have a look at IG1228 use cases

And if you have a specific catalog example in mind, with composition of products/CFS specification, you can join our End to End ODA Call Flow Use Cases Meetings on thursday 2 pm CET to share it and discuss.

Best regards

Sylvie

Please note that the statement you referenced is from section 4.3.3, which outlines "Orange best practices."

IG1233 essentially serves as a guide from Orange's perspective and experience.

Ideally, IG1233 should be revised to reflect a broader range of opinions and best practices, rather than just those of a single CSP.

While it remains a valuable resource, it's advisable not to follow it verbatim.

It's also worth mentioning that other CSPs and ISVs (Independent Software Vendors) have contributed their own product modeling recommendations. However, these have not been officially published as TMF deliverables. It's hard to find them and they are often Powerpoint presentations, word docs "hidden" in TMF confluence page.

On Page 24 of IG1233_Product_and_Service_Modelling_Best_Practices guide, i noticed below statement. Does this mean, we should try to stay away from composite pattern for product specifications. If yes, should we try to make product offerings composite to achieve the required results ? I am little confused on this part. Any help would be appreciated.