TM Forum Community

 View Only

  • 1.  Open API Packaging and TAM Mapping Considerations

    Posted Apr 08, 2026 04:29

    We are exposing OpenAPI-compliant interfaces through the Enterprise Service Bus (ESB). For logical organization and governance, we plan to group these Open APIs into packages using the following naming convention:

    <<TM Forum Domain>_<TAM Level 2>>

    Current Challenge

    The primary challenge we are facing is the lack of clear and authoritative mapping between TM Forum Open APIs and either TAM Level 1 or TAM Level 2 process areas.

    Specifically:

    • There is no official or published reference that maps TM Forum Open APIs directly to TAM process levels.
    • Unlike the well-documented eTOM-to-TAM mappings, we have not found equivalent guidance from TM Forum that aligns Open APIs with TAM process hierarchies.

    Example: TMF 621 – Trouble Ticket Management API

    To illustrate the issue, consider the TMF 621 – Trouble Ticket Management API:

    • TM Forum Domain: Common
    • Potential TAM Level 2 mappings (based on interpretation):
      • Service Problem Management
      • Customer Problem Management

    This API can reasonably be associated with both TAM Level 2 areas, depending on the business context:

    • If the trouble ticket relates to internal network or service issues, it aligns with Service Problem Management.
    • If the trouble ticket originates from or is managed in relation to customer interactions, it aligns with Customer Problem Management.

    However, this classification is deductive and subjective, as we were unable to locate any TM Forum documentation that explicitly confirms or standardizes this mapping for Open APIs.

    Request for Guidance

    We are seeking advice on the following:

    1. Recommended practices for associating Open APIs with TAM Level 1 or Level 2 processes.
    2. Whether TM Forum provides (or plans to provide) official guidance or reference models for Open API-to-TAM alignment.
    3. How other organizations typically approach this problem-especially for APIs that legitimately span multiple TAM process areas.

    #OpenDigitalArchitecture

    ------------------------------
    Mohamed Saleem Hyder Ali
    Saudi Telecom Company
    ------------------------------


  • 2.  RE: Open API Packaging and TAM Mapping Considerations

    Posted Apr 08, 2026 07:47
    Edited by Rodrigo Elhaibe Apr 08, 2026 07:48

    In my opinion, Open APIs don't have a direct alignment with TAM; rather, they are an exposure layer based primarily on SIDs and indirectly and conceptually aligned with eTOM. In any case, TAM would indicate who, in terms of platform, should implement a given interface or functionality, but with the evolution to ODA, i believe, TAM is relegated and in the process of being deprecated.
    Open APIs are primarily based on SIDs. There's a document from a few years ago outlining the rationale for creating the Open API model; I don't remember the title now, but its origin is based on an SID-oriented grouping.
    If what you want is to group components in an ESB, exposing Open API interfaces, I suggest using ODA as a reference. Or, failing that, levels 3 or 4 of eTOM, which is how I implemented it years ago when ODA didn't exist.
    Another characteristic of OPEN APIs is that they are interfaces that do not necessarily have to be used to front a single component, so in your example scenario you could have more than one incident component exposed under the same OPEN API as an interface, obviously with different tags and locations.



    ------------------------------
    Rodrigo Elhaibe
    Texas Department of Information Resources
    ------------------------------



  • 3.  RE: Open API Packaging and TAM Mapping Considerations

    Posted Apr 12, 2026 03:37

    Thank you



    ------------------------------
    Mohamed Saleem Hyder Ali
    Saudi Telecom Company
    ------------------------------

    Original Message


  • 4.  RE: Open API Packaging and TAM Mapping Considerations

    Posted Apr 13, 2026 02:55

    HI Mohamed,

    I hear this question come up quite regularly.

    Rodrigo's answer is both useful and correct to my knowledge.

    FWIW, whilst TAM is in the process of being deprecated, I still find it's widely recognised by many in the industry, especially within the medium / smaller operators and vendors. I also find that some TM Forum's concepts can be a little complicated for these groups and therefore require simplification. We often refer to the simplified TAM described here (https://passionateaboutoss.com/what-if-most-oss-bss-are-overkill-planning-a-simpler-version), which also provides a directional mapping to the Open APIs. It's probably not going to be fit-for-purpose for you, but thought I'd share just in case.



    ------------------------------
    Ryan Jeffery
    PassionateAboutOSS.com
    ------------------------------



Related Content