IoT Lives Better On the Edge

Any scan of the Internet of Things literature (IoT), and there is lots of it, exposes the reader to a mix of assertions and impressions that are hard to ignore if you are in the field. The most common theme starts with the usual forecast that the market will soon be awash with tens of billions of machines, devices, and sensors “Things” in the next 2 to 5 years, that all these will cause a huge Big Data problem, and that all this will require significant investments in the network, Cloud, and analytics or other types of enterprise applications. Not surprisingly perhaps, the primary source of much of this literature are the large marketing machines of traditional enterprise IT vendors trying to keep their wares relevant and to protect their heavy investments in technologies, products, and channels in the fast approaching IoT era. While this view may be generally true in the long term (next 10 or more years) for some applications, it is a simplistic over generalization for many IoT applications and is not true for many others. The bigger concern however is that the remote central data integration and analysis architecture approach that commonly underlies and justifies this dominant view in IoT marketing literature ignores, not clear if by omission or commission, many factors that are particularly important for the types of applications that will drive most of the growth in the number of “Things” and dollars the same literature love to quote. These factors include but are not limited to the following:

  • The type and nature of the “things” that will drive the anticipated growth. These are certainly not the Jet Engines, Windmills, or even the few billion smartphones that dominate the hype literature but rather small and in most cases resource-starved sensors and devices. More importantly these types of devices will not be pushing video or steady streams of high volume data into the network but rather generating low-bit data rates infrequently and in bursts. Unfortunately this is just one of the many problems that come with the false implied-homogeneity of referring to the vast types of sensors and devices as simply “Things”.
  • The loss of time and context when data is moved away from its local collection point. This makes the “Thing” itself, whenever possible, the ideal place for data filtering and the local access point or gateway the ideal place for integrating local inputs and constructing local contexts, outputs, and decisions. Please note that this kind of local context sensitive functionality is done in the firmware inside pre-IoT devices today (otherwise your fire detector would ring all the time or not at all) and that it is only natural to extend this capability to cover additional IoT functionality in the future.
  • The large number and types of applications that have different requirements than the few application focused on the finite market for targeted advertising and maintenance of large expensive assets that seem to dominate the literature. While these types of applications may be important, the number of applications that require integration of data from many geographically dispersed local domains (“GDLDs”) to make very complex analytical decision at a remote central point (Cloud or Enterprise on premise) are much smaller than ones where the data needed to make an intelligent timely and in most cases a simpler decision is all local.
  • The Economics and QoS requirements will preclude the architectures that rely on remote central integration and analysis of data. In a significantly large number of applications it is neither possible nor economically wise to provide data integration and analysis functionality remotely in the cloud or the Enterprise particularly as more of the resources required to support IoT functionality are built into Things (machines, devices, and sensors) and local gateways over the next few years. This includes many potentially more exciting classes of IoT applications where the real-time and latency QoS requirements cannot be supported by this approach and where the constant recurring cost of shipping data over the network to make decisions that do not depend on data from GDLDs remotely then ship them back to be acted upon locally does not make economic sense.

As discussed above, while this view and the remote central data integration and analysis architecture approach that underlies it makes sense for some important applications, common systems and networking engineering sense implies that this will be more the exception rather than the rule. In addition to the business, architecture, and engineering issues above, the traditional remote Cloud or HQ-based data collection and analytics approach ignores many of the important differences between the traditional Internet of People and the emerging Internet of Things that I intent to blog about in the future.

While there are a number of IoT architectures variations possible and many under development (more on that also in future blogs), the best and most promising ones recognize that the great variety of IoT applications require an agile and flexible architecture with built-in provisions for placing the data filtering, aggregation, analysis, and the resulting decisions and actions wherever needed based on the requirements of different applications. That said, if it makes sense to have a generic default architecture starting point for your business or for a “generic” IoT application (if such an abstraction has enough utility at all) it would be to deploy all data collection, filtering, aggregation, decision(s), and action(s) locally in the device domain or as near as possible to the edge of the network and to progressively and slowly move outward only when the application requirements absolutely dictate it.