The thing that has made over-the-top players successful in the service layer is that they’ve dodged inertia. Because they don’t worry about standards beyond blowing a casual kiss here and there, they can expose features via APIs very quickly. If you wait for industry consensus on APIs, you’re putting yourself at the tail end of a multi-year process and then saying you’re running at market speed. I’d like to see Alcatel-Lucent open up more regarding how it will create features in Application Enablement and how quickly it can expose them using RESTful APIs.

 With Phone 7, operators have only limited ability to create their own services or their own “brand” with the handsets they have to subsidize.  Microsoft justifies this with the notion that the user experience is seamless everywhere, but that’s not what operators want—they want an experience that differentiates them.  Even Apple was smart enough to realize that they couldn’t tell operators that they were “partnering” without providing some sort of unique service-to-phone tie.  Alcatel-Lucent recognized that a seamless experience had to start with a mobile operator ecosystem largely because without it, there would be great resistance to any kind of roaming data plan or any cross-operator feature set. So it established its Open API program as a federation.

Federation is what Microsoft needs to be looking at. The operators want to build a global ecosystem of national or even regional players.  Microsoft had a chance to bring something tangible to the table in that space, something broader and more powerful than even Alcatel-Lucent proposed.  Instead it has extended its past CSF strategies into its present mobile offering, and compromised it fatally.

It’s clear that Alcatel-Lucent is still having a bit of an identity crisis—several, in fact. It’s still apologizing for the aftermath of the merger, which looks like it’s finally finished, and not just in name. It is also having a bit of a confidence crisis, even though its articulation is strong and its strategic credibility numbers lead the network equipment vendor space by a pretty decent margin. Alcatel-Lucent has been battered a bit by Wall Street and by the internecine struggles of the past; it kind of needs a hug.

In a tangible sense, the big news out of the event was that Alcatel-Lucent has a much broader capability set in Open API than was first apparent. Yes, the program is linked to applications and developers and the smartphone universe, but it’s really more than that. Open API is a federation engine that absorbs multiple APIs, orchestrates unions and exposes the results. It could be used to federate content delivery networks (CDNs) — which is something Alcatel-Lucent says it’s working on, though it didn’t say if the Open API was part of the work), cloud computing, and even multiprovider service provisioning of the type that the TM Forum/IPsphere forum (IPSF) has been involved in. How far the company take this capability probably depends on operator traction, but watch the space for some action later this year as a possible signal.

It’s also clear that Alcatel-Lucent is betting heavily on LTE and still doubling down on IMS, which is logical given its LTE focus. I still think there are a few too many IMS references; yes, we know ALU has it and that operators will leverage it if they deploy it. We need to know what else the company will have in the way of enablers for its Open API to expose.

The Alcatel-Lucent challenge, in fact, is to try to rise above legacy, including IMS, without turning its back on it. Part of the secret of Alcatel-Lucent’s high strategic credibility is its broad engagement. The company can’t sustain its whole portfolio forever and needs to exploit the parts of it that continue to involve it in the broad strategic sweep of the service provider space. At the same time, it has to stop making every application look like IMS in a brown paper bag, or every benefit come down to offering QoS. The future is built on the past and present, but that doesn’t mean the three march in lockstep.

We think this is a very important announcement because it represents a willingness of Alcatel-Lucent to promote APIs independent of the standards efforts. Virtually none of the over-the-top player APIs are standardized, though they (like Alcatel-Lucent’s) are based on Web/REST principles and XML templates. For operators to secure a place in the services market for smart devices, they will need to be more agile, and will need agile service APIs to promote that. This is also the first set of “provider-service-layer” APIs that have been published openly by a vendor. We’re watching this program with interest; it could prove significant.

More capabilities should come along at some point—they must because standards-based programs already offer the same capabilities. The developer program for the Open API service is public and open (and so we’ve joined our ExperiaSphere activity to it). We are not yet able to determine whether the Exposure Suite’s APIs are public and open, but the Open API program alone makes Alcatel-Lucent the first major player to actually open its service-layer development program.

There is also a strong professional services linkage to aid operators in fielding their own service-layer framework. In all, the story was articulated reasonably well and the presentation of the structure of the Alcatel-Lucent architecture was detailed enough to make it credible, particularly given the early fulfillment of a developer commitment. We believe that a mature developer program is critical to any service-layer strategy.

Alcatel-Lucent’s strategy follows an announcement by Juniper that is more tool-and-software based, and by comments by NSN that its own service-layer strategy is based on professional services rather than on productized components. Three vendors are now strung along a kind of theoretical line between (at the NSN side) a pure professional-services solution and (on the Juniper end) a pure software/tool solution, with Alcatel-Lucent spanning a good chunk of the middle.

The operators like a tool approach, we’re told, though they are willing to pay for services to help them create their service-layer strategy. They just prefer to have a framework they can examine in detail. Operators also believe that a tool-based approach has intrinsic developer potential, something difficult to achieve with a professional services approach. Juniper has tools, and now so does Alcatel-Lucent. We don’t think NSN can sustain its service-driven approach in the face of so-far-universal support for a more productized service-layer offering by competitors. Interestingly, Cisco has yet to really make any noise in the service layer, and it would normally have been making its own announcements at least in synch with, if not ahead of, major competitors. Cisco is either planning something extravagant or planning to do nothing at all; either will say a lot about Cisco’s future strategies.