Accelerating the Path to Digital Transformation

A Q&A on Open API’s with the TM Forum, a global not-for-profit association focused on digital transformation.

I recently participated in a Q&A session on Open API’s with the TM Forum, a global not-for-profit association focused on digital transformation. The original version of this Q&A ran on the TMForum in March 2020. You can also check out the interview below.

Tell us about yourself and your job.

I’m responsible for executing on CommScope’s Professional Services vision to drive the development and execution of complex software solutions to ensure digital transformation success for service providers. Previously I was a senior manager of software development at Motorola where I developed complex IP Video software applications, OSS/BSS adaptors, and workflows from inception through their entire life-cycle. At Comcast I interfaced with PMO, external sponsors, leadership, and internal team members to scope, develop, deploy, maintain & support Web Services, software applications and tools designed to improve the efficiency of, and generate revenue for, the organization.

Why do you believe in TM Forum’s Open API program?

This is what operators are asking for. They are looking to break the proprietary chains of vendors to remove vendor lock, enable service agility and reduce operational cost. This approach simplifies the integration of back office, enables self-service with instantaneous results, eliminates service delays and accelerates the path to digital transformation.

Tell us about the example you are focusing on for this story.

CommScope executed a program with the CTO office from a large, nationwide cable operator in the AsiaPacific region to provide an abstraction for the HFC/ DOCSIS domain (Hybrid fiber-coaxial/Data Over Cable Service Interface Specification) by creating a simplified API that executes the underlying complex interactions required with DOCSIS equipment.

What TM Forum Open APIs are most valuable to your company?

Service Catalog (TMF 633) , Service Ordering (TMF 641), Service Qualification (TMF 645), Service and resource inventory (TMF 638 and TMF 639), Alarm management (TMF 642) and problem management (TMF 656) are all a valuable part of managing the service lifecycle in this project.

How have you benefited from using these APIs?

Having a robust set of APIs driven by the community that spans various aspects of service lifecycle provides our solution with a consistency, agility and portability which would have been difficult to achieve using proprietary APIs. By having well-defined interfaces and using Open API models, we achieved significant reduction in time in onboarding a new service from concept to market. By standardizing our architecture on TM Forum Open APIs we not only provide standard APIs, but also provide the ability to integrate with third-party solutions which expose Open APIs for consumption by other clients at a faster rate than before. Because of the standard definitions and clarity, we reduced the ambiguity when designing services.

How do you use those APIs?

We use these TM Forum Open API’s for: 1. Integration of a model-driven TOSCA-based designer for easy customer-driven service design and the catalog of available services using the Service Catalog (TMF 633) API. We design the elements from the HFC DOCSIS domain (eg: Cable Modem, CMTS and plant elements) and upload them to the catalog for composition. The service designer then assembles domain and end-to-end services for consumption. The HFC end-to-end service definition is then accessed using using the Service Catalog (TMF 633) API. 2. Service ordering and service qualification are performed by leveraging the Service Ordering (TMF 641) and Service Qualification (TMF 645) APIs respectively. Users select services (eg: HFC end-to-end service) from the catalog and service qualification is invoked using the Service Qualification (TMF 645) API. After this, service is ordered and executed using Service Ordering (TMF 641). 3. Service and Resource inventory API’s are used to maintain Service to Resource mappings in addition to state-of-services and resources. 4. Alarm management and problem management APIs are made available for internal and external interactions.