Hi community,
I'm currently looking for some clarity regarding the interplay between TMF760 (Product Configuration Management) and TMF622 (Product Ordering Management), specifically within the Core Commerce domain of the ODA.
In my view, TMF760 acts as the bridge between the Engagement and Core Commerce domains, whereas TMF622 serves as the handoff from Core Commerce to Production.
This question came up during an ODA implementation workshop for a "Plan Change" use case (e.g., upgrading an internet service). We had a debate regarding the scope of each API and how they should interact. For the sake of clarity, I'll leave out other supporting APIs and focus on these two specific perspectives:
The Arguments:
-
Perspective A: TMF760 can handle the process independently of TMF622. Under this model, TMF760 validates the plan change rules and ultimately triggers/generates the order itself.
-
Perspective B: TMF760 is used during the "capture" phase. When a customer requests a plan change, they are shown eligible options and add-ons. TMF760 validates the commercial rules for the product and its bundles. Once the selection and characteristics are finalized, a call is made to TMF622 to formally instantiate the product order for fulfillment.
The Context: This is for a mid-sized ISP providing FTTH along with complementary services (Fixed Voice, Partner-led Streaming/IPTV, and Gamer accounts) over the same infrastructure.
I'd love to hear the community's thoughts: Is TMF760 intended to be a transient "rules engine" that feeds into TMF622, or can it stand alone as the order initiator in certain ODA implementations?
Looking forward to your insights!
#OpenDigitalArchitecture------------------------------
Carlos Lau
WIN Perú
------------------------------