Telco standards gone, dead and buried

Originally posted on 22Auc12 to IBM Developerworks (13,006 Views)

Further to my last post, it now looks like the WAC is completely dead and buried. One thing that is creating a lot of chatter at the moment though is TelcoML (Telco Markup Language) – there it a lot of discussions about it on the TeleManagement Forum (TMF) community site and while I don’t intend to get in a big discussion about TelcoML, I do want to talk about Telco standards in general. The Telco standards that seem to take hold are the ones with strong engineering background – I am thinking of networking standards  like SS7, INAP, CAMEL, SigTRAN etc, but the Telco standards focussed on the IT domain (like Parlay, ParlayX, OneAPI, ParlayREST and perhaps TelcoML) seem to struggle to get real penetration – sure standards are good – they make it easier and cheaper for Telcos to integrate and introduce new software; they make it easier for ISVs to build software that can be deployed at any telco. So, why don’t they stick? Why do we see a progression of standards that are well designed, have collaboration of  a core set of telcos around the world (I’m thinking the WAC here) yet nothing comes of it.  It we look at Parlay for example, sure CORBA is hard, so I get why it didn’t take off, but ParlayX with web services is easy – pretty much every IDE in the world can build a SOAP request from the WSDL for that web Service – why didn’t it take off?  I’ve spoken to telcos all around the world about ParlayX, but it’s rare to find one that is truly committed to the standard – sure the RFP’s say must have ParlayX, but then after they implement the software (Telecom Web Services Server in IBM’s case) they either continue to offer their previous in house developed interfaces for those network services and don’t use ParlayX or they just don’t follow through with their plans to expose the services externally: why did we bother? ParlayX stagnated for many years with little real adoption from Telcos. Along comes GSMA with OneAPI with the mantra ‘ParlayX web services are too complicated still, lets simplify them and also provide a REST based interface’.  No new services, just the same ones as ParlayX, but simplified. Yes, I responded to a lot of Requests For Proposal (RFP) asking for OneAPI support, but I have not seen one telco that has actually exposed those OneAPI interfaces to 3rd party developers as they originally intended.  So, now, OneAPI doesn;t really exist any more and we have ParlayREST as a replacement.  Will that get any more take up? I don’t think so. The TMF Frameworx seem to have more adoption, but they are the exception to the rule. I am not really sure why Telco standards efforts have such a tough time of it, but I suspect that it comes down to:

  • Lack of long term thinking within telcos – there are often too many tactical requirements to be fulfilled and the long term strategy never gets going (this is like Governments who have a four year terms not being able to get 20 year projects over the line – they’re too worried about getting the day to day things patched up and then getting re-elected)
  • Senior executives in Telcos that truly don’t appreciate the benefits of standardisation –  I am not sure if this is because executives come from a non-technical background or some other reason.

 What to do? I guess I will keep preaching about standards – it is fundamental to IBM’s strategy and operations after all – and keep up with the new ones as they come along.  Lets hope that Telcos start to understand why they should be using standards as much as possible, after all they will make their life easier and their operations cheaper.

Impact 2010 -Orange France, Decreasing the development time for Telco apps

Originally posted on 05May10 to IBM Developerworks ( 8,995 Views)

Orange in France are using WebSphere sMash to provide an easy development environment using PHP and Groovy to build Telco enabled applications that consume Orange Application Programming Interface (API) which are exposed through pre-built widgets. The custom Orange API is not compliant with either OneAPI or ParlayX and I would normally not endorse a custom API like this, but time to market forces meant that Orange had to move before the (OneAPI) standards were in place. What I would take from their experience in France is their model and use cases. All of which could be done and (now) use standards for those APIs. Interestingly, I think that Orange could also use IBM Mashup Center to support developers with even less skills that the PHP and Groovy developers they’re currently targeting.

http://orange-innovation.tv/webtv/getVideo.php?id=1040