Open APIs

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

Hi
In version 5 of the TMF620 API we have introduced the concept of a Product Offering Group, which will allow semantics (for example) of choosing between 3 and 5 items out of a list of 20.
You can see a preliminary version of this in the beta Open API table https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=128855518 . Since then, following valuable input from @Lutz Bettge of Deutsche Telekom, we made additional changes. I cannot share here yet, since we are still in an internal team review process. Watch this space.

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

so "product Offering Group" is the new name for "Selection Group"?

Hi
In version 5 of the TMF620 API we have introduced the concept of a Product Offering Group, which will allow semantics (for example) of choosing between 3 and 5 items out of a list of 20.
You can see a preliminary version of this in the beta Open API table https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=128855518 . Since then, following valuable input from @Lutz Bettge of Deutsche Telekom, we made additional changes. I cannot share here yet, since we are still in an internal team review process. Watch this space.

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

Selection Group is an informal name for a set of common use cases that the model enables.
The formal name in the model is BundledGroupProductOffering, and it has cardinalities in a sub-entity called BundledGroupProductOfferingOption.

so "product Offering Group" is the new name for "Selection Group"?

Hi
In version 5 of the TMF620 API we have introduced the concept of a Product Offering Group, which will allow semantics (for example) of choosing between 3 and 5 items out of a list of 20.
You can see a preliminary version of this in the beta Open API table https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=128855518 . Since then, following valuable input from @Lutz Bettge of Deutsche Telekom, we made additional changes. I cannot share here yet, since we are still in an internal team review process. Watch this space.

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

@Jonathan Goldberg Thank you, the Product Offering Group example semantics you gave sound very promising! Do you have an idea when v5 could be released (weeks/months/years/…)? Using a beta version is probably not recommended for anything other then testing purposes.

@Matthieu Hattab Thank you, the "selection group" (or "Product Offering Group") sounds very promising for this purpose indeed.

I'm aware of at least some of the possibilities of using characteristics, though I couldn't think of a suitable way to model the "mandatory choice of router" example I gave. From my understanding, a ProductSpecificationCharaceristicValueUse allows choosing a subset of the ProductSpecificationCharaceristicValues defined on a ProductSpecification, either on ProductOffering or ProductOfferingPrice level. The semantics (from my possibly flawed understanding) is that the given PO or POP then has all the characteristicValues selected in the Use. How could this be used to enforce the choice of one of the values?

We do intend to use characteristics for a choice of bandwidth in the mandatory internet product in the example I gave, which uses exactly one of the all available bandwidths. I assume other bandwidths would have different prices, and thus (I think) would have to be modeled in separate product offerings. The choice would then be between one of the product offerings.

Product eligibility/compatibility I didn't find within the TMF620 v4.1 spec, is that something new (v5?), or in a different API?

When looking for "policy" in the TMF620 v4.1 spec I found ConstraintRef for POPs, which I haven't looked at in detail yet. Is that what you meant? The docu says "The Constraint resource represents a policy/rule applied to ProductOfferingPrice". I suppose one could make a "MustHaveOneOfThese" constraint and apply it to the 3 router-options, which the ordering system would then have to know how to follow. Though that seems similarly cumbersome as using self-defined POPRelationships.

----

I'll have to search this forum some more to hopefully find more inspiration/info, and continue to be grateful to all pointers.

------------------------------
Oliver Büechi
Ergon Informatik AG

Original Message:
Sent: May 15, 2023 10:57
From: Matthieu Hattab
Subject: TMF620: How to model a choice?

From SID/TMF620

• If you want a composite bundle, BundledProductOfferingOptions is the way to go (it also supports cardinality)
• for non-composite bundle, ProductOfferingRelationship is a better option (for fit to support business rules, cross sells, up-sells...)
• for product with cardinality rules at 2 levels (at product category level + at product level) use "Selection Group".
  Notes:
  • "selection Group" will be added to API620 V5 (although with a different name, I heard)
  • that should fit very well with your example of routers
• You can also use characteristic values to model "choices", i.e the choice of bandwidth. (also supports cardinality)
• in a wider sense, product eligibility/compatibility rules may also be use to some extend.
• for complex scenariso, Policy can also be used.

for guidance, general information about product modelling:

TMF communities

• search this term "selection Group", "product model" or equivalent, lots of discussions have been posted over the years.

TMF WIKI
Some members (BT, Orange, Amdocs...) have shared their product model techniques in powerpoint, videos etc that are shared in their weekly meetings in TMF Wiki or shared at TMF events, typically at Accelerate events. These are extremely hard to find, though. If you're willing to get your hands dirty, you can also find some gems hidden in documentations provided by participants of TMF Catalysts

TMF publication

• GB922 - Product
• IG1236__Best_Practice_CPE_Modelling_for_Quotation_Ordering_Delivery_and_Support
• IG1233_Product_and_Service_Modelling_Best_Practices_Conforming_to_ODA
• IG1228 How to use ODA – Using Open APIs to realize Use Cases
  • IG2228 has one or two use cases showing product model from multiple point of views, catalogue, order...)

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 15, 2023 03:28
From: Oliver Büechi
Subject: TMF620: How to model a choice?

Let's assume we'd like to offer a composite product comprised of multiple components

1. Mandatory internet access
2. Optional router hardware
3. Optional security software
4. Optional IP-TV software

From my understanding, a reasonable way to model this would be to make each of the 4 bullet points into its own ProductSpecification (PS). Given that "internet access" is the only mandatory part of the product, the later 3 PS will be bundled with it using BundledProductSpecification (BPS). This sets the stage for the next layer.

Part 1: Option:
From my understanding, the ideal way to model the optional parts seems to be BundledProductOfferingOptions (BPOO).

So each of the 4 PS would get its own corresponding ProductOffering (PO). The "internet access" PO is kind of be the "master", and the other 3 POs would be bundled with it using BundledProductOfferingOptions (BPOO), with numberRelOfferLowerLimit 0, numberRelOfferUpperLimit 1, and appropriate numberRelOfferDefaults: for example 1 for the hardware and 0 for the softwares.

Does this seem like a reasonable way to model this so far?

Part 2: Choice
Making the router hardware a mandatory part of the bundle would be easy: set its numberRelOfferLowerLimit to 1.

Let's then say we'd like to offer a choice of 3 types of router:
a) default router for 5/month
b) deluxe router for 10/month
c) no router for free (customer has its own router already)

What would be a good way to model the requirement of having to make a choice? My thoughts are:

A possibility would be to split the original bundled PO into 3 separate POs: one with the default router, another with the deluxe router, and a last one with no router. So the choice was sort of extracted to the top level. This feels somewhat natural, but depending on the number of available choices in one's product catalog this might lead to a large number of POs due to the combinatorial explosion.

Another thing that came to mind: there's always the fallback of defining one's own ProductSpecificationRelationship (PSR). So maybe a mandatory "router" PS and PO would be a bundle consisting of the 3 choices as their own PS/PO, and the 3 choices of POs would be related among each other with some sort of "exactlyOneOf", which the bundling "router"-PO would have to respect. This seems kind of cumbersome, because for each new relationship-type all consumers of the API have to agree on how it needs to be handled.

Are there other/better options I failed to think of, or is there official guidance, or … ?

------------------------------
Oliver Büechi
Ergon Informatik AG
------------------------------