As an OEM, you offer a specific, unique product application, ranging from tracking the oil pressure on a rig to energy management on industrial plants, from airport surveillance to data-center condition monitoring. However, when it comes to selecting a data-monitoring solution, there is more commonality with your neighbors than you would initially expect, best described with four workflows your data platform should enable.
- Prepare your devices in the factory. You are producing large numbers of devices and distributing them to installers, either directly or via specific distribution channels. Once your devices leave the factory they should include credentials so they can automatically connect to your IoT platform in a secure manner without the ability of anybody tampering with them.
- Plug-and-play for your distributors or installers. Your installer or end-user installs your product anywhere in the world. Once he powers on the device it automatically registers to your IoT platform. Optionally, an installer can add information, such as its location or configuration details.
- End-users register and connect their product. Your end-users download your branded app, register an account and connect their product. The IoT platform warrants that the account has restricted access to only the devices this user owns. Certificates protect the communication between users and your IoT platform as well as between the product and your IoT platform, without anybody outside your team being able to compromise these secure connections.
- You offer remote services and predictive maintenance. Both you, your distributors and your end-users should be able to monitor the data you need for your application. A full blown account-management and identity service should allow you to define the correct roles, (restricted) access, and ability to separate products across (branded) distributors. For predictive maintenance or enhanced services you need ways to process data, set thresholds for alerts or add your specific advanced (and company secret) logic. Building on that, your end-users need a mobile app to monitor their product performance but also as a communication channel for you to push service alerts.
What considerations to take into account?
So what are the considerations for picking a baseline to start your development, and whether to go for the proprietary Platform-as-a-Service (PaaS) route or the fully open-source route? There are three main categories of considerations while choosing: organizational, financial and, of course, functional. We’ll briefly address them and discuss how they influence your choice.
Organizational, transparency on where you are getting yourself into
While extending your product offering and developing your own IoT-platform solution to support it, you want a clear picture in your head of how this needs to be organized and, more importantly, where it will impact your organization in the future. How to organize product management, product development, logistics, or support, both for installers as well as end-users.
Your choice in IoT platform partially is defined by the choice between open source or proprietary. A proprietary solution will restrict you, as you have an inherited dependency on the provider, where open source offers you all freedom to move independent of the provider offering more flexibility to blend a solution into your own workloads. Regardless of your choice, it is critical to have a professional service provider accompanying your choice, one willing willing and knowledgeable to support any organizational requirements you have.
Financial, what are the overall costs to safeguard your business case
Your business case depends on the quality and costs of your IoT platform. Costs relate to the initial development costs as well as ongoing costs for hosting, support and maintenance. Costs of future extensions and implementing a roadmap will remain important and, with a not-fully-paved future, you want to prevent having to start from scratch.
Your choice in IoT platform initially depends on the cost of getting your first product version developed and released. While you are growing a team, your choice should rather be for a concise and user-friendly solution to lower the threshold of taking control, while on the other hand, your choice should be flexible enough to be extended after a successful first launch of your product as well as the establishment of your own in-house team.
Later, during operation, support and maintenance will become critical costs. Open source is transparent—you can decide what to do in-house and where to depend on a professional service or even a community. Note that bare hosting costs are negligible if you are hosting yourself with the larger data centers. For proprietary solutions, hosting costs are, in most cases, only a way to partially cover support costs and ongoing development.
Functional or technological, does it cover my current and future requirements
When discussing functional requirements, the focus tends to be on technical requirements, rather than functional requirements fitting your use cases and workflows. Things like flexibility and usability across workflows (as described earlier) are easily underestimated.
So first look at whether and how your choice—open source or proprietary—matches with the workflows you need. The other consideration here is the flexibility toward future needs: flexibility to adjust or add new features, scalability and data privacy and software security. Regarding features and scalability, with proprietary solutions you depend a bit more on whatever functionality the platform of choice offers, while open source offers you more freedom as you can always decide to add it yourself, with professional support or your own team.
On security there are two camps and the choice is yours. Large proprietary solutions have much to lose in failing to address security and data-privacy requirements at the highest quality levels. However, it is not a guarantee, just remember Cambridge Analytica…fully open-source solutions are fully transparent, including to those with bad intentions. However, due to community involvement, they have also proven to be more responsive in reacting to and fixing discovered vulnerabilities.
By Pierre Kil, CEO OpenRemote
