The IoT is Not the 80’s Video Wars

One of the questions I often see in forums, and hear from the floor at conferences, is ‘What will be the standard protocol for the Internet of Things?’, or sometimes the alternative ‘What will be the standard framework/architecture for the Internet of Things?’

Don’t get me wrong, I understand completely why the question is being asked. Those of you old enough to remember the ‘80s will remember the war of the competing video formats – VHS, Betamax and V2000. Many consumers and indeed corporations had their fingers burned by picking the ‘wrong’ standard, and ending up with equipment that had no long term upgrade path, and for which content became increasingly more restricted. I was one of those who guessed ‘wrong’ – I needed a format that would both play and record and, being an engineer, went for the better technical solution, which was BetaMax. The industry adopted VHS – mainly because the political power of the corporations backing this technology was greater than that of those invested in other solutions. Did it really make any difference to me?…. I don’t think so, I enjoyed better quality recordings than mates with VHS, at the cost of ending up with a few unusable pre-recorded movies when I eventually traded up – although by then DVDs were on the horizon and so, effectively, everyone else ended up in the same place as me.

The memory has however lived long within the technology sector, and organizations continue to be reluctant to adopt new technologies until it is clear that they will continue into the future, and what better way is there than to wait for the emergence of an all consuming, universally adopted standard in order to guarantee long term, cross industry support.

Except, of course, in the context of the Internet of Things, it’s nonsense.

The video wars were about one type of device, performing one type of task, in an industry where it served the interests of the all powerful media distribution companies to only have to supply on one format, rather than have to support three. This is a completely different scenario to that facing us with the Internet of Things.

Ask 10 different industry experts to outline a typical IoT system and you will get 10 different answers, covering applications like smart home, connected person, smart city, individualized retail, smart grid, plus the range of industrial IoT use cases aimed at process optimization, predictive analytics etc. It is inconceivable that a single standard can emerge to encompass this diversity, whilst at the same time addressing the vastly differing needs of different applications with regards to security, authentication, data privacy, data storage, system latency and communications cost.

I cycle. I love the fact that I can capture my rides on an App like Strava running on my phone and have all of my key route, speed, heart rate & cadence etc. data captured while I’m out on the road and synchronized back to my computer so that I can analyze my performance development to figure which elements of my training I need to focus on. Better still is the fact that I can share these details with friends so that we compare how we’re all doing and provide mutual support and encouragement – and that I can get summary data from total strangers riding the same routes to see how I’m doing in general. While playing with our Wzzard recipes within IBM Bluemix, I noticed that someone has now contributed a node that will allow me to import my Strava data into Bluemix and thereafter use it within my code. I suppose (if I was nerdy enough) I could therefore get the kettle to turn on when I’m about 5 minutes from home, or have the lights in the house flashing when I come home if I have a new personal best time.

To think however that this application has much in common, other than at the highest conceptual level with, for example, a system controlling an oil and gas pipeline is just wrong, and therefore to think that a single standard could address both types of system requirement is equally flawed. Again, don’t get me wrong- standards are a good thing (some would add that the good thing is that there are so many to choose from), but to have a single standard would mean that it had to be so wide reaching it would, in effect, be meaningless. Instead, it seems to me that the model is more likely to be, as has been the case in the past with previous technologies, the emergence of a relatively small number of predominant standards, with a variety of niche standards applying to specialist use cases or industries.

History in this area has much to teach us. Think about SCADA protocol standards. There still remain a plethora of proprietary standards in the industry, but slowly Modbus, DNP3 and IEC60870 have emerged as the most common open standards. Smart instrumentation went through DE, HART, Profibus, Foundation Fieldbus, LON and many others. What seems to happen is that a small number of suppliers, end users and systems integrators get together to define a standard which will make life easier for everyone. As these bodies start work, more cynically when they start to look like they are getting to something useful, other companies join the standard body, each wanting to protect its existing markets and IPR or to make sure that its use case is covered. The standards committee descends into continuous infighting up until either some newer better technology emerges, or a subgroup jump off of the process and decide to use the ‘then current’ version of the standard with some of the more niche or extreme parts removed – this almost invariably then becomes ‘the’ standard.

Do I want standards for the Internet of Things – of course, but I don’t want to have to wait for ten years until I know which ones are going to emerge as the predominant ones. That’s why we’ve designed our Swarm architecture in a way which makes it very easy to slot in different components to address different standards requirements, whatever they turn out to be. This means we can start bringing applications to market now and adapt as standards emerge. If two verticals end up adopting different security standards, or different IoT protocols, we will be able to slot in appropriate modules for each but retain the integrity of the rest of the architecture, and still have the benefits of cross vertical application layers.

It seems to me that this is just sensible engineering practice given the history of how standards have emerged over the years in the technology industry. Sadly, I fear that the IoT standards process will not be any different to others in the past, and so the trick is not to bet on one, or even spread bet on a number of them – the trick is to move ahead now, selecting solutions which can adapt in the future as the winners emerge.