Hi Jiri,
This is a very interesting question because both Variant A and Variant B actually highlight a deeper architectural ambiguity: which domain is the authoritative source of qualification truth?
From an end-to-end flow perspective:
Product domain decomposes the order (Product → CFS).
Service catalog defines which CFS are technically qualifiable.
SQM (TMF645) evaluates feasibility.
SOM (TMF641) expresses intent and orchestrates action.
The confusion comes from the fact that each of these domains holds only a partial view of the truth. Because of that, Variant A and Variant B are not really opposite choices - they are symptoms of the same structural question:
Should qualification truth be determined before entering the service domain,
or inside the service domain?
If qualification authority lies with:
Option 1 – Service domain
Variant A aligns naturally:
Send the full CFS set and let the service domain decide which ones require meaningful qualification.
Option 2 – Product domain / Catalog
Variant B becomes cleaner:
The catalog marks qualifiable CFS and only that subset enters TMF645, while TMF641 still carries the full CFS set.
In many implementations, teams gradually centralize more of the detailed qualification rules within the service domain, simply because those rules live closer to resources, topology and feasibility constraints.
This often makes Variant A easier to evolve as qualification logic becomes more complex.
Just sharing an architectural perspective - would be very interested to hear how others have drawn this boundary in their environments.
Regrads,
Furooshin
------------------------------
Furooshin Firoz
TO BE VERIFIED
------------------------------
Original Message:
Sent: Dec 08, 2025 10:13
From: Jiri Smekal
Subject: TMF645 Service Qualification CFS set vs. TMF641 Service Order
Hi all,
from a product-domain client (POCV/PODOM) point of view, TMF645 Check Service Qualification and TMF641 Service Order look quite similar: in both cases the client typically decomposes Product → CFS, and in the service domain (SQM, SOM) this continues as CFS → RFS.
I'm trying to decide what principle to follow when building the set of CFS services that should be included in the TMF645 Check request:
- Variant A – full CFS set
Send all CFS corresponding to the product order to TMF645, and let the service domain decide (based on Service Catalog rules, etc.) which services require real qualification (e.g. access) and which are trivially always available (e.g. SLA / delivery options; or perhaps deeper check could be implemented later …). - Variant B – only "qualifiable" CFS
Mark in the Service Catalog which services are subject to qualification (e.g. via specific ServiceCatalog entity, or a simple flag), and send to TMF645 only that subset (typically access / connectivity), while the final TMF641 Service Order still contains the full CFS set.
My understanding currently leans towards Variant A (full CFS set to TMF645, "smart" handling in the service domain, with possible evolution), but I'm not sure if this matches TMF expectations.
Questions:
- Is Variant A in line with how TMF645 is intended to be used?
- Or is Variant B closer to recommended practice?
- Or eventually completely different approach?
Thanks in advance for any opinions or experience.
------------------------------
Jiri Smekal
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------