One of my recurrent rants has been that the IMS proponents in the market (largely those Big Four network equipment vendors with mobile RAN and related components in their portfolios) needed to somehow make IMS a part of web development for mobile devices rather than an alternative to it. Happily, that’s exactly what Alcatel-Lucent said yesterday it would do. The company introduced a set of “New Conversation APIs” aimed at making IMS services visible as RESTful interfaces. These integrate into their ngConnect developer/operator community initiative.
If all Alcatel-Lucent was doing was announcing IMS calling and messaging features in API form through a developer program, I’d not be particularly excited, frankly. We’ve had all manner of developer programs and APIs offered already, some supported heavily by Alcatel-Lucent, and all of them have fallen on their face. Why is this one different? It’s in the architecture or roadmap.
Put into what I must emphasize are my terms, Alcatel-Lucent proposes to define a “virtual appliance model” for mobile devices, not based on a fixed set of interfaces like what you’d see with iOS or Android but rather based on a composable set of APIs. The New Conversation APIs are Alcatel-Lucent’s initial contribution to this model, which is most easily visualized by considering for a moment the Firefox OS announcement by Mozilla. Firefox OS is essentially a component that exposes handset features as APIs so HTML5 developers can get to them. The obvious inference is that anything that’s exposed as an API can be accessed that way, which means that operators could contribute services in API form and have them composed into apps by developers and deployed on Firefox OS handsets.
Where we have to look forward in the Alcatel-Lucent roadmap is in how this happy process moves beyond making calls or sending SMS messages. In the model Alcatel-Lucent shows in their slides, operators could build their own RESTful services and incorporate them in their virtual appliance model. That would give them both a differentiable set of mobile assets and a unique sandbox to attract developers. The services they expose could go considerably further, and deeper, than the initial New Conversation APIs expose. In theory they could expose HSS data, even admission and resource control. Obviously you’d not let developers dip promiscuously into subscriber data or drive network policies, but you could expose services that in turn utilized these lower-level IMS elements. Thus, you can make IMS a partner in future service creation without requiring all services be IMS applications. Instead they could be OTT-like web apps that just suck data from IMS or utilize IMS resources. IMS is a big part of virtually all LTE deployments, so it’s there. Why not make money from it in a realistic way?
Inevitably this is going to have to make IMS into what’s effectively a cloud application, since mobile/behavioral apps for the web are going to be cloud-hosted for sure according to operators. Alcatel-Lucent is making that happen by transitioning IMS to be cloud-ready and hypervisor-independent. As this happens it’s logical to assume that it will be easier to offer IMS components as services to more general application development, with as always the proviso that you’ll need to certify the APIs by trust level to insure that Junior doesn’t take down the global network.
The one thing Alcatel-Lucent hasn’t done and still needs to have, in my view at least, is announce an SDN strategy. Software integration with the network, absent software integration with an SDN conception of the network, is out of step with current market evolution and also with operator views of the future. Alcatel-Lucent is the only major network vendor with no SDN story, and so as a part of maturing this initiative on the virtual-mobile-appliance future, it’s essential they get one. While there’s no SDN arrow in the Alcatel-Lucent quiver, competitors have a shot at creating something that’s at least as strong a story as Alcatel-Lucent now tells.
I’ve said all along that Alcatel-Lucent had the closest thing to a real service layer than any vendor, and this brings it so close that it might actually be there. The qualifier is needed only because taking a direction isn’t the same as arriving at the destination; Alcatel-Lucent will still need to deliver on the things that are stated or can be inferred from their material. We’ve been here before, Alcatel-Lucent. I opened by saying the roadmap and architecture made this announcement different; poor articulation and execution could make it the same missed opportunity you presented with prior API-related launches. Ball’s in your court now.