TAM (Telecom Application Map) is one of the frameworks of the NGOSS (Frameworx) initiative. Its main goal is to draw the boundaries of the OSS/BSS applications. Standardized business processes and the applications that run those business processes, emerged in parallel. However, the OSS application vendors named and scoped their applications by themselves without following a standard. This led to confusion among the customers (service providers). That’s why, TAM started as an initiative that was triggered by the service providers. The service providers needed an application map where they can see the scope of their current and future OSS/BSS applications. They created a complete view of applications. TAM will help the providers to identify the missing applications within their infrastructure. It will also help to discover the overlapping functionalities. Why should I maintain 2 applications that are capable to run the same functionality? That’s where the TAM helps.
TAM is a logical view of applications. That is to say, it does not include any platform dependent, or implementation specific information. Rather, it focuses on the applications and their capabilities to perform business process requirements.
TAM can also help in creating RFI/RFP documents. Suppose you want to issue an RFP and constructing the compliancy matrix that will be submitted to the vendors. Which functionalities should be asked? You can utilize TAM for this purpose. If you will invest on an Order Management application, open TAM, and find the Customer Order Management application. Ask your vendors how they can comply with these functionalities. A real time saver…
The framework is mapped to eTOM and SID frameworks. How? via the domains. We have seen that eTOM Level 0 domains (concepts) are consistent with the SID domains (which include the ABEs). This domain concept continues in the TAM framework. TAM also includes the domains “Market/Sales, Product Management, Customer Management, Service Management, Resource Management and Supplier/Partner Management”. The concept is the same but the naming is different. TAM calls these as “Application Areas”.
Application Areas are composed of Applications. There are Customer Management Applications, Service Management Applications etc. Each area will include applications under it. For each application we can see the overview, functionality and supported business services section. Like eTOM, TAM was also designed in a hierarchical structure. Applications that are listed in Level 1 may also be decomposed into lower levels sub-applications (Level 2 and below). These sub applications are also called modules. A customer order management application should have an orchestration (workflow) module. This module can also be decomposed into order distribution and order tracking modules. (This is the L3 detail). Vendors heavily use this module concept within their applications and they apply separate licenses per module. This also gives the provider the option to select the modules it wants from the application. If another, previously bought application has a workflow module that can be reused in the order management, while procuring for an Order Management application; I may not want to buy that specific module.
TAM brings a common application dictionary that can be used by multiple types of stakeholders. It represents an application standardization which also guides the vendor products. Vendors use it for marketing purposes. TAM mappings are used by the vendors to draw the scope (footprints) of their applications. Service providers utilize it for creating RFPs, deciding on the IT transformation strategies which will lead them to increased automation and organizational efficiency.