There is some inherent flexibility in the TMF Open API design to support different business models. One area where this flexibility is clear is whether the network exposes single services and service order processing is fully a BSS responsibility. Or the network may accept the full or partial service order and service order processing is a network responsibility. The decision would drive the usage of TMF 641 and/or 640.
Also refer to IG1164 Requirements Analysis for the Ordering and Configuration of Services and Resources: with Impacts on APIs and Information Models for further information.
Since my posts were not appearing on submit, didn't know if they were taken or not, leading to duplication. So am updating this post to remove the content which is already in another post below.
Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.
Thank you for all the inputs.
Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.
Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.
Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.
Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.
Provider of TMF-641 works with Service Inventory using TMF-638
Provider of TMF-640 doesn't need Service Inventory
Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?
HiWe recently debated this on back of actual implementation for complex Enterprise segment of Tier 1 Telco. Our conclusion is that RFS Order Mgmt is of limited use and definitely should be avoided when there is already CFS Order Mgmt
RFS Order Mgmt could potentially be used for Bulk Operations of RFS for eg Migration, and that too when RFSes have no CFS for eg Backhaul Circuits for Plan & Build, when hese circuits are being upgraded etc
Even that can be avoided by extending TMF640 slightly to allow multiple RFSes in payload, and Plan & Build Workflow Manager consumes this. Please see our thoughts on the subject compiled below
It would help if the TMF 641 / TMF 640 write-ups updated for such clarification and give clear guidance by addressing the ambiguities
Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?