Result

IoT patterns and architectures

Product-neutral reference architecture for IoT

The “IoT Patterns and Architectures” workstream developed a reference architecture (RA) for IoT solutions. Unlike most reference architectures in the commercial IoT environment, the reference architecture created by the CBA Lab members who participated in the workstream was designed from the beginning to be product-neutral, and its individual elements were designed to be reusable.

The new reference architecture will help CBA Lab member companies create their own commercial IoT solutions and assess solutions from other companies. “The reference architecture is both a guide for the development of our own IoT systems and a checklist / assessment tool for systems from IoT solution providers," says Workstream Coordinator Dr. Verena Schmidtmann from Detecon.

The workstream participants also took into account their belief that one should examine both the origins and intentions of IoT solution providers. Companies therefore need to have a neutral reference architecture geared toward the needs of users in order to be able to evaluate commercial solutions in terms of their structure and functionality as well.

The workstream presented a “clickable” PowerPoint file with an overview that contains all architecture elements and a special feature that users can click on to display clear and detailed explanations of these elements.

Because the workstream participants all had previous experience with IoT solutions and platforms, they decided to use their knowledge before the actual development work began to formulate five requirements that the reference architecture would need to meet:

1. Cross-business design for ecosystems  
IoT solutions must extend across company boundaries. For this reason, the reference architecture should include API management, integration, and connectivity features that enable it to function effectively across company boundaries.

2. Connection to enterprise IT
IoT solutions do not operate in an environment detached from “traditional” enterprise IT. IoT architectures must therefore take the associated interactions and interrelationships into account. It was also very important to the workstream participants to take into account the increasing digitalization of traditional enterprise IT. For example, very few digital business models are implemented solely via an IoT solution, as enterprise IT also plays a role here. This means that enterprise IT needs to make adjustments in line with new requirements. That’s why traditional IT architecture is also developing further, whereby the objective is for this type of architecture to contain elements of the IoT architecture in the future.

3. Incremental operating principle 
The workstream participants wanted to create a reference architecture that contains both the elements needed for pilot projects and those that play a role in company-wide IoT projects.

4. Lean design 
The reference architecture should only contain elements that are actually needed for an IoT solution. Everything that’s only “nice to have” should be left out in the early stages of the development process.

5. Reusability 
The architecture implemented on the basis of the reference architecture should contain reusable elements that support the largest possible number of the IoT use cases included in the company roadmap.

The architecture stands on three vertical pillars known as the Edge, Integration, and Enterprise tiers. Mounted across these pillars, so to speak, are the overarching functions of infrastructure management, monitoring, and engineering. There are also layers for security, API management, third-party ecosystems, and networks (see the chart below).

Because of the variety of use cases involved, the workstream participants decided to use their own experience with IoT solutions as a guide for developing the reference architecture.

There was certainly plenty of experience available, as all workstream participants had already created IoT solutions in the past.

The key conclusions reached by the workstream are as follows:

  • When choosing an IoT solution, it is important to consider the entire lifecycle of the IoT solution – i.e. development, monitoring, and operation. A significantly high degree of reusability of the IoT solution can be achieved across various use cases with regard to operation and monitoring in particular.
  • The IoT platform must be kept lean! It is important to keep this component of the IoT solution lean if you wish to ensure that the core IoT platform capabilities (e.g. for analytics and machine learning) will be reusable. Here, one should not allow themselves to be influenced too much by the wide range of solutions from providers and the extent to which one or more of these might be an exact fit for a specific IoT use case. Instead, it is important to keep in mind the range of one’s own use cases.
  • The IoT solution not only needs to be connected to the existing traditional IT world; the latter will also transform itself in order to facilitate the implementation of IoT scenarios. This fact must therefore also be taken into account when selecting and building IoT solutions.
  • API management and the necessary development of technical and business operation standards – and standards for everything in between – are essential for ensuring effective cooperation in cross-business ecosystems.
The reference architecture is both a guide for the development of our own IoT systems and a checklist / assessment tool for systems from IoT solution providers.
Dr. Verena Schmidtmann
Workstream Coordinator