[Update 5:27pm: The author’s bio has corrected.]
These days, when you hear about the Internet of things, it’s usually about body sensors, such as Fitbit, or smart home sensors. But while consumers are just now beginning to be exposed to these sensors, they already exist extensively in the enterprise.
Industrial-grade sensors are being used in energy, retail, manufacturing, and other commercial applications, but companies are moving to Internet-enable those sensors now. And they’re running into heavy debate lately about how best to architect IoT in the enterprise so that it is effective and secure and doesn’t open up a company to liability issues.
Many companies seem to think they can avoid problems by centralizing the solution, and thus collectively enforcing it in the hub, moving as far away from the data collection centers (not to be confused with data centers). There is also a lot of talk about hub-and-spoke model winning this battle.
Recently, Sanjay Sarma of MIT, a pioneer in the IoT space, spoke on this very topic at MassTLC (where I was fortunate enough to present as well). But based on what I am seeing in the field, based on actual implementations, I disagree with this one size fits all notion.
While, according to Sarma, the “Internet of Things” is nothing but “Cloud things.” He also made a flashy statement that in the IoT landscape, the hub-and-spoke model will win. He continued that the “things” will not talk to each other in a distributed manner, but to a central server, especially in a cloud based location, which will control them. He even went on to suggest that the IoT lacks success as it is too distributed as it exists now.
The first issue I have with this architecture philosophy is that we are making an assumption that all of the “things” will have Internet, or cloud, connectivity all the time. If your architecture holds certain assumptions, forgetting the great “Murphy’s Law,” then it ultimately will fail. While this assumption of constant connectivity will work under normal operating circumstances, there are times, important times, it will fail; for example, when someone is hacking into your system or trying to sabotage your system. As any professional burglar would tell you, when they try to break into a house, they will first disable the landline (which takes out 911 calls and home security systems – pre-mobile era, of course), take out the power to the house, and use darkness as an ally.
The professional invaders to your distributed IoT system will do the same thing. They will take out the connectivity to your hub first and re-direct the connection to them, wherever that is. Unless you are on a completely private network, this is a real possibility. Especially, given the remoteness of these IoT installations, it might be difficult to restore connectivity to your hub, during which time your productivity will be lost.
In order to avoid that, you need to first have some intelligence built-in on the local “spokes,” so that when the connectivity is lost to the “hub,” the system will be able to independently operate. And if the connection re-direction occurs to an unknown site, it should have enough intelligence to shut itself down.
The major hurdle to this architecture is if your spokes mostly consist of low-powered or no-powered devices (such as RFIDs). In such cases, you need smarter local hubs that will connect all these devices and provide such intelligence before connecting to the central hub. These local hubs could be at a factory floor level, building level, or a city block level. Building smartness into your “first mile” of your IoT architecture is key to a smarter architecture.
The advantage of building smarter local hubs is that they can communicate and inter-work between themselves even if the central hub connection is lost. In the hub-and-spoke model this is impossible, as it is expected to collect data, send it upstream, and wait for actionable results.
Second, the most important issue, is that data collection needs to be analyzed, localized, and executed as much local as possible. While the bigger data centers have smarter capabilities built-in, you can’t always assume you can connect to them. Besides, you can’t send all the data collected to the backend and overwhelm your data centers.
People tend to forget that what matters when using IoTs is not just the data collected by it, but also the sequence of events and time of occurrence. There is a reason why time-series databases are becoming very popular. So when you collect so much data from specific sites, you need to analyze and create actionable intelligence at the smart local hub level, which will not only give you faster decisions but also site-specific decisions. Of course, the decision can be adjusted based on the collective intelligence from the hub at a later time.
Third, a subject near and dear to my heart: security and privacy. The local spokes, and the associated hubs, should be able to first anonymize the information and secure it before it gets moved to the backend. Hackers haven’t figured out the right way to monetize IoT data yet. This is partially because IoT is not mainstream yet, and partially because commercial-grade hacking hasn’t arrived on the IoT scene yet. It is only a matter of time until that happens.
People often forget that IoT is about interconnection and integration of smaller, smarter networks to the larger enterprise networks. Once you realize your IoTs are much smarter than “dumb data collection” devices, you will design things differently.
While I have great respect for Sarma, and others who support the hub-and-spoke model, it’s important to consider disruptive design principles, as these are disruptive technologies and need a game changing design.
Andy Thurai is Program Director – Emerging Technologies with IBM, where he is responsible for solutionizing API, IoT, and few other emerging technologies (such as connected cloud). You can find more of his writings at www.thurai.net/blog or follow him on Twitter @AndyThurai.
VB's research team is studying mobile user acquisition... Chime in here, and we’ll share the results.