5 steps to a successful IoT Strategy
Define an Technical and Business Strategy for your IoT Projects
Every successful IoT strategy must include two sides of the project, the business side as well as the technical side. Because at the core, IoT is just a collection of physical assets equipped with sensors. These sensors capture data to represent previously defined business values. Yes, it matters what assets and sensors you chose and what protocols will transmit the measured data (Technical side) but at the end of the day the whole project is a business-driven solution.
01. Define - Outcome & Success
Many people are aware of IoT and consider it as the “NEXT BIG THING”. They do not want to miss out on it and profit from all the estimations and growth opportunities they have heard about. They want IoT (whatever IoT is) in their business to be “future proof” and to be prepared for the next stage of Industrialization (Industry 4.0 and beyond).
Unfortunately, there are no shortcuts and work needs to be done prior to harvesting the benefits of IoT. Like with every other project, the very first thing you must do is to define the outcome of the project by answering the most important question:
How does success look like?
By answering this question you define the direction of the whole project and enable a detailed planning of the next steps:
- Where to go?
- Who or what do we need to get there?
- In what time frame?
- What are the milestones on the way?
- What are the KPI’s the project should trigger?
Many people freeze-up when it comes to this type of questions, they are afraid of giving a wrong answer and dance around the decision by delaying it or pushing it onto other members of their team. It is therefore important to keep in mind that the answer you provided today is based on today's knowledge and today’s understanding but might need adjustment tomorrow.
It is the responsibility of every product owner to re-align the product strategy in regular intervals to ensure a successful outcome and a clearly defined path forward.
One more thing, just that we are one the same page, a success definition of “More Money” is not a proper goal. This is one of the outcomes that can be measured at the end but does not help to determine what you and your team should do right now. A project can have financial motives but money alone should never be the focus since there are many ways to achieve this outcome.
02. Connect - Network & Data
Your Network architecture is the second most important aspect you need to define for your IoT strategy. The goal is to have at the end of the day a whole fleet assets & sensors that generate and transmit data over the network into your server/application.
The tricky part is to define here a smart balance between granularity and what is really necessary to have a successful outcome (mast have, should have, could have).
For example, let’s assume your asset transmits the GPS position for tracking. The GPS data by itself has only 6Byte and one would assume we can send a lot and as often as possible, this is unfortunately not the case.
- Depending on what IoT protocol you chose, the payload will be encapsulated in an additional 120 to 500 Bytes of headers, checksums and transmission information. Let’s assume for this example we use an average message of 300 Byte for our project.
6 Byte → 300 Byte
- You also would like to receive the data multiple times a day to increase the accuracy of your asset and track it’s position. Transmitting the position of your asset every 10min over a period of 24h results in 144 Messages and your total data consumption grows 144 times.
300 Byte → 43.200 Byte
- Like most businesses you use a monthly payment cycle and calculate the data consumption over the whole cycle. For an easier calculation we assume a 30 day cycle which increases the transmitted data to 1,296,000 Bytes or 1.296MB
43.200 Byte → 1,296,000 Bytes or 1.296MB
- Our goal is to have at the end of the day a whole fleet of assets and not only one, you must therefore multiply this data one more time considering all your assets. We can take here a benchmark of 100k assets, which is on the lower end of an IoT fleet but very reasonable. This leads us to a total data consumption per cycle of 129,600 MB.
1.296MB → 129.6GB per Month (1.56 TB per Year)
- Last but not least this is just one value “GPS” but you might be also interested in other parameters like, temperature or battery or selfcheck or … . These parameters can be of course transmitted instead of the “GPS” information or in addition to it.
It is therefore important to consider for your network design not only the technical architecture, how everything will connect but also the protocols and what information will be sent. Because at the end of the day you must pay your telecom provider for every MB transmitted and make sure that your server has sufficient storage capacity to manage your fleets data.
03. Automate - Protocol & Communication
The whole IoT market is based on years of industrial automation. This means you will find various protocols which were introduced in the past and have full right to exist as well as modern and more efficient protocols which support modern hardware.
Some IoT protocols limit the amount of data that can be transferred (e.g.: Sigfox: max payload = 12 Byte and 144 Message per day) others do not transmit only the data but also a lot of overhead information e.g.: TR-069 which is often used for assets connected via Broadband.
Protocol overhead is not the only criteria to be considered. Another very important aspect is the payload itself. The LwM2M protocol for example requires a very strict object/data definition which might increase the efforts for the initial implementation but once it is fully configured you will benefit from the extremely high automatisation of existing as well as future data. On the other side is the widely spread MQTT protocol which does provide only subscriber management and everything else (asset management, updates, data definition, automatisation, …) must be developed on top of it.
One thing I highly recommend is NOT to develop your own proprietary protocol. IoT is an industry that requires many players to realise one project.
You need ...
- At least one IoT hardware/asset/sensor manufacturer. Most likely multiple when you plan a 10-year project and future asset replacements.
- A Telco to connect your assets and transmit the data
- An asset management software that can handle your assets data
It is much cheaper to base your IoT strategy on a standardised solution used by the whole IoT industry (like LwM2M) instead of developing your own protocols and forcing everyone to implement your specifications on top of their existing solutions.
Reinventing the wheel Is an expensive undertaking
04. Build - Assets & Logic
Not once in the history of mankind was an IoT or IT project released that worked perfectly from day one and didn’t require any changes nor updates. Sooner or later you will encounter new requirements and changes, for example to transmit information in a different interval (granularity) or to update the assets firmware and software due to security issues.
Even if you plan not to offer these functionality from a Hardware & Software point of view, you must plan for it from a Business point of view. Let’s assume your assets can not be updated over the air and you must manually replace it due to network risks and DDOS attacks. A manual replacement effort of 3 minutes per asset, results in years of work when you consider a fleet of 100,000 assets - not even calculating the travel times to access every asset.
Said that you can’t solve every issue with a software update. Manual intervention is sometimes inevitable and MUST be planned into the lifecycle of every project. This applies in particular for assets that are battery operated. Sooner or later (depends on the assets design and usage) the battery will require to be replaced. Which might be a very timely underacking based not only on the size of your IoT fleet (amount of installed assets) but as well on the lifetime of every asset. When you install 100 assets per day you must be able to replace at least 100 assets per day in the future otherwise you run into the risk that part of your fleet will be offline.
Coming back to the logical software functionality of your asset, it is recommended to use assets that are configurable and can execute a higher level of logic than just measure and transmit data. Considering the previously described GPS data, you actually only need this information when the GPS position changes --> when the asset is moving but not when it is stationary. Being able to configure and install or trigger these types of behaviour on all your assets enables you to operate your fleet more efficiently.
You could for example, reduce the total data consumption (less data transmitted = cheaper + increased lifetime through longer in standby periods) or keep the same amount of transmitted data and increase the number of messages during active hours ( = increased accuracy).
Optimisation like these enable your fleet to adapt to changing circumstances and the possibility to extend the battery lifetime once the battery reaches a critical level.
05. Present - Application & Enrich Data
The final factor for your IoT strategy focuses on the application which manages your whole fleet of connected assets. This application must correspond with all other factors you choose so far.
It must ...
- … enable you to achieve the predefined success from a Technical as well as Business point of view.
- … integrate seamlessly into your network and be able to handle your growing fleet of connected assets or maybe even a multitude of IoT projects.
- … support the chosen IoT protocol and provide automatisation functionality to all your assets
- … give you the possibility to implement your own logic and Business strategy on top of the asset management functions for individual assets as well as groups of assets.
- … present the data in an easily understandable manner - this means providing an overview over the whole fleet as well as the ability to dig deep into the configuration of a one specific asset and/or sensor.
By fulfilling these five must haves, your IoT application will be able to connect all your assets and manage them remotely. But you should not stop here! There are a few more functionalities which are highly recommendable and from whom you will benefit over the runtime of the project.
Your IoT Application should furthermore ...
… work for you. It should inform you by itself about changes in your fleet e.g.: anomalies like battery levels or signal strengths. This could be achieved by
- Monitoring specific parameters
- Generating daily/weekly/monthly reports which provide an overview and comparison over all your assets
- Forward Alarms (Notifications, SMS, E-Mail, …) directly to you about assets that are at a higher risk (based on your own configuration)
- … support more than one IoT protocol and have the capability to extend the existing one. This functionality comes very handily down the track once the project is in operation for some time and the hardware must be replaced or you plan maybe even to switch the future rollout to newer assets with more functionality.
- … northbound and southbound API’s which enable you to access the gathered data through other systems. This could be, for example, a Mobile-App that informs an individual asset owner about the state of the asset installed in her apartment. Or an external system like a CRM (Customer relationship management) that can enrich the collected data and fill the missing gaps → What asset (ID) belongs to what customer?
Another huge benefit from having access to all kinds of API’s are the KPIs which indicate the performance of the application itself and can connect as well to a billing system and automatically generate invoices to your customers.
- … logic and handlers with the ability to run fully independent from the connected assets. This enables your application to monitor and trigger functionality even when an asset handler is not triggered. It gives you, for example, the ability to execute periodic functionalities over your whole data set.
- … virtualisation to be future proof. This is a extremely practical functionality when you must deal with assets that
- come from multiple manufacturers
- are newer - at some point your new assets will become legacy for newer projects
- have different configurations/updates installed on them
- use different Firmware (New/Old)
- us different IoT protocols but require the same logic/behaviour
- have multiple assets installed in one thing. For example, a cooling truck that uses one asset to report the state of the truck itself and another one that reports the state of cooler.
By now you have probably realised (which is also indicated in the graphic on top), it is not possible to develop an IoT strategy by implementing one step after the other. You must consider all aspects at the same time and make sure that they fit with each other.
You might choose an IoT protocol that fulfills all technical requirements but your Business requirements require different data exchange capabilities. Or you use a specific asset but the Application can not automate all the incoming and outgoing data.
It is therefore important to keep in mind what was mentioned at the very beginning of this article, the decision which you make today is based on today's knowledge and today’s understanding but might need adjustment tomorrow.
For questions or comments please use the contact form below contact me directly on LinkedIn.