The most common question I receive on a daily basis is “what exactly is the Internet of Things?”. It took a while for me to realize that the most important term here was 'exactly'. This suggested to me that most people believed they felt they understood the term 'Internet of Things' to a certain degree but still had some gaps in their overall comprehension of this considerably over-hyped term. When I decided to turn this around and asked them what they believed the 'Internet of Things' or IoT for brevity, actually meant to them, it became apparent that the problem was more in the accepted definition than the omnipresent IoT hype. Everyone understood what the 'Internet' was but failed to appreciate what 'things' was in this context.
There's a lot of confusion, mistrust, and misunderstanding around IoT. In this series of articles, we're going to explore what IoT means and why that should matter to you.
What’s in a name?
People are frequently confused by the term 'thing'. When Peter T. Lewis originally coined the term 'Internet of Things' as far back as 1985, he defined it as:
The integration of people, processes and technology with connectable devices and sensors to enable remote monitoring, status, manipulation and evaluation of trends of such devices
The key point here is the distinction between people, processes, and technology, with devices and sensors. The devices and sensors are simply a means to an end in order to integrate the real world with the digital world. This encompasses all aspects of people and technology (machines) interacting in one or more locations. The process refers to the series of steps, or activities, which are involved in this interaction. The more traditional non-technical phrase is 'people, places, and things'. People, places and things generally suggest that any object that isn’t a person or a place must be a thing. By definition, even a device must be a type of thing.
The fundamental problem is that since the original use of the term in 1985 we have witnessed incredible and unforeseen innovation and progress in all aspects of technology. In 1985 the term 'Internet' was in its infancy, and 'thing' generally referred to any object we couldn’t easily find a name for.
Asking someone to give their definition of a 'thing' is akin to asking them to explain how to ride a bike. It is second nature; everyone believes they fully understand the concept so well they do not need to explain it anymore. Technologists are guilty of this on a daily basis every time they use the term 'cloud'. It’s fully understandable that everyone has their own cognitive definition of what a thing means to them. 'Thing' is by definition the vaguest term ever devised.
There have been many subsequent alternative attempts at defining the 'Internet of Things' since Peter’s original definition. This has only resulted in a dilution of understanding as to what it meant in 1985 and what it should mean in 2017. Ironically, most people are actually unaware that IoT is such an old term and believe it is much more modern in origin.
In a nutshell, technologists are far too obsessed with devices and sensors in the world of IoT. While these play an important role, consumers and businesses are only interested in the value and benefits that IoT can offer, and that value lies in things and data, not in electronics. Let us understand why that is.
Things in action
One of the simplest use cases that we can use to illustrate the importance of distinguishing between devices and things is one of the oldest and most recognized technologies, the humble light bulb. While the underlying technologies responsible for creating light energy over the last century may have evolved, the user experience is pretty much unchanged.
Applying our approach to this, the lightbulb is the thing and it contains a device inside that transforms it from a 'dumb thing' into a 'smart thing'. In addition, we have another smart thing which is the smart switch. It also has an internal device inside then wirelessly transmits the 'press' to the smart bulb over the selected IoT protocol of choice (ZigBee, Bluetooth, WiFi, etc.).
The user activates the switch which switches on the bulb. Press again and the bulb switches off. Simple process. The majority of innovation from an IoT perspective over the last ten years has been predominantly in the area of convenience and control. We now have wireless switches and LED bulbs that consume a fraction of the energy while allowing fine-grained control over the intensity and color of the light. In this scenario, we activate the sensor (switch) which transmits a wireless signal to switch on the RGB LED bulb (actuator). The complete picture looks something like this:
Figure 1: A smart home setup
What the user sees
From the user’s perspective, all of the complexity you see should be invisible. They still have a switch or a button that they use to operate the lightbulb. It should be so simple that it does not require an instruction manual in order to operate. The same principle applies to the mobile application. The end user simply relates to the connected lightbulb in much the same way as the traditional lightbulb. They shouldn’t need to care about the fact that the lightbulb actually contains a device and an actuator that controls the power of the LED. They should also not need to know that the light switch they have been familiar with for so long is now a combination of a switch, a sensor, and a device. They have a lightbulb and a switch. These are the 'things' to which we refer. They are real-world objects, and we need to ensure that we hide any unnecessary complexity for the product to be successful in the market.
What the developer sees
From a developer’s perspective, the same principles of abstraction of things and devices still apply. The developer will obviously need to understand the basic 'thing' data model that supports the creation of new and innovative user experiences, but this should be as intuitive as possible. It should not require them to fully appreciate the inner-workings of the devices and communication protocols. That is the device creator’s responsibility to hide the hardware complexity while guaranteeing long-term security and stability of the product. An Internet of Things product’s success is critically dependent on its usability and developer-friendly data model. Customers won’t buy or use over-complicated products. Developers will only want to build software for those products that are simple, fun to work with and commercially attractive.
Things are not devices but devices are things.
Most of the alternative definitions of IoT have generally revolved around aligning IoT to current technology trends that may be considered fashionable. Vendors and marketers have also successfully exploited IoT as an opportunity to either sell more products, services or hype. This has unfortunately resulted in the terms “things” and “devices” slowly being used interchangeably when attempting to articulate this emerging concept to technology stakeholders. The dilution of the distinction between things and devices only increased as the IoT concept was marketed towards consumers and end-users who knew even less about the concept of a device and why they should actually care in the first place. Peter T. Lewis had a distinction between things and devices, but that clear distinction appears to have all but eroded over the decades.
In my experience, most organizations and their senior stakeholders see security (the Internet of Threats ) as being one of the major handicaps to the adoption of IoT technologies in their business. The remainder cites confusion in the terminology expressed by vendors and marketers as being responsible for the lack of faith in the Internet of Things. When we discuss the 'things' in IoT the vast majority of individuals and organizations are actually referring to the device associated with the thing and not the thing itself.
There is a confusion between devices and things that is blinding people to the opportunities that IoT can deliver, and without understanding the opportunity, they let security fears and hype fatigue cloud their judgment.
Technology companies are focusing far too much on the technology aspects of IoT and, as a result, incorrectly perceive hardware devices as things. This has resulted in the over-emphasis of the devices component in IoT from a consumers perspective. Yes, devices are an important part of IoT, but real people, business, and technologists should only need to be interested in the things that they interact with in the real world. Devices are simply an enabler for the interface of the physical world to the digital world.
If we can no longer see the relevance of IoT to real people, then we risk the 'Internet of Things' actually being the 'Internet of Devices'. This is already clearly visible in the thousands of IoT devices appearing on the market, designed by device-centric technologists with a lack of understanding of the user-centric design aspects of their intended owners. Products designed by technologists, for technologists, does not represent a sustainable commercial model and is only detrimental to the minority of device and product designers who fully appreciate the importance of the user in the equation.
Even when we are referring to Industrial IoT (IIoT) use cases where the user does not have a direct physical interaction with the devices and sensors (other than initial installation), there is still a need to ensure that the data actually relates to the real-world physical thing itself. When we are in the realm of the Smart Home and Home Automation, if we focus too much on the electronics aspect then this can result in products targeted at hobbyists and early adopters with an overemphasis on the technology aspects of the product. These are the products normally referred to as “gadgets” when they are no longer of interest, or the parent company has ceased to exist.
This problem is also evident with the proliferation of 'Internet of Things Platforms' that are in reality 'Internet of Devices Platforms'. Previous generations of developers focusing on the IoT space required deep knowledge and experience of the device hardware and low-level programming languages. Modern developers should no longer be constrained by these legacy hardware expectations. While we will always need some degree of deep hardware expertise for device integration, the modern developer should be able to interact with the 'thing' at a clearly defined abstracted level as long as they understand how their 'thing' works in the real world. The less the developer needs to know about the device model the more rapidly we can innovate and deliver real value to both the product owner and the product maker.
You say 'Internet of Things', we prefer 'Connected Things'
The Internet of Things landscape is now so highly competitive and fast-moving that products that previously took years to develop can now be realized in months or even weeks for a working prototype. This agility should not be allowed at the expense of customer usability or developer accessibility. Customers will not be interested in buying products unless third-party developers are incentivized to develop for those platforms. A rich developer ecosystem can imagine and realize smart product features that the original device creator could have never imagined. The effort and expense should be invested into the Application Programming Interfaces (APIs) creation and developer ecosystem well before the product is released to market.
The key to success is, therefore, a 'human-centric' approach to product design and a 'developer-centric' focus on product data. For this to be possible, we need to reshape the 'Internet of Things' definition. Smart products do not always need or should need, to connect the Internet. More importantly, we should understand that a 'thing' is not the device itself. When we appreciate these tenets as product makers, then we are in a much stronger position to fulfill the original vision proposed by Peter T. Lewis over 30 years ago. For this reason, at Thoughtworks, we prefer the term 'Connected Things' over 'Internet of Things'.
In my next post, we will discuss the Data aspect of Connected Things and understand how we derive real value from the data and not the hardware.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.