Cisco is generally credited with driving the concept of the Internet of Things (IoT), even though it was Carnegie Mellon back in 1982 that first conceptualized the idea. I’m still at Cisco’s big analyst event this week and was fascinated by a survey shared on stage. Apparently, 74 percent of the survey’s respondents have indicated that their IoT efforts have been going really badly, either not finishing or not finishing within expectations. In addition, these same folks are indicating that about half their time is spent on troubleshooting problems. Cisco connects the latter to complexity. Given that there really is nothing as complex as a typical IoT effort, I see the two stats as related and suggest that IoT efforts are poorly planned, which is why they aren’t completing as expected and likely adding to the complexity problems overwhelming IT organizations.
Now, Cisco is positioning its Network Intuitive efforts at this problem and certainly massive automation can reduce the amount of work, particularly with regard to often repetitive troubleshooting efforts. However, with the IoT in particular, really understanding the problem you are trying to solve and simplifying the effort at the front end would likely have an even bigger initial positive impact.
The World Is Not Yet IoT Ready
One of the big problems with the IoT efforts I’ve seen is that they seem to want to connect a set of things that weren’t initially designed to interoperate. This would be kind of like trying to build a car based on what was already in your garage. Yes, you likely could get something that would roll, albeit badly, but driving the spouse to dinner in it would likely require a more forgiving one than any of us now have.
Forcing interoperability is something we in IT have pounded our heads against for years. Major vendors have for years viewed interoperability as a negative, and even today IT vendors often have to be dragged kicking and screaming to provide acceptable levels of interaction between systems. We’ve learned to avoid those vendors and pick those that use interoperability as a competitive advantage.
However, outside of IT, the world is very much as it was in IT decades ago: Very few firms building control systems, lighting systems, HVAC systems, or even some types of manufacturing systems believe interoperability is a good thing. As a result, we are back to pounding our heads against the wall, trying to get large numbers of systems that are designed to be antisocial to suddenly be happy members of our new IoT connected family. Much like it would be if you were to do this with people, it clearly isn’t going well.
But I have some suggestions.
Many failed IoT efforts were simply too ambitious. If you start small and focus on those things that will play well together first, you’ll not only gain needed experience (another part of the survey indicated a severe skills shortage), but you are more likely to complete the effort successfully and have budget if you need to make some critical changes to get the thing to work. Now, this could still have you going down a blind alley, resulting in your having to redo what you just did in order to get around an unexpected road block.
So even though I’m suggesting you start small, you should model at scale. Use your contacts with firms that have executed these efforts (the vendors assisting you generally will provide reference accounts if you don’t have these contacts yourself). Model the result you want and particularly look for problems that may result from your unique shop and the core connectivity and control technology you have selected. This may force you to either change the primary vendor, budget changing out the systems you have in place that are identified as too costly to integrate, or simply take those systems out of plan.
Put in Place a Hard Purchasing Rule
This is likely something you should have done about the time you started to get the IoT bug. But, as noted above, there are vendors that embrace interoperation and those that don’t. Any vendor that isn’t an aggressive supporter of interoperability and tied to the IoT platform you have decided to deploy should be labeled unacceptable. Think of this like buying parts for your car; you wouldn’t buy Ford parts, no matter the cost, if you drive a Mercedes. Going forward, every connected system is going to have to fit into your connected enterprise. Not assuring compliance at the front end will simply result in massive problems once you try to integrate that system into the site you are trying to make smart.
Eventually, I expect, firms that aren’t building in strong hooks to leading IoT platforms will start going out of business, and this too justifies you blocking them from your sites. No one wants hardware from vendors that have failed, and if these folks don’t get on the ball,, they will eventually be seen as the problem and blacklisted.
Wrapping Up: KISS to Accountability
One of my favorite acronyms is KISS: Keep It Simple, Stupid. I think this goes to the heart of why many IoT efforts are failing at the moment. They are simply too complex. Certainly, consider tools like Cisco’s, which automate a lot of the labor, but aggressively designing in simplicity will likely have an even bigger initial impact. Model big but start small and focus on things that will naturally work well together emphasizing interoperability, including both control and patching, into your optimal solution, and blacklist vendors that don’t play well with others.
I think the skills you need with IoT mirror largely what teachers learn in grade school. You want kids who play well with others in your class; you want the socially challenged kids in the class of the peer you don’t like. In our case, we’d like the vendors that don’t play well with others have the greatest success selling to our competitors, but stay the heck away from our own shops.
One final thought. As I’m writing this, Michael Giresi, CIO of Royal Caribbean, one of the early adopters of Cisco’s new architecture, is talking to this topic and recommends assigning full accountability. He means that the entire IoT effort should be clearly owned by identified people and that they are held accountable for the total performance, and don’t do the more typical separate infrastructure and apps. This is a big idea that I think we’ll explore next week.
Rob Enderle is President and Principal Analyst of the Enderle Group, a forward-looking emerging technology advisory firm. With over 30 years’ experience in emerging technologies, he has provided regional and global companies with guidance in how to better target customer needs; create new business opportunities; anticipate technology changes; select vendors and products; and present their products in the best possible light. Rob covers the technology industry broadly. Before founding the Enderle Group, Rob was the Senior Research Fellow for Forrester Research and the Giga Information Group, and held senior positions at IBM and ROLM. Follow Rob on Twitter @enderle, on Facebook and on Google+