If you have any plans getting involved with the Internet of Things (IoT), chances are that you will come across the term “IoT platforms”. This article describes some of the most common questions regarding these platforms, such as what they are used for, how they differ from each other and what you should consider before selecting one.
Which role does an IoT platform play in the overall IoT architecture?
IoT spans a lot of areas, but most IoT solutions have four major building blocks in common:
1) Data collection (via sensors, devices, gateways, APIs, humans etc.).
2) Some (wireless) infrastructure or network to transmit the data from the sensor.
3) An IoT platform where data is collected, analyzed and from where devices often can be managed to some extent.
4) An application layer (dashboard, mobile app, API for integration to other systems, services platform, ERP or sales systems etc.).
What else can an IoT platform do?
Apart from the basic stuff described above, many IoT platforms can also do a lot of other tricks. Examples:
– Store, normalize and filter data.
– Represent data sources and objects/humans/places in logical object models.
– Analyze and build logics between the collected data to automate a process, create an alarm etc. based on rules that you can define yourself.
– Present data in dashboards/maps/portals or publish it through (open or industry-specific) Application Programming Interfaces (APIs).
– Perform device management of sensors, devices and gateways.
– Manage and monitor (SIM) connectivity and data plans.
– Perform more advanced cognitive tasks, AI and machine learning based on collected data. This is sometimes offered as modules.
– Offer connectivity plan and subscription management, especially for SIM cards.
– Offer multi-tenancy support so that you can define who should get access to what kind of data.
– Billing management.
Why is the IoT platform landscape complex to understand?
Some platforms can provide a lot of the above described functionality in a very narrow way, some focus on just a few aspects, some are only handling network connectivity while other platforms actually are not platforms but Lego boxes with platform pieces that you can use to build something of. Some platforms support industry standard protocols like FIWARE or FHIR. Most platforms are created for vertical reasons (see below). All platforms are mixed up in comparison matrixes for various reasons. Any platform comparison should always come with a clear definition of what is compared, but that is seldom the case. As the result, you often end up looking at fruit salads rather than apple vs. apple comparisons.
What does “vertical platform” mean?
Unlike the “regular” fixed/mobile Internet, IoT is not standards driven but application driven. Most platforms are therefore originally created for specific purposes, like optimization of an industrial process, a home burglar system, asset tracking in a hospital or disruption of the taxi industry. We refer to these platforms as “vertical” as they target specific use cases or areas. A vertical platform comes with a well-defined ecosystem of supported devices, sensors and gateways from certain vendors. These platforms are seldomly interconnected to other vertical platforms (IoT really means Intranet of Things in most cases). As there are no well-spread open standards for device management, adding more sensors to a vertical platform later on may be costly in time and pesos. Vertical platform integration (for IoT or anything else) often gets exponentially complex with the number of involved systems. The reason is that API integration is a per-platform game due to poor standardization.
While vertical platforms often solve the tasks they are created for, they also come with scalability issues and lock-in effects. When you go for a vertical solution, always take the northbound APIs into consideration. You should be able to not only receive data from a vertical solution, but ideally also have device management control. A simple example is a street light system where you want to be able to not only read out data from the lights but also be able to dim them and turn them on and off. If you are a municipality or a large corporation, specifying the APIs here as part of a procurement process is key to be able to grow with solutions over time. It is actually more important than the platform selection. Also look out for any platform provider who is charging “per device” and/or “per Byte of storage”. Those kinds of models work well in proof of concepts, but you could end up with a non-scalable and costly infrastructure in the end.
I have heard about horizontal platforms. What is that?
The main task for a horizontal platform is to aggregate and cross-connect verticals and by that also allow for data to be shared between systems in a scalable way.
The figure below shows the concepts of a horizontal platform. As each vertical only has one integration with the horizontal layer, this results in linear complexity when verticals are added, and suddenly it is possible to scale. New services can seamlessly be added and immediately reach entire populations.
Horizontal platforms are often used to aggregate vertical platforms within Smart Cities, Smart Buildings, Healthcare etc. The purpose is not only for the application layer to get access to data in an easier and more scalable way, but it also allows logics to be built between verticals without the operator having to do stuff in many systems.
Horizontal platforms are often built with the Lego bricks provided by Microsoft, AWS or Google and can therefore also natively provide dashboards, cognitive functionality, machine learning and much more over time. During 2018 we saw several very capable open source platforms emerging. This will over time remove “per device and per Byte” cost for collecting data from sensors.
A properly built horizontal platform is the foundation for a scalable platform economy that can enable enormous values for a city, a hospital, a population or an entire nation. A good example is the X-Road system which is the (Blockchain based) e-health backbone for both Estonia and Finland.
Now, can you tell me which platform I should choose?
As the bullets above hopefully have described, various platforms solve different tasks and are created for different purposes. There is not one size fits all, and it is not possible to tell which vertical platform that is most suitable for a specific application or task without knowing what that application looks like. A general recommendation is to look at the open source communities early in a process. Several such platforms are very mature and allows you to start off building business from day one rather than spending time on development.
Another important thing to consider is that a lot of people who today are spending time on IoT probably instead should focus on the foundation of data collection and define what APIs should look like. If your patient data ends up in 20 different healthcare systems that you cannot access, you will never be able to use that data in an efficient and innovative way regardless of platform choice.
And that sums up where you should always start with IoT. Before picking a platform, a radio standard or a sensor you need to understand the use cases, business cases, problems to be solved, opportunities, humans, needs, business impact analysis and much more. Too often things are done the other way around.