If you are looking to embrace the internet of things (IOT) and connect your products, devices or equipment to the internet then there are a whole host of things that you need to consider first.
Know where the value is in connecting to the internet of things.
It's all well and good jumping on the trend of being connected, however you should be crystal clear about what the benefits are to the end user. For example: Will it save them time or effort? Or is there real value in allowing them to controlling things remotely?
What do you want to monitor or control?
To make something part of the internet of things you will need to extend it by building in hardware or software that reads from or controls the device. This will require extra components to be added with circuitry that measures how things are functioning and to control the device. The more functions you choose to support in your IOT device, the more extension that may been needed to your product. All of this can have an impact on your cost of manufacture.
Consider the market and the competition.
If you are unsure about whether to embrace the internet of things with your product line then we would recommend you look at the value of the marketplace and the risk of your competition doing it first. For example research reviewed in our internet of things paper (below) shows that the global IOT opportunity is expected to be $19 trillion over the next 10 years.
Have a reset process.
If something fails then you should have some way to reset it to its default setting. This process should be easy enough to do if you are near the device but hard enough that it doesn't happen accidentally.
Consider the connection hardware.
Are you going to connect your device using WIFI or over the mobile networks (e.g 3/4/5G)? WIFI is generally cheaper though it will limit versatility as the device will always need to be within a certain range of a WIFI hot spot.
Rethink your revenue model.
It depends on how you plan to implement your internet connected device (e.g WIFI v.s. 4G), however your cost of sale and recurring business costs may change meaning that you also need to rethink your revenue model. Many IOT services take a "software as a service" approach to their revenue model by charging on a monthly basis. Depending on your product / service this may or may not be something that your client base is willing to do right away, especially if you are building connectivity into a product type that has been around for a long time without it. Due to this it is common for vendors to put in place a "freemium" service where users get a basic level of access for free but have to pay monthly premium features.
How will you handle updating firmware
IOT devices need hardware and software to read and control them, this means firmware / software. Make sure that you have some process of updating this should an issue be found with it after launch. You will need to consider whether updates have to be done by you (and the product be sent off to HQ), by a technical process the user handles (e.g. via USB connection to a computer), or remotely via a web service (e.g. you trigger the update by logging into your web portal).
Think about where the device will be used.
Many build considerations can arise out of the location that the device will sit. For example if you know it will always be close to a person then you can look to develop a mobile application to support the internet connectivity requirements. However, if your IOT device is to sit in the middle of a remote location then you may need to operate over the mobile networks.
There are also trade-offs with regard to whether the processing of information or functionality happens on or off the device. With the above example where the device is near a person at all times you can have a very lean logic layer sitting on the device and keep leave most of the functionality to be handled via a mobile app. On the other hand if the device is in a remote location then it is much more likely that you will need to drive functionality through hardware and software that is connected directly to the device at all times.
Be aware of the standards
As with anything tech related there are IEEE standards around the internet of things. Make sure you are aware of them before you get started.
Global location matters too.
Global data costs vary greatly. If you are planning to have your product or device sending a lot of data then you will need to consider the implications of that, especially if you are looking to roll it out globally.
Calculate average uptime.
The internet isn't always reliable and you should remember this when developing and selling your service. It may not be possible to deliver a completely real-time system and you should plan for what happens if some messages between your product and the web service monitoring were to go missing. The implications of this should filter right through the business from your sales process through to your terms and conditions.
Have an offline mode.
Don't rely entirely on the internet and have some other means of controlling or accessing your product should there be no connection. You may choose to do this by having buttons and controls on the device, or by allowing a mobile app to communicate with it over Bluetooth, WIFI or cable.
Plan for recurring costs.
Part of connecting a device to the internet is to enable the ability to monitor it from a remote location. To achieve this you will introduce recurring costs associated with server, infrastructure and maintenance.
Think about transmission security.
If you have a device transmitting data then what is to stop someone clever from intercepting those messages and reading them? You should make sure that communications between your hardware and web service are properly encrypted (e.g. TLS/SSL).
Hardware capability vs cost.
The storage and processing power of your hardware will have an impact on its unit cost. You can keep costs lower by going for lower power hardware but this may come at a cost in terms of capability. For example some encryption technologies may not be possible on lower powered hardware and you may need to make compromises to combat this.
Back up your 'Internet of Everything' data.
This point applies to any product or service that collects data: Back it up regularly! If your whole value offering hinges around your customer base having access to accurate historic data then they may not be too happy if they log on to access it and find that everything has been deleted.
Have a backup retention policy.
As time passes your user base will increase and you will be storing more data. You should work out how much this is likely to be and decide if you should set a reasonable expiration date. For example some information may not be as valuable after a year or two so it may be worthwhile deleting older data or archiving it to a cheaper storage location (e.g. Amazon's Glacier web service). Alternatively you may decide that all data is valuable and you should retain as much as you can for as long as you can. Either way there is a cost benefit trade-off.
Put a value on each minute of data.
Could you afford to lose a weeks' worth of data? What about an hour? Or maybe a minute? If you can't afford to lose an hour of data then you should at least have a backup process that runs every hour. You may also want to mirror some incoming or calculated data across multiple silo servers so that it is backed up the second it is created.
Do you need GPS capabilities?
You can track the location of your products by building in a GPS unit. This can be particularly useful if you want to show data on a map.
Is it worth creating an API?
An API (Application Interface) is a way for other people / companies to write software and systems that directly communicate with your internet connected service. You could allow your clients to automatically read data from your web service and use it how they see fit. This can be particularly useful for enterprise customers and can be a great additional value offering as it enables more mature topics such as automation. You could also provide access to your API as a premium service offering.
Have an update strategy.
If you change the way your device works then you may need to update the software that connects it to the web. If the content of the messages changes then you will need to account for this on both the device and the web service. This can become problematic if you have lots of different devices running different firmware versions if you need an approach that supports backwards compatibility.
User experience matters.
It goes without saying that things should be as plug-and-play as possible, though usability extends beyond the product itself with Internet of Things services.
It is likely that you will want to provide access to your internet connected device via a login portal on your website so make sure that the user interface of the portal is friendly an intuitive. Ideally users should be able to figure out what they are doing by playing around rather than having to read a manual.
Make things fool proof.
Think about a child switching an old lightbulb on and off repeatedly, and some point it is going to blow. Put in checks and balances that prevent users from accidentally breaking your product or destroying data on your web service. For example you may limit the amount of request they can send to a device or put restrictions on what they are able to control remotely.
What else?
Have you found this list useful? if so why not download our eGuide on exploiting the internet of things:
Or, if you would like professional advice on anything discussed here then please don't hesitate to contact us.
