Let him speak now or forever hold his peace

Central communications hub

The heart of any IoT ecosystem is the IoT platform, which carries out the core function of communicating with devices in the field. Most platforms also offer a range of ancillary basic functionality, such as firmware updates for connected hardware or archiving and analysis of data uploaded from devices. Such basic features rarely cover the full gamut of functional requirements in a given IoT use case (or application), however, as business segment- or company-specific applications are often needed as well. Business-specific functionality is typically not a feature of an IoT platform, which is primarily intended to lay the technical foundations for getting a large number of applications up and running quickly and easily.

As it provides basic functionality, an IoT platform can be used as a component in constructing an IoT ecosystem, allowing a company to focus on developing features and processes that are relevant and specific to their business, and, thus, potentially shortening time-to-market.

Occasionally, an IoT platform will cover all, or nearly all, of the requisite applications. This makes it possible to trim the interval before product launch still further but will generally involve highly-specific preconditions for device hardware and software. This may mean that it is hard or even impossible to use the hardware and software for future applications.

Looking for a needle in a haystack

But how does a company go about choosing an IoT platform? The range of functions to be offered will be an important criterion; overall requirements can be worked out from the scope of the applications envisaged. The final decision often remains a tricky one, though. There are currently hundreds of platforms on the market, with both licensed and open-source software, and it can often be difficult to pin down the exact range of functionality required. The documentation that comes with a platform can be a good starting point for a ballpark estimate but is often not clear or detailed enough to make it possible to say with 100-per-cent certainty whether a platform will be a good match for a given application.

Practical testing

Practical experience has shown that clearly identifying requirements is invariably worthwhile as a first step. You can then attempt to accommodate these in a ‘proof of concept’ (PoC) on the platform under review.

Many requirements such as secure communication between platform and devices; initial secure capture of device master data – including relevant key data; or the option to map assignments between users and devices, should be covered by the basic functionality. It is important to check whether, and to what extent, such basic functionality is offered by the relevant platform.

Many requirements are business-specific and are typically covered by another component of the IoT ecosystem rather than by the platform itself. Such business-specific requirements are important as they may in turn give rise to indirect requirements, such as timely responses to device events, for example.

Ultimately, it is important that the requirements selected do not cover the application in its entirety, as the PoC is not intended to deliver the complete application. Significance, universality and priority must be properly assessed in advance. A selection can be used to evaluate several platforms, creating a good basis for comparisons.

To cloud or not to cloud?

Setting up a PoC on too many different platforms for comparison purposes is not practicable, so making a preliminary decision based on the firm’s operational model can help to minimise cost and effort.

A lot of platforms are offered as cloud services by major vendors, such as Amazon, Microsoft and Google, providing increased levels of performance, scalability, availability and reliability. If such criteria are critical, the leading vendors have a good range of solutions. But remember, taking the leap onto an external, cloud-based platform will entail long-lasting and close partnership with, and thus dependence on, a third-party provider, and it can often prove anything but easy to break free if conditions change. In many cases, devices are deployed off site once they have been brought onstream. As such, hardware can then often only be reached via the platform, so the choice of solution is of strategic importance. The platform must be contactable throughout the entire planned life cycle of the devices, otherwise you will be faced with expensive recalls.

Client-operated platforms present an alternative to the major vendors. These can be run in a firm’s own data centre or farmed out to a third party. Operating the system in-house incurs additional expenditure but allows access to the system’s internal components, thus making fine-tuning, such as configuration of communication protocols, possible, for example. Such adjustments may be constrained by limitations in device software or hardware and are often impossible on large platforms. In addition, client-operated platforms offer better control over deployment – in the event of updates to the software, a firm can determine whether its own deployment should be brought up to date quickly or in a phased approach.

A combination of cloud-based and client-operated platforms should also not be excluded. A so-called “hybrid” model (i.e. with two platforms in the ecosystem) is absolutely possible. Critical functions such as software updates can be carried out by the firm itself, with other operations being covered by cloud-based services. Should the conditions of the IoT cloud service no longer meet requirements, a replacement can be integrated into the ecosystem. Devices would have to be updated appropriately in such a case but this should be entirely possible via self-operated and unaltered software update functionality.

Keeping an eye on the big picture

There is still no “default” platform on the market – there are numerous platforms available with widely differing core features. Making the right choice is no trivial matter and is all the more important because of this variety; when constructing an IoT ecosystem, you are potentially committing yourself for the entire life cycle of its internet-enabled devices.

There are different ways to approach such a choice, from mugging up on the platform documentation to building PoCs based on existing requirements. Experience has shown the latter approach to be the more efficient. Making comparisons equates to the first stages of developing your planned IoT ecosystem, with requirements being worked up and an initial architectural sketch of the system as a whole, including all interfaces, being developed. The resulting list of requirements will also prove a good foundation for retrospective comparisons with other platforms.

It is important to view an IoT ecosystem as holistically as possible and consider aspects such as the development of the device logic, the platform and the business applications, not to mention security and the prospective development of the system over time, from the outset. Such a comprehensive approach may be demanding but it will ensure that the system genuinely contributes to sustainable business success.