MWC is nearly upon us, so it’s not surprising that we have more mobile-related news than usual. In fact there are a couple of stories that offer not only the usual mobile/product slant but also say something about the companies making the announcements and the market they’re trying to address.
The first announcement was from IBM, with “MobileFirst”, a sweeping push at the mobile-device-in-the-enterprise space that includes everything from application development to device security. It’s obvious that IBM is taking the space I’ve called “point-of-activity intelligence” very seriously, looking not only at the issue of how to empower workers with the what-they-need-and-where kind of insight that boosts productivity, but how to manage the delivery.
Mobility and point-of-activity empowerment is critical to that because you can’t make a worker more productive without altering how they work. And when you do that you collect more information about work processes (big data and “mobile fusion” applications), change how computing relates to its users (the cloud), and change how networks have to support workers and resources (SDN, NFV, mobile/wireline convergence). None of these things are created by point-of-activity empowerment, but all of them are impacted, and on an upward trajectory.
Another less obvious truth is that IBM is staking out a claim in enterprise mobility, a claim it’s creating and supporting from the software/IT side of the house. If PofA empowerment is critical and if it boosts productivity benefits, it drives IT spending. Anywhere more money will be spent is a place where players can gain both profits and market share. Further, in the never-ending battle for account control between network and IT players, it’s the collision zone. Rival Cisco’s recent pushes into mobility at the network level signal they want these productivity dollars too, and IBM is making it clear to Cisco that to get those dollars it will need SOFTWARE. Hey, Cisco, you want to be an IT company? Start thinking IT in mobile PofA empowerment, says IBM. Good advice for Cisco, I think.
Juniper also made a mobile announcement, linked to its MobileNext (which was, for the record, announced before “MobileFirst”) approach. MobileNext has been a bit of a poor stepchild of profit goals as far as Juniper’s relationship with the Street goes, but the fact is that Juniper needs a mobile/metro strategy desperately because that’s where the money is. Since Juniper doesn’t have radio or IMS capability, they’re at a disadvantage in the mobile space, and so they need to get hot in mobile transport, which in the language of LTE means the Evolved Packet Core and the signaling and data components thereof.
What Juniper has announced is a virtualized form of the signaling-plane elements of EPC on their JunosV App Engine, with help from Hitachi. The move would make it possible to host these signal functions (MME, SGSN) rather than to employ dedicated appliances to support them, which would make this a credible step toward implementing service provider goals for Network Functions Virtualization (NFV).
Which is where this gets strange—again. Juniper’s SDN, story just amplified and the subject of several of my blogs, cast service chaining via Junos V App Engine as the centerpiece of SDN. It’s clearly an example of NFV, and so is this latest EPC-virtualization step, and yet again Juniper doesn’t mention NVF at all in its release. Every other telecom equipment vendor I’ve talked to has something to say about NFV and their participation in it. I get more search hits on my blog on “NFV” as a term than I do on “SDN”. From an implementation perspective, doing NFV would give you the model to implement the centralized functions of SDN. So how does this NFV-aversion make sense? I have no idea, and even a phone conversation with Juniper’s top software guy didn’t resolve my confusion.
Apart from whether it makes sense to prance accidentally into a football game because you’re wearing pads and carrying a ball to a ballroom dance contest, the lack of a forthright NFV position is both a direct technical problem and a symptom of yet another market risk. You can’t virtualize network functions as a one-off process, you need an architecture to define the component relationships in a cloud-distributed service-layer implementation. This is something that I think the NFV ISG in ETSI needs to make a priority, because otherwise the efforts of vendors like Juniper (whether they are calling those efforts “NFV” or not) show that we’re going to get NFV-like elements offered as products before they can be put into an architectural context. That would weaken the foundation of NFV and compromise its “openness” goal.