When the industry talks about IoT, it does seem like there is only a singular pattern that is applicable across all industries and consumer segments. The reality is that there are multiple IoT patterns that need to be considered when devising solutions or creating value. In fact, this may be one of the main problems why an effective value framework does not exist to date. In this post, I will be discussing six main interaction patterns in IoT. In my next post, I will discuss a few advanced interaction patterns as well.
At the essence, there are three main actors in a typical IoT interaction. They are:
- End user or customer
- Business or Organization
- Device/Sensor/Appliance (the thing in question)
Kees, Oberlander, Roglinger, Rosemann (2015) in their discussion paper at the European Conference on Information Systems present the interactions between these three actors that yield the following basic set of interaction patterns:
- Thing to Customer Interaction: In this pattern, the interaction is primarily between the device and the end customer. Little or no interaction exists between the device and the business organization. Examples of this pattern are fitness wearables (Microsoft Band, FitBit, etc.), remote control (remote enablement of automobiles, etc.).
- Thing to Business Interaction: In this pattern, the interaction and connectivity is between the device and the business organization. Many times, the end user of the device is probably not aware (or does not care) of all the interactions taking place. Examples are firmware updates of internet provider modems, routers, etc. Another example is a home where a connected refrigerator may be transmitting water filter usage information to the manufacturer.
- Customer Centric Interaction: The customer is the key focal point in this interaction model. Both the device and the business communicate through the customer. If the customer chooses to enable connectivity between the other actors, then there is no data exchange. For example, smart operation of lights in a home can only be done by the manufacturer of the device with active cooperation by the customer. Another example is remote entry into a house; unless the customer explicitly authorizes each entry, the security device cannot be unlocked by the company.
- Business Centric Interaction: The business is the key focus in this interaction pattern. The usage of this pattern usually implies that some sort of smart learnings are being applied in the operation of the device. Without the business getting involved in the middle and storing/analyzing the data, no smart learnings can be gleaned. A common usage is the drive monitoring OBD (On Board Device) supplied by insurance companies to ostensibly provide cost effective premiums. “Snapshot” OBD provided by Progressive Insurance is a good example. Another example for this pattern is NEST, the machine learning digital thermostat that monitors temperature conditions to optimize heating/cooling in the house.
- Thing Centric Interaction: This interaction pattern is probably the least used in monetization models. Most usage scenarios for this pattern reflect emergency situations where the action based on device feedback needs to happen imminently. Consider the case of a sensor that detects abnormal radioactive levels in a nuclear power plant. Obviously taking into account the probability of a false alarm, algorithms are built by the organization that automatically activate safety procedures without waiting for customer intervention. Another example is that of a health bracelet that, upon detecting low pulse rate of the wearer, automatically alerts emergency response team.
- Full Actor Interaction: The final pattern is that where all the actors (customers, businesses and devices) interact with each other actively. Consider the following situation: A driver allows her location information and current fuel level of her car to be continuously monitored and shared to the business. In addition, the driver has also enabled her calendar information to be shared with the business. The fuel gauge device automatically triggers an event when it detects low fuel levels. Based on this information (and perhaps time of day), the business can recommend various refueling options. Incorporating the calendar information, fuel levels, traffic conditions and time of day, the organization can recommend a course of events where the driver can refuel, eat lunch and then proceed to her destination in the most efficient way possible.
