Original Source: http://feedproxy.google.com/~r/buildinternet/~3/AwO8myx1V6c/
This morning I found a device that would turn my bed into a giant scale.
It’s a high point for hardware. The rise of crowdfunding and the maker’s movement have helped awesome ideas turn into products you can actually own. We live in the future. Everything is wonderful and nothing is wrong.
Unless you count the islands. Those are a problem.
What are islands? Turns out when great hardware launches constantly, the connected device space becomes an overloaded tech flea market. The devices are all valuable on their own, but most suffer from “Now what…?” moments of integration with other things. No two speak the same language, forcing real world application to be based on which parts are easy to stitch together instead of best. Everything is technically connected, but design isolates the useful parts.
Islands are isolated grids of connected devices — silos in an “Intranet of Things”. They come in four types:
A device connects to a closed grid only. Access is through a proprietary gatekeeper which limits available data and features. Most common for security systems or payment processing devices where the data needs to be accurate.
A device is capable of connecting to anything, but you’ll need to build the bridge first. These devices require technical skills to work with anything outside their product family. Most crowdfunded devices targeting the maker’s culture (i.e. Arduino) launch with “if it has an API, it’ll be fine” DIY mentality. IFTTT has started to attack this particular flavor of device fragmentation with support for smart systems SmartThings and Wemo.
A device generates sensitive data or runs inside private spaces. If these devices were to connect to a public grid, they’d have to stay anonymous. So far IoT has been a homebody, and privacy islands are most common in home automation device grids.
A device connects to a specialty grid with an intentionally limited user base. This island is most common with today’s enterprise IoT platforms, which miss out in the same way an internet for only business websites would.
Islands are not automatically a bad thing. There are plenty of situations (especially with security and privacy) where intentional islands are the right decision. As the IoT space expands, it’s the unintentional islands and fragmentation we need to look out for.
Connected… to what?
Today’s hardware-first approach for the Internet of Things is like having a room full of smart people that refuse to meet each other. Great on paper, independently impressive, but dead silent from the balcony above. “Build it and they will connect” doesn’t work.
A lot of folks talk about “connected devices” and the “Internet of Things” as statements of connectivity. They aren’t. They are statements of context. A device with a Wi-Fi signal and API isn’t necessarily connected the Internet, it’s just accessible. The important part is not the device, it’s what the device connects to.
I’ll repeat that.
The important part of a connected device is not the device. It’s what the device connects to.
The moment you realize this, IoT’s future is no longer about hardware. Hardware is a constantly revolving door of better stuff that makes last year’s thing obsolete. The Internet of Things is a software problem.
Hardware helps software ask better questions
When you start with hardware, software is what makes your hardware work. A hardware focused approach may create great devices, but most fail the “now what” moment of open-ended integration that comes with connectivity. Offering a RESTful API is only the first step. Some try to sidestep this problem by promoting an open source software initiative, but that’s open-sourcing the wrong piece of the equation and most of the responsibility for teaching.
When you start with software, hardware is what helps your software ask better questions. Questions like “How hot is it in here?”, “Who just walked in?”, and “What’s the quietest conference room available?”. All of these examples are answerable only through a combination of software and hardware. What would you app do if it could ask questions about the real world?
Future proofing the device grid
The Internet of Things is a grid, and we’re all responsible for organizing the things we put on it. What’s important is not just the types of things we attach, but how we teach them to communicate. Today one of the popular answers is Bluetooth LE. Last year it was NFC, but years of barcodes, RFID, and QR also carried the torch to today.
The newest spec will always be around the corner. An ecosystem can’t grow on a foundation that needs to be replaced every two years. What won’t change is the translation. The world needs more people building ecosystems and products that celebrate the latest Kickstarter success story instead of panic attacks about differentiating.
Platforms like IFTTT get this. To them, new stuff is an opportunity to build more great tools. Why wouldn’t they want more players? More importantly, IFTTT doesn’t require a monopoly to be successful. It’s part of the pipeline, and can be responsible for all, pieces, or none of specific interactions. Platforms as tools don’t depend on universal usage — just being the best option more often than not. GitHub isn’t the only source control platform folks use, but it’s damn good at the collaborative bits.
We need more onramps
As people realize the connected space is more than Twitter-enabled toasters, more “things” will join the grid. Awesome. The problem now is a lack of structure waiting for them. Something to bridge the islands. There is no good way for the average person to get involved. When’s the last time you visited a site direct via IP address? The IoT needs its version of browsers.
Developers won’t have any problem, but they aren’t always why we build things are they? The early onramp is paved by the folks that get it, but at a certain point you’re joined by people who don’t know how to code. These are the people delighted to build if only they were offered a “hammer”.
Now where’s the toolbox?
Banner image source.