Avoid custom code where possible and don’t get locked into a custom coded app.
Coding for IoT is not for the faint of heart. It takes quite an effort unless you are able to find a platform that lets you concentrate on your business needs without having to worry about concerns such as the following:
- Building a team with the diverse and specific skills you require can be difficult and expensive. A platform should allow you to do custom scripting leveraging well-known languages.
- Building an underlying platform on which you can code your business-specific IoT implementation can also present challenges.
Some of the elements that you will need to consider include security, scalability, cloud controls, integration, and protocols. A solution should have all those elements defined and adopted already. They should be an integral part of the toolset to be used through configuration without the need to code. For example, It is unlikely that you will find a platform that lets you avoid custom code or custom scripts altogether. It is important, though, that all non-business related functions are part of the platform and that any business-related custom code or custom script is identifiable through clearly-defined entry/exit points in the platform, with version controls.
Avoid business model lock-in so that you can quickly change your business model.
This topic addresses development from a different point of view. It is related to buying an IoT solution that could accomplish 75% or more of what you want to accomplish. Business rules are typically parametrized functions and features in commercial off-the-shelf (COTS) solutions. You are dependent on whatever inherent flexibility exists in those functions and features already and you have to rely on your vendor’s roadmap for further changes. This leaves you unable to change course quickly. Your solution or IoT platform should isolate “all” business rules and have them available for coding and scripting within the flow of transactions throughout your system.
For example, there is a vibration sensor attached to a pump. The app configuration has a business rule to set an alert elsewhere in the system when vibrations get too high. After too many false alarms, it is determined that a flow sensor has to be attached to the pump as well. Now the business rule only has to set the alarm based on a table of combinations between flow throughput and vibration levels.