07 Oct TMF and MEF tie-up avoids nasty API fork | Light Reading
Too many standards organizations can fork the code.
About a year ago, George Glass discovered the TM Forum (TMF), his own employer, and the Metro Ethernet Forum (MEF), another telecom standards group, were at work on the same application programming interfaces (APIs).
“They had developed their instances of those APIs for metro Ethernet and SD-WAN,” says Glass, the TMF’s vice president of architecture and APIs.
“There was a danger that the APIs based on the TMF baseline were going to diverge.”
Members of both the TMF and the MEF who alerted Glass to the danger were alarmed.
Some 69 companies, including most of the world’s major service providers and a number of big vendors, have now signed up to the TMF’s Open API manifesto.
The hope is the industry will coalesce around a single set of vendor-agnostic tools that eliminate time, complexity and cost when operators want to spin up a new service. A fork in the API road would upset the manifesto.
But the risk has receded after the TMF and the MEF came together to align their activities.
For the TMF, the ten-month fix essentially involved making changes to its APIs so they can be more easily used by other standards bodies.
It did that, says Glass, by introducing what he calls a “domain context specialization” so an API could be tweaked for an organization or product while its “openness” is maintained.
The upshot is that the MEF now has inter-provider APIs, which conform with the TMF’s Open API standards, for carrier Ethernet, SD-WAN and so-called SASE (secure access service edge) products.
James Crawshaw, a principal analyst with Omdia, says the TMF has based its Open APIs on Swagger, a popular open source project for describing and documenting APIs.
The problem arose, he says, because those APIs did not meet all of the MEF’s needs.
“They deconstructed them and rebuilt them to make them more useful,” Crawshaw explains.
The fork-avoiding fix means the MEF now makes suggestions to the TMF instead.
“That way when TMF makes future changes to its generic APIs, the MEF will be able to take advantage of these without needing to rewrite the MEF APIs,” says Crawshaw.
Does any of this software pruning really matter in the wider world?
Pascal Menezes, the MEF’s chief technology officer, says ridding the industry of custom APIs will lead to greater service automation.
“What we have done together is create this idea of a federated model where automation between the carriers can be done very efficiently and you can turn up cloud-like services in seconds,” he says.
Importantly, it is not just the standards bodies that are making a noise.
Laurent Leboucher, a technical vice president at France’s Orange, describes the alignment between the TMF and the MEF as “a win-win for us and vendors like” in the TMF’s official statement.
Lester Thomas, Vodafone’s chief systems architect, is also quoted as saying the collaboration will help to “speed our procurement, transform our IT and roll out services faster and more cost-effectively.”
On the vendor side, Ericsson, NEC and Salesforce have all given their blessing to the tie-up.
Juicy metrics are attached to the use of a common set of open APIs, too.
“If you take one of our open APIs and implement that, you are probably saving four to six months’ development time for a technical software engineering team,” says Glass.
“One of our members has quoted in excess of $100,000 per API in savings by using the TMF APIs.”
Because they’re worth it?
Not everyone is convinced the TMF initiative is of huge value, though.
In essence, says Omdia’s Crawshaw, it should define how telco IT systems communicate with one another at a high level.
“For example, what information should an ordering system exchange with a provisioning system?”
The doubts exist because the TMF APIs are “very generic,” he says. “Some question if they are useful at all.”
Nevertheless, a successful collaboration with the MEF could persuade other standards bodies to adopt TMF APIs, and the Linux Foundation is already using them for its ONAP project, an attempt to build an open platform for network management and orchestration.
“This won’t turn telcos into hyperscalers or platform businesses overnight but is a helpful step in making their IT systems more standardized and repeatable, as opposed to the traditional handcrafted and insular approach,” says Crawshaw.
Iain Morris, International Editor, Light Reading