I guess that like many out there, I regard Cisco announcements with a mixture of interest and cynicism. I remember well the times when Cisco would announce a “five-phase strategy” that was (whatever the technology focus) always something that they were already in Phase Two of and never something that was actually delivered in “Phase Five” at the end. In effect, it was a placeholder for a real Cisco push, one that would develop when Cisco was sure the market was ready. Cisco is a “fast follower”, remember?
Cisco seems to have outgrown that five-phase approach, but I admit that when I saw their latest IoT announcement had six pillars, I was taken back to the good old days in a different wrapper. The obvious question is whether that cynicism is warranted, and the answer in my opinion is “Yes”, at least at some level. That means we have to look a bit deeper. For those who want a specific reference to the Cisco announcement to follow my points, their press release is HERE.
The six pillars Cisco identifies are network connectivity, fog computing, security, data analytics, management and automation, and application enablement platform. At a very high level this is a fair statement of IoT needs, but hardly one that’s insightful. I’ve had some discussions with network operators and they have some fairly specific views of how IoT has to be done. You can fit the operator visions into Cisco’s model as long as you stay vague.
Operators start with the notion that IoT has to partition sensor, control, and application elements in private networks. The stability, security, privacy, and governance risks of “unbridled IoT” are so profound that nobody in their right mind would accept them. If you start IoT with the presumption that things that talk to you about conditions (sensors), things that command actions or processes (control elements), and things that can convert one into the other are partitioned and exchange information only in a very controlled way, you’re covering the basic risks.
Their second point is that to applications, IoT is not a network of devices at all, but a hosted repository of “big data”. You cannot make IoT work if you assume that applications just cast about in the world for stuff to talk to (or listen to). You have to structure information so that applications can find and make use of stuff without threatening the underlying elements in any way (deliberate or by error).
Their third point is that IoT is most likely to be useful when it’s seen as a tool in exploiting mobility-generated opportunities. Sensors and controllers out there in the world make sense if you’re out there too, not sitting at a desk somewhere. This means that while it’s not necessary for IoT and mobile services to be considered a single problem. LTE connection of a sensor or controller is just a question of finding the most convenient and cost-effective approach, not a question of creating an enforced unity of implementation.
The final point is that even if IoT is pervasive and important, it can’t be a service silo. Whatever architecture defines support for IoT has to be generalized enough to be applied elsewhere, and tools from elsewhere have to make up as much of the IoT framework as possible.
You can see even at a glance that it’s possible to map Cisco’s approach to these four points. The challenge is that the mapping isn’t convincing because Cisco hasn’t supplied a lot of detail to go with the basic notion of pillars. This is where I think Cisco is falling back to “followership” in their approach, even though they’ve made the notion of IoT (as Internet of Everything) into a marketing slogan.
At a high level, it looks like IoT to Cisco is a combination of some new-age networking concepts and “fog computing”, which is Cisco’s name for deployment of hosted service elements at or close to the edge. That seems to me to be a given, so it’s not telling me much. The big question is how the applications (in the “fog”) and the sensors and controllers (in some sort of network) are linked. Increasingly, operators I’ve talked with make the point that indiscriminate deployment of IoT elements raises way too many regulatory issues, and they’re rapidly settling on an IoT-as-a-database model. Cisco’s “data analytics” isn’t defined that way in their announcement, but it could be positioned like that.
Cisco’s 15 IoT product announcements don’t provide a lot of clarity either. Most of them are related to what I’d call simple issues—connecting stuff and managing stuff. The notion of “fog data services” again skirts the edge of IoT reality, but it’s tied to a “data-in-motion” model that to me seems to suggest that IoT is a set of data flows and not a database.
What I’m wondering is whether “six pillars” is a Cisco solution to something that they see as having firm demand but vague deployment models, where “five stages” were to address something vague in a demand sense. I personally think that large-scale rollout of IoT is more likely to happen through network operators than through any other source, but Cisco may think there are other early models that might make up in timing what the lack in convincing scale. It’s in a way similar to the situation with NFV, which exposes “can it work” issues before it exposes “can it pay off” issues.
I think the risk to Cisco here is that they’ve grabbed apples that are a bit too low, IoT-wise. My experience with operators shows that there are real early opportunities for a realistic IoT model based on the points I described. I’m looking at a couple now, in fact, that map to those points almost exactly. And Cisco’s not the only player talking in this space. HP did an IoT announcement at MWC and followed up with more detail in their Discover event in June, and the HP approach seems to map to the operator points pretty directly. As a major cloud and NFV player, HP is certainly in a position to get their story out there, and their story included using their IoT architecture as a framework for other services, including virtually any form of contextual service to mobile users.
Another risk is created by Cisco’s dance around NFV support. Most operators think that applications using IoT data would be deployed and sustained through NFV, but that’s not part of Cisco’s six pillars. They talk about management, but in the general sense that’s appropriate to the “I-don’t-know-the-buyer” position I suggested they might have. While an NFV tie here would make their IoT story palatable to operators they may feel the specificity would turn off other possible early adopters.
Which raises an Oracle risk. Oracle was interviewed in a New IP story on NFV that opened with the comment that NFV hadn’t progressed to make the business case for its own deployment, and that more operations centricity was the right path to address that. It’s been clear for a while that Oracle’s own NFV approach is OSS/BSS-driven and analytics driven. It’s a small step from analytics to deliver management data and analytics to deliver IoT data.
It’s smart for Cisco to spread its marketing wings wide in a world that’s changing as rapidly as networking and IT are likely to be changing. Their fast-follower approach has also worked pretty well for them over time. The risk, though, is that any kind of follower can wait too long to start, and watch others cross the finish line well ahead. Whether that will happen here depends on the pace of the market, which means the collective pace of Cisco’s competitors. That’s a risk, no question about it, to Cisco.