Mind the Gap Part 1: Device and Software Management

Mind the gap

This is the first in a series of articles focusing on the shortfalls in the initial M2M / IoT product offerings. We’ve titled the series “Mind the M2M Gap” after the iconic signs in the UK warning to rail passengers to take caution and not step in the gap, between the platform and the train. The gaps here are the differences in the features in M2M/IoT solutions on the market today, and the features one expects in more mature industrial solution offerings.

Device and Software Management

M2M/IoT solution providers have one primary objective in common; that is get products & services to market and generate revenue…ASAP.  All the development energies are focused on form and function. That’s understandable of course, but to realize mainstream adoption, solutions must be scalable, secure, and manageable. This protocol landscape diagram[1] does a good job illustrating the transport / protocol / application hierarchy, and it correctly shows Device Management at the same level as analytics and business intelligence functions. Additionally, security and privacy functions transverses all layers.


What does it mean to be scalable, secure, and manageable?

The alternative to having manageable devices is to have smart people (i.e. expensive) dedicated to the deployment, care, and feeding of any given solution; that is if it can be done at all.


Using a broad definition, most solutions marketed today are scalable; meaning that there are no limits to how many devices you can deploy.  However, “real life” scalable also implies that provisioning occurs from a central authority; preferably automatically when the device is removed from its shipping container. Provisioning includes the setting of operational variables, verification of firmware & software settings, and network address variables.  The ONLY way for a large population of devices to be uniform and supportable is if these functions occur with a bare minimum of human interaction.  This needs to apply to equipment swaps after device failure as well.


The Internet is not secure so there is no reason to think the Internet of Things will be secure. Kaspersky Lab published an interesting blog post called the “Internet of Crappy Things“. The title says it all. It’s advantageous wherever possible to keep the devices on the outside of your enterprise firewall, bringing the data in through well established secure connection methods. There are obvious reoccurring costs to this, but letting the cellular carriers and data hosting services worry about network security has value.

There are numerous examples however, that the devices will be directly connected to your enterprise network. An example of this is RFID readers (discussed in our RFID-as-IoT whitepaper), and it’s reasonable to expect that there will be compelling business reasons for the number of devices to grow. Security variables must be managed and part of the provisioning process whether the devices are connected wirelessly or wired.  Even if the device capabilities limit the security schema, if every device has to be configured individually – you’re doomed.



You’ve probably noticed a reoccurring theme in this paper; if devices have to be touched by personnel and made unique to perform their function, the honest cost burden associated with the effort will trash even the most compelling ROI expectations. These costs are directly proportional to the population size of the deployment.  A manageable system must minimally include:

  • Management Reports
    • What devices are failing
    • What devices are missing
  • Configuration Management
    • The ability to push configuration changes across a population to assure that all configurations are uniform
  • Asset Management
    • What do you have and where is it at
  • Software Management
    • Assure that all devices running the current firmware and software versions
  • User Management
    • What users have what permissions to change system variables

A look into the crystal ball

For the foreseeable future, device management features and functions will come from each individual M2M / IoT solution provider, and they’ll be proprietary (i.e. no interoperability with more mature network management platforms).  And they’ll only develop these functions as they are forced to by their customers.

There are eerie similarities to the evolution of handheld computers from the mid 1980’s through today; the manufactures had to deliver these functions if they hoped to sell tens of thousands of devices to retail and manufacturing giants. As operating systems standardized driven by a tsunami of Smartphone commercial grade products came to market, 3rd party device management platforms emerged. Some are still vertical market focused like Wavelink, and other BYOD (Bring Your Own Device) like AirWatch have incorporated extensions to support mobile devices.  M2M / IoT devices will follow a similar path, but the solutions providers will be dragged along kicking and screaming; it’s the price of admission for mainstream adoption.




[1] Antony Passemard, Amazon Web Services

Share this post


Sign up for our Newsletter

Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit