Open APIs

 View Only
  • 1.  Migrating to TMF620 - Catalog Management

    Posted Nov 23, 2020 12:53
    Good day Community Members!

    We are trying to adopt TMF620 for our catalog management system. We already have a well established catalog system in place with APIs being exposed to other systems. With our Initial analysis of TMF specs, found there are differences in current underlying system architecture (obviously there should be!) with TMF's one. Need few suggestions with respect to migration.

    1. Do we need to modify the existing data model of the current system?
    2. We have some business process which can't be eliminated whereas that is not a part of TMF's specs. Should we need to modify the business process to follow TMF's framework?
    3. If we build a API proxy layer between TMF API spec and Inhouse APIs (Current system), will it make our API TMF's standard?
    4. How about the certification? I have read through the process and conformance docs, but will the evaluation involve the underlying system's architecture or just API?
    5. Can we extend on top of the TMF's spec or not use some portion of it in order to adapt with our business process? Will it affect the certification?

    ------------------------------
    Eswar Babu
    Verizon Communications
    ------------------------------


  • 2.  RE: Migrating to TMF620 - Catalog Management

    TM Forum Member
    Posted Dec 01, 2020 13:16
    Hi Eswar

    Apologies for the delay in answering. I've copied your questions and provided an answer inside. Hope it helps

    Disclaimer: I am answering strictly from a TM Forum perspective, without reference to a particular implementation of the TMF620 API by any vendor or in-house.

    1. Do we need to modify the existing data model of the current system? <Jonathan> No need to change, provided that you can map your model predictably, and in both directions, to the TMF model

    2. We have some business process which can't be eliminated whereas that is not a part of TMF's specs. Should we need to modify the business process to follow TMF's framework? <Jonathan> There is currently no direct relationship (to best of my knowledge) between the Open API and the Process Framework (eTOM). So if we are talking strictly about Open API conformance then this does not matter.

    3. If we build a API proxy layer between TMF API spec and Inhouse APIs (Current system), will it make our API TMF's standard? <Jonathan> From the conformance perspective, your API proxy layer is the API provider – the conformance test doesn't "care" against what it works.

    4. How about the certification? I have read through the process and conformance docs, but will the evaluation involve the underlying system's architecture or just API? <Jonathan> Conformance works against the API definition and implementation, not against internal details. It could be written in COBOL or assembly language.

    5. Can we extend on top of the TMF's spec or not use some portion of it in order to adapt with our business process? Will it affect the certification? <Jonathan> You can extend as per the design guidelines (TMF630).

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------