The promise of an Internet connected future is real. Most companies that choose to compete in the rapidly growing IoT marketplace will have access to new methods of monetization that enable rapidly scalable business models only seen to this point in the byte-world where an app can be launched and relaunched and modified with little upfront cost relative to the total potential gain. MMID believes in this connected future and, for the most part, it’s an increasingly utilized facet of our extensive electronic integration and development capabilities. That being said, integration is not a blanket recommendation: there are risks associated with incorporation and the rush to connect is, as best described in this delightfully dated late-nineties infomercial by Gartner, at the Peak of Inflated Expectations. Those who will not benefit from integration generally possess at least one of the three following attributes:
Increased information and control does not automatically increase product value for the end user
Good product design and development starts with a thorough understanding of the needs of a given user. This is especially true in the case of IoT products like smart home technologies as the availability of data greatly increases and augments the inherent utility of such a product and its life cycle. At the extreme end of the spectrum, a company that produces bricks (known as a perfectly durable good in the context of economics) used in home construction would not benefit from the inclusion of an IoT sensor package baked into every brick. The bricks themselves are too stable in form and function to provide meaningful interpretable data to a user through their lifecycle and their multi-generational duration of utility is far too long to ensure continued interoperability with the technology of even the relatively near future. Before embarking on an IoT development effort, companies must question if increased connection actually yields tangible benefit for overall user experience.
Greater utility comes from a top-down IoT framework versus a bottom-up network of discrete units
If greater benefit can be achieved by analyzing or controlling a system from a top-down perspective where the user has access to system-wide averages and metrics or controls, individual discrete units in that system should not be directly connected to an IoT framework. Like a brick, a blade of grass is usually considered as part of a larger whole; in the case of the blade of grass, that larger whole is a lawn. Using current technology, it is possible to put a sensor package the size of a grain of rice at the base of each stalk of grass in a lawn. By aggregating data from the millions of micro-sensors spread across an entire lawn, it is possible to gain a hyper-precise reading of hyper-localized soil and plant health metrics. In such a system for example, the pH level of the soil surrounding Blade 1H834K is perfectly understood as it fluctuates throughout the growing season just as it is understood for the immediately adjacent Blade 2O982E and Blade 2R599V. While potentially interesting as an intellectual exercise, this data is not actionable. Ultimately the human responsible for the maintenance of the grass cares very little about those individual stalks and instead is far more interested in the global health of the lawn. It’s far easier- and far more efficient- for a gardener to measure the pH level at the vertices of a half meter by half meter grid spread over the lawn. While not nearly as precise, that gardener is able to gather more than enough information from that top-level analysis to make a qualified decision on how to vary fertilizer concentration across different parts of the lawn. By nature of the limited amount of data processing germane to top-down systems versus bottom-up systems of discrete units, top-down systems are also much more suited to lightweight embedded IoT deployments where computational or electrical supply are in lessened availability. Additionally, top-down systems are easier to service and require less maintenance infrastructure simply via a reduction in the number of points of failure.
Product life cycle does not justify (direct) IoT integration
Just by accepting delivery of saleable product, grocery stores worldwide incur large deficits before they even open their doors to their hungry customers. Why? The USDA says it’s due to food spoilage:
The average loss rates for 2005-06 for individual fresh fruit, vegetable, meat, and poultry commodities at the supermarket level, as estimated by the Perishables Group, Inc., varied from 0.6 percent for sweet corn to 63.6 percent for mustard greens.
Sixty four percent?! Either people really hate mustard greens or they are incredibly fragile. Because the life cycle of the average piece of produce in the supermarket is so short, ultimately ends in the designed destruction (cooking) of the individual unit, and because the cost of each unit is so low, there is little to be gained from adding even a relatively cheap sensor to each bunch of mustard greens. Additionally, this is a prime example of a product where a top-down IoT framework is far more useful than that of a discrete/bottom-up approach to sensorization. In general, consumables should not be directly connected to IoT infrastructure as the cost of computing is not yet at the point where it is disposable. Instead, IoT adjacent solutions like bar-coding can be used to track product life cycle; the barcode reader is a centralized nexus for connection and data collection. In practice, this is how products are already tracked and sold at grocery stores although generally each individual unit does not have a unique identifying code. Instead, products are grouped based on similarity which- again- offers a far more useful data set (consumption rates, times of purchase, etc.) to a produce or grocery buyer. It is only once the mustard green is in the hands of the end consumer that focus shifts from mustard greens as a collective unit to an individual finite element. Unless the end consumer is a massive mustard green aficionado, there is no need for IoT integration at point of consumption because, obviously, the end consumer has no issue processing and collecting data when manually examining their grocery haul of (apparently totally gross) salad.