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
------------------------------
Original Message:
Sent: Apr 08, 2026 03:24
From: Mohamed Saleem Hyder Ali
Subject: Open API Packaging and TAM Mapping Considerations
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:
- Recommended practices for associating Open APIs with TAM Level 1 or Level 2 processes.
- Whether TM Forum provides (or plans to provide) official guidance or reference models for Open API-to-TAM alignment.
- 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
------------------------------