We’ve been thinking for a long time about how to make a more useful "Internet of Everything." We often find ourselves in the situation to either describe why an application isn’t the answer, or why the Internet of Everything is more than just the Internet of "Everything Connected to the Cloud and Therefore Instantly Cool." To us, the Internet of Everything also involves proximity, locality, context, and privacy. Yes, there is a relationship to the cloud and cloud-based services. But one size does not fit all. The Internet of Everything includes a personal cloud, your most personalized connections to Your Things.
Consider the context for "there’s an app for that." The time had come to migrate services from the richness of the desktop to these new smartphones. At first the constraint was computing power, but we’ve worked through that. The real issue was the new styles of interaction required on the smaller screens of these very personal and mobile devices. At the time, the core technology of desktop services (HTML5 and friends) was not up to the task (I no longer believe this to be true, but that’s another story). No one was properly putting mobile style sheets on their web pages. No standard had emerged for access to location, the camera, and other interesting bits of the smartphone.
Developers are like the honey badger. They don’t care. They go where the money is, and to create revenue-generating experiences they created apps. Millions of apps to encapsulate experiences in bite-sized, constantly updated little nuggets.
All fine and good, but part of the beauty of the Internet is the ability to mash up services, to interoperate, and to partner in the creation of experiences. Social sites used Facebook and Twitter; location-oriented sites used Foursquare. This was the ecosystem that emerged to create billions of dollars of value.
Now back to the Internet of Everything—a mouthful, so I’ll just go with IoE. Some parts of the IoE are very smart—smartphones, tablets, obviously computers, and now TVs too. Many, many more things are quite simple. Light switches. Washing machines. Speakers. Thermometers. And these things have very different product cycles than we are used to in the fast-paced virtual world of the Internet. These things stay in your driveway or the buildings you find yourself in (home, office, out and about) for years. Sometimes more than 10 years.
That begs the question of how we could possibly predict what will be the right architecture or protocol for interoperability and communications for something in 10 years? I don’t think we can predict it. We can say unequivocally that the version of Android and iOS and Windows Phone that we are using now will not run on 10-year-old hardware. Nor will the apps. So what can we do in a robust and forward-looking way?
The answer is not apps. The answer is core services (what programmers mean by services, just to be clear)—building blocks that stand the test of time because they are small enough to be used over and over again in new ways. One example of this is SMS. That service, to send short messages efficiently over a wireless network, was never intended for consumer use. And yet because it was so simple and so widespread (interoperable), billions of dollars of revenue were generated. A whole ecosystem used SMS to drive compelling user experiences over decades.
We need the same kinds of building blocks for the IoE. Durable and useful building blocks that allow an ecosystem to bloom because developers and manufacturers can create experiences knowing that these building blocks are available for their use. And consumers must feel confident that their investments represent sustained value. So any such building blocks need to be openly available and interoperate on many dimensions: across OSes, across fields of use (car/home/office/mobile), across languages—and across all vendors. It can’t be the experience that each smart TV will require another app on every brand of smartphone in order to work. That won’t create an ecosystem. It can’t be that a washing machine can only interact with same-brand devices. That won’t create an ecosystem.
For the IoE to provide consumers with a much more useful and enriching set of experiences as they connect to and interact with Their Things, it needs an open communications framework that allows virtually any product, app, or consumer service to discover, connect, and communicate with other products/apps/services nearby. This protocol must work across major OSes—mobile, embedded, desktop. It must be hardware-agnostic, able to run on products from any manufacturer. It must work across device segments, from low-end embedded devices to the most sophisticated consumer electronics. And it needs a core set of services (configuration, notification, control, etc.) to insure all communication is interoperable regardless of application provider or equipment maker. And it must be secure.
Only when such a common communications framework is in place will a personal Internet of My Things join existing cloud-based service in the IoE. As proximal internets of Individuals Things emerge, IoE will begin to really include. . . Well, nearly Everything.
—Rob Chandhok is the software strategy leader at Qualcomm. He can be reached at @robchandhok
[Image: Flickr user Miuenski Miuenski]