Takeaways for a Successful IoT Project

Ever wondered how to tackle an IoT project that you need to start from scratch? Felt overwhelmed by extremely detailed how-to guides on the internet or glowing (possibly sponsored) technology recommendations for just part of your problem statement? IoT projects can grow in scale and complexity much quicker than you would expect.

Whether your IoT project is a proof of concept, a check of a certain value proposition, or even a full-fledged pilot with multiple customers involved, you will find some guidelines in this article, where we will put you in the reins of your IoT project and give you the handles to wrestle this beast to the ground. We will go into some detail on differences between the different IoT projects and concepts. We will share with you some insights, aptitudes, and attitudes to bring your IoT project to a successful outcome as well as sharing some of our learnings we picked up along the way! 

Both authors work for Signify Research and have a combined experience of 20 years working in the information technology sector, where we have been running different sorts of IoT projects for various customers. 

After all, we can only learn from each other by sharing! 

Definitions

In this article, we presume that you have some grasp on IoT terminology. For a quick refresher, we will shortly reprise on certain basic concepts.

Client device, sometimes referred to as edge device. This is often a relatively cheap means to collect data (sensor readings most commonly). These client devices come in a wide variety of types, from bare metal devices which have no operating system, to a more complex miniaturized computer which can run higher levels of functionality, process information on the spot, and have an operating system.

Back-end services. This is the workhorse of any IoT system and it can be hosted in the cloud or on-premise. It offers you a wide variety of services and capabilities that allow you to collect data from your clients’ devices, store it, and process it. It can also host your front-end applications so that users can connect to it as well as take care of user and access management. For the sake of convenience, we assume for the rest of the article that your back-end is a cloud implementation, but the same feature richness can be achieved with on-premise hardware and software implementations.

Front-end services, sometimes referred to as dashboard or visualization application. This is where you interact with the data, create views into the collected data after processing, and correlate it in such a form that the end-user/customer is presented with insights or value. Application logic and human to computer interactions take place here.

Now, what is exactly an IoT Proof of Concept and an IoT Pilot? What are some of the distinctions we have come across? 

A IoT Proof of Concept (PoC) is where you try to validate clearly and quickly, with as little effort as possible, if a value proposition is valuable and feasible. Often, these PoCs can be piggybacked on top of existing products or parts of those products, or any other convenient material you have at your disposal. Usually, there are components that can be repurposed to fit the minimum viable requirements. In a PoC, the requirement of having a customer using your system is not always warranted but often it is recommended. Technical flexibility is very important in these kinds of projects because of progressing insights as you are working through your PoC’s value proposition. 

An IoT Pilot is a small-scale preliminary demonstration of a PoC that can potentially scale up to a production system. A pilot can be viewed as an echo of a full-fledged product development and can contain all the aspects that relate to this. The entire pilot is standalone, lowering the effort to transfer the pilot into a finalized product; however, when integrating it in the rest of your company’s product ecosystem, the effort is higher. An IoT Pilot will involve a limited and carefully selected number of key customers that are enabled to test out the pilots.

An IoT pilot is an excellent way to validate your use case(s) in a small scale pre-alpha product. Validation of the use case means making sure that your product adds value for the customer, which is also your main hypothesis. Before going through the effort of developing a complete product, it is good practice to ensure the validity of the case hypothesis. Some people might doubt the necessity of a pilot, especially for trivial use cases. This doubt has no binary answer. Deploying a pilot costs time and money, but at the same time can provide the company with reassurance about the value of the soon-to-be product. In our experience, when it comes to IoT use cases, the added value is not always apparent from the get-go. Many times, the value is not initially recognized by the customer until they genuinely experience it first-hand. On the other hand, a use case that might sound fascinating for the customer, might lack tangible value in the real world or perhaps the customer is not willing to pay the price for what the products bring to the table. Lastly, as you are working through the pilot, be open for progressing insights on you proposition, do not be afraid to address the unknown needs of both your customer and your company to maximise on value creation. These might disrupt your initial thoughts.

Context

The scope of the pilots mentioned in this article is broad, including multiple domains like offices, retail, factories, warehouses, but also outdoor. It is of great importance to restrict each pilot’s application to a distinct domain. Take, for instance, an outdoor domain. On one hand, you have a smart city pilot, where devices are installed in the lighting infrastructure of the city. On the other hand, you have a pilot in an office domain, where devices are mounted on the ceiling. Both these domains have a similar general connectivity requirement, yet implementations are likely to be different. Differences are not only limited to the device’s location and its connectivity but the environmental conditions, laws, regulations, etc. also play a role. Therefore, having the context clear for your pilot is very important.

Takeaways

Client/Device

As mentioned earlier, the client device is a hardware platform with one or more sensors and communication means, running its own software. Some of the points of this section might sound trivial but are very important to consider from the beginning of the project since they can create huge overhead later. 

• Logs are like painkillers. It is commonly painful to identify a bug in an end-to-end system that contains multiple components. Having ways to identify bugs in each component is a must and the client is no exception to this rule. Do not be shy on verbosity. This will help you identify bugs faster. Perhaps consider a way to change verbosity levels from your DevOps framework. It is advised to aggregate logs in the device and send them to the cloud for storage. This can enable future log analytics.
• Carefully choose your hardware platform. A well-established platform will ensure that most of the hardware and software issues are resolved and that there is a big community of developers out there that have already faced your challenges. For example, Rasberry Pi, Beagleboard, MangOh, etc.
• When building the client, make sure you adapt the hardware specifications to the pilot environment. For example, if you have a client with a microphone, you cannot install a fan in the box since this will add noise to your audio input. That consequently can significantly increase the temperature of your CPU, which can lead to performance degradation. 
• A physical connection to the client can be your last resort. It is always handy to have a physical connection to the client box, like a serial or USB port. In this way, you can easily connect to a device when all other means are out of the picture and find that painful bug that you are chasing. Of course, a password is needed to ensure security. 
• Choose an operating system over bare metal devices. This can increase development speed and provide you with a variety of tools that will make your life easier. If you are a larger company, this approach is preferred since speed is your main disadvantage. On the other side, smaller companies could consider a bare metal implementation, which can be much closer to the end-product for cost sake. At the same time, speed will not be significantly affected since start-ups seem to be fast by nature. It is important, though, to carefully estimate the complexity of the application since for rather complex applications an OS will be mandatory. 
• Carefully choose the client’s software programming language. Higher-level languages like Java or Python can provide two main benefits: speed of development and platform independence. On the negative side, higher-level languages will have a much lower innate performance. Consequently, if you are opting for a relatively expensive hardware platform like a Raspberry Pi, then opt for a higher-level language. 

Back-End Infrastructure 

Back-end infrastructure is the part of the IoT system that is not directly accessed by the end user and it acts as the heart of the system. Consequently, it is important to design it carefully.

• Minimize complexity by sticking to the Minimum Valuable Product (MVP). Follow a minimalistic approach. The risk of increased costs is significantly present when building a back-end infrastructure using cloud services. 
• Do not reinvent the wheel. Cloud providers offer out-of-the-box services (SAAS) that will most likely fit your requirements. Sometimes, open-source initiatives can also help you speed up.
• Use infrastructure as a code. Some of the key benefits are consistency, less configuration drift, remove human errors, lower costs, and faster development cycles. Examples of infrastructure as a code are Terraform, AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager, etc. When working in a single cloud environment, we advise using that cloud provider’s proprietary format (e.g. AWS CloudFormation). For hybrid cloud deployments, a universal approach (e.g. Terraform) can be more optimal, as you do not need to know multiple syntaxes. However, you accept a slight delay in feature richness as a cloud provider’s proprietary language is always going to have better support. 
• Be aware of the costs that are involved when using managed cloud services. Not all pricing schemas are equally transparent. For example, in the AWS IoT core, you pay for each MQTT message. However, the maximum size of an MQTT message can be up to 128KB. Even if sending multiple MQTT messages can sound attractive and straight-forward, it’s better to aggregate values and minimize the number of messages being sent. 
• Try not to write monolithic applications in the cloud, like deploying a Docker image in a server that does “everything.” Try to build up component layers properly to increase code reusability, transparency, and readability, in turn decreasing complexity by separation of duty and clear, extensible interface definition. This can help you in scaling up or down when needed. In the end, it will be easier to pinpoint bugs. 
• In the pilot phase use, distinct environments for development, staging, and production to deploy and test releases so that they live up to the quality your software and hardware should uphold for the customer.

Use Case Under Test

The main goal of every pilot is to verify if a certain use case or technology brings the expected added value to the customer. While most of the hard work will go into developing the technology around the pilot, it is of vital importance to know what and why you are building something. In this way, you will avoid surprises in the end of your journey.

• Interpret the customers’ needs. Try to have a clear view on the end user requirements. Often, it’s difficult to get clean and distinct requirements from customers since they also might not know their needs. Try to understand their needs. Having iterative feedback loops with your end-users and stakeholders will make your life easier. Do not wait until deployment day to get feedback from your customer. 
• Do not add unnecessary complexity to the use case. Refine your use case just enough to comply with customer requirements. Do not implement ideas that are not necessary and add complexity to the system. Constantly ask yourself if you are adding value for the customer or the use case validation or just because the customer asked you to do something. A common pitfall is that you can easily get distracted by customer problems you did not intend to solve and are out of your scope. 
• Time is critical. Try to be done as fast as possible with the minimal amount of effort. If the development cycles take too long, value might be lost because of competitors entering the market before you. 
• For large companies, it is important to make the dependencies transparent between various departments, e.g. legal and development. Moreover, is a good practice to define roles and responsibilities from the beginning of the project. 
• Make a conscious decision regarding how generic your solution should be. Are you planning to execute multiple pilots for multiple use cases, then it is wise to invest time and money in building a generic hardware and software end-to-end infrastructure that can host various use cases without the need to rebuild everything from scratch. 

Privacy and Security

Privacy and security are topics of high interest. But in order to increase development speed, many projects do not spend enough time on privacy and security issues, which will lead to big delays, dead ends, or even liability.

• Be aware of the local regulations and laws regarding data collection & privacy. Laws may vary from country to country. Consider audio data, for instance It might be ok to collect sound pressure values, but not to actually record the audio. To successfully handle these situations, involve the legal department or an external expert. 
• Where do you store your data? Some countries require data to be stored within its borders. 
• How long can you store the data? Some countries or regions have different regulations.
• Do not gather personal identification data if you are not allowed to. To gather this kind of data, you need user and legal consent. Take, for example, the 2015 AVG privacy scandal. 
• Working with governments or local authorities is proven to be much more difficult than working with companies. Usually, the public sector is bound with lengthy processes and multiple laws and regulations that will probably lead to big delays. On top of that, having a pilot for country A does not mean you can execute the same pilot in country B. 
• Get clarity on the ethical consequences. Some technologies can grant you insights in private personal data. It is your responsibility to treat this data responsibly and inform the user about the data usage. 
• It is good to be aware of your own regulations. Usually, multinationals have certain processes in place to ensure privacy and security of users. 
• When it comes to security, follow the principle of least privilege. This principle means giving a user account or process only those privileges which are essential to perform its intended function. Consider the following actions: 
  1. Clients need a password for terminal access. 
  2. Preferably, clients should have a VPN connection so that SSH tunneling is transparent from the underlying network topology.  
  3. Encryption and authentication are required between the communication of client, cloud, and other parts of the system.
  4. Limit the number of users that can have access to the system. Always ask people that need access why they need it. Always provide them with the minimum possible permissions.

Deployment Framework and DevOps

DevOps is an important aspect for pilots. Pay attention to the following points.

• Have control of the entire process from building to shipping hardware and software. This helps your developers feel empowered in solving bugs and releasing features rather than depending on a different team to do that. 
• Make sure that you have fallback mechanisms in place in case the newly shipped software that you have downloaded on devices does not work. Devices should be able to revert to the previous software version. 
• Proper use of version control of all the code is a given. We recommend having a build and deployment process defined (continuous integration (CI)/continuous deployment (CD)), but keep it flexible, modular, and convenient so that it is not to become a hurdle during your PoC or pilot phase.
• Automating unit tests and integration tests is a must when starting any IoT project. This will enable you to feel more confident about the features delivered, e.g. Jenkins, Octopus, TeamCity, Microsoft Team Foundation Server, Ansible, etc.
• Ensure that you have a way to remotely reboot devices, all together or a group of them. For example, for a smart city pilot using 4G connection, SMS can be a good alternative way to reboot remotely devices. 
• Installing your devices behind an external network can create problems. External networks might have different firewall rules than your testing network environment. If you deploy an IoT pilot in a company building (e.g. offices, retail, factories), you need to follow their network regulations. Make sure you have all the information needed upfront. A good practice is to install one device early in the process as a test. 
• Make sure you can refer to an individual, a group, or all devices from your deployment framework. You should be able to do basic operations like start, stop, restart, reboot, or grep loggings. 
• Ideally, have a health monitor application indicating the status of each device. For example, you can conclude about the health of a device by tracking the periodical sensor messages that are sent to the back-end. 
• Another good practice is to build alarms, for example, alarms in the cloud that indicate the amount of errors in a certain cloud service.
• A very important point is to have a test environment within the premise of your company. Have a set of devices, preferably more than one, that always runs with the latest software. In this way, you can identify bugs and errors. Even better, maintain one device in the final pilot destination to observe differences between your company environment and your pilot environment. As mentioned in the back-end infrastructure section, is a good practice to have distinct development, staging, and production environments. 
• Make your software modular. In this way, each software component should have a separate release. Keep track of different release versions and ensure that proper documentation is in place. 
• Ensure that each software component can be shipped on its own. For instance, a device might have an OS image and one or more different software modules running on it. Make sure you can upgrade one of these components without having to update the whole image. It takes less time, and the risk of causing issues is limited to the component itself.

Miscellaneous 

In this section, we have gathered various attention points that do not fit the other sections. 

• Try to make a rough initial prognosis and keep tracking costs. 
• Be very clear on the licenses you are using when importing libraries. There are tools on the market to help you get visibility on these. As it could happen, one of the underlying licenses in use might just put your entire project at risk when starting your IoT pilot (e.g. Whitesource, GitLab, JFrog Xray, etc.).
• Some teams prefer dividing stories in device, back-end, and front-end categories. We believe that end-to-end feature stories can help share knowledge in the team and increase the overall performance when it comes to identifying bugs. 
• Agile methodology is highly advised for IoT pilots and PoC development. 
• Documentation of devices is important. Label each device with a distinct name by literally sticking a label on the physical device. An idea for a distinct device name could be the CPU id. Sometimes, it helps to also use a more readable distinct name. Keep a list of each device and what sensors or hardware they have so that you can easily identify the capabilities of each device. 

Conclusion

This article has the intention to address the attention points for IoT pilots. Some of the takeaway points might seem straightforward, but we hope that others prove to be useful insights. You can use this article as a checklist for your future IoT pilot, considering your project scope. Do not try to follow all the takeaway points of this article — only those that are suited for your own IoT pilot environment. 

Acknowledgements

Rian P.N. Wouters, Raj Derasari, Bram Hoefnagel