Epilogue

As I begin to write the final chapter of the book, I am experiencing mixed feelings – satisfaction about this book soon hitting the stands and anxiety about whether it will reach its intended audience. As we wrap up this book, the most obvious way forward in this chapter was to summarize the key points of what has been covered. However, as this might have limited benefit for you, I ultimately decided to jot down the key takeaways I have gathered while working on IoT solutions and projects for nearly a decade. Providing practical tips drawn from actual project experiences will also help to balance the relative abstractness of a few of the prior chapters. Accordingly, this chapter lists a few nuggets of knowledge that might help you to avoid common pitfalls or mistakes in IoT implementation.

Most of the software engineering principles and best practices that ensure the successful completion of a project are applicable to IoT projects as well. However, IoT solutions...

Project implementation considerations

The points listed in this section may appear to be more relevant to a project/program manager; however, they would be useful for architects as well, since architects are expected to remain part of the implementation team even after the completion of the architecture. The expectation stems from the fact that the architect bears the responsibility of ensuring that the implementation is always aligned with the approved architecture. So, the following project management/implementation considerations for IoT projects would benefit people belonging to technical and project management roles:

• Component procurement considerations: Field devices (sensors, gateways, and actuators) and components providing connectivity (such as SIM cards) form a key part of any IoT solution, and the timely procurement of these components is crucial. However, the procurement and deployment of these third-party components pose a challenge, as multiple parties (such as...

Lessons learned from IoT projects

There are a few lessons that I’ve learned from my experience of working in the IoT domain. Keeping in mind the list of miscellaneous points mentioned in this section may help you avoid unnecessary hassles/issues. The list of the key lessons (in no particular order) is as follows:

• Scoping a project with unclear objectives or an unclear end state: There are cases where the scope of the IoT solution is clearly defined and there is clarity on the overall business objective. However, there are other scenarios where practitioners struggle to find the right-fit or optimum solution for the stated business problem. A limited-scope proof of concept (PoC) or pilot is typically executed to reduce the ambiguity and number of unknowns. As the budget for the PoC/pilot is limited, there is a need to optimize scope/cost but still obtain crucial inputs that can help to move in the right direction.

In addition to technical/architectural skills,...

NFR considerations

Most of the previous chapters focused on implementing functional requirements; however, NFRs (especially the ones that are related to the solution’s efficiency or performance) are equally important. Not giving required importance or priority to non-functional aspects (such as battery life, data transfer latency, and compatibility with different connectivity providers) can adversely impact the customer’s experience, jeopardizing the realization of business objectives.

All the components of the IoT system should be optimized individually to provide overall (end-to-end) efficiency; however, performance expectations are generally more stringent for field devices than for central servers (for example, frequent replacement of batteries in remote or large geographical areas is difficult from a cost as well as an operational standpoint). Accordingly, some of the key NFRs that should be considered while conceptualizing/developing IoT solutions are listed...

IoT connectivity protocols

When finalizing the architecture for IoT solutions, there are multiple protocol options (at each layer of the network/connectivity stack) to choose from, as shown in the following figure:

Figure 13.4 – IoT connectivity protocols mapped to different layers of the networking stack

Important note

The preceding figure provides a representative list of commonly used protocols and in no way should be considered an exhaustive listing.

The multiplicity of connectivity protocols at each layer does result in some amount of ambiguity or perplexity. However, this diverse set of protocols also provides us with a certain degree of flexibility in choosing the protocol that best matches the specific solution requirements such as bandwidth available, allowed range, power consumption, and so on. In general, protocols at each layer can be distinguished based on one or more of the following listed parameters:

• Number of Quality-of...

Summary

In this final chapter, we covered practical issues and challenges that are typically encountered while implementing IoT solutions/use cases. It listed key lessons learned from my past IoT projects. Specific references were made to two frameworks (Bain’s and Porter’s) as these can help to gauge as well as articulate the benefits/value of the envisaged IoT solution(s). It also listed the key NFRs and emphasized the importance of focusing on them during the complete project life cycle and covered two examples (power and cost optimization) in detail. Finally, it provided a representative list of IoT connectivity protocols, along with the scenarios in which they are most appropriate.

The IoT ecosystem, in general, is very dynamic, new techniques/technologies are continuously being discovered, and existing ones getting refined/evolved. Going forward, the trend is expected to continue with advancements expected at all layers of the IoT reference architecture. Some...