Open APIs

The future’s in Open APIs, getting it right

Open application programming interfaces (Open APIs) are fueling innovation and this is not going unnoticed. The example of Apple is an extraordinary case of the business benefits opening up an interface, while Google’s growth and rise to prominence can be massively attributed to third-party development. Google was one of the first 100 companies to open up its interface, which in turn drew in talented developers who could add to the Google brand.

In 2017 alone, TM Forum went from having 31 APIs to 52 as a part of two releases, R17 in August and R17.5 in November. This marked our transition to a fully-fledged API development system, stimulating industrialization and widespread deployment across all enterprises for fast digital transformation.

I spoke to Jonathan Goldberg, Principal Integration Architect at Amdocs who took on a leading role in the review process of a rather large number of these Open APIs that were part of R17 and R17.5. We discussed his involvement in the releases, and the importance of the collaborative efforts to develop standardized APIs.

Standardization

Consistency in API design means standardizing the makeup of all APIs and the resources they provide, which is what TM Forum is enabling through our API work. A consistent voice, brand and experience makes it easier to adopt, maintain and consume them. Ease of use means a better experience for the developer, while time and money is saved and the time to market for new products is much faster. What’s more, any design differences between vendor and client can lead to confusion and overhead during development. Such inconsistencies persevere and multiply across the API life cycle.

“Why do we need API standards?” Goldberg asks rhetorically. “You’ll get different answers from different people. In our view, standardized APIs enable rapid digital product and service innovation and improved customer experience across increasingly complex digital partner ecosystems. In addition, standardized APIs fit in with our [Amdocs’] API-first design and microservices architecture approach to enable greater agility for our service provider customers.

“We welcome standardization as we now talk a language we all understand. We can work with our customers more easily. In a sense, everybody benefits and we need to realize standards are good.”

Compliance

Amdocs’ key reasons for getting involved with developing the Forum’s Open API’s were two-fold, self-interest and for the benefit of the wider community.

“For the APIs that Amdocs are releasing, we have an interest in making sure they comply with the TM Forum APIs. Our involvement means that the API’s allow Amdocs to expose our business capabilities in an open and flexible way.

“If we see that there are APIs that could be improved by adding functionality, then we see it as an opportunity for self-interest, and also for the interests of the community. We want to also promote inclusion, and ensure the APIs are available to everybody.”

Amdocs’ deep understanding and alignment with the Forum’s Open APIs means that Amdocs’ own APIs can interact and integrate with what other talented developers create from the Forum’s APIs. This nurtures a value fabric which can quickly turn around new and valuable solutions.

Quality in the quantity

Of course, it’s not just about the quantity of open APIs we were (and still are) getting out there but the quality too. So, suffice it to say, there was a lot of reviewing needed.

The reviewing process ensures that service providers are getting what they need from these APIs in terms of consistency, guidance and usability, so this process is vital to the long-term success of any API project.

“The API program [at the Forum]was taking off very rapidly, and we saw this [getting involved]as a great opportunity,” stated Goldberg.

“I didn’t have just one specific hat, or work only on one API. My prime intention was to ensure the APIs were usable and of good quality.”

The APIs he reviewed:

17.0:  Prepay Balance, User Roles and Permissions, Payment Methods, Resource Inventory, Product Catalog, Document Management

17.5: Geographic Location, Geographic Address, Geographic Site, Product Ordering, Payment Management, Customer Account, Resource Pool, Communication, Usage Consumption (scroll through Open API table for details of the latter two).

His reviewing objectives:

  • Consistency in modelling
  • Good documentation
  • Good examples/use cases
  • Met business requirements
  • Clear guidance on attributes

Next steps

Goldberg’s involvement with TM Forum’s API projects don’t stop here:

“I plan to continue working on the mapping between the Open API models and the SID (Information Framework). The mapping working party has published the first set of mapping documents as part of R17.5, including the mapping that I did for Product Inventory.”

Goldberg will also be reviewing R18 API specifications as they are released for review, and will continue my involvement in reviewing the SID changes.

“And of course, I’ll be working in cooperation with my design colleagues in Amdocs as we continue our journey to provide a quality implementation of the TM Forum Open APIs.”

Get involved in the Open API discussion on TM Forum’s Community site.



Advertisement:
Share.

About The Author

VP, APIs & Ecosystems

Joann’s career spans over 20 years in technology, ranging from consumer electronics, telecommunications mobile switching to OSS/BSS and more recently to industry collaboration. Joann is currently the program lead for TM Forum’s Open API & Ecosystems initiative, chair of the API Steering Committee and lead for the Open Hack program. Joann has significant experience leading complex large scale transformation programs for a number of organizations.

Leave A Reply

Back to top