Are standard APIs the way to simplify automation?
By Yuval Stein, AVP Technologies, TEOCO
For many long years, Communication Service Providers (CSPs) have been trying to reduce their integration costs by using standard APIs. This “integration drive” is currently accelerating due to the additional complexity and plethora of new technologies and services being implemented in the network, requiring operations to become more and more automated to maintain productivity and efficiency. OSS systems, once isolated and managed manually, now need to be integrated within a tightly coupled ecosystem. It is no longer sufficient – or efficient – to have ad-hoc or bespoke APIs for each integration instance.
What is required are new interfaces that are easier to deploy and, most importantly, are reusable. This need for new interfaces drives the standards organizations, including TM Forum, ETSI, and MEF, alongside the more technology-specific, including 3GPP, IETF, BBF, and others, to propose more and more new REST APIs.
TEOCO recently implemented a set of TM Forum APIs as part of our Helix suite of products. We have primarily focused on assurance APIs but we have primarily focused on assurance and continued with orchestration across-system APIs that provide the tight integration needed between orchestration & inventory systems and address the broader assurance ecosystem.
Key ‘lessons learned’ from TEOCO’s recent TM Forum API implementations.
TM Forum’s OSS APIs have been designed at a functional level to be reusable. Unlike some other APIs, which unnecessarily assume the use of Kubernetes or Dockers, TM Forum APIs are functionally and technology agnostic. By this I mean they do not depend upon any underlying platform. We see this as a big advantage. By not tying APIs to a specific technology, however common it may be, it simplifies not only the initial integration, but also the ongoing maintenance and upgrades of any OSS ecosystem.
When implementing an integration project, it’s essential to have a strong understanding of the environment. REST supports an efficient development and deployment lifecycle. It is the current leading technology for APIs due to its robust and mature infrastructure and long list of available tools.
There are several key concepts that should be considered when thinking which Standard API – which are implemented within the TM Forum APIs:
- Each API should include a set of operations for the consumer side.
- The API on the provider side should support events and notifications for registered subscribers.
- The data model should accurately describe each aspect of the API but be separate from the API payload data model. (This is because the data model of the API payload is a Meta model, which means that it describes the managed entities at a fairly high level, which needs to be further specified for a specific technology. This approach is aligned with TM Forum’s long years Information model, also known as SID.)
TEOCO has focused on using, where possible, TM Forum APIs due to three key benefits:
- The separation between ‘operations’ and ‘events’ makes it possible for the API to support non-functional requirements. Network failure events, especially within service assurance, will create vast quantities of data. Losing any alarm events can hinder or cause the loss of key recovery information.
- The separation of the payload Meta model from the API data model allows the same operations and notifications to be used for multiple types of payloads, e.g. utilization between different technologies.
- Support for customer-level customizations. TM Forum APIs use a ‘polymorphism pattern.’ This makes it possible to extend the API payload, which many OSS systems require, and it allows API extensions to be easily identified and managed.
Our recent implementation experience leads us to make the following recommendations, especially when considering the use of Standard APIs for future integration projects:
- The first recommendation is to increase the potential for re-use. Utilizing the Meta-models is a good approach to reusability, but the specific technology level which is standardized by some of the industry organizations (i.e. TM Forum APIs) needs to be more reusable as well, within the same API!.The API model is a Meta-model that requires specific technology-level modeling. It would be helpful if this could be further standardized. If there is a way to support the original data models of technology standards organizations, or to build a set of recommended technology specifications, this may increase the level of API re-use beyond what’s possible today.
- The second recommendation is to continue to build support for larger payloads. REST technology is natively better at control layer functionality and works best with small to medium-size data payloads. For larger payloads, additional technologies may help, especially if they require to be closely integrated.
- Finally, it would be good to see further progress on recovery mechanisms. For most types of data, losing synchronization between the two API parties would require a path for resolution and recovery. Having the built-in mechanisms to manage this would be helpful.
This article outlines our initial conclusions. As we gain experience and learn more from our current and future Helix deployments, additional recommendations may follow. To learn more about Helix and TEOCO’s full line of service assurance solutions, please visit our website or contact us for more information.