The Internet of Things arguably constitutes the mega-trend of our present time. In fact, it is such a big thing that one can easily spot trends within the trend — one of which is the boom of IoT platforms.
Can You Define That?
So what exactly is an IoT platform? A little research shows that different vendors offer very different products under this label. Therefore, a common definition would have to be about as vague as the following attempt:
An IoT platform is a toolkit comprised of software components, hardware components, and/or infrastructure components (or services) such that
- Generic functionality that is typically required for IoT products is already covered by the toolkit — it does not need to be constructed from scratch, but can be set up in significantly less time.
- Specific functionality that is required for a given IoT product can be added as needed.
Admittedly, I am not happy with this attempt at all. Despite its overall vagueness, the above definition most likely still won’t cover all the IoT platforms out there today. Plus, it is already broad enough to include items that are certainly out of scope (for example, the Internet itself is infrastructure that offers some generic functionality required for IoT products and can be used for specific purposes as well, but nobody would seriously want to call the Internet an IoT platform).
The Goal and the Path
Either way, the goal and business value of IoT platforms is a rather intuitive classic: Since IoT products have certain aspects in common, we do not want to solve these common aspects from scratch in every new IoT project. It really is as easy as that at the end of the day.
So, what are these aspects, or where might we find them? In order to see that, let us perform a shallow, first-level breakdown of IoT products: Practically by definition, IoT systems involve devices (things) and a backend that communicates with these. Moreover, they often include frontends that allow users to observe or control the devices — or to access services based on the data collected in the backend. The following schematical figure subsumes these considerations:
The list of aspects could easily be extended. Many IoT systems, for instance, rely on gateways to connect devices to the internet. As another example, proper communication protocols are an important building block for IoT products.
A Typology of IoT platforms
Since there are so many IoT platforms out there and they come in so many varieties, it probably makes sense to classify them. So let’s find out: What are the major compounds in the zoo of IoT platforms?
Of course, there are arbitrarily many possible ways of classifying platforms. What we are looking for in this posting, however, is a classification based on the aspects listed above. And when it comes to that, I can make out the following important types (and subtypes, depending on how you prefer to cut):
Type 3B: Backend-Only Platforms
For natural reasons, this is the class of IoT platforms you can expect from tool vendors with a focus on desktop/enterprise/server software: They come up with backend-only platforms. These platforms address issues such as scalability, cloud computing, and big data. On the downside, they practically ignore the existence of devices — those are usually assumed to be simple sensor nodes, already implemented and manufactured, that sporadically upload data to the backend by more or less magical means. That, and they offer little or no help regarding communication, integration, or just anything outside the big server machines that are supposed to run the backend.
Please don’t get me wrong: This is not to say that backend-only platforms are bad products. It’s just that they only solve a rather small portion of the entire task at hand. Hence, it is important to understand this limitation before deciding for such a platform. And in particular, it is imperative to question some euphoric marketing statements about how such platforms take away all your development troubles. Because they don’t.
Type 3A: Backend-plus-Antenna Platforms
Some vendors take the above kind of backend-centered solutions a bit further: They still ignore the device side, but their platforms at least include support for a certain set of communication standards and/or protocols. (In some cases, this class of IoT platforms also includes building blocks for gateways.) As a result, such a platform can be a good choice if the devices you want to bring to the Internet happen to exist (as in: you don’t need any more help in developing them) — and if they happen to support exactly the standard and/or protocol in question.
Type 2B: Mobile-App Platforms
Another class is comprised of IoT platforms that actually take the device side into account, but that are tied to a widespread type of devices, namely generic smartphones or tablets together with the respective software platforms — as opposed to custom devices with custom firmware. There are, for instance, platforms that only support iOS or Android devices. For obvious reasons, such platforms come in handy when your project is aimed at smartphones or tablets anyway, but they are rather useless as soon as you enter the endlessly different world of device development.
Type 2A: Hardware-Locked Platforms
A variation of the above: Platforms of this kind are not tied to a widespread type of devices, but to a standard hardware building block such as an Arduino or a Raspberry Pi. This approach may well be suitable for certain scenarios where such a generic piece of hardware incidentally meets the product requirements, and especially in rapid prototyping or feasibility studies. But again, it is really hard to imagine such an approach in the world of device development with all its hard constraints regarding manufacturing costs, power consumption, heat dissipation, construction space and the like.
Type 1: Domain-Specific Platforms
Strikingly, all the IoT platforms considered so far are defined by technology, not by business need: For the most part, they were built around existing software (e.g., Android) or hardware (e.g., Arduino) components — based on what was available or feasible at the time. Given this insight, a different type of IoT platform comes to mind, namely by taking exactly the opposite direction:
- Identify tasks that allow for a generic solution across a vast majority of all IoT projects. As a rule of thumb, this is easiest on the backend side, moderately easy on the frontend side, and hardest on the device side, especially if custom hardware comes into play.
- Identify tasks that may require a project-specific solution, but that at least allow for a common solution in one important domain.
- Now build a platform that is optimized for the given domain.
Note that the common solution mentioned in step 2 only becomes possible because the problem space (in terms of context and requirements, see below) is narrowed down drastically when we choose a particular domain.
Here at Zühlke, we gave this approach a try and built an IoT platform designed for the domain of automation engineering.
In summary it can be stated that every IoT platform considered above either ignores certain aspects of IoT systems or establishes strict constraints regarding these aspects. To put it differently: Every IoT platform either ignores some problems that need to be solved in IoT projects — or enforces predefined solutions that are only suitable under specific conditions. As I see it, the reason for this is rather simple: Since IoT is a vast topic, it is simply impossible to build the one IoT platform that fits all IoT projects. As architects of the Internet of Things, it will remain our task to choose the best platform depending on the given context and requirements.
Would you like to learn more about the Internet of Things and IoT platforms? Attend the Hannover Messe from April 25th to 29th and visit us at the Microsoft booth, Hall 7, C40! (Please feel free to make an appointment.)