In the tech world, the word “platform” is everywhere. It’s so common; in fact, it’s becoming increasingly difficult to see consistency in use and context.
The dictionary definitions of the word have little pertinency to technology, possibly only enabling the term’s use as a metaphor for something in the digital world. It does become more relevant in various lexicons in combination with other words, like the following examples from “Dictionary.com”:
Numerous companies working in the Internet of Things space describe their offerings as some type of “IoT Platform,” which always requires some digging to understand their scope and value proposition. Most seem to find it challenging to craft taglines, pitches, etc., to frame their product well enough for someone to comprehend the depth and breadth of functionality quickly. Of course, this only makes it more critical to represent what they are selling effectively.
Combining terms to form the two categories, “IoT Hardware Platform” and “IoT Software Platform,” provides some useful context, with the former being the easiest to characterize.
IoT Hardware Platforms provide components to design, prototype, and create devices. A Printed Circuit Board (PCB) brand provides the base, with communication and interface technologies either already incorporated or easily added. There is a need for embedded software or firmware programming, but assembling hardware elements into a working device is the primary focus.
Most IoT Software Platforms (sometimes just called IoT Platforms) are cloud-based. These products vary, primarily in three aspects:
For the first, many products focus on a small subset of the architectural areas. Some platforms only provide network and device management, for example. At the other end of the spectrum, these two functions are just parts of a broad platform scope that includes things like database management, action management (rules engine), analytics, visualization, API integration, and external system interfacing. In these environments, the easy substitution of “best of breed” or customer-preferred options for some functions is a plus. Accommodating different database technologies, for example, can be significant.
When evaluating the breadth and depth of capabilities, network and device management is an appropriate analysis to perform. If a product supports LoRaWAN only, there is a limited breadth of connectivity options. Additionally, this implies less depth due to the nature of LoRaWAN. Devices are not continuously connected, cannot be triggered to respond by “downstream” requests, and, in most implementations, do not support Firmware Over The Air. There are “connectivity-agnostic” platforms with support for Bluetooth, Wi-Fi, cellular, or any other network option in sharp contrast to these single option solutions.
More frameworks, templates, and modules that exist to enable faster application construction may seem to be an obvious goal of all platforms. However, it’s best to strike a balance between the level of “low code” or “no code” construction and sufficient flexibility to meet customers’ potentially diverse needs. For example, many experts agree it is no longer necessary to program most visualizations “from scratch,” but “drag and drop” development environments often limit creativity.
When debating about what an “IoT platform” is, there will always be semantic variation. Although this may create confusion at times, the objective should be to lean towards the products with the best balance of comprehensive, flexible, and rapid capabilities as the true “IoT Platforms.”
|