Short Answer:
The examples provided by TMF are just starting points to help you understand the basic interactions between ODA components.
You have full flexibility in deciding how and when to use these components and their APIs.
Long Answer:
Understanding ODA Components:
It seems like you're trying to understand two key aspects:
- Orchestrating ODA components effectively (this is the secret sauce for a great composable architecture, IMHO)
- Interdependencies between ODA components β Understanding how each component consumes and interacts with others is essential for "internal" orchestration (done by the ODA component itself, typically those dependent APIs that are listed in each ODA specification).
Since your post contains multiple detailed/short questions, I'll just address some key ones:
Question:
"My main question is, which ODA component is responsible for ensuring that Product Offering Qualification (POQ) and Service Qualification (SQ) match? Is it POCV?"
Answer:
- TMFC027/POQ and TMFC009/SQ compute qualification rules and return a qualification status.
- TMFC003 is responsible for orchestrating these service APIs
To use a metaphor:
- TMFC027/POQ and TMFC009/SQ are like the violinist and pianist playing their parts.
- TMFC003 (or any orchestration engine) is the conductor, ensuring they perform in harmony.
Question:
"Is this check missing in this example below?"
Answer:
No, it's not missing. TMFS003 documentation and sequence diagrams indicate that it "follows TMFS001 and TMFS002." This suggests that the author may have assumed TMFC027/POQ was handled in TMFS002.
However, if needed, you can configure TMFC003 to also orchestrate TMFC027/POQ. It depends on your specific architecture and requirements.
Question:
"Our purpose is to display only commercially and technically valid offerings. I assume it is ultimately POCV's responsibility to revalidate that in these outputs CFS->PS->PO matches?"
Answer:
TMFC003 should not be involved.
A useful reference for this is TMFS002, which provides guidance to show only valid offerings.
but I understand BSS can be very "composed" (not composable) and requires the product offering to be in the cart/order before further computations (qualification, configuration, pricing, recommendation....), in which case, you do have to use TMFC003.
π‘ In TMFS002, the orchestration is handled by a BFF (Backend for Frontend) rather than TMFC003. This is just one possible approach. You could also use a data orchestration engine, Digital Experience Orchestration engine, or other modern alternatives.
Question:
"What happens when the PC receives a task to create a product configuration, but POQ has not been performed beforehand? Does it generate an error back, or does it perform the POQ itself if it hasn't been done yet?"
Answer:
This behavior depends entirely on your TMFC027 implementation.
In our case:
- Our TMFC027/Pcfg does not trigger TMFC027/POQ or TMFC009/SQ for the root product (the one selected by the customer from the offer list).
- This is because the root product was already qualified during the previous user experience phase: "show offer list" (I call this "prepick eligibility").
However:
- If the computedProductConfiguration includes CFSS or bundle components, then TMFC027/Pcfg may need to orchestrate TMFC027/POQ or TMFC009/SQ as part of the product configuration process when customers interact with the PcfgUI.
- For instance, our Altibox Extra bundle includes an optional Viasat Total channel package. TMFC027/Pcfg may need to orchestrate TMFC027/POQ to check if customer is eligible to buy Viasat Total. This can be done in prepick (before customer select Viasat Total, what you call "beforehand") or postpick mode (= after customer selected Viasat Total). We do prepick because we believe it offers a vastly superior user experience.
My 2 cents,
------------------------------
Kind regards,
Matthieu Hattab
Lyse Tele AS
------------------------------