Navigating the Complexities of TMF APIs in Modern Telecom and E-commerce

Overview of TMF APIs

The TMForum OpenAPIs are a set of RESTful APIs designed to support the telecommunications industry. The OpenAPIs can be grouped into categories such as Product & Service Management, Customer Management, Service Assurance, and Resource Management.

The current v5 API definitions use Open API v3. And the shared data model is based on TMF SID and published as a set of JSON schema definitions. The shared model is implemented across multiple TMF Open API specifications so any specific business model e.g. Customer domain requires model components (schema definitions) from other related Open API specs in order to maintain SID data model compliance.

While these APIs and models promote interoperability across service providers in a Telecom services domain, there are some challenges to be faced when working with business services in e-commerce like domains that have marketplaces for products that represent endpoint OTT services. These OTT services can use any of the underlying connectivity services provided by CSPs.

The API-first approach in these domains is different from TMF API-first built products and services in the BSS/OSS domain.

Navigating API and Schema Integration Challenges in Business Services

Marketplaces for business applications and/or business applications themselves have sets of API and related JSON schema definitions that rarely map one-to-one with TMF JSON schema definition sets used by TMF APIs.

The need for such mapping could arise when offering additional services to customers with existing telco services and subscriptions. This allows customer to also subscribe to these OTT services which can be delivered and billed with existing Telco services.

Given most of the interactions are B2B there is some challenge in building this adaptation for use cases related to ordering and fulfilling such services.

Evolving API Architecture for Interoperability and Consumer Focus

While there is a need for interoperability between service providers there is also a need for simplicity and interoperability between B2B2X providers and consumers. And API design ideally needs to be API consumer focussed. Consumer designs depend on the context. There are consumers of Telco services APIs and consumers of e-commerce business services APIs.

When using TMF APIs, REST resources are used to represent Collections, Tasks, and Individual Resources represented by REST APIs and related JSON schemas. And these resources are identified via an identity of an “Addressable” resource; they can be extended (using polymorphism) via an “Extensible” resource. The “Types” of resources have a type related meta-data. These can either be extended or modified to add attributes to the resource that the “Type” represents by way of characteristics.

When using e-commerce APIs however, in many cases the APIs are nested to maintain logical relationships between resources. This is for grouping related information in logical end points by association. This helps align with the bounded context of the solution. For example /users/:userId/orders/:orderId or /categories/:categoryId/products/:productId

Bridging the Gap: Integrating Diverse Models and Languages

This requires additional effort to integrate, such as the development of anti-corruption layers or translation layers to bridge the gap between different models and languages.

And this makes it challenging to implement all the mandatory aspects of the TMF APIs as described in the API specification. Especially when integrating with Non-TMF Compliant SaaS APIs which leads to complexity with data mapping and extensions of APIs.

Therefore, the scope of adoption and the extent of adoption of the TMF APIs have to carefully considerered in any architecture design for such scenarios.