Enterprise IOT: Mixed Model Architecture
August 19, 2014 Leave a comment
– By Andy Thurai (@andythurai)
This article was originally published on VentureBeat.
Recently, there has been a lot of debate about how IoT (Internet of Things) affects your architecture, security model and your corporate liability issues. Many companies seem to think they can solve these 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 how the actual implementations work, I disagree with this one size fits all notion.
[Photo Courtesy: http://www.joyoftech.com ]
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, and thereby controlled by 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 might work under normal operating circumstances, there are times, important times, this will fail. One such example would be 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 ofcourse), 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 even if the connectivity is lost. 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 case, 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 “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 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 them. Especially with IoT it is not just about the data, but also the sequence of events and time of occurrence matters as well. There is a reason why the 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. As I indicated in my earlier articles, the hackers haven’t figured out the right way to monetize the IoT data yet. This is partially because IoT is not mainstream yet, and second the commercial grade hacking hasn’t arrived at the IoT scene yet. It is only a matter of time when that happens.
People often forget that IoT is about inter-connection 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, you need to take into consideration these disruptive design principles as these are disruptive technologies and need a game changing design in place. I will write a deep technical article on the IoT reference architecture and different usage models very soon.