Open APIs

Expand all | Collapse all

Adapting TMF655 Change management API

  • 1.  Adapting TMF655 Change management API

    TM Forum Member
    Posted 28 days ago
    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 27 days ago
    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 24 days ago
     @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

    TM Forum Member
    Posted 24 days ago
    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 24 days ago
    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 22 days ago
    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

    TM Forum Member
    Posted 22 days ago
    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 22 days ago
    Edited by Girish Gajria 22 days ago
    Duplicate


  • 9.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted 22 days ago
    Edited by Girish Gajria 22 days ago
    Duplicate


  • 10.  RE: Adapting TMF655 Change management API

    TM Forum Member
    Posted 18 days ago
    Thank you @Girish Gajria & @Daniel Lauxtermann​. It helps.

    Best Regards,

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