Video
Introduction
Hello, it’s LMtx. Today I would like to talk about the PoC design checklist.
The PoC (Proof of Concept) is used to verify assumptions regarding the business value provided by a new solution.
We should focus on the business value, not the technical details of the future initiative. It is very common that people dive deep into technical feasibility and forget about the required business outcome.
Let’s say that we avoided that trap and clearly defined the business goals.
On the PoC stage, we typically work with very limited resources (time and money). That is why we need to decide which functionalities should be excluded from the PoC scope.
I saw many initiatives that failed because they were too successful at the very beginning.
It typically looks like this:
- no one knows the exact capabilities of a new IoT device developed by the R&D department,
- business owner asks for a short and cheap PoC to check the potential business outcome provided by that device,
- during the PoC only a few devices are used, so no one cares about automation and security stuff (we will handle that at a later stage),
- PoC is successful, new IoT device generates insights that can be monetized,
- business owner demands to deploy hundreds of devices in a month (why not if the PoC was so successful)
- launched product is insecure, very hard to manage, and can not scale to the required number of devices.
Can we avoid this kind of scenario?
Here is my personal checklist of functionalities that should be included in the design of a PoC solution.
I am not saying that all of them need to be implemented during the PoC stage. They should be designed so developers can easily add them at a later stage.
Automation
Automation is crucial to manage and scale the IoT deployment.
You should automate:
- backend/cloud infrastructure deployment,
- IoT device provisioning,
- credentials management.
The initial solution does not have to be perfect end-to-end, state-of-the-art automation. During the PoC, you should create the overall framework for automation. It should be designed in a way that allows for easy extension in the future.
It is perfectly fine to start with a simple solution like BASH scripts and a few manual steps. At later stages of this initiative, you will improve the automation framework piece by piece (according to the high-level design created during the PoC).
Monitoring and Alerting
Monitoring and alerting are frequently ignored when you work with just a few devices during the PoC stage. Developers check the low-level debug logs to investigate spotted issues.
Once you have the connectivity issues resolved, you should invest some time into monitoring and alerting development. This initial investment will save you tons of time in the future.
I suggest monitoring the following cases:
- dropped connections,
- authorization issues,
- timeouts,
- device measurements out of expected range or type.
The biggest risk is that the above issues might not appear during the initial connectivity verification. Once you start to work on your business logic, you might realize that gathered data does not contain expected values. This might happen at a later stage of PoC and put the overall timeline at risk.
Basic monitoring and alerting solution should detect these kinds of issues. They can be fixed before you start the development of a business application.
During the PoC, design the monitoring framework that will be extended at later stages of your initiative.
Credentials management
That is very common that security is not a priority at the PoC stage. Why should we protect a system used only by internal users?
In the reality, it is very hard to add security “on top of” the existing system. You can try to close some gaps, but usually, that is not a very effective approach.
The IoT solution should be secure by design. Using the least privileges approach and unique credentials for every device is absolutely crucial.
There is not a good way to handle a security incident when you use the same credentials for every IoT device and someone compromise one of them.
Avoid hardcoded passwords and use certificates as a proof of identity for your devices.
Design the certificate rotation process. It does not have to be fully automated during the PoC stage, but your design should allow for that in the future.
Summary
By no means this is a complete list of requirements for an IoT initiative, but I hope that it presents the most important areas you should cover.
Once again - the PoC goal is to focus on the business outcome, not on the technical details. Keeping this short list during the PoC design should help you build a solution that can be easily scaled (in case your initiative happens to be more successful than expected).
Let me know what points would you add to this list.
