Open APIs

 View Only
  • 1.  Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 25, 2020 01:50
    Hi,

    We have a requirement to expose change management API for planned network maintenance.  As per eTOM, change management process affects entities related to resources, services, products and partners. The change management API's resource model supports all these entities. I am thinking of creating separate change management API for each of these entities. Entity specific resource model simplifies the design, maintainability & monetisation of API - entity specific API to be touched only when there is change in the particular entity. Also, reduces the chattiness of the API. Would like to know forum's thoughts on it  and the practical approach to implement the API.

    @Adrienne Walcott, @Marcello Borzi
    Could you please help.

    Thank you.

    Best regards,​​​

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------


  • 2.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 25, 2020 07:15
    Hi Kalpana

    The Open API has a pattern similar to what you are suggesting in the catalog and inventory domains, where we have service, product, resource all modeled as specific types, as well as an entity catalog that generalizes entity specification (and we are working on entity inventory.

    BUT you will notice that we don't go any further, we don't define specific models for specific products or services (e.g. broadband, TV, etc.). So there is a fine line to be drawn between generic and specific modeling. I'm afraid that I don't know how this would apply to the change management discipline, perhaps friends like @Kamal Maghsoudlou, @Vance Shipley, and @Pierre Gauthier might have more insights.

    Hope it helps

    ------------------------------
    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.
    ------------------------------



  • 3.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 28, 2020 07:02
     @Kamal Maghsoudlou@Vance Shipley, @Pierre Gauthier , @Adrienne Walcott@Marcello Borzi
    Could you please help.


    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------



  • 4.  RE: Adapting TMF655 Change management API

    Posted Sep 29, 2020 00:37
    Hi Kalpana!

    I did not understand you intention completely. Do you want to create four separate APIs (one for product, one for resource, ...)?

    If so do you have different consumers for all of these APIs? 

    Regards
    Daniel

    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------



  • 5.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 29, 2020 01:19
    Hi Daniel, 

    Thanks for the response. Yes, I feel creating separate API for each areas like resources, services, products etc., is advantageous. Consumers of resource based & service based change management API could be partners getting affected by the service/resource. Consumers of product based change management API would be sales and marketing team, product managers etc.

    Thanks,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------



  • 6.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 30, 2020 15:19
    Hello Kalpana,

    Based on my limited knowledge, I can see this going down two ways.

    Approach 1: Separate APIs, depending on the backend application
    From your example, if you use a different change management application for a products vs service requests, you may be able to create separate change management APIs for each, with their own individual mapping information

    Approach 2: Same APIs, with a canonical Microservice model
    Create a single API for consumer exposure. This API invokes an internal Microservices layer in the canonical TMF format. Based on the request type and/or entity, the MS transforms the canonical model into the appropriate backend format

    Hope that helps.

    Regards,


    ------------------------------
    Girish Gajria
    Torry Harris Integration Solutions
    ------------------------------



  • 7.  RE: Adapting TMF655 Change management API

    Posted Oct 01, 2020 00:37
    Hi Kalpana!

    Sure you can do this. I think you have to decide between beeing more generic and 'data driven' or beeing more specific and perhaps more 'consumer friendly'. It strongly depends on the context you are working in and your customers/consumers. In my opinion nether is wrong, it just depends. 

    I mean the api allows you to specify the Impact-/Target Entity as you need. You could use it to refer to a resource, service or even a product. 

    My perspective about this API is that it is mainly desigend for a Resource Change in the Network. So a typical use case I would see is like:

    1. A change for an network element is created and referred as TargetEntityRef
    2. During change planning all impacted products or services are identified and referred as ImpactEntityRef
    3. Based on this information the change will be classified (for example can it be executed or must I inform customer about an outtage of the network with a list of the products which are impacted)
    4. The information can then be used from Customer Care to communicate to the customers

    My feeling is when you talk about make it specific, it's more about the format of the notification. So that (a) a party see only what is necessary and (b) is not overwhelmed by the information. 

    In this case you could think about adding specific notifications for these stakeholders or bring in a layer which expose a minimal set of the api, but use the same api in the background. But maybe this API must not support all operations.

    Questions I would aks my self are:

    1. Who is allowed to see which information
    2. Which capabilities do my consumers have (maybe they work with a legacy system)
    3. What are the costs of operation in the future if specific APIs have to be maintained 
    4. Who want's to have an information and for what reason

    Regards
    Daniel



    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------



  • 8.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 30, 2020 15:19
    Edited by Girish Gajria Oct 01, 2020 01:52
    Duplicate


  • 9.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Sep 30, 2020 15:19
    Edited by Girish Gajria Oct 01, 2020 01:52
    Duplicate


  • 10.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted Oct 05, 2020 02:16
    Thank you @Girish Gajria & @Daniel Lauxtermann​. It helps.

    Best Regards,

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------