Protocol Standardization, aka Internet of Things Red Herring
Which protocol should the IoT standardize on?
MQTT, that is the way! Nyet, must use XMPP! Away with you sir, COAP is it! Step off, IPv6 is the one ring to rule them all! Excuse me sonny, but websockets are tried and true! Ok, ok strange character voices debating in my head aside, the question is a legitimate one, but I think the answer is really quite simple: ALL OF THEM.
That answer might send you to another browser window so you can grab a URL to a dictionary site then send me a link to the meaning of the word “standardization”. However, I think there is a slightly different way to look at it. First off, let me ask you a question. What is the standard used to transfer a file? Answer is there isn’t one. People use HTTP, HTTPS and FTP to transfer files all the time. It’s strange but I don’t hear a chorus of people screaming for a standardize file transfer protocol.
This is because of two reasons. First, the technology abstracts the use of these protocols from the user. You open your browser and click on a link to download the file or drop it into a file sync program like Cubby, Box, Dropbox and it just replicates the file. The program has handled it for you and you not only don’t care which protocol is being used, you don’t HAVE to care. Secondly, it serves a higher purpose. In the file sync example, the first order principle of the system is to share information through files, not just transfer files for the sake of moving bits.
This is the same thing with connected solutions on the Internet of Things. The first order principle is the connected solution itself and the technology is subservient to that principle. Each protocol has its pluses and minuses but at the end of it all the Connected Lab freezer serving a researcher with enzymes to help accelerate his DNA experiments for the good of humankind doesn’t care if you use MQTT, XMPP or anything else. They just need the refrigerator to unlock at the right time so he can get his supplies while the company that provides the freezer wants to make sure they get the usage and consumption information for billing and future marketing purposes. Not only does the connected freezer system abstract the protocol from the user, it also serves the first order principle that is the multidimensional business case.
Beyond these examples, the IoT/E needs to embrace the “open” philosophy. That means supporting multiple embedded platforms, gateways, and third-party services being joined together through a myriad of connecting protocols to create solutions that are exponentially better than the sum of their parts. No one protocol standard will dictate how a TI chipset is integrated with an iOS based application and Salesforce.com for sales tracking nor should it.
Now to be clear, we are dealing with the realities of the market today and how we see it evolving. Yes there will be a point in the future where these stove pipes of solutions will need to interconnect with other solutions, devices, objects, etc. in a more web like manner to create solutions greater than the sum of their parts. However, since we can’t wave a magic wand and make a standard protocol everyone will use today nor once we do could we retrofit the billions of devices that will be running heterogeneous stacks. So the industry will have to come together to develop protocols based on requirements we learn over time that will interconnect these solutions either at the gateway and/or cloud levels. However, if the evolution of the Internet itself is any indication of a timeline for the network effect that interconnection provides to evolve, then something as comparably large as IoT/E/Services/FOO will require the same 30 or so years to mature as well. In the meantime, the industry is going to keep building connected solutions using what works best for that solution at that point in time.
We’re excited to play a big part in how the future will shake out, but for now, the protocol Agnostics will be best positioned to serve the real first order driver of IoT adoption that is the functional use case.