Hi,
this thread is a little old but while I am at it (and for posteriority :-)), I am going to briefly describe my view:
1. I agree that this probably is due to the incomplete alignment between the Frameworx initiatives.
2. On the other hand, I think there is an aspect that points towards a natural distinction between process/application vs. API scope. This also is an issue in almost every project (which are quite a few) we are working on:
- Customer Order Management (as an eTOM-process, often also as an application (regarding TAM)) deals with complete customer orders.
- This process typically also includes (validating and creating) the customer account and billing accounts, customer locations, the formal contract/agreements and then handing over the order to fulfillment.
- This involves managing a couple of business entities which are not in scope of Product Order Management (namely providing the ordered product) on which the TMF 622 API focusses.
Regards,
Andreas
------------------------------
Andreas Schlueter
NTT DATA CORPORATION
------------------------------
Original Message:
Sent: Sep 10, 2018 12:33
From: Mikhail Alekseyev
Subject: TMF622 vs Customer Order Management
Hi All,
I have a question about naming inconsistency between TMF622 OpenAPI (Product Ordering Management) and eTOM&SID&TAM.
According to specs:
1. eTOM: "Order Handling" core process in "Customer" domain.
2. SID: "Customer Order ABE" in "Customer" domain.
3. TAM: "Customer Order Management" application in "Customer" domain.
4. OpenAPI: "ProductOrder" is used as a resource (model, naming etc).
So the questions is:
What's the reason to have such naming inconsistency (customer vs product) between frameworks? In other words what's the reason to have different naming for data and integration models? Is there any benefit to have this inconsistency in solutions? is it planned to align naming for frameworks?
------------------------------
Mikhail Alekseyev
------------------------------